Skip to end of banner
Go to start of banner

Anuket Org and Deliverables (Proposal)

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

This page is for DRAFTING an Anuket org structure and deliverable proposal

  • 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:
    • Governance 
      • Technical charter
      • Ops guidelines
      • TSC election process
    • Marketing
      • Mission
      • Scope
      • Value prop
    • Operations
      • Tooling
      • Release process
      • etc.


Bin list of opens raised in discussions (not limited to the specific proposals discussed here)

  1. How to structure Anuket repos
  2. Handling variations of an RA
  3. 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.
  4. ?

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. 

  1. Original strawperson presented in 2020-10-22 Meeting Notes - Anuket Strawman Top level Structure v0.2.pptx
  2. Updated and presented in 2020-10-29 Meeting Minutes - Anuket Strawman Top level Structure v0.5
  3. Updated after meeting discussion  Meld Ops and Org 2020-11-12 Meeting notes - Anuket Strawman Top level Structure v0.6.pptx

Consensus points:

  • A single TSC
  • Marketing committee separate from the TSC
  • ?


Anuket Deliverables


What Anuket delivers as an RI

Key question - should there be only one RI?

  • 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

  1. Suite of tests that express conformance
  2. Test tools (frameworks) and methods
  3. Test traceability mapping test to RM/RA requirements
  4. 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) 





  • No labels