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] Groups - 2015-04-19 tosca_elk_DRAFT_CSAR.zip uploaded

Hi Chris,

Appreciate your thorough review. Very helpful.

I am still little confused about MyConnectTo so other than that I have replied your comments below in-line. Most of them are straightforward except few where I have question/comment. Please take a look.

Since how we should deal with custom relationship is under discussion, I think it would be a quicker and better to discuss it during one of our group calls.


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/20/2015 04:26 PM
Subject:        RE: [tosca] Groups - 2015-04-19 tosca_elk_DRAFT_CSAR.zip uploaded

Thanks Sahdev, but I don’t believe this change fixes the problem, it only moves it somewhere else. Yes, we now have a new MyConnectsTo relationship type, but MyConnectsTo implicitly creates a new Interface Type (based on tosca.interfaces.relationship.Configure) that adds a new input parameter. If we’re not allowed to dynamically “augment” types in entity definitions, then clearly augmenting Interface Types shouldn’t be allowed either. The correct solution here is to explicitly introduce a new Interface Type (e.g. MyConfigure) that derives from Configure and then have MyConnectsTo use the MyConfigure interface.
In addition, your change doesn’t address the corresponding issue in requirement assignments. For example, the logstash node template uses an “in-line” relationship assignment syntax to assign an IP address value to the IP address input defined in the MyConnectsTo relationship type. According to the spec, this is not allowed. Instead, a new relationship template needs to be defined explicitly.
(Note that my argument here is solely based on what’s in the spec. I want to re-iterate my personal opinion that the spec is too restrictive and that what you were trying to do in the first version of this file is perfectly acceptable and should be allowed).
Aside from the requirements-related issues, here are some other comments (in no particular order)
1.       The tosca_base_type_definition.yaml file is not a valid Tosca file (i.e. it doesn’t include any valid Tosca keynames) and as such should not be used in an “import” statement
          (sahdev) Sorry but I didn't exactly get it. To me, this file represents normative types and related definition as defined in the spec. I am specially confused when you said " it doesn’t include any valid Tosca keynames". I am fine to take it out of CSAR per my answer to your next comment.
2.       More importantly, in my opinion it should be the responsibility of the Tosca runtime to import all the normative type definitions, not the responsibility of the application developer.
          (sahdev) OK, that's fine. Actually, that's how we do it in heat-translator. I put in import thinking that if someone want to try CSAR as such in an environment where normative type aren't handled at runtime then also CSAR will work. I am good removing related import statement if all agree and in that case I think it's a good idea to update README about assumption we are making here.
3.       The PayPalPizzaStore node type defines a “database_connection” capability with capability type tosca.capabilities.DatabaseEndpoint. There is no such type in the normative type definitions. The correct type is tosca.capabilities.Endpoint.Database
(sahdev) Yes, my bad. It was there but I missed the latest changes. I will fix it.
4.       A number of node templates include a “get_attribute[<server>, ip_address]” where <server> is an instance of Compute. However, Compute no longer has IP address attributes. For this use case, I believe we need to use “private_address” instead.
(sahdev) Yes, agree. I missed the latest in spec here as well.
5.       In the MyConnectsTo relationship type definition, you reference the Configure interface by its type name (tosca.interfaces.relationship.Configure) rather than by its symbolic name (which is “Configure”).
(sahdev) Sorry here too and for following two comments, but I think it's up to template author whether to use the full name or short?
6.       You have a similar problem in the PayPalPizzaStore node type: you refer the “Standard” interface by its type name (tosca.interfaces.node.lifecycle.Standard) rather than by its symbolic name.
7.       This problem then carries over into all the node templates as well (about a dozen instances). Whenever you reference an interface, you refer to that interface by its type name rather than by its symbolic name.
8.       Your “list” syntax is incorrect for requirements definitions in logstash.yaml. There is a missing “dash” before the “search_endpoint” requirement name. The correct syntax is as follows:
        (sahdev) Ah, it was correct in the previous draft but I missed "dash" in the current draft while making changes. I will fix it.
    derived_from: tosca.nodes.SoftwareComponent
      - search_endpoint:
          capability: tosca.capabilities.Endpoint
          node: tosca.nodes.SoftwareComponent.Elasticsearch
          relationship: tosca.relationships.MyConnectsTo
9.       Whenever you declare inputs to an Operation in an Interface, you use the “input” keyname rather than the “inputs” keyname. I don’t believe “input” is a valid keyname anywhere in the Tosca spec.
(sahdev) Yup, agree. I have used it correctly certain places and missed it at  few places.  I will fix it.
10.   The “mongo_db” node template fails to set the following required properties: “user”, “name”, “port”, and “password”.
(sahdev) I have a point to make here, the default installation of mongoDB doesn't require user, password, port or db name. The scripts we have doesn't require any of these. When we created this use case, I found from people who have worked with mongo db that the default implementation is a common usage and provides a simple configuration. Using mongoDB as an example, I feel that the properties for Database and DBMS should be optional instead of required. Something to discuss in our YAML call.
11.   The “paypal_pizzastore” node template fails to set the required property “context_root”
(sahdev) Hmm... The spec has “context_root” as optional an optional property for WebApplication and I think the template is not explicitly mentioned it anywhere. Please help me understand.
12.   The “mongo_dbms” node template fails to set the required properties “port” and “root_password”
(sahdev) (Same as my reply for #10.)
13.   In the “interfaces” section of the “paypal_pizzastore” node template, the “mongodb_ip” and “github_url” inputs are assigned only for the “configure” operation, but in the PayPalPizzaStore node type these inputs are declared for all operations in the “Standard” interface. The correct assignment is as follows:
       (sahdev) I see. Since these inputs are only required for 'configure', may be better to update the custom type definition for paypay_pizzastore though I agree what you recommended correct the grammar.
      type: tosca.nodes.WebApplication.PayPalPizzaStore
             github_url: { get_property: [ SELF, github_url ] }
             mongodb_ip: { get_attribute: [mongo_server, private_address] }
             implementation: Scripts/nodejs/configure.sh
           start: Scripts/nodejs/start.sh
Let me know if you need more detail on any of these,
Best regards,
From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Sahdev Zala
Sunday, April 19, 2015 8:17 PM
[tosca] Groups - 2015-04-19 tosca_elk_DRAFT_CSAR.zip uploaded

Submitter's message
Hello, in this draft, I have tried modifying the requirements section per comments from Chris Lauwers. For logstash types I have created a custom relationship for now as the topic is still under discussion. Thanks!
-- Sahdev Zala

Document Name: 2015-04-19 tosca_elk_DRAFT_CSAR.zip

No description provided.
Download Latest Revision
Public Download Link

Submitter: Sahdev Zala
: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
: Working Documents
Date submitted
: 2015-04-19 20:16:21


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