This page is for DISCSSION and DRAFTING of proposals for Anuket org and deliverables
- Proposals are WIP and both OPNFV and CNTT communities are encouraged to provide input and participate in the discussions (all ideas are welcome and good)
- This page is not intended to capture discussions about other topics which are being worked such as:
- Technical charter
- Ops guidelines
- Value prop
- Release process
Bin list of opens raised in discussions (not limited to specific proposals)
- How to structure Anuket repos
- Handling variations of an RA
- Release topics e.g. frequency, artifacts, process (planning → release), dependencies, etc.
- Dependencies between specifications (RM, RA) and implementations / tests (RIs/RCs) ... must allow for lag
Anuket Org Structure
A diagram representing Anuket org and relationships with other entities is shown below and likely to evolve. This is a high level picture to help clarify how Anuket will be organized and some relationships deemed important. Many details re. process and artifacts still need to be decided to allow the projects (specifications, implementations, conformance) to deliver on Anuket objectives.
- Original strawperson presented in 2020-10-22 Meeting Notes - Anuket Strawman Top level Structure v0.2.pptx
- Updated and presented in 2020-10-29 Meeting Minutes - Anuket Strawman Top level Structure v0.5
- Updated after meeting discussion Meld Ops and Org 2020-11-12 Meeting notes - Anuket Strawman Top level Structure v0.6.pptx
- Updated after meeting 12/10/2020 - Anuket Strawman Top level Structure v0.7.pptx (show feedback loop between spec projects and conformance projects, remove backlog management from TSC work intake)
- A single TSC
- Marketing committee separate from the TSC
- Business coordination with other technical bodies is responsibility of the TSC
What Anuket delivers as an RM
What Anuket delivers as an RA
What Anuket delivers as an RI
The RI is a known (good) instantiation of the RA
Number of RIs
Key question - should there be only one RI?
- The RI project could conceivably implement more than one known good instantiation that is faithful (conforms) to the RA.
- Each implementation may have different performance because they are running on different hardware (or different configurations of hardware, firmware or software causing infrastructure resources to be allocated differently)
- Each implementation may use different install tools and process but still end up with a setup that conforms to the RA
An RI is a set of artifacts (delivered continuously or with a release) that allows anybody to instantiate an implementation (hardware and software) that conforms to the Anuket RM and RA specifications
- There is one "cookbook" (code, scripts, recipe, etc.) available per release
- All the artifacts in a release are versioned (tagged)
- Scripts are treated like code i.e. licensed, version controlled, tested, documented, ...
- Using the release artifacts anybody can stand up an RI that behaves just like the one that the Anket RI project has instantiated
- The RI is analogous to a university project ... there are no expectations that it will be productized or used commercially.
- It is anticipated that there will be commercial solutions that are aligned with the RM/RAs. These may be referred to as "vendor RIs" but they are are not what we mean by Anuket RIs
- Anuket will not release installers but leverage them (e.g. upstream installers such as Airship, etc.)
- Install scripts released by Anuket may be interpreted as a type of installer
- Anuket scripts used to install/test the RI are not recommended by Anuket for production use however may be useful for lab/PoC purposes
What Anuket delivers as an RC
RC is a full artifact of an Anuket release, its not just used to pass a gate for getting to the release
RC release artifacts to include
- Suite of tests that express conformance
- Test tools (frameworks) and methods
- Test traceability mapping test to RM/RA requirements
- Test criteria for conformance pass / fail or quantitative results
An RI is dependent on an RC
- The RC determines if the RI conforms to the RA and RM i.e. it is a known good (faithful to RM/RA) RI
- Without the RC we cannot be sure that the RI meets the requirements of the RA and RM
An RC is not dependent on an RI
- If an RC test fails => ask what is wrong with the RI (otherwise the test is a bad test)
- We do not tailor (optimize) the RC tests around the RI
When developing the RC we must take vendor implementations into account
- Anuket should engage with vendors to determine what tests will be helpful as part of RC from both Vendor and Service Provider perspectives (agree the tests are useful for commercial purposes)
- A vendor may use many tests for development that are not run by the Service Provider as a conformance test.
RC tests must be traceable to RM and/or RA related requirements
- Tests used to stand up an RI are not automatically RC tests i.e. RI may use tests for developing the RI that are not used as an RC test
RCs must have independent lifecycles and can't be conditional (i.e. 1-to-1 mapping between RC and RA)
- Example if say Calico and Multus (two networking technologies) are mutually exclusive there should be separate RAs for each (avoid the multiple scenarios problem)
- Today the RAs have exceptions and variations - how will these be handled?
The main focus of Anuket with respect to VNF/CNFs are infrastructure interop aspects e.g. how the VNF/CNF consumes infrastructure resources.
VNF/CNF aspects such as onboarding, "cloud-nativeness", performance etc. are out of scope.
Performance was initially considered beyond the of scope of CNTT specifications. Strong feedback from SPs suggests that industry agreed methods and tools for measurement of quantitative aspects are required for evaluating and comparing Cloud infrastructure offerings as well as for planning of deployments that are informed by RM/RA specifications. For this reason we envisage RC to undertake performance related work such as benchmarking.