[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 答复: [tosca] Groups - Change in SwImage artifact type uploaded
I just upload a related document for discussion in today’s simple yaml call.
发件人: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
代表
Chris Lauwers Hi Arturo, That sounds like a reasonable approach.
That said, we should go through the original list of the SwImageArtifact properties to discuss whether there might be a better way to handle those:
-
As Shitao pointed out, some of those may be informational only, in which case they might be better expressed as “meta data”
-
Other properties such as “version” and “checksum” might be important to the orchestrator, in which case we should consider turning them into keynames
(supported in the TOSCA grammar) for property assignments.
-
As Matt suggested earlier, we plan on formalizing the concept of “artifact processors” at some point. Some properties could be used to drive the “processing”
process itself (although I don’t believe the SwImage contains such properties). Thanks, Chris From: Arturo De Nicolas <arturo.martin-de-nicolas@ericsson.com> Hi Chris, Matt and Claude, It would be good to come to a conclusion on this tomorrow during the TOSCA YAML WG call. In the meantime, I have uploaded the attached contribution to ETSI NFV, where I define the Sw_image artifact type without properties, and place all properties
related to the Sw_image in the nodes that use it, the Vdu.Compute and Vdu.VirtualStorage nodes. Chris, do you think this is the way forward? Best regards, Arturo From: Chris Lauwers [mailto:lauwers@ubicity.com]
Hi Arturo,
I need to look at the details of IFA 11 again, but it seems to me that if any attributes are required, they should be part of the node type that contains the artifact,
not of the artifact itself. Chris From: Arturo De Nicolas <arturo.martin-de-nicolas@ericsson.com> Thanks for the clarification. I assume this was overlooked when the SwImage artifact type was defined in the NFV profile, at least I have not got any other information, as you saw in a separate
e-mail. The question is what to do now to comply with IFA011. Do you have any proposal? Should we create a new node as a wrapper of the SwImage artifact and we define the properties in the node? Or define the properties in the nodes that use the SwImage artifact, i.e. the Vdu.Compute and the Vdu.VirtualStorage? Best regards, Arturo
From:
tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Chris Lauwers Hi Arturo,
The problem is not with defining new node types with type-specific properties. The problem is with associating properties with Artifacts. The artifact
definition grammar in TOSCA does not allow properties (see Section 3.5.6.1 in Version 1.1 of the spec). The reason for this is that there is no mechanism in TOSCA currently to use such properties even if they were allowed. There are three ways in which property
values can affect how services get orchestrated:
·
By serving as inputs into Interface operations. This can be done using the get_property or get_attribute functions, but those functions
only retrieve properties from node templates, relationship templates, or capabilities
·
By directing the orchestrator for how dangling requirements need to be fulfilled from an active inventory. This can be done by specifying
property values in node filters, but node filters only use properties from node templates, relationship templates, or capabilities.
·
By driving the substitution mappings process. Again, artifacts don’t get involved in substitution mappings. In summary, even if we allowed properties in artifacts, there is nothing an orchestrator could do with those artifacts. That said, I just noticed that there is a glaring inconsistency in the spec, since Artifact Type definitions do allow properties. Since artifact
definitions themselves are not able to assign values to properties defined in an Artifact Type, this needs to get fixed. My recommendation is remove property definitions from Artifact Type definition, for all the reasons I outlined above. Chris From: Arturo Martin De Nicolas [mailto:arturo.martin-de-nicolas@ericsson.com]
Hi Chris, I am not sure what is your proposal then for the NFV profile (or ETSI NFV SOL001) to mirror the VNFD and NSD information models. We are defining new node types
with new properties. Don’t we have the same issue with all of them? I assume a TOSCA orchestrator that supports this profile should understand these new types, or?
It is also possible that the service template contains interface operations scripts that know what to do with these properties. How do you see it? Best regards, Arturo From: Chris Lauwers [mailto:lauwers@ubicity.com]
Hi Arturo, We should discuss this more broadly. I believe it would be unwise for OASIS TOSCA to publish a Profile (e.g. the NFV Profile) that includes types that cannot be
deployed by a “generic” TOSCA orchestrator. As a TC, I believe we should not vote to ratify such a spec. Thanks, Chris From: Arturo Martin De Nicolas [mailto:arturo.martin-de-nicolas@ericsson.com]
Hello Chris, Please, note that I am not proposing to add any property, but to remove one. The listed properties are already there in the NFV profile. That is anyway a general issue in the NFV profile. There will be properties mapped from IFA011 with semantics that existing TOSCA orchestrators do not understand. Best regards, Arturo From: Chris Lauwers [mailto:lauwers@ubicity.com]
Hi Arturo, If we added these properties to the artifact, how do you envision an orchestrator would use those? There currently isn’t any TOSCA orchestrator
functionality that could make decisions based on those properties. Thanks, Chris From:
tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Arturo Martin de Nicolas
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]