...
- The RI is a known (good) instantiation of the RA
- The RI project could conceivably implement two more than one known good instantiations that are faithful to (conforms) to the RA however ...
- have different performance because they are running on different hardware
- use different install tools but end up with an identical setup and configuration
...
- 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 which are out of scope (Fuel, Airship but leverage them (e.g. upstream installers such as Airship, etc.)
- Install scripts released by Anuket may be interpreted as a type of installer ... that is ok
- 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
...
- The RC determines if the RI conforms to the RA and RM (i.e. it is a known good RI(faithful to RM/RA) RI)
- Without the RC we cannot be sure that the RI meets the requirements of the RA and RM
...
- 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)