Retrying as first attempt was denied..I agree with Chris on the fact that allowing augmentation of interface to add parameters is quite nice, the way I see interfaces in TOSCA is basically to define some lifecycle management (potentially automated like for our Standard interface that allows to manage creation and deletion lifecycles). The parameters and how they are injected are not that much relevant to interfaces and operation Types in TOSCA but more to their implementation that specifies both implementation script and inputs with their values (get_property / attribute / artifacts do the job here).
Now the other questions is, do we need to provide some relationship type or not, I think the interest of types in TOSCA is reusability, when scripts are defined at the template level we loose some reusability anyway (In our example it is not possible to reuse the ElasticSearch component outside of the EKL easily as the type doesn’t specifies the implementation but the implementation is lost in the middle of a topology template). So in such situation I don’t think that creating a type brings value. Even in a Node type we could specify an inline relationship with it’s implementation if we don’t think that the relationship can be reused (because it’s really related to both source and target component for example).
That said we are currently focusing on one of the 2 way to use TOSCA which is to allow people to develop really fast a template of a portable deployment - in this usage Types doesn’t bring a lot of value. This is great but I think there is another great value in TOSCA where types brings a lot of value which is reusability of components. Indeed in an enterprise I think that elastic-search can be used in an EKL topology but also in many other topologies with other components. And still I don’t want to develop again and again or copy (with the difficulty to maintain changes) the scripts in a template CSAR and antother template CSAR. This is why we can define node types with implementations and just create templates that refers these nodes types. This would mean that the implementation scripts are not placed at the node template level but on the node type level. In such situation I guess that interface augmentation is still valid (for same reasons expressed before - they are more used for lifecycle ordering and management in my opinion), but some relationships may want to define new types in order to be reused in some other context, and the more you can make your scripts reusable the best it is. For example you could make a generic config file token based replacement relationship that applies to many different softwares.
I think the reusability kind of use-case is great and really shows the power of TOSCA vs other specs while the first use-case (current EKL) shows the ability to provide to ops a way to work very fast (before making things more reusable though types ;))
Luc
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 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
<image001.jpg>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 messageDocument for InterOp. SC review. Thanks to Matt and Christopher Kaufmann for their initial comments, update the draft with some minor changes. Thanks! -- Sahdev Zala
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
|
|