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] RE: 2015-04-13 tosca_elk_DRAFT_CSAR: issues with requirements


Matt wrote:

 

Ø  Yes, I can see both sides of the argument.  However, I know how much trouble it took to get the where we are with Req/Cap definitions and we created hard rules around what can and cannot be done in a Type definition and I do not want to deviate from these long fought decisions and start creating dynamic Relationship types that have no names and can be further subclassed and changed

Ø

 

I think I see where the disconnect is based on this statement. In my opinion, we’re not creating a new (unnamed) relationship type here. We’re just using ConnectTo relationship type in what I would call a “relationship definition”. I realize this is not a concept that’s formally introduced in the spec, but I believe this is actually what we’re doing here.

 

Let’s use “properties” and “capabilities” as an analogy. For both of these concepts, we clearly distinguish between types, definitions, and assignments:

 

1.       We have Property Types (actually Data Types) and Capability Types that define how these entities are composed of other (sub)-entities

2.       Next, we have property definitions and capability definitions that specify how properties and capabilities of certain types are used (or “declared”) in other entities (e.g. node templates). A property definition “declares” the presence of a property of a certain type in some other entity (e.g. a Node Type). In our current grammar, property and capability definitions allow elements of the type (e.g. constraints, default values, “required” flags, etc.) to be tweaked without having to create a new type.

3.       And finally, we have property assignments and capability assignments. These assign real values to the properties and capabilities defined elsewhere. Note that these values need to be validated against the property and capability definitions (which will ultimately use the Types), not against the property and capability types directly.

 

If we use this analogy, then we can identify 3 different relationship-related concepts as well:

 

1.       Relationship types. I believe it’s clear what these are. The ConnectTo relationship type is what’s used in the logstash example.

2.       Relationship definitions: while not explicitly specified, I believe the way we use the “relationship” keyname in a requirement definition is as a relationship definition (i.e. a declaration of the presence of a relationship of a certain type), not as a relationship type definition.

3.       And finally a relationship assignment. This is what a relationship template is: it assigns values to relationships defined in a relationship definition (which means that relationship templates need to be validated against relationship definitions, not relationship types).

 

If we agree that this is what we’re doing, then there is not disagreement about what we’re allowed to do with Type definitions. Clearly we can’t create on-the-fly “unnamed” types. However, the question then becomes what we’re allowed to do in a relationship “definition” (i.e. in the declaration of the presence of a relationship of a certain type). My vote continues to be that we should be allowed to “augment” inputs in a relationship definition (similar to the way we’re allowed to “augments” constraints etc. in a property definition). Again, this doesn’t create a new type but it gives us a clear entity against we can validate relationship templates (i.e. relationship assignments).

 

By the way, this is exactly how our code at Ubicity is structured, and it works extremely well.

 

Thanks,

 

Chris

 

 




In this morning’s discussion, Matt suggested that the “proper” way to augment interfaces in Tosca types is to create a new type. I agree that this might be the cleanest approach, but I’m afraid this might result in lots of unnecessary work for the template designer.
 
Let’s look at the logstash example below. All we want to do is to add one input (“elasticsearch_ip”) to the pre_configure_source operation on the Configure interface on the ConnectTo relationship type. This would result in the following:
 
1.       First, we have to create a new Interface Type (e.g. MyConfigure), derived from tosca.interfaces.relationship.Configure, that adds the “elasticsearch_ip” input to pre_configure_source). Note that if we had operation types as well, we would have had to first create a new operation type.
2.       Then, we have to create a new Relationship Type (e.g. MyConnectTo) derived from ConnectTo that uses the new MyConfigure interface.
3.       Then, we can create the Logstash node type with the “search_endpoint” requirement definition that uses the MyConnectTo relationship type
 
When the template designer creates the topology template that uses a Logstash node, they have to do the following:
 
1.       First, they have to create a relationship_template (e.g. search_endpoint_relationship) that assigns a value to the “elasticsearch_ip” input defined in the MyConfigure interface of the MyConnectTo relationship type
2.       Then they have to specify the search_endpoint_relationship in the search_endpoint requirement assignment in the logstash node template
 
Most of these steps could be avoided if we simply allowed augmentation of interface operations in-line in requirement definitions and requirement assignments.
 
Chris
 
 
From: Sahdev P Zala [mailto:spzala@us.ibm.com]
Sent:
Tuesday, April 14, 2015 8:18 AM
To:
Chris Lauwers
Cc:
tosca@lists.oasis-open.org
Subject:
Re: 2015-04-13 tosca_elk_DRAFT_CSAR: issues with requirements

 
Hi Chris,

Good catches. I will make updates per your suggestion for Logstash and any other node where it makes sense.


I have a question on node types grammar in spec for providing arguments to the 'relationship', interfaces in Logstash case. I will bring it up in today's YAML call.


Thanks!

Regards,
Sahdev Zala

____________________________ el

development, IBM Cloud
Durham, NC

(919)486-2915 T/L: 526-2915




From:        
Chris Lauwers <lauwers@ubicity.com>
To:        
Sahdev P Zala/Durham/IBM@IBMUS
Cc:        
"tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Date:        
04/13/2015 11:25 PM
Subject:        
2015-04-13 tosca_elk_DRAFT_CSAR: issues with requirements






As promised, here are a number of comments on the latest CSAR file. Most of the issues with this file are with requirements definitions and assignments and are similar in nature. I’ll use the logstash.yaml file to illustrate a couple of them.
 
The first set of issues has to do with requirement definitions in node types. logstash.yaml defines the following node type:

 
node_types:

 tosca.nodes.SoftwareComponent.Logstash:

   derived_from: tosca.nodes.SoftwareComponent

   requirements:

       search_endpoint:

         capability: tosca.capabilities.Endpoint

         node: tosca.nodes.SoftwareComponent.Elasticsearch

         relationship:

           type: tosca.relationships.ConnectsTo

           interfaces:

             tosca.interfaces.relationship.Configure:

               pre_configure_source:

                 implementation:

                   type: string

                 inputs:

                   elasticsearch_ip:

                     type: string

 
This node type has invalid grammar for the search_endpoint requirement definition. According to the requirements definition grammar (section A.6.2.2) the ‘relationship’ keyname is only allowed to take a relationship type name, not an extended grammar that overrides interfaces.

 
The second set of  issues have to do with requirement assignments. The logstash node template in the tosca_elk.yaml file contains the following:

 
   logstash:

     type: tosca.nodes.SoftwareComponent.Logstash

     requirements:

       - host: logstash_server

       - search_endpoint: elasticsearch

         interfaces:

           tosca.interfaces.relationship.Configure:

             pre_configure_source:

               implementation: Python/logstash/configure_elasticsearch.py

               input:

                 elasticsearch_ip: { get_attribute: [elasticsearch_server, ip_address] }

 
There are 2 issues with this:

 
1.       The syntax for ordered requirements assignment lists is invalid based on section A.7.2.2.2. The correct syntax is as follows:

 
   logstash:

     type: tosca.nodes.SoftwareComponent.Logstash

     requirements:

       - host: logstash_server

       - search_endpoint:
           node: elasticsearch

           interfaces:

             tosca.interfaces.relationship.Configure:

               pre_configure_source:

                 implementation: Python/logstash/configure_elasticsearch.py

                 input:

                   elasticsearch_ip: { get_attribute: [elasticsearch_server, ip_address] }

 
2.       More importantly, a requirement assignment does not take ‘interfaces’ as a top-level keyname. I imagine the intent here is to override interfaces for the relationship in the requirement as follows:

 
   logstash:

     type: tosca.nodes.SoftwareComponent.Logstash

     requirements:

       - host: logstash_server

       - search_endpoint:
           node: elasticsearch

           relationship:

             interfaces:

               tosca.interfaces.relationship.Configure:

                 pre_configure_source:

                   implementation: Python/logstash/configure_elasticsearch.py

                   input:

                     elasticsearch_ip: { get_attribute: [elasticsearch_server, ip_address] }

 
Unfortunately, the latest version of the grammar seems to have removed support for that as well so it is no longer possible to define interfaces directly in requirements. The only option here is to introduce a relationship template with the appropriate interfaces.

 
 
Chris

 
 
 
From:
Sahdev P Zala [mailto:spzala@us.ibm.com]
Sent:
Monday, April 13, 2015 4:42 PM
To:
Chris Lauwers
Cc:
tosca@lists.oasis-open.org
Subject:
RE: [tosca] Groups - 2015-04-13 tosca_elk_DRAFT_CSAR.zip uploaded
 
Hi Chris, sounds great!


Thanks!!


Regards,
Sahdev Zala





From:        
Chris Lauwers <lauwers@ubicity.com>
To:        
Sahdev P Zala/Durham/IBM@IBMUS
Cc:        
"tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Date:        
04/13/2015 07:17 PM
Subject:        
RE: [tosca] Groups - 2015-04-13 tosca_elk_DRAFT_CSAR.zip uploaded
Sent by:        
<tosca@lists.oasis-open.org>







Thanks Sahdev, I’ll start with an email, since a number of the issues will likely need some discussion. Based on the discussion, I can upload edited YAML files.


I’ll work on this later today and tomorrow.


Thanks,


Chris



From:
Sahdev P Zala [mailto:spzala@us.ibm.com]
Sent:
Monday, April 13, 2015 4:15 PM
To:
Chris Lauwers
Cc:
tosca@lists.oasis-open.org
Subject:
RE: [tosca] Groups - 2015-04-13 tosca_elk_DRAFT_CSAR.zip uploaded

Hi Chris,

Thank you so much for the review. I am looking forward to have your comments.

I think email probably is a good way or may be you can upload them as a doc at the same place we have CSAR? I will make changes per your comments unless I have questions or need to have a discussion.

Thanks again!



Regards,
Sahdev Zala






From:        
Chris Lauwers <lauwers@ubicity.com>
To:        
Sahdev P Zala/Durham/IBM@IBMUS, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Date:        
04/13/2015 04:57 PM
Subject:        
RE: [tosca] Groups - 2015-04-13 tosca_elk_DRAFT_CSAR.zip uploaded
Sent by:        
<tosca@lists.oasis-open.org>








Hi Sahdev,


Thanks for the update. I finally managed to run this test case through my validator, and it turns out there are many issues with the YAML files in this package. In particular, many of the “requirements” sections (in Node Templates as well as in Node Types) do not conform to the spec.


What is the best way for me to submit my comments so we can get this package updated?


Best regards,


Chris




From:
tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Sahdev Zala
Sent:
Monday, April 13, 2015 7:10 AM
To:
tosca@lists.oasis-open.org
Subject:
[tosca] Groups - 2015-04-13 tosca_elk_DRAFT_CSAR.zip uploaded

Submitter's message

Document for InterOp. SC review.

Thanks to Matt and Christopher Kaufmann for their initial comments, update the draft with some minor changes. Thanks!
-- Sahdev Zala

Document Name: 2015-04-13 tosca_elk_DRAFT_CSAR.zip






No description provided.

Download Latest Revision
Public Download Link






Submitter
: Sahdev Zala
Group
: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
Folder
: Working Documents
Date submitted
: 2015-04-13 07:09:19


 



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