Hi,
Question to Marton: why would the properties from the substitution template need to go up to the abstract node ?
The VNFM has access to the entire substitution template and as long as those properties are specified in a consistent and standardized way the VNFM should be able to find them.
BR,
/Calin
From: <
tosca@lists.oasis-open.org> on behalf of Chris Lauwers <
lauwers@ubicity.com>
Date: Monday, 17 December 2018 at 00:50
To: "Marton, Gabor (Nokia - HU/Budapest)" <
gabor.marton@nokia.com>, "tosca@lists.oasis-open.org" <
tosca@lists.oasis-open.org>
Subject: [tosca] RE: Question on mandatory properties vs. node type substitution
Hi Gabor,
Thanks for the explanation, since this may not be a proper use of substitution mappings. Specifically, substitution mapping does not provide an ability for the substituting template to set property values in the substituted node.
If I understand your use case, then the correct way to communicate resource requirements back to the NFVO is by using, well, requirements:
Consider an abstract VNF node template that needs to be substituted
Presumably, a specific flavor_id will be provided as a property value of the abstract VNF node.
Based on the value of the flavor_id, the orchestrator will select the appropriate substituting template
The substituting template presumably will use TOSCA requirements to express its resource requirements. These resource requirements must not be communicated back to the substituted node as property values. Instead, they need to remain as requirements that need
to be fulfilled by the orchestrator.
Is this inconsistent with the ETSI spec?
Thanks,
Chris
From: Marton, Gabor (Nokia - HU/Budapest) <
gabor.marton@nokia.com>
Sent: Saturday, December 15, 2018 12:46 PM
To: Chris Lauwers <
lauwers@ubicity.com>;
tosca@lists.oasis-open.org Subject: RE: Question on mandatory properties vs. node type substitution
Hi Chris,
thanks a lot for your response.
The scenario is about setting a property value in an abstract node by a substituting template, i.e. bottom-up. This unusual need, like a number of others discussed with you and other TOSCA experts in relation to ETSI
NFV SOL001 (VNF descritor, NS descriptor), comes from the unusual use of TOSCA: a VNFD is
at the same time (1) a descriptor with read-only /output values for informing the NFVO about the resource requirements of a VNF so that the NFVO can do necessary resource allocations and granting, and (2) a declarative descriptor with input values to
the VNFM for defining the workload to be managed. We ended up with a VNF node type of which one property (flavour_id) is top-down (2) whereas others (flavour_description, descriptor_id, ) are bottom-up (1).
Wishing you a Merry Christmas and a Happy New Year,
GÃbor
p.s.: back in the office from 3 January.
From: Chris Lauwers <
lauwers@ubicity.com >
Sent: Tuesday, December 11, 2018 6:42 AM
To: Marton, Gabor (Nokia - HU/Budapest) <
gabor.marton@nokia.com >;
tosca@lists.oasis-open.org Subject: RE: Question on mandatory properties vs. node type substitution
Hi Gabor,
Apologies for the late reply.
I m not sure if I understand your scenario correctly, but in general, property values in an abstract node will never be set by a substituting template. The must be set in the top-level template that includes the abstract node (e.g. using
get_input functions) and then these values will be propagated to inputs of the substituting template (assuming the property mappings are set up correctly).
Of course, since each property is automatically reflected in a corresponding attribute with the same name, the attribute values will get retrieved from the substituting template (assuming outputs of the substituting template are properly
mapped onto attributes of the abstract node).
Please let me know if I misunderstood your question.
Thanks,
Chris
From:
tosca@lists.oasis-open.org <
tosca@lists.oasis-open.org >
On Behalf Of Marton, Gabor (Nokia - HU/Budapest)
Sent: Tuesday, November 06, 2018 12:52 AM
To:
tosca@lists.oasis-open.org Subject: [tosca] Question on mandatory properties vs. node type substitution
Dear TOSCA Experts,
the following question is related to a problem under discussion in the ETSI NFV SOL001 group.
In the below second service template (example-top.tosca.yaml), can the value of property_2 come from a substitution template? In other words, is the second service template valid?
example-type.tosca.yaml:
tosca_definitions_version: tosca_simple_yaml_1_2
node_types:
node_type_1:
derived_from: tosca.nodes.Root
properties:
property_1:
type: string
constraints:
- valid_values: [ value_1, value_2 ]
property_2:
type: string
example-top.tosca.yaml:
tosca_definitions_version: tosca_simple_yaml_1_2
imports:
- example-type.tosca.yaml
topology_template:
node_templates:
node_template_1:
type: node_type_1
properties:
property_1:
value_1 # property value constraint for matching
outputs:
output_1:
value: { get_property: [ node_template_1,
property_2 ] } # value_3 from the sole matching substitution
example-subst-1.tosca.yaml:
tosca_definitions_version: tosca_simple_yaml_1_2
imports:
- example-type.tosca.yaml
topology_template:
substitution_mappings:
node_type: node_type_1
properties:
property_1:
value_1
property_2: value_3
example-subst-2.tosca.yaml:
tosca_definitions_version: tosca_simple_yaml_1_2
imports:
- example-type.tosca.yaml
topology_template:
substitution_mappings:
node_type: node_type_1
properties:
property_1:
value_2
property_2: value_4
In case the second service template is invalid, we need to use a work-around which is not perfect, e.g.:
example-type.tosca.yaml (modified):
tosca_definitions_version: tosca_simple_yaml_1_2
node_types:
node_type_1:
derived_from: tosca.nodes.Root
properties:
property_1:
type: string
constraints:
- valid_values: [ value_1, value_2 ]
property_2:
type: string
default: ''
Looking forward to receiving your response,
kind regards,
GÃbor