ETSI's Bug Tracker - SOL001 - TOSCA-based NFV descriptors spec
View Issue Details
0008118SOL001 - TOSCA-based NFV descriptors spec[NFV Specifications] Clarificationpublic12-09-2022 09:2530-03-2023 01:41
Sujeet Banerjee 
lishi 
normalminorhave not tried
confirmedno change required 
4.2.1 
 
0008118: [MCIOP] [Section 6.8.14] Does not specify if the Helm chart maps to a multitude of OSContainers
Section 6.8.12.6 [OsContainer]
------------------------------

One OsContainerDeployableUnit (VDU) links to only one OsContainer, which in turn can specify only one artifact of type 'tosca.artifacts.nfv.SwImage'

Section 6.8.14 [MCIOP]
-----------------------
'tosca.artifacts.nfv.HelmChart' may point to an archive of helm-chart. 'associatedVdu' may point to 1 or more VDUs associated to the helm-chart.

CLARIFICAITON-1: The Helm chart has its own set of declarative intents which a Kubernetes can interpret and deploy. Then why does the VNFD need to specify the associated VDUs again. How is MANO supposed to control the behavior of Helm-Chart deployment on Kubernetes (which is scripted in the helm-charts), based on the VNDF.VDU definitions?

CLARIFICAITON-2: What if the helm archive (artifact) internally specifies more Containers/Pods than what is defined in the VNFD (VDUs)? How does one define 'dependencies' and 'affinity / anti-affinity' in the VNFD in those cases?




No tags attached.
Issue History
12-09-2022 09:25Sujeet BanerjeeNew Issue
01-11-2022 01:09lishiNote Added: 0016261
01-11-2022 01:09lishiDescription Updatedbug_revision_view_page.php?rev_id=593#r593
10-11-2022 02:26lishiAssigned To => lishi
10-11-2022 02:26lishiStatusnew => confirmed
10-11-2022 07:08Sujeet BanerjeeNote Added: 0016285
15-12-2022 09:18Sujeet BanerjeeIssue cloned: 0008166
07-03-2023 13:48lishiNote Added: 0016472
30-03-2023 01:41lishiResolutionopen => no change required

Notes
(0016261)
lishi   
01-11-2022 01:09   
Notes SOL#223:
W.r.t. issue 1: The information of assicatedVdus is necessary as this is the way how MANO can learn which Helm charts it needs to deploy. Not always needs all, it depends on the DF. Mano controls the behaviour by selecting the Helm charts to deploy.

W.r.t. issue 2: then it would be hidden from MANO, so this is not how it is supposed to be. The VNFD should contain a representation of all the pods/containers, otherwise it cannot know which resources are used by the workloads.

In both cases this is the design pattern defined in IFA
(0016285)
Sujeet Banerjee   
10-11-2022 07:08   
Issue1: There could be a case with a helm-chart may contain descriptions with dependencies amongst the MAIN / Side-car containers. The SOL001 does not offer any provision to specify ordering or dependency amongst the associatedVdus (i.e. among the OsContainerDeployableUnits corresponding to/within one helm chart). So, this would blind the orchestrator - as it would have no idea which containers within a given helm-chart to deploy first, next and so on.

Issue2: This "may be" a design pattern or/and a guideline. However, if there is a violation from the VNF provider, what ERRORs (error-code) / alt. executions a MANO is supposed to execute?

I issue is, MANO has to rely on one source of truth. If it's the helm-charts, then MANO really has no control over how/what containers inside the helm-chart would be deployed. In such case, It has two pieces of information: one from within the helm chart which is beyond MANO's control, and the second from the VNFD declarations of MCIOPs. If both information are conflicting, MANO has no idea which one to use (i.e. from the VNFD declarations or from the one coming from Kubernetes/CISM).
(0016472)
lishi   
07-03-2023 13:48   
Issue1: which containers within a given helm-chart to deploy first is based on the information described in MCIOP(e.g. Helm chart), not VNFD (i.e. OsContainerDeployableUnits).
Issue2: that issue has been studied in IFA051, please see https://docbox.etsi.org/ISG/NFV/Open/Drafts/IFA051/NFV-IFA051v006.zip [^]
for more details.