[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] RE: Map of maps in TOSCA?
|
Chris, I think this would be good to add. Alex From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Chris Lauwers This sounds like another shortcoming in the language. Just like it should be possible to specify an entry_schema when deriving from list (or map), it should also be possible to specify an entry_schema within
another entry_schema. This would avoid the need for unnecessary levels in the data type hierarchy.
Unless anyone objects, weâll try to get this added to v1.3 Chris From: Marton, Gabor (Nokia - HU/Budapest) [mailto:gabor.marton@nokia.com]
Thanks Calin, this clarifies the picture. Seems like in v1.1, we either have an extra key (level) in the structure or we re-structure the policies according to plan âBâ. Maybe the second option is better, because the typical case is that a VDU is only used in one scaling aspect
(i.e. the aspect_deltas map would be a one-element map in most of the cases). For the record---we need to create a CR to SOL001 if we agree---, the restructured types would look like: tosca.policies.nfv.VduInitialDelta: derived_from: tosca.policies.Root properties: initial_delta: type: tosca.datatypes.nfv.VduLevel required: true targets: [ tosca.nodes.nfv.Vdu.Compute ]
tosca.policies.nfv.VduScalingAspectDeltas: derived_from: tosca.policies.Root properties: aspect: type: string required: true deltas: type: map # key: scalingDeltaId required: true entry_schema: type: tosca.datatypes.nfv.VduLevel targets: [ tosca.nodes.nfv.Vdu.Compute ] tosca.policies.nfv.VirtualLinkBitrateInitialDelta: derived_from: tosca.policies.Root properties: initial_delta: type: tosca.datatypes.nfv.VirtualLinkBitrateLevel required: true targets: [ tosca.nodes.nfv.VnfVirtualLink ] tosca.policies.nfv.VirtualLinkBitrateScalingAspectDeltas: derived_from: tosca.policies.Root properties: aspect: type: string required: true deltas: type: map # key: scalingDeltaId required: true entry_schema: type: tosca.datatypes.nfv.VirtualLinkBitrateLevel targets: [ tosca.nodes.nfv.VnfVirtualLink ] And the corresponding examples would look like: - dbBackendCapacityVduInitialDelta: type: tosca.policies.nfv.VduInitialDelta properties: initial_delta: number_of_instances: 1 targets: [ dbBackend ] - dbBackendCapacityVduScalingAspectDeltas: type: tosca.policies.nfv.VduScalingAspectDeltas properties: aspect: dbBackendCapacity deltas: delta_1: number_of_instances: 2 delta_2:
number_of_instances: 1 targets: [ dbBackend ] - internalVlBitrateInitialDelta: type: tosca.policies.nfv.VirtualLinkBitrateInitialDelta properties: initial_delta: bitrate_requirements: root: 100000000 targets: [ internalVl ] - internalVlBitrateScalingAspectDeltas: type: tosca.policies.nfv.VirtualLinkBitrateScalingAspectDeltas properties: aspect: dbBackendCapacity deltas: delta_1: bitrate_requirements: root: 100000000 targets: [ internalVl ] Greetings, GÃbor From: Calin Curescu [mailto:calin.curescu@ericsson.com]
Hi Gabor, As far as I understand you cannot have an entry_schema within an entry_schema. You can get around it in v1.1 by defining a new intermediary type like below: tosca.datatypes.nfv.ScalingDeltaMap derived_from: tosca.datatypes.Root properties: scaling_deltas: type: map # key: scalingDeltaId entry_schema: tosca.datatypes.nfv.VduLevel tosca.policies.nfv.VduScalingDeltas: derived_from: tosca.policies.Root properties: initial_delta: type: tosca.datatypes.nfv.VduLevel required: false aspect_deltas: type: map # key: aspectId required: false entry_schema: tosca.datatypes.nfv.ScalingDeltaMap targets: [ tosca.nodes.nfv.Vdu.Compute ] If we allow the v1.3 extension that Chris is proposing then we could redefine the tosca.datatypes.nfv.ScalingDeltaMap as follows thus getting rid of the âscaling_deltasâ key in the structure: tosca.datatypes.nfv.ScalingDeltaMap derived_from: map entry_schema: tosca.datatypes.nfv.VduLevel To do everything in one block that would mean to allow for anonymous type extensions in v1.3, i.e. to redefine the map type anonymously (please note the extra indentations (red) in the lines after the type assignment): tosca.policies.nfv.VduScalingDeltas: derived_from: tosca.policies.Root properties: initial_delta: type: tosca.datatypes.nfv.VduLevel required: false aspect_deltas: type: map # key: aspectId required: false entry_schema: type: map # key: scalingDeltaId
entry_schema:
type: tosca.datatypes.nfv.VduLevel targets: [ tosca.nodes.nfv.Vdu.Compute ] BR, /Calin From:
<tosca@lists.oasis-open.org> on behalf of "Marton, Gabor (Nokia - HU/Budapest)" <gabor.marton@nokia.com> Thanks, Chris. And before v1.3, is the below construct valid in v1.1? Or do we have an issue with the second entry_schema, similarly to the case of deriving from map? tosca.policies.nfv.VduScalingDeltas: derived_from: tosca.policies.Root properties: initial_delta: type: tosca.datatypes.nfv.VduLevel required: false aspect_deltas:
type: map # key: aspectId required: false
entry_schema:
type: map # key: scalingDeltaId
entry_schema: type: tosca.datatypes.nfv.VduLevel targets: [ tosca.nodes.nfv.Vdu.Compute ]
Greetings, GÃbor From: Chris Lauwers [mailto:lauwers@ubicity.com]
It is absolutely valid to derive from type map or from type list as follows: tosca.datatypes.nfv.VduAspectDeltaDetails:
derived_from: map # key scaleDelta One could to this to constrain the length of the list or the map, for example. However, what is currently not possible is to use entry_schema to constrain the types of the elements in the map or the list, but arguably it should be. We should discuss this as a possible extension in Version 1.3 Chris From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Marton, Gabor (Nokia - HU/Budapest) Arturo, I believe that it is not a valid construct in TOSCA either (having a âtype: mapâ line in a data type definitions). Excerpt from TOSCA YAML v1.1: 3.6.6.2 Grammar
Data Types have the following grammar:
Or am I misunderstanding something? Greetings, GÃbor From: Arturo Martin De Nicolas [mailto:arturo.martin-de-nicolas@ericsson.com]
Hi Gabor, Why should tosca.datatypes.nfv.VduAspectDeltaDetails be derived from map? It should be a map of VduLevel, right? tosca.datatypes.nfv.VduAspectDeltaDetails:
type: map # key scaleDelta entry_schema: type:
tosca.datatypes.nfv.VduLevel tosca.policies.nfv.VduScalingDeltas: derived_from: tosca.policies.Root properties: initial_delta: type: tosca.datatypes.nfv.VduLevel required: false aspect_deltas: type: map # key: aspectId required: false entry_schema: type:
tosca.datatypes.nfv.VduAspectDeltaDetails BR, Arturo From: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>
Hi Arturo, I cannot see a way in TOSCA to derive a data type from map. We would need something like: tosca.datatypes.nfv.VduAspectDeltaDetails:
derived_from: map entry_schema: type: tosca.datatypes.nfv.VduAspectDeltaDetails tosca.datatypes.nfv.VduAspectDeltaDetails: derived_from: tosca.datatypes.Root But even the âderived_from: mapâ line seems invalid in TOSCA (e.g. OpenStack tosca-parser says: âType "map" is not a valid typeâ), not to mention the âentry_schemaâ line. We could have one more level in the hierarchy, which would be syntactically correct in TOSCA: tosca.datatypes.nfv.VduAspectDeltaDetails: derived_from: tosca.datatypes.Root properties:
details: type: map entry_schema: type: tosca.datatypes.nfv.VduAspectDeltaDetails tosca.datatypes.nfv.VduAspectDeltaDetails: derived_from: tosca.datatypes.Root But it is not what we would like. What do you think? Greetings, GÃbor From: Arturo Martin De Nicolas [mailto:arturo.martin-de-nicolas@ericsson.com]
Hello Gabor, I agree that type of aspect_deltas, âmap of tosca.datatypes.nfv.VduLevelâ , is wrong in the table, it is not even aligned with the yaml definition
which is map of map. I think we should define a new datatype tosca.datatypes.nfv.VduAspectDeltaDetails which would be a map of
tosca.datatypes.nfv.VduLevel. Then the property aspect_deltas should be map of
tosca.datatypes.nfv.VduAspectDeltaDetails. Comments? Best regards, Arturo From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Marton, Gabor (Nokia - HU/Budapest) Hi Shitao, in fact, the âmap to tosca.datatypes.nfv.VduLevelâ Type in Table 6.10.6.2-1 is wrong: it should be âmap of
map of tosca.datatypes.nfv.VduLevelâ, because by IFA011, one can define a VduLevel per scalingDelta per ScalingAspect (one VDU may participate in multiple ScalingAspects in principle). As a plan âBâ, in case it turns out that the map of maps construct is invalid in TOSCA, we could tear the
VduScalingDeltas policy apart along two directions: (1) separate policy
types for initial delta and aspect deltas, and (2) separate policy templates for aspect deltas per aspect. I.e.: tosca.policies.nfv.VduInitialDelta: derived_from: tosca.policies.Root properties: initial_delta: type: tosca.datatypes.nfv.VduLevel required: true targets: [ tosca.nodes.nfv.Vdu.Compute ]
tosca.policies.nfv.VduScalingAspectDeltas: derived_from: tosca.policies.Root properties: aspect: type: string required: true deltas: type: map # key: scalingDeltaId required: true entry_schema: type: tosca.datatypes.nfv.VduLevel targets: [ tosca.nodes.nfv.Vdu.Compute ] # .. same separation for VirtualLinkBitrateScalingDeltas Resulting in policies like these ones: - dbBackendCapacityVduInitialDelta: type: tosca.policies.nfv.VduInitialDelta properties: initial_delta: number_of_instances: 1 targets: [ dbBackend ] - dbBackendCapacityVduScalingAspectDeltas: type: tosca.policies.nfv.VduScalingAspectDeltas properties: aspect: dbBackendCapacity deltas: delta_1: number_of_instances: 2 delta_2: number_of_instances: 1 targets: [ dbBackend ] Con: too many policies (we already have quite a few). Letâs first see what TOSCA experts respond to the original question. Greetings, GÃbor From: Lishitao [mailto:lishitao@huawei.com]
Hi Gabor Interesting topic. I did not realize it when we discussed it the ETSI NFV SOL meeting.
I just check the definition of VduScalingDeltas in SOL001, it has
Table 6.10.6.2-1: properties
Should it be defined as? tosca.policies.nfv.VduScalingDeltas: derived_from: tosca.policies.Root properties: initial_delta: type: tosca.datatypes.nfv.VduLevel required: false aspect_deltas:
type: map # key: aspectId required: false
entry_schema:
type: tosca.datatypes.nfv.VduLevel targets: [ tosca.nodes.nfv.Vdu.Compute ]
regards shitao åää:
Marton, Gabor (Nokia - HU/Budapest) [mailto:gabor.marton@nokia.com]
Dear TOSCA Experts, is the following type definition correct in TOSCA YAML v1.1? tosca.policies.nfv.VduScalingDeltas: derived_from: tosca.policies.Root properties: initial_delta: type: tosca.datatypes.nfv.VduLevel required: false aspect_deltas:
type: map # key: aspectId required: false
entry_schema:
type: map # key: scalingDeltaId
entry_schema: type: tosca.datatypes.nfv.VduLevel targets: [ tosca.nodes.nfv.Vdu.Compute ]
We currently have the above definition in the ETSI NFV VNFD specifiction (alias SOL001), where we intend to define the
aspect_deltas property of the
VduScalingDeltas policy to be a map of map of
VduLevels: The definition seems logical, but it is not obvious whether it does or does not conform to the property definition syntax in TOSCA YAML v1.1 (section 3.5.8.4) which is: <property_name>: type: <property_type> description: <property_description> required: <property_required> default: <default_value> status: <status_value> constraints: - <property_constraints> entry_schema: description: <entry_description> type: <entry_type> constraints: - <entry_constraints> The idea is to be able to write policies like this: - dbBackendCapacityVduScalingDeltas: type: tosca.policies.nfv.VduScalingDeltas properties: aspect_deltas: dbBackendCapacity: delta_1: number_of_instances: 2 delta_2: number_of_instances: 1 targets: [ dbBackend ] Thanks a lot for your answer in advance, kind regards, GÃbor |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]