Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
00081663GPP SA5 Bug Tracking[NFV Specifications] Clarificationpublic12-09-2022 09:2515-12-2022 09:18
ReporterSujeet Banerjee 
Assigned Tolishi 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0008166: [MCIOP] [Section 6.8.14] Does not specify if the Helm chart maps to a multitude of OSContainers
DescriptionSection 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?




TagsNo tags attached.
TS/TR Rapporteur
Source (company - Author)
TS number
TS version
Clause Reference(s)
Attached Files

- Relationships

-  Notes
(0016404)
lishi (reporter)
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
(0016405)
Sujeet Banerjee (reporter)
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).

- Issue History
Date Modified Username Field Change
15-12-2022 09:18 Sujeet Banerjee New Issue
15-12-2022 09:18 Sujeet Banerjee Issue generated from: 0008118

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker