Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Stop monitoring 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
0008133SOL001 - TOSCA-based NFV descriptors spec[NFV Specifications] Feature Gappublic16-09-2022 08:3822-02-2024 09:51
ReporterSujeet Banerjee 
Assigned To 
Prioritynormal 
StatusconfirmedResolutionno change required 
Product Version4.2.1 
Target VersionFixed in Version 
Summary0008133: [V4.3.1] [Claim 6.8.13.2] Property 'mcio_constraint_params' in Vdu.OsContainerDeployableUnit is irrelevant and CONFLICTING
DescriptionThe valid values for 'mcio_constraint_params' as given below are irrlevant:

- affinity_nfvi_pop
- affinity_zone
- affinity_zone_group
- affinity_nfvi_node
- affinity_cis_node
- anti_affinity_nfvi_pop
- anti_affinity_zone
- anti_affinity_zone_group
- anti_affinity_nfvi_node
- anti_affinity_cis_node
- local_affinity_nfvi_pop
- local_affinity_zone
- local_affinity_zoneGroup
- local_affinity_nfvi_node
- local_affinity_cis_node
- local_anti_affinity_nfvi_pop
- local_anti_affinity_zone
- local_anti_affinity_zone_group
- local_anti_affinity_nfvi_node
- local_anti_affinity_cis_node

That is because, the placement constraints can be specified CORRECTLY using the policies: "AffinityRule" / "AntiaffinityRule" (Clause 6.10.10)

The property 'mcio_constraint_params' may be CONFLICTING because, it does not specify, say in case of affinity GROUPS (e.g. affinity_cis_node), how more than one SETs of VDUs can be placed into more than one groupings.
Additional InformationThese allowed values of 'mcio_constraint_params' are irrelevant as well:
- node_additional_capability_ssd
- node_additional_capability_dpdk
- node_additional_capability_sriov
- node_additional_capability_gpu
- node_additional_capability_fpga
- node_additional_capability_cpu_pin
- node_capability_logical_numa
- node_pool

That's because, these are NOT contraints. They are indeed requirements for additional capabilities, and can be specified using other properties of Vdu.OsContainerDeployableUnit, eg. "requested_additional_capabilities" and/or "logical_node" (clause 6.8.13.2)
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0016474)
Sujeet Banerjee (reporter)
18-04-2023 11:27
edited on: 19-04-2023 11:27

 IFA011 specifies the Enums listed above.

However, there are no associated configurations for the attribute "mcio_contraint_params".

For instance, with "node_additional_capability_dpdk" specified, there is not way / associated config for the Orchestrator to know the details of the underlying VLAN (or SDN resources) to use, in case there are more than one choices in the NFVI/CSI.
(0016493)
martindenico (reporter)
06-07-2023 08:31

 W.r.t. the comment on affinity related properties, the mcio_constraint_params are relevant and necessary to fulfill the affinity requirements.

These are expressed with the affinity properties, correct, but the (anti-)affinity has to be enforced by k8s, the NFVO cannot as it is not responsible to select the specific CIS node for each pod.

With these properties, the VNFD is indicating that the NFVO has to provide a label in the grant response to be injected in the Helm chart to realize this affinity requirement. Then the Helm charts have to be designed to be able to receive a label in an input parameter, to be assigned to a specific key in the affinity or placement rules in the k8s manifests, e.g. in the topologyKey.
(0016494)
martindenico (reporter)
06-07-2023 08:35

 W.r.t. the comment on properties related to specific HW capabilities, it is a similar reason. The requirement for a specific capability is expressed usually with another VNFD property, correct. But it has to be k8s that enforces the placement of the pod in a node that has that capability, the NFVO is not responsible to indicate the specific node.

So with the parameter, the VNFD is indicating that in expects from the NFVO a label as an input parameter to be injected in the Helm chart. The value would be e.g. the label that has been assigned in the cluster to nodes that support the required capability.

In both cases, the NFVO has to be aware of the labels assigned in the cluster.

I hope this clarifies.
(0016497)
Sujeet Banerjee (reporter)
13-07-2023 08:07

 >In both cases, the NFVO has to be aware of the labels assigned in the cluster.

I see a few cases this may not work:

1. The cluster/node labels may not be the same as (or one of) those defined in list (Claim 6.8.13.2).

2. There is a likelihood that the values in other attributes (e.g. nfvi-constraints, and/or requested_additional_capabilities, and/or logical-node, affinity/antiaffinity policies defined in the VNFD) may be conflicting with the labels defined under 'mcio_constraint_params' - owing to human errors.

3. There is *no* provision in the VNFD to specify "which specific key or a set-of-keys defined in the helm charts, would be mapped to a (or more) given mcio constraint Enum". The designer of the helm charts may make a provision for accepting labels, but where does the VNFD declare the corresponding key?

- Issue History
Date Modified Username Field Change
16-09-2022 08:38 Sujeet Banerjee New Issue
15-12-2022 09:18 Sujeet Banerjee Issue cloned: 0008175
18-04-2023 11:27 Sujeet Banerjee Note Added: 0016474
18-04-2023 11:31 Sujeet Banerjee Note Edited: 0016474 View Revisions
19-04-2023 11:27 Sujeet Banerjee Note Edited: 0016474 View Revisions
06-07-2023 08:31 martindenico Note Added: 0016493
06-07-2023 08:35 martindenico Note Added: 0016494
13-07-2023 08:07 Sujeet Banerjee Note Added: 0016497
22-02-2024 09:51 lishi Status new => confirmed
22-02-2024 09:51 lishi Resolution open => no change required

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