Page tree
Skip to end of metadata
Go to start of metadata

D-release (Q4, 2020)

  • Measured boot and Remote Attestation to the controller
  • Encrypted disk vault keys sealed under the TPM PCR values
  • End-to-end security even with content inspecting proxies
  • Off-line support - verify that applications come up even if there is no connectivity to the controller
  • Off-line support - user-setable reset/reboot time if connectivity is lost to controller (to recover from hung network adapters)
  • App side-loading/pre-loading by being able to specify content trees independent of volume creation
  • Use containerd as Content Addressible Storage for containers, VM and EVE images
  • Verify device passthrough for primary video adapter
  • Provide an API so Azure IoT edge workload can report status/metrics for the running modules via EVE to controller
  • Non-virtio emulation of devices
  • Reduce EVE memory footprint (single zedbox process for most microservices); apply C-group controls
  • Experimental support for ZFS for the /persist filesystem including encryption

E-release (Target : Q1 2021)

  • New EVE Logging Infrastructure (replace rsyslogd with simpler and more robust logging)
  • Make IP geolocation more robust by moving to controller
  • Enable deploying K3S workloads (including shared switch network instances to avoid NAT)
  • Download EVE as OCI (one layer so far)
  • Initial monitoring support for applications (crash, hang, ...)

F-release (Target : Q2 2021) TBD: add link to GH issue for each item

  • Next generation storage architecture (design approved; in progress)
  • Extract and report GPS coordinates to controller (if device has a cellular modem with GPS) (proposed)
  • Incremental image download (rsync-like) (proposed)
  • Better enforcement of volume size limits for the OCI-derived volumes (proposed - after storage rework)
  • EVE self-monitor and log memory and disk usage increases - (first cut done
  • EVE report more hardware counters? (e.g., disk/SSD S.M.A.R.T counters) (proposed)
  • Combine eve, adam, and eden and just call it "eve"? Commands then looks like: "eve pod deploy ...", "eve generate server", ... and maybe after all the config is done, a command like "eve generate image" could be used to create an EVE-OS image for a specific board or hw arch (proposed)
  • Expand EVE test coverage to improve overall stability: performance under stress; search for security vulnerabilities; automated code analysis; board farm daily and release testing (proposed)
  • Controlling "VM bundles" (see below for a bigger scope around Local Controller) via "run profiles"
    • Controller feature to define the run-profiles, will allow customer to define the set of VMs that form their applications
    • Modifiable via MetaData APIs
    • User-owned APP responsibled for providing a local API endpoint on the box
  • "VM bundle" VM version selection
  • Hardening USB passthrough
  • Hardening GPU passthrough
  • Custom CA for HTTPs downloads
  • GCP data store
  • USB or SAN datastore

Future - to be planned

  • Support multiple disks using different forms of RAID configurations (might use ZFS)
  • Tailscale integration?
  • Build EVE as OCI layers (reduces size of EVE update downloads)
  • Local Controller
    • EVE toolkit (AKA MetaData server): read-only endpoints, protected by access control, physical access to the system required
      • Extending meta-data server API’s
      • provide local access to system metrics
      • provide a local access to change the run-profiles
    • HW Level metrics (IPMI-like): could be part of the above
  • CPU affinity
    • Controlling "VM bundles"
  • Infrastructure as code (Teraform plugin?)
  • Snapshot/differential VM upgrades
  • OCI observability
    • coredumps
    • crashkernel
  • Sensor I/O virtualization
  • Target upstream component for the next release
    • Alpine
    • Linux Kernel
    • Xen
    • Qemu
    • Golang
  • No labels