OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [tosca] Groups - Change in SwImage artifact type uploaded


Hi Priya,

 

I have two comments about your example:

 

  1. It appears that the main property that needs to be associated with an artifact is a “version” (presumably of the artifact processor). If that is the main concern, then we should consider adding a “version” keyname to the artifact definition. It may also be helpful to  add a “checksum” keyname.
  2. Your example shows a problem with how VDUs are modeled: a VDU combines a Compute node with a Software Component running on that Compute node. Your “sw_image” is the artifact for creating the Compute node, and the Ansible playbook is the artifact for creating the Software Component running on that Compute node. It would be (much) better if two separate nodes were used for modeling the VDU. Alternatively the VDU should really represent the Software Component, and the Compute could be expressed using a HostedOn requirement. In any event, I believe that combining both the Software Component and the Compute into a single VDU abstraction creates your “multiple artifacts” problem.

 

Chris

 

From: Priya T G <priya.g@netcracker.com>
Sent: Tuesday, April 17, 2018 9:51 AM
To: Chris Lauwers <lauwers@ubicity.com>; Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>; tosca@lists.oasis-open.org
Cc: claude.noshpitz@att.com; Matthew Rutkowski (mrutkows@us.ibm.com) <mrutkows@us.ibm.com>; Steve Baillargeon (steve.baillargeon@ericsson.com) <steve.baillargeon@ericsson.com>
Subject: RE: [tosca] Groups - Change in SwImage artifact type uploaded

 

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]
Sent: Tuesday, April 17, 2018 9:27 PM
To: Priya T G; Arturo Martin De Nicolas; tosca@lists.oasis-open.org
Cc: claude.noshpitz@att.com; Matthew Rutkowski (mrutkows@us.ibm.com); Steve Baillargeon (steve.baillargeon@ericsson.com)
Subject: RE: [tosca] Groups - Change in SwImage artifact type uploaded

 

[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>
Sent: Tuesday, April 17, 2018 2:45 AM
To: Chris Lauwers <lauwers@ubicity.com>; Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>; tosca@lists.oasis-open.org
Cc: claude.noshpitz@att.com; Matthew Rutkowski (mrutkows@us.ibm.com) <mrutkows@us.ibm.com>; Steve Baillargeon (steve.baillargeon@ericsson.com) <steve.baillargeon@ericsson.com>
Subject: RE: [tosca] Groups - Change in SwImage artifact type uploaded

 

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
Sent: Saturday, March 10, 2018 12:11 AM
To: Arturo Martin De Nicolas; tosca@lists.oasis-open.org
Cc: claude.noshpitz@att.com; Matthew Rutkowski (mrutkows@us.ibm.com); Steve Baillargeon (steve.baillargeon@ericsson.com); Chris Lauwers
Subject: RE: [tosca] Groups - Change in SwImage artifact type uploaded

 

[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]
Sent: Wednesday, March 07, 2018 4:49 AM
To: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: RE: [tosca] Groups - Change in SwImage artifact type uploaded

 

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]
Sent: Sunday, March 04, 2018 7:37 PM
To: Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>; tosca@lists.oasis-open.org
Subject: RE: [tosca] Groups - Change in SwImage artifact type uploaded

 

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]
Sent: Wednesday, February 21, 2018 11:56 PM
To: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: RE: [tosca] Groups - Change in SwImage artifact type uploaded

 

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]
Sent: Wednesday, February 21, 2018 9:12 PM
To: Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>; tosca@lists.oasis-open.org
Subject: RE: [tosca] Groups - Change in SwImage artifact type uploaded

 

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
Sent: Tuesday, February 13, 2018 7:16 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] Groups - Change in SwImage artifact type uploaded

 

Document Name: Change in SwImage artifact type


Description
Proposal to remove the sw_image property in artifact type definition.
Download Latest Revision
Public Download Link


Submitter: Mr. Arturo Martin de Nicolas
Group: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
Folder: Working Documents
Date submitted: 2018-02-13 07:15:24

 

 


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]