[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Groups - Change in SwImage artifact type uploaded
|
Chris, Find below some inputs on how the Orchestrator could use these artifact properties: 1. Orchestrator could check for the version property and use this information for handing off to the correct version of artifact processor. 2. Orchestrator could use the checksum property to verify if the integrity of artifact is retained (i.e. successful transfer) after copying the artifact to
the artifact processor. 3. Orchestrator could try to locate the artifact processor based on the artifact type and if not found, try to install the artifact processor and its licenses
using certain artifact properties. 4. Orchestrator could use artifact properties to invoke appropriate package manager for installing an artifact. Regards, Priya
From: Chris Lauwers [mailto:lauwers@ubicity.com]
[External Email] Hi Priya, Yes, if you have suggestions for how the orchestrator would use those properties, that would be very helpful. Thanks, Chris From: Priya T G <priya.g@netcracker.com>
Chris, Thank you for the response. We can retain artifact properties and also cover what the TOSCA Orchestrator could do with these properties in the specification
(TOSCA v1.3). This also ensures that backward compatibility is not affected. Regards, Priya From: Chris Lauwers [mailto:lauwers@ubicity.com]
[External Email] Hi Priya, Perhaps I’m not reading the XML spec correctly, but I don’t see anything that talks about semantics of property definitions in artifact type, i.e. that document doesn’t seem
to specify what an orchestrator is supposed to do with properties associated with artifacts. That remains my biggest issue with artifact properties: if I’m building a TOSCA runtime, there is absolutely nothing in the language that enables me to do anything
useful with artifact properties. Yes, we could allow properties to be defined as part of artifacts, but then every orchestrator will come up with its own interpretation of what to do with those artifacts, and we’re losing portability as a result. Chris From: Priya T G <priya.g@netcracker.com>
Chris, Thank you for the response.
The snippet I shared was an example to illustrate the problem statement. There could be other artifact type-specific properties (features) resulting in addition
of keywords in the long term (e.g. vim type, disk format, hypervisor type etc.).These artifact properties have existed since TOSCA YAML v1.0 and the XML TOSCA v1.0
http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html#_Toc356403693 described the semantics for property definitions in artifact types. It appears that the semantics of artifact definition were not preserved in the YAML v1.0 specification.
Hence it would be better if TOSCA allows defining the typed values of artifact specific properties. Regarding your response regarding representing the VDU as two separate nodes, the multiple artifacts use case can also apply when implementing multiple interface
operations on the given node. We could use the "operation_host" to specify whether the operations are to be executed on "node" environment or "orchestrator" environment. The Ansible playbook described in the example is for "configuring" the VDU Compute node.
Please let me know your thoughts on this. Regards, Priya From: Chris Lauwers [mailto:lauwers@ubicity.com]
[External Email] Hi Priya, I have two comments about your example:
Chris From: Priya T G <priya.g@netcracker.com>
Chris, Find below an example. Regards, Priya
dbServer:
type: tosca.nodes.nfv.VDU
properties:
name: sprout
description:
artifacts:
- sw_image:
type: tosca.artifacts.nfv.SwImage
file:
http://1.1.1.1/images/ubuntu-14.04.qcow2
properties:
name: ubuntu-14.04
version: 14.04
checksum: e5c1e205f62f3
- configuration:
type: tosca.artifacts.Implementation.Ansible
file: implementation/configuration/Ansible/configure.yml
properties:
ansible_version: 1.1.1
- terminate:
type: tosca.artifacts.Implementation.scripts
file: implementation/configuration/scripts/terminate.sh
properties:
version: 6.2
From: Chris Lauwers [mailto:lauwers@ubicity.com]
[External Email] Hi Priya,
Do you have an example or a use case that illustrates this problem? Thanks, Chris From: Priya T G <priya.g@netcracker.com>
Chris, Revisiting this topic for further discussion - Consider a case where the node has many artifacts types and certain properties of the artifact are needed to be processed by the Orchestrator for delegating
to the appropriate artifact processor. Moving these properties to the node causes overhead in terms of identifying a suitable mechanism for describing these properties so that the Orchestrator can correlate them to the concerned artifact. The parsing of
such properties at the node to delegate control to the appropriate artifact processor would complicate the Orchestrator logic. Please let me know your thoughts on this. Regards, Priya From:
tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Chris Lauwers [External Email] 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
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]