Anuket Org and Deliverables (Proposal)

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)

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 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

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 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

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

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.