Re: [tosca] substitution

["Matt Rutkowski" <mrutkows@us.ibm.com>]

Hi Huabing,

Apart from the examples you cited, there
are no rules written anywhere.  Of course, any "required"
properties for nodes in the topology will fail without Input values being
mapped and provided (via get_input) or some other means to set (or use
of defaults).

We will be reviewing a proposal to update
subst. mappings in 2 weeks at the Simple Profile WG meeting to include
properties, attributes, and interfaces (and metadata) on the subst. mapping
grammar to allow for better "matching" of a Service Templates
topology (as exposed by its subst. mappings) and external abstract nodes
(in another service template).  This proposal, if accepted, would
allow a more clear means to perhaps set "defaults" (and communicate
outside defaults), but not replace Inputs in Service Templates. 

These changes might present the opportunity
to clarify with better examples how Inputs -> properties are to be used
(as we will need to add examples of how "matching" would be done
and improved).

Kind regards,
Matt 




From:      
 <zhao.huabing@zte.com.cn>
To:      
 <mrutkows@us.ibm.com>
Cc:      
 <tosca@lists.oasis-open.org>
Date:      
 05/12/2017 03:11 AM
Subject:    
   Re: [tosca]
substitution

---

Matt,

Thank you for your prompt reply.

Is there any rule to map the inputs/outputs to the properties/attributes in the TOSCA specification? Or the TOSCA specification leave it to the implementation?

Thanks,

Huabing

Original Mail

Sender:  ＜mrutkows@us.ibm.com＞;
To: zhaohuabing10201488;
CC:  ＜tosca@lists.oasis-open.org＞;
Date: 2017/05/11 11:25
Subject: Re: [tosca] substitution

Hi Huabing,

The correct properties for Database are defined in its normative type and are:

Properties

Name	Required	Type	Constraints	Description
name	yes	string	None	The logical database Name
port	no	integer	None	The port the database service will use to listen for incoming data and requests.
user	no	string	None	The special user account used for database administration.
password	no	string	None	The password associated with the user account provided in the ‘user’ property.

At some point in the past (prior to 1.1) the names 'db_user' and 'db_password' were used but the WG agreed the "db_" prefix was redundant.  If any examples in ch.2 (or other places) still use the old "db_" prefix then it is an error.  However, ch 2. are all examples (and should be correct) but they are NOT normative.

All the Examples in section 2.10.x look like they need review for v1.2 as they are confusing... the problem stems from the fact that "Inputs" map to "properties" and the names do not have to match...  this is something the WG has discussed and would like to change and needs more discussion which was on our agenda for this week, but the first topic discussion went 2 hours and we did not get to it.

The thinking at the time was that inputs and outputs existed before "subst. mappings" (which came in late to the 1.0 spec.) and the TC at the time did not want to change confuse people by calling them properties...

In addition, subst mappings only indicate that the topology template can fulfill the Node Type (its requirements and capabilities as well) for the node type it is substituting for.  

NOTE in the Database example... the Input names do NOT need to match the property names... in fact, the template does NOT even need inputs at all...

as long as the Database node can get a "user" and "password" value from somewhere (even hard coded in the Node Template called "db" is valid).

If you read the drafts (with comments in v1.1 and v12, we have a long-standing work item (not completed) to add a process flow / diagrams...

In addition, the comments acknowledge the paragraph "Further note that no mappings for properties or attributes of the substituted node are defined. Instead, the inputs and outputs defined by the topology template have to match theare mapped to the appropriate properties and attributes of the substituted node. If there are moreinputs than the substituted node has properties, default values must be defined for those inputs, since no values can be assigned through properties in a substitution case."

is very confusing and needs to be rewritten... I attempted to correct the wording some using red (old) and blue (proposed) corrections above, but the 2nd sentence is confusing and not entirely correct, as default values can be provided in the actual "db" node template as well.

Kind regards,
Matt Rutkowski

STSM, Master Inventor, IBM Open Cloud Technologies and Standards
Apache OpenWhisk Incubator Project Lead, Initial Committer
Chair, Lead Editor OASIS TOSCA Simple Profile WG,
Co-Chair OASIS TOSCA Interop. SC,
Founder of DMTF Cloud Audit (CADF) Standard
mrutkows@us.ibm.com,  mobile: 512-431-5002




From:        ＜zhao.huabing@zte.com.cn＞
To:        ＜tosca@lists.oasis-open.org＞
Date:        05/10/2017 03:04 AM
Subject:        [tosca] substitution
Sent by:        ＜tosca@lists.oasis-open.org＞

---

Hi all,

I'm confused when I went through the substitution example of simpl yaml v1.1.

According to the specification, the inputs and outputs defined by the topology template should match the properties and attributes of the node type definition, but the inputs of database example obviously doesn't match the properties of Database node type. which is db_user,db_password and user, passord.

Is it a document issue or I misunderstand ?

Thanks for your help.

Huabing

The below sentence is from 2.10.3 Definition of the database stack in a service template

"Further note that no mappings for properties or attributes of the substituted node are defined. Instead, the inputs and outputs defined by the topology template have to match the properties and attributes or the substituted node. If there are more inputs than the substituted node has properties, default values must be defined for those inputs, since no values can be assigned through properties in a substitution case"

The substitution example from 2.10.3

tosca_definitions_version: tosca_simple_yaml_1_0

 topology_template:

  description: Template of a database including its hosting stack.

   inputs:

    db_user: (should be 'user' ?)

      type: string

    db_password:(should be 'password' ?)

      type: string

    # other inputs omitted for brevity

   substitution_mappings:

    node_type: tosca.nodes.Database

    capabilities:

      database_endpoint: [ database, database_endpoint ]

 

  node_templates:

    database:

      type: tosca.nodes.Database

      properties:

        user: { get_input: db_user }

        # other properties omitted for brevity

      requirements:

        - host: dbms

    dbms:

      type: tosca.nodes.DBMS

      # details omitted for brevity

    server:

      type: tosca.nodes.Compute

      # details omitted for brevity

The definition of Database nodetype:

tosca.nodes.Database:

  derived_from: tosca.nodes.Root

  properties:

    name:

      type: string

      description: the logical name of the database

    port:

      type: integer

      description: the port the underlying database service will listen to for data

    user:

      type: string

      description: the optional user account name for DB administration

      required: false

    password:

      type: string

      description: the optional password for the DB user account

      required: false

  requirements:

    - host:

        capability: tosca.capabilities.Container

        node: tosca.nodes.DBMS

        relationship: tosca.relationships.HostedOn

  capabilities:

    database_endpoint:

      type: tosca.capabilities.Endpoint.Database

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php