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. The rule
we set about was "if you do not use the default relationship Type
constructor, that is with no params. then you MUST create an explicit relationship
type.
What we really need to do for this specific
case is not jump to conclusion we open up the grammar (once again and invite
another months of debate and anguish), but rather see how either side of
the ConnectsTo relationship (the source and target nodes) can more easily
access the others' Endpoint (IP address) information by default whenever
using ConnectsTo. Then this addtional property in the ELK use case goes
away and we have no other use case that requires us to change the grammar
to create "on-the-fly" types.
Kind regards,
Matt
From:
Chris Lauwers <>
To:
Sahdev P Zala/Durham/IBM@IBMUS
Cc:
""
<>
Date:
04/14/2015 03:54 PM
Subject:
[tosca] RE:
2015-04-13 tosca_elk_DRAFT_CSAR: issues with requirements
Sent by:
<>
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:]
Sent: Tuesday, April 14, 2015 8:18 AM
To: Chris Lauwers
Cc:
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 <>
To: Sahdev
P Zala/Durham/IBM@IBMUS
Cc: ""
<>
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:]
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
