Versions Compared

Old Version 7

changes.mady.by.user Trevor Cooper

Saved on

compared with

New Version 8

changes.mady.by.user Trevor Cooper

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 processTSC 
    • 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. ?

...

  • 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

Key question - should there be only one 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 mayhave may have different performance because they are each running on different hardware (or different configurations of hardware, firmware or software causing infrastructure resources to be allocated differently)
  • Each implementation may use use different install tools and process but still end up with an identical setup and configurationa setup that conforms to the RA

RI Artifacts

An RI is a set of artifacts (delivered per continuously or with a release) that allows anybody to instantiate an implementation of hw/sw (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 must be 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 but these are not  Anuket . 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

...

  • 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 i.e.

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

All RC tests must be traceable to RM and/or RA related 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
  • tests i.e. RI may use tests for developing the RI that are not used as an RC test

RCs RC1 and RC2 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 must should be separate RAs for each If a CNF works with Calico but not with Flannel conformance test cannot be conditional 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 Main concern of Anuket re. VNF/CNFs is interop with the infrastructure (other are infrastructure interop aspects e.g. onboarding is out of scope) 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.