This page is being used for DRAFTING an Anuket org structure that will be proposed to CNTT an OPNFV. The contents is WIP and anybody is welcome to provide input here.
A diagram representing the new org and relationships with other entities will continue to evolve as discussions progress.
- 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
Open issues:
- how to structure Anuket repos
- Handling of RA variations
- Dependencies between specifications (RM, RA), RIs and RCs ... must allow for a lag
What Anuket delivers as an RI
Key question - should there be only one?
- The RI is a known (good) instantiation of the RA
- The RI project could conceivably implement more than one known good instantiations that are faithful (conforms) to the RA however ...
- have different performance because they are running on different hardware
- use different install tools but end up with an identical setup and configuration
An RI is a set of artifacts delivered per release that allows anybody to instantiate an implementation of hw/sw that conforms to the Anuket RM and RA
- There is one "cookbook" (code, scripts, recipe, etc.) per release
- All the artifacts in a release must be 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
- It is anticipated that there will be commercial solutions that are aligned with the RM/RAs but these are not Anuket RIs
Installers
- 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
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
- We do not tailor (optimize) the RC tests around the RI
When developing the RC we must take vendor implementations into account i.e. engage with vendors
All RC tests must be traceable to RM/RA requirements
- Tests used to stand up an RI are not automatically RC tests
RC is a full artifact of an Anuket release, its not just used to pass a gate
RC release includes
- 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
RC1 and RC2 must have independent lifecycles and can't be conditional
- Example if Calico and Multus are mutually exclusive there must be separate RAs for each
- If a CNF works with Calico but not with Flannel conformance test cannot be conditional
- Today the RAs have exceptions and variations - how will these be handled
Main concern of Anuket re. VNF/CNFs is interop with the infrastructure (other aspects e.g. onboarding is out of scope)