...
- Various types of container implementations
- Performance, security, other aspects of container improvement
- Orchestration : Kubernetes (auto deployment, scaling, management etc.), Kubernetes + Openstack (including Kubernetes on Openstack, and other variations)
- Integration of these upstream components
- Goal is to move the integration process to XCI style continuous integration with both Openstack and Kubernetes
+ Currently the integration and testing work happens in several tracks within OPNFV
...
Establish a coordinated effort to produce a common figuration configuration that can be jointly tested and promoted into a high quality system that is consumable to (a) users who seek convenience for NFV use cases (b) developers/users in other projects who can leverage OPNFV's work (e.g. ONAP) (c) other developers who want to build other higher layer software on the top.
...
- There are many aspects of container networking, some involve VNF data path, but many don't. (Note: the phrase "data path" is ambiguous).
- For the normal case, we should stay fully faithful to Kubernetes and CNCF, and participate in the ongoing efforts there (upstream first). This should be our baseline in producing a consumable Kubernetes configuration (see Recommendation #1).
- For the bump-in-the-wire case, various acceleration designs have been proposed/developed, OPNFV should work with related projects to test/validate their applicability with respect to solving user's demonstrated requirements. Some of these are based on ongoing data path work within OPNFV and projects within LFN (e.g. ligato/FD.IO ), and others in open source community (e.g. Linux BPF). These acceleration methods are critical to many NFV use cases, but we should not mix importance with maturity, the promotion of these features should be gated with a neutral set of test cases. Doing so is not to demote its importance, but to give space and freedom in its development so those projects can move faster.
- We are not here to "choose", but provide a consistent validation process to test features, gauge maturity, and help down-stream to consume these features in an easier way. All implementations solutions demonstrated benefits and maturity should be promoted to the same level.
Recommendation #2:To be continued...
Encourage testing projects to develop consistent test methodologies for container networking. Build these test methods into CI/CD/XCI test and promotion pipeline (see Recommendation #1).
Encourage OPNFV integration projects and the upstream projects to contribute the necessary integration and testing work in OPNFV to realize this pipeline for all of the LFN community.
3) Micro-services support
- Micro-service service mesh
- Micro-service visibility/data collection and analysis, and related tools and automation methods
- Tools for best practice of micro-services
- Software (micro-services) components commonly needed for NFV use cases
- Test methodologies and tools in the micro-service/cloud native approach
...
The work here has been started in the Clover project. We encourage more community participation in advancing these goals.
4) Cloud native continuous deployment (CD)
- One of the integral part of being cloud native software is its continuous deployment (Note: Continuous Deployment is a distinct process from the other use of CD in OPNFV.)
- We should extend current CI (strictly speaking XCI is still CI, just for clarification of terminology) to new CD for cloud native software. See this proposal from the ONS Technical Forum: Extending CI/CD to support Cloud Native VNFs and Operations.
- Note that this toolchain works for both containers and VMs - one can adopt this style of CD for VM as well - however, the initial objective should be focused on container first.
- Will require "long lasting computing resources" - this can be current UNH pods being allocated for this purpose, Pharos-pods dedicated for this purpose, virtual public cloud (GCE, AWS, ...) paid for for this purpose, or new resources.
- Software tools and automated tests that implement this CD pipeline.
5) Concrete use cases and sample applications
- Use case driven (user/customer driven) is an important way to make OPNFV more relevant to customer needs and be more "consumable".
- Work cross project to identify common priority use cases. Future deployment should be a focus for us as today's commercial deployment has yet to adopt cloud native in large scale.
- One of the outcome of these sample VNFs should be a best practice document helping the community/vendors/customers understand the challenges involved and best methodology of moving to cloud native.
6) Cross project collaborations
- ONAP also aims to move to cloud native. We need to position OPNFV in helping ONAP achieve their goals without unnecessary replication.
- FD.IO has goals in high performance data path for cloud native VNFs. We should investigate best way to integrate that as one of the acceleration methods.
- The CD (continuous deployment) initiative is applicable for all projects within LFN, and related to upstream (CNCF, Openstack), and of course the XCI initiative, Lab-as-a-service/Pharos etc.
- Cloud native is a general theme that we should push together in LFN.
Related projects in OPNFV:
...