VOLTHA Lock-In January 10 & 11, 2018

Kubernetes Goal Support deployment of VOLTA under Kubernetes Support deployment without build, via pre-built, published containers Sub-Goals Don’t invalidate support for Docker Swarm Support deployment to Kubernetes using Helm Remove pain points experienced with docker swarm mode deployments (e.g. split brain) Tasks Normalize container naming / tagging Issues State

Containerized Adapters Goal OLT and ONU adapters are run as individual containers Sub-Goals Common code will be in a “base” container from which adapters are derived GRPC or Kafka will be used as the transport between the VOLTHA core and the adapters The iAdapter interface will not be disturbed to minimize impacts to existing core and adapter code Tasks Develop the protobuf structures and GRPC calls / Kafka messages based on iAdapter requirements Implement the voltha core southbound GRPC / Kafka adapter call shim Implement the common northbound GRPC / Kafka call shim for use in the adapters Each adapter owner to transition their adapter into a container using the framework. Issues Latency / through put over “remote” interface

Containerized Adapters (cont'd) Preferred characteristics Stateless Access master data via vcore  Maintain redundant connections to OLTs HA Architectural thoughts Should there be an Adapter SDK?  OpenOMCI would be part of it. Vcore <-> Adapter communication. Established connections: Adapters expose a common GRPC API and support streaming.  Faster but requires complex HA logic Message driven:  Use an event bus (internal Kafka bus) for messaging.   Simple but slower. Should there be generic API available for adapters to expose advanced/newer capabilities?

Software Component Upgrade Goal Leverage the underlying container orchestration system Sub-Goals Component versioning Tasks Automate backup and restore Issues State versioning and migration Rollback Maintain backward compatibility

Stability Enhancements Goal Improve initial deployment success Improve restart / HA scenarios  Sub-Goals Address existing issues  Tasks Use of etcd Kubernetes migration Disaggregation of vcore into specialized services, e.g. coordinator, adapters. Separate global data from per-instance data New stateless containers for read-only requests Choose a KV store with a client API that is more responsive Issues