CNF packaging

[iawells]

We need to ensure that a CNF, with all its bits, are deliverable. We assume that many CNFs will be provided by third parties. We need a consistent install and use experience across CNFs, to avoid exploding the ops workload because we install and start and use every CNF in a unique way. This begins by ensuring they're all wrapped up in the same way.

Transfer into its running environment may need to be sneakernet, since there are some networks that are explicitly and deliberately not internet connected.

Sub-discussion: I am specifically thinking that this should include some metadata as well as the software. I need something in that package:

• Describing how to start this specific CNF (are inputs needed to a Helm chart, e.g.? Does it even start with a Helm chart?
  Which Helm chart?)
• Describing how to configure this specific CNF after it's started (Does it have a Netconf or (standardised) REST endpoint, where might I find it?)
• (perhaps) Gives me a clue as to weighty the CNF is going to be when it runs at a specific scale
• Tells me about common services that the CNF will attach to - specifically logging and metrics. These are not currently standardised. We don't have to say 'uses elasticsearch', we have to say 'emits logs in this way'.

Note in the above: I think we should be preserving the ability to change our minds about this stuff in the future. What I'm thinking here is that if the CNF documents what it does, even if there's only one choice today, it means that if we find a better way of doing this in the future we can write in the metadata that this uses the old method or the new one.

[rannyh]

We need to ensure that a CNF, with all its bits, are deliverable. We assume that many CNFs will be provided by third parties. We need a consistent install and use experience across CNFs, to avoid exploding the ops workload because we install and start and use every CNF in a unique way. This begins by ensuring they're all wrapped up in the same way.

Transfer into its running environment may need to be sneakernet, since there are some networks that are explicitly and deliberately not internet connected.

There is on-going work in the ETSI-NFV SOL004 workgroup to address CNF packaging. There is also work in the ONAP community to develop the implementation of an orchestrator that deals with those packages (https://wiki.lfnetworking.org/pages/viewpage.action?pageId=50528918&preview=/50528918/50528919/LFN-DDTF-ONAP-ETSI-Alignment%20Architecture%20for%20Honolulu-Plus-2021-2-2.pptx).

Even for those who are not big fans of ETSI-NFV, it is at least worth a look, just so the wheel is not re-invented here.

[electrocucaracha]

This has also to include the deployment or usage of private registries, specially for those cases where networks don't have internet access.