RE: [tosca] Questions on the TOSCA model

Thank you Chris and Matt.

Firstly, where can I find the latest version of the spec ? (Sorry for asking the basic question)

Chris - Unfortunately I will not be able to modularize the node template

Matt - Let me file a jira for the feature proposal and put in the use-case details. 

Thanks and Regards,

Nikunj

From: Matt Rutkowski <>

Sent: Tuesday, May 5, 2015 5:51 PM

To: Chris Lauwers

Cc: Nikunj Nemani; 

Subject: RE: [tosca] Questions on the TOSCA model

 

Thanks Chris, 

Good analysis thanks for passing along. 

Hi Nikunj, 

First, the spec. version you are referencing is from December 11, 2014.  The TC publishes 1 or 2 new revisions per-week.  We are almost to CSD (major releases) past the version you are reading and and functionally have added
 so many new features in the last 5 months that you are missing many useful features and updates.

The properties are a bit scary as they are non-normative, but ignoring the details and accepting this as a use case for "providing groups of property settings" ...

As Chris pointed out, we now have a "copy" function for node templates so you can copy an existing template which inherits all properties and you can then proceed to change a few.  We also have endorsed the use of "DSL definitions"
 which is essentially a YAML macro. that can be used to define sets of properties that are used multiple times to avoid coding them every time.  Your use case is slightly different, but can be address now with using an external mechanism to pass in Input parameters
 to the service template and code your nodes in a way to copy these inputs to node properties.  

I have been thinking of a way to formalize this using YAML files that contain only the YAML for Input properties (mainly for our use in testing our orchestrator code in OpenStack Heat-Translator project).  If we can formalize
 this use case with a simpler version (and does introduce custom types with SCSI and other hardware-centric properties) then this is something we should open up as a JIRA issue and track as a feature proposal.

Kind regards, 

Matt 

From:        Chris Lauwers <>

To:        Nikunj Nemani <>

Cc:        "" <>

Date:        05/05/2015 06:40 PM

Subject:        RE: [tosca] Questions on the TOSCA model

Sent by:        <>

Hi Nikunj, 

  

It looks like you want to organize your properties into “buckets” and then have a “blueprint” for each bucket that you can apply wholesale. I’m not sure that can be easily done since the “copy” keyword operates
 on an entire node template, not on sets of properties (or capabilities). Can you modularize things more and introduce additional (sub) node templates?

  

Chris 

  

From: Nikunj Nemani [mailto:]

Sent: Monday, May 04, 2015 11:51 PM

To: Chris Lauwers

Cc: 

Subject: Re: [tosca] Questions on the TOSCA model 

  

Hello Chris, 

  

Appreciate all your responses. 

May be it will help if I can explain my use-case some more

  

1. I want to define a standard rhel machine 

I defined a NodeType 

node.yaml 

node_types: 

mycompany.nodes.Compute: 

derived_from: tosca.Nodes.Compute 

Properties: some proprietary 

  

I created a rhel blueprint which can be either requestable by itself or can be used to create a database

  

rhel_7.0.yaml 

tosca_definitions_version: tosca_simple_yaml_1_0_0 

description: TOSCA simple profile for a standard rhel 7 machine

imports: 

    - node.yaml 

  

node_templates: 

rhel_7.0: 

derived_from: mycompany.nodes.Compute 

properties: 

  

I want to create a database node 

Database:

        type: rhel_7.0 #vra.nodes.Compute 

        properties: 

  

In this case, I want to have multiple property lists to be assigned to the rhel blueprint. E.g.

properties_list1: 

    environment: 

    backup_enabled: 

  

properties_list2: 

VirtualMachine.admin.ThinProvision: true 

VMware.SCSI.Type: pvscsi 

MonitoringOptions: true 

MonitoringOptions.HasAlerting: true 

SysPrep.GuiUnattended.adminPassword: 

Cost: 

ProjectCode: 

  

And the two property list defined above is such that both 1 & 2 will be applied to rhel as well as to a CentOS or a Ubuntu blueprint

  

Thanks and Regards, 

Nikunj 

From: Chris Lauwers <>

Date: Monday, May 4, 2015 at 10:44 AM

To: Nikunj Nemani <>

Cc: "" <>

Subject: RE: [tosca] Questions on the TOSCA model 

  

Hi Nikunj, 

  

I just realized I hadn’t responded to the first part of your second question. You would have two different yaml files: one to define your “custom” Compute node type, and one to assign “standard” values to nodes
 of your custom type. 

  

1.      For example, you could create a file called custom-compute.yaml that defines your customized Compute node type as follows:

  

tosca_definitions_version: tosca_simple_yaml_1_0_0

  

node_types: 

  CustomCompute: 

    derived_from: tosca.nodes.Compute

# Add custom properties 

    properties: 

     VirtualMachine.admin.ThinProvision:

        type: boolean 

      VMware.SCSI.Type: 

        type: string 

      MonitoringOptions: 

        type: boolean 

      MonitoringOptions.HasAlerting:

        type: boolean 

  

2.      You could then create a file (e.g. standard-compute.yaml) that assigns “standard” values to the properties of your customized Compute nodes:

  

tosca_definitions_version: tosca_simple_yaml_1_0_0

  

imports: 

  - custom-compute.yaml 

  

topology_template: 

  node_templates: 

    standard-compute: 

     type: CustomCompute

     properties: 

       VirtualMachine.admin.ThinProvision: true

       VMware.SCSI.Type: pvscsi

       MonitoringOptions: true

       MonitoringOptions.HasAlerting: true

    

  

Then you should be able to “copy” your standard compute node template as before:

  

tosca_definitions_version: tosca_simple_yaml_1_0_0

imports: 

   - standard-compute.yaml

topology_template: 

  node_templates: 

    node_template_1: 

      type: CustomCompute

      copy: standard_compute

  

  

Hope this helps, 

  

Chris 

  

From: Nikunj Nemani [mailto:]

Sent: Thursday, April 30, 2015 11:17 PM

To: Chris Lauwers

Cc: 

Subject: RE: [tosca] Questions on the TOSCA model 

  

Hello Chris, 

  

Appreciate your response. 

1.        ​For #1 - Understood your point, But we do have a use-case where we want to specify constraints on the node template. E.g. CentOS is a node type with memory constraints 2 - 8 GB,
 but when I am using that CentOS to create an application stack, I want the database to have constraints 4 - 8 (Good example is database vendor requires 4 GB minimum)

2.        For#2 - In your suggestion:

1.        ​I am missing one thing, how is
standard-compute.yaml a topology template ? I thought it is just a node type ?

2.        I couldn't find a reference to the 'copy' keyword in the spec
http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csd02/TOSCA-Simple-Profile-YAML-v1.0-csd02.html#_Toc409427376,​
 am I missing something ? 

  

Thanks and Regards, 

Nikunj

From: Chris Lauwers <>

Sent: Wednesday, April 29, 2015 2:51 PM

To: Nikunj Nemani

Cc: 

Subject: RE: [tosca] Questions on the TOSCA model 

  

Hi Nikunj, 

  

1.      
You can’t specify constraints on properties in a node template. You can think of a node template as an “instance” of a node of a certain Node Type. When you define the node type, you specify all the properties
 for that type and any constraints on those properties. In the node template, you would assign values to those properties. Said another way: the “properties” key in a node type is used for “property definitions” and the “properties” key in a node template is
 for “property assignments”. When you assign values to properties, your software should validate whether those values satisfy the constraints specified in the node type.

  

2.      
Two comments on your second question:

a.      
If you have Compute nodes that need properties beyond those defined in tosca.nodes.Compute, you will have to create a derived Node Type that adds those properties. You can define your new node type in a separate
 YAML file that can be imported in the service templates that need it. 

b.      If you want to create “standard” values that should be used for all your Compute nodes, you
 could do the following: 

·  
Create a separate file (e.g. standard-compute.yaml) that defines a node template (e.g. called standard_compute)  of your Compute type and assign your standard property values to that node template

·  
Import this file into the service templates that want to use the standard property values

·  
When defining node templates, use the “copy” key to copy all the property values from your standard_compute node templat

  

Here is sample YAML 

  

tosca_definitions_version: tosca_simple_yaml_1_0_0

imports: 

   - standard-compute.yaml

topology_template: 

  node_templates: 

    node_template_1: 

      copy: standard_compute

  

Please be aware that there is one potential problem with this: node templates (including standard_compute) are defined inside a topology_template. It is assumed that there is only one topology_template per service
 template. The behavior where a service template that has a topology_template includes another file that also has a topology_template is undefined. This is an issue that needs to be resolved in the spec.

  

c.      
Another option might be to put the dsl_definition statement into its own file and import it, but depending on the YAML parser this might not work (since “import” is a Tosca concept, not a YAML concept). Anybody
 have any opinions about whether this should work or not? 

  

  

Hope this helps, 

  

Chris 

  

  

From: [mailto:]
On Behalf Of Nikunj Nemani

Sent: Wednesday, April 29, 2015 12:04 AM

To: 

Subject: [tosca] Questions on the TOSCA model 

  

Hello, 

  

Recently, I have been trying to model few applications in TOSCA.

I have two questions, appreciate your response and help.

  

1. Can constraints be specified inline on properties of node template ? In the spec I could find the constraints only defined either in the node template or in the inputs.

E.g. - Is this a valid TOSCA node template ?

  

    appserver: 

        type: tosca.Nodes.Compute 

        properties: 

        

num_cpus: 

        

type: integer 

        

description: Number of CPUs 

        

default: 1 

        

required: true 

        

constraints: 

        

- in_range: [1, 4] #alternate is to specify as num_cpus: {in_range [1, 4] }

  

2 . I  have a of a list of properties which I want to use across my nodes in different blueprints. E.g. I have a set of properties which I want to apply to all my linux nodes whether it is CentOS or RedHat in a LAMP stack or in
 a JavaStack. How can I define that ? I know that I can define a dsl_definition, but that will only be within a blueprint (or application). The other thing I can do is define a  different nodeType, for e.g

linux_property_list: 

derived_from: tosca.Nodes.Root 

  

properties: 

VirtualMachine.admin.ThinProvision: true 

VMware.SCSI.Type: pvscsi 

MonitoringOptions: true 

MonitoringOptions.HasAlerting: true 

ProjectCode: 

  

But when I want to use it in my node template, is this valid ? (Note the properties are a combination of the property_list as well as very specific properties for that node)

  

appserver: 

        type: tosca.Nodes.Compute 

  

properties: 

- linux_property_list 

        num_cpus: 

        type: integer 

        description: Number of CPUs 

        default: 1 

        required: true 

        mem_size: 4 MB 

        disk_size: 10 GB 

        

Thanks and Regards, 

Nikunj Nemani