This page is for DRAFTING proposals re. Anuket org structure and deliverables.
- Proposals are WIP and both communities are encouraged to provide input
- This page is not intended to capture discussions about proposed Anuket release process (also an important topic for discussion)
Bin list of opens from discussions (may be related but not part of proposals being discussed here)
- 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
- etc.
Anuket Org Structure
A diagram representing the new org and relationships with other entities will continue to evolve per discussions.
- 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
Most recent version of org structure proposal ...
Anuket Deliverables
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 instantiation that is faithful (conforms) to the RA. Each implementation may
- have different performance because they are each 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 or quantitative results
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)