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 <mrutkows@us.ibm.com>
Sent: Tuesday, May 5, 2015 5:51 PM
To: Chris Lauwers
Cc: Nikunj Nemani; tosca@lists.oasis-open.org
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 <lauwers@ubicity.com>
To: Nikunj Nemani <nnemani@vmware.com>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Date: 05/05/2015 06:40 PM
Subject: RE: [tosca] Questions on the TOSCA model
Sent by: <tosca@lists.oasis-open.org>

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:nnemani@vmware.com]
Sent: Monday, May 04, 2015 11:51 PM
To: Chris Lauwers
Cc: tosca@lists.oasis-open.org
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 <lauwers@ubicity.com>
Date: Monday, May 4, 2015 at 10:44 AM
To: Nikunj Nemani <nnemani@vmware.com>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
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:nnemani@vmware.com]
Sent: Thursday, April 30, 2015 11:17 PM
To: Chris Lauwers
Cc: tosca@lists.oasis-open.org
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 <lauwers@ubicity.com>
Sent: Wednesday, April 29, 2015 2:51 PM
To: Nikunj Nemani
Cc: tosca@lists.oasis-open.org
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:tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Nikunj Nemani
Sent: Wednesday, April 29, 2015 12:04 AM
To: tosca@lists.oasis-open.org
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

tosca message