You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 26 Next »

G-release (Q1-Q2 2022)

Storage

  1. NVMe/Vhost
    • Prototype
      • Implement creation of data queues
      • Rework Admin queue creation – move away from hardcoded implementation
      • Implement the minimum set of commands required to operate under linux
      • Implement Shadow Queue
      • Make sure works with Windows
    • Harden the prototype
      • Submit RFC patches to the mailing list once Prototype phase is ready
      • Address comments, work on cleaning up hacks
      • Run correctness tests, implement any missing bits an pieces
  2. ZFS
    • First official support
      • Revise current storage health reporting in Eve OS
      • Add
        • Reporting multiple disks
        • S.M.A.R.T reporting
        • Zpool status errors
      • Enable reporting in the cloud
    • Zvol direct-io evaluation
      • Based on Delphix efforts presented on OpenZFS Dev Summit 2021
    • Async DMU / Async CoW
      • Deferring the reads so writes are not blocked
    • Online pool grow
      • If more disks added to the pool

Networking

  1. NIM + zedrouter refactoring
    • Generically solve the state reconciliation problem (will be applicable not only for network config management)
    • Better separation of concerns (more sub-components inside)
    • Improve robustness, readability and extensibility
  2. VLAN and LAG support
    • Support VLAN+LAG for EVE management and local network instances
    • Should be a lot easier to do after the refactoring
  3. Support Jumbo frames
  4. Expose GPS data to controller and applications (from GPS which is part of the LTE modem)
  5. Network Instance VRFs
    • Isolate network instances on the L3 layer
    • Should be a lot easier to do after the refactoring
  6. Network performance testing
    • Prepare lab for network performance testing
  7. SR-IOV support

Testing/Validation

Release Engineering

  1. Info
    1. Monthly Video about EVE 
    2. Release notes distribution
  2. CI/CD
    1. Github Actions refactoring 
    2. Implement performance benchmarking CI/CD
    3. Speed up the GH Actions 
    4. Deploy DataDog CI 
    5. ROL and Github Actions integration
    6. DockerHub account verification
    7. Github Account Verification
    8. Add Github Registry 


Security

  1. Enable scalable enforcement of TPM PCR values on controller (PCR values should be the same when the hardware, firmware, config, and EVE are the same)
  2. Explore Linux Integrity Measurement Architecture (IMA) with the TPM
  3. Signed images from the release engineering process including the kernel SHA for the TPM PCRs

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 - https://github.com/lf-edge/eve/pull/2023)
  • 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