This page is the original Clover project proposal. Please refer to the project wiki main page for up to date information: Clover Home.
Proposed name for the project: clover
Proposed name for the repository: clover
- Monolithic infrastructure slows development and constrains scalability and reliability, so the industry has been trending on micro-services based architecture [micro-services]. Growth of micro-services, however, often leads to ‘container sprawl’: service-to-service communication becomes unwieldy and hard to manage; integration and testing permutations quickly multiply; uniform policy enforcement becomes a lot harder…These issues can be esp. prominent in service provider and NFV use cases. A dedicated service layer (Service Mesh) agnostic to individual app and deployment and built on top of k8s’s existing pod and service constructs and orchestrator functions, is designed to overcome these challenges.
- The service providers found operating a large set of micro-services challenging without a common set of tools that give them visibility and traceability. This challenge is esp. relevant when applications are developed independently (by different teams, vendors or communities), or e.g. legacy software components are containerized and brought in to the mix. A common set of reusable services, such as monitoring, logging, tracing…, agnostic to development and deployment environments is needed. NFV specific use cases may demand additional common utility services that are outside of the general computing applications. Such reusable services may include network tracing, nat, dpi etc.
- Continuous delivery – a core benefit of cloud native applications is that its components (micro-services) can be updated live independently. Currently CI/CD pipeline in OPNFV largely stops at CI level. Building safe, low risk, platform independent and at-scale continuous deployment is an important challenge facing NFV use cases. We need to address it in collaboration with xci/releng and upstream e.g. cncf cross-cloud ci.
- NFV specific use cases introduce new challenges to solve that are different from the general cloud native cases. E.g. network needs for gateway (intermediate systems) common in NFV use cases, potential network performance issues, security issues, edge related challenges, in collaboration with edge related projects, enhancements or additional common services for NFV and necessary interfacing with other OPNFV or LFNF projects (e.g. ONAP).
To meet the above challenges, the Clover project intends to integrate and test a cloud native computing framework for NFV use cases, based on CNCF and other upstream components and cloud native computing community’s best methodologies and tools.
Cloud native computing technology can be very beneficial to NFV in terms of elasticity, scalability, dynamism, resilience, simplified operation, among others. In the area of edge NFV, it also has the benefit of being more lightweight. Although cloud native may not be suitable in all use cases, it can clearly be an important addition to the OPNFV solutions. So best practice solutions to the challenges identified above are critically important for supporting cloud native technology in NFV.
Clover will require Kubernetes, which can be the output of other OPNFV projects, e.g. container4nfv or XCI or other k8s scenarios. It will also be transparent to Clover if Kubernetes runs natively in bare metal or on Openstack virtual machines or other underlying cloud computing platforms (like AWS, GCE, …).
Existing OPNFV projects support Kubernetes and containers as a foundation. Clover intends to solve problems that arise from adopting cloud native computing in scale, to better support cloud native computing for NFV virtual functions. We've identified a micro-services service mesh framework, common agnostic reusable services (logging, tracing, monitoring,...), nfv specific requirements (e.g. light-weight edge support, gateway mode support, security enhancements, additional nfv common services), continuous deployment that is optimal for cloud native micro-service based deployments... and make these capabilities easier to use for NFV.
Gap analysis and upstream engagement as necessary
It will be integrated with OPNFV XCI or classic CI/CD, upstream initiative e.g. cross cloud ci, and be extended towards continuous deployment.
Testing will be implemented by automation with supported platforms and integrated with OPNFV testing infrastructure. Sample cloud native use cases will be developed or dopted for fulfilling testing and validation needs. Will support live debugging and tracing.
Client console may also be integrated/developed for ease of use.
Foundation/infrastructure layer support of Openstack or Kubernetes (VIM and orchestration) or Docker are out of scope. We rely on existing OPNFV or other projects, such as container4nfv or XCI, for bringing up the prerequisite foundation.
Edge NFV is a common use case for containers, we will demonstrate suitability to support edge use cases, but we do not intend to cover the actual edge systems as in, e.g. ENFV project or the Multi-Access Edge project proposal. Clover intends to solicitate collaboration ideas with these projects.
Deliver the solution in a k8s- scenario.
Future extensibility of the project will depend on user and developer community feedbacks.
We intend to develop fully automated unit test and integration test that can be incorporated in OPNFV testing infrastructure.
QA and test resources can be existing OPNFV Pharos labs, future OPNFV Lab-as-a-Service, virtual machines in a developer’s laptop, or common cloud services such as aws and gce.
Introductory and developer oriented documentations are to be developed.
Clover depends on Kubernetes and other projects in CNCF and other upstream communities.
Depends on either an OPNFV project or XCI scenario or another tool to bring up common k8s support or Openstack support.
Depends on some Pharos community or Lab-aaS computing resources, although we intend to make developers able to use a local laptop or public cloud services as well.
Container4nfv (aka OpenRetriever) is a comprehensive container and orchestration project in OPNFV. Clover can use the output of container4nfv and is complimentary in scope (OpenRetriever's Scope).There are also other k8s scenarios in OPNFV.
Collaborations with AUTO, Models, on related deliverables
- Additional dependencies (or gaps) in areas such as storage, edge cases, performance tools etc may become more concrete when we investigate further.
Names and affiliations of the committers
Stephen Wong (Huawei)
Wenjing Chu (Huawei) Wenjing Chu
Dave Neary (Red Hat) Dave Neary
Xuan Jia (CMCC) Xuan Jia
Yujun Zhang (ZTE) Yujun Zhang
… being populated
Names and affiliations of any other contributors
Andrew Theurer (Red Hat)
… being populated
- A new scenario based on k8s integrating micro-service oriented core services
- Service mesh
- common reusable services: Monitoring, logging, tracing
- Networking (from infrastructure)
- Additional services
- Cloud native CD and testing linkage with opnfv dev infrastructure
- Automated testing of resiliency, scalability …
- Best practices for cloud native application development
- Example use cases, sample and test containers
Upstream patches to relevant upstream projects to address gaps identified and solved
Proposed Release Schedule:
The first release planned: Fraser
Tentative deliverables for the Fraser release
Clover core services
Development and test platforms
At least one use case and test cases
Will this align with the current release cadence
Key Project Facts
Project Name: Clover (clover)
Repo name: clover
Lifecycle State: Incubation
Primary Contact: Wenjing Chu, firstname.lastname@example.org
Project Lead: Stephen Wong, email@example.com
Jira Project Name: Same as Project name : clover
Jira Project Prefix: [10 Characters max [A-Z] ] CLOVER
mailing list tag [Should match Jira Project Prefix] Clover
*Link to TSC approval: TBD
Link to approval of additional submitters: TBD