[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [tosca-comment] Feedback on TOSCA 1.3 spec
|
Dear TOSCA-teers, FYI, please see the latest âAdam threadâ from TOSCA-comments, provided to you without further comment.
Regards, Paul From: tosca-comment@lists.oasis-open.org <tosca-comment@lists.oasis-open.org>
On Behalf Of Chris Lauwers Hi Adam, Thanks for the detailed feedback, and weâre excited to hear about yet another TOSCA-based orchestrator implementation. (By the way, OASIS keeps a list of TOSCA implementations at
https://wiki.oasis-open.org/tosca/TOSCA-implementations. Would you mind if we added yours?) We will try to provide detailed responses to your comments. Please be on the lookout for a response in the next couple of days. Best regards, Chris Lauwers Co-Chair, TOSCA TC From:
tosca-comment@lists.oasis-open.org <tosca-comment@lists.oasis-open.org>
On Behalf Of adam souzis Hi, I've been implementing a TOSCA 1.3 orchestrator for the past few months so I've been spending some quality time with the specification document. The software is not quite yet ready for serious use but it has implemented most of the spec,
you can find the source at https://github.com/onecommons/unfurl and
docs at https://www.onecommons.org/unfurl/. Here are some comments and questions that came up as I was implementing the specification, I hope you find them useful: # Normative questions and comments: * Unless I missed something, it appears that tosca identifiers (e.g. template names, property names etc.) are only defined as YAML strings. I assume this is under-specified? Given TOSCA's XML heritage and that namespace prefixes are still
used, should they be constrained to XML's NCName production (XML names without colons)? * The lists of node states in section 3.4.1 (p74) doesn't include "available" but it is used elsewhere in the spec. For example in the diagram on p.226. (That diagram also show the "delete" operation moving the node state from "configured"
to "configured" -- I assume that is an error and it should be "stopped" and "deleted" respectively?). The example in section 7.3.3.1 (p260) also references an "available" state. * metadata is allowed on property and attribute definitions but not on parameters (inputs and outputs) or on artifacts. Is this inconsistency an oversite? I have found it necessary to add metadata to input and artifact definitions. * requirement assignments can specify the capability and relationship types but capability assignments can not. Is this an oversite? I found declaring the type in capability assignment necessary, for example, to specify that the "endpoint"
capability of a node template is a subtype of the generic "endpoint" capability. * I have had to make other extensions to spec, some of which you may want to consider for a future version of TOSCA -- the list of changes are documented here:
https://www.onecommons.org/unfurl/tosca.html # Editorial comments: * The discussion in 13.4.1 Shell Scripts (p.360) about implementation outputs is confusing because it seems to imply that exporting an environment variable in shell script makes it available to the parent process when in fact doesn't (instead
it makes it available to child processes). To implement something like this the orchestrator would have to wrap or rewrite the shell script (that's what Yorc does) or place other requirements on the script -- for example, Cloudinary requires shell scripts
to call a helper child process to pass outputs back to the orchestrator. * It would be extremely useful if the table of contents for Section 3 Definitions was more detailed -- the core YAML vocabulary is defined there and it's hard to find those definitions currently. (Or maybe there could be a separate table
for definitions?) * Section 5.3.6.5.1 (p 198) The example looks wrong, it should be: <some_tosca_entity>: * Section
7.3.1.2: (p. 255) "on_success" should be a list * Section 13.4.1 Example on p. 360: "template_name", etc. should be inside "metadata:" In general, the specification document is quite comprehensive and useful, thank you for all your hard work on this. Regards, Adam |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]