Re: 2015-04-13 tosca_elk_DRAFT_CSAR: issues with capabilities

Hi Chris, 

I agree with you on how to use capabilities
in the node template. 

About capabilities ambiguous capabilities
in types, when we worked on this use case, we were aware of the fact that
both, collectd_endpoint
and rsyslog_endpoint,
has same type. Couple of small things that were discussed were preference
of type author and possible future extension of type with specific set
of arguments. May be it's something we want to discuss in today's YAML
call as well. 

Thanks again for your comments. 

Regards, 

Sahdev Zala 

From:      
 Chris Lauwers <>

To:      
 Sahdev P Zala/Durham/IBM@IBMUS

Cc:      
 ""
<>

Date:      
 04/13/2015 11:42 PM

Subject:    
   2015-04-13 tosca_elk_DRAFT_CSAR:
issues with capabilities

A second set of issues in
the latest CSAR has to do with capabilities. I’ll use the logstash example
again. The Logstash node type defines the following capabilities:

 

node_types:

  tosca.nodes.SoftwareComponent.Logstash:

    derived_from: tosca.nodes.SoftwareComponent

    capabilities:

      collectd_endpoint:

         type:
tosca.capabilities.Endpoint

      rsyslog_endpoint:

         type:
tosca.capabilities.Endpoint

 

The problem here is that
the collectd_endpoint and rsyslog_endpoint capabilities are semantically
identical since they both have the same type and (presumably) the same
valid_source_nodes. The only thing that distinguishes them is their (symbolic)
name. 

 

The problem becomes obvious
when we look at the app_collectd and app_rsyslog node templates that use
these capabilities:

 

    app_collectd:

      type: tosca.nodes.SoftwareComponent.Collectd

      requirements:

        - host:
app_server

        - collectd_endpoint:
logstash

 

   app_rsyslog:

      type: tosca.nodes.SoftwareComponent.Rsyslog

      requirements:

        - host:
app_server

        - rsyslog_endpoint:
logstash

 

Based on the requirement
assignments, either capability in the Logstash node type can be used to
satisfy either requirement. 

 

We could fix this specific
use case by augmenting the requirement assignment with the symbolic name
of the specific capability that’s needed, as follows:

 

   app_rsyslog:

      type: tosca.nodes.SoftwareComponent.Rsyslog

      requirements:

        - host:
app_server

        - rsyslog_endpoint:

         
  node: logstash

         
  capability: rsyslog_endpoint

 

 

However, it believe it is
bad practice to rely on symbolic names to differentiate between things
that are semantically different. If the collectd_endpoint and rsyslog_endpoint
capabilities are different, they should have different types. Relying on
symbolic names only also makes it impossible to do “requirements fulfillment”
dynamically (i.e. have the orchestrator dynamically match nodes to requirements).

 

 

Chris

 

 

From: Sahdev P Zala [mailto:]

Sent: Monday, April 13, 2015 4:42 PM

To: Chris Lauwers

Cc: 

Subject: RE: [tosca] Groups - 2015-04-13 tosca_elk_DRAFT_CSAR.zip uploaded

 

Hi Chris, sounds great!

Thanks!!

Regards, 

Sahdev Zala 

From:        Chris
Lauwers <>

To:        Sahdev
P Zala/Durham/IBM@IBMUS 

Cc:        ""
<>

Date:        04/13/2015
07:17 PM 

Subject:        RE:
[tosca] Groups - 2015-04-13 tosca_elk_DRAFT_CSAR.zip uploaded

Sent by:        <>

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:]

Sent: Monday, April 13, 2015 4:15 PM

To: Chris Lauwers

Cc: 

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 <>

To:        Sahdev
P Zala/Durham/IBM@IBMUS, ""
<>

Date:        04/13/2015
04:57 PM 

Subject:        RE:
[tosca] Groups - 2015-04-13 tosca_elk_DRAFT_CSAR.zip uploaded

Sent by:        <>

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: 
[mailto:]
On Behalf Of Sahdev Zala

Sent: Monday, April 13, 2015 7:10 AM

To: 

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