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

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

  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 NotesAnuket 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
  4. Updated after meeting 12/10/2020Anuket Strawman Top level Structure v0.7.pptx (show feedback loop between spec projects and conformance projects, remove backlog management from TSC work intake)

Consensus points:

  • A single TSC
  • Marketing committee separate from the TSC
  • Business coordination with other technical bodies is responsibility of the TSC

Anuket Deliverables

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

RI Artifacts

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 Artifacts

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

RC Dependencies

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?

VNF/CNF Conformance

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.

Infrastructure Performance

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.

  • No labels


  1. Sorry I don't see why Anuket changes the former CNTT RC process.

    Was it discussed in CNTT RC1 and Functest which are the first groups concerned by this discussion?

    Scot Steele Would you mind adding it in CNTT RC1 agenda? it seems disconnected from the current work.

  2. Intention for this page is to focus on the Anuket org structure and deliverables. Lets keep process discussion separate for now (such as the discussion in the release meeting this morning)

    1. Why not keeping process discussion separate but we have never solved the main issue in the picture from an opensource mindset.

      The TSC and the release management become far too much important over the contributors (and their companies) which defacto impact the existing contributions and the next ones.

  3. What implication does this line have for the Airship project?

    • Anuket will not release installers but leverage them (e.g. upstream installers such as Airship, etc.)
    1. I think the original agreement w.r.t. installers out-of-scope was a CNTT agreement (someone please confirm). AIRSHIP is an Upstream project and there is an OPNFV AIRSHIP project with emphasis on CNTT RI implementation and conformance.

      IOW, I assume the bulleted text above can be tweaked to reflect reality.

  4. Scot Steele Trevor Cooper Al Morton et al.

    For me, this picture is incorrect as it puts project and contribution decisions under TSC (Backlog management, resource priorization, etc.).

    I don't see why Anuket would not take into account what ONAP and CNTT are currently leveraging from OPNFV: "Automation guidelines and tools", IaaS verification, etc.