[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (TOSCA-7) Alternative Encodings of TOSCA Service Templates
[ http://tools.oasis-open.org/issues/browse/TOSCA-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36336#action_36336 ]
Paul Lipton commented on TOSCA-7:
----------------------------------
Apologies. This comment is slightly out of sequence. Thomas kindly walked us through his YAML by Example document. Matt kindly taking scribing duties from Thomas (double thank you's to both!).
Minutes can be found at https://www.oasis-open.org/committees/document.php?document_id=51908&wg_abbrev=tosca). Discussion excerpted below:
[09:57] Thomas Spatzier (IBM - scribe): next topic TOSCA-7
[09:57] Jacques (Fujitsu): In Kishore proposal: if Relationship types are entirely defined based on Capabilities and Requirements, then Node types seem to become much less important in a topology? I.e. The main reason for the concept of "Node type" seems to be an aggregator of Capabilities and Requirements.
[09:58] Thomas Spatzier (IBM - scribe): Matt will give overview and brief into to TOSCA Simple Profile by example document
[09:58] Paul Lipton (co-chair) WebConf: @Simon, please make document full width.
[10:01] Matt Rutkowski (IBM) morphed into Matt Rutkowski (IBM) - scribe
[10:04] Matt Rutkowski (IBM) - scribe: Thomas: describing section 2 of "by example" TOSCA simple profile doc
[10:04] Matt Rutkowski (IBM) - scribe: Thomas: still dependencies on normative NodeType definition work
[10:04] Matt Rutkowski (IBM) - scribe: Thomas: ssction 2.1 describes input/output parameter example
[10:05] Matt Rutkowski (IBM) - scribe: Thomas: kind of matches XML bounary defintions, presented as Input.Output is easier to understand
[10:06] Matt Rutkowski (IBM) - scribe: Thomas: 2.1 also allows constraints on I/O Parms (i.e. valid values)
[10:07] Matt Rutkowski (IBM) - scribe: Thomas: NodeType is still "master" of constraints on properties, I/O constraints should describe more constraints that align with and further restrict the ones declared by the node type thay will be passed to
[10:08] Matt Rutkowski (IBM) - scribe: Thomas: please read doc. offline and email comments (or open issues)
[10:09] Matt Rutkowski (IBM) - scribe: Thomas: we wish to address new use cases with this YAML work, please provide them.
[10:10] Matt Rutkowski (IBM) - scribe: Thomas: Section 3: have 2 nodes that refence each other, relationship template section is not included in this profile instead relationships can be inferred from the "requires" section (still can be explicitly declared)
[10:10] Matt Rutkowski (IBM) - scribe: Thomas: much more compact style
[10:11] Matt Rutkowski (IBM) - scribe: Jesus: like to know objective, translation from XML to YAML?
[10:11] Matt Rutkowski (IBM) - scribe: Thomas: goal to have transalation from XML to YAMl and vice versa
[10:12] Matt Rutkowski (IBM) - scribe: Jesus: will there be a document to show translation
[10:12] Matt Rutkowski (IBM) - scribe: Thomas: yes, perhap in this same or diff. document
[10:13] Matt Rutkowski (IBM) - scribe: Matt: intend to add a translation appendix to this profile document
[10:14] Matt Rutkowski (IBM) - scribe: Matt: may split apart later
[10:15] Matt Rutkowski (IBM) - scribe: Karsten: had similar question as Jesus... for sake of simplicity, the YAML spec. might be a subset of the XML spec. but currently have the same level of what can be expressed. perhaps need TC clarification
[10:15] Matt Rutkowski (IBM) - scribe: Thomas: not 100% clear, at the end it may be 100% or may be a subset. Want to make this use case driven.
[10:17] Matt Rutkowski (IBM) - scribe: Thomas: If there ends up being something in v1.0 (XML) spec. (at the end of the first YAML profile version), then we would address or document with TC
[10:17] Matt Rutkowski (IBM) - scribe: Thomas: could imagine, simple profile may be more restrictive or not advantage all XML spec. options
[10:19] Matt Rutkowski (IBM) - scribe: Derek: YAML is a good place to move TOSCA, greater audience. In some ways, could morph TOSCA into something more usable and practical. Should attempt to express the same types of constructs as TOSCA today, could be as powerful as current DSL. Many companies may not want toimpl. both XML and YAML
[10:20] Matt Rutkowski (IBM) - scribe: Derek: at some point we may revisit what is canonical XML or YAML based upon which provides TOSCA most success/adoption, Perhaps in future agree to move over to YAML if it has great success as canonical
[10:21] Matt Rutkowski (IBM) - scribe: Thomas: section 4: introduces a new feature. allows node templates to provide simple/small updates to existing node types without defining new node types by "overriding" a portion (of the node type template is derived from)
[10:22] Matt Rutkowski (IBM) - scribe: Thomas: had this in early TOSCA but removed for fear of complexity, but believes we can define what is strictly allowed and provides powerful benefits
[10:23] Matt Rutkowski (IBM) - scribe: Thomas: section 6: new concept introduced. "requires" section is very compact
[10:24] Matt Rutkowski (IBM) - scribe: Thomas: orchestrator can derive the relationship type (a base type). Custom or explicit types are allowed as well (see my.types.WordPressDbConnecton) example
[10:25] Matt Rutkowski (IBM) - scribe: Thomas: Section 8: Address use case from Travis at HP
[10:25] Matt Rutkowski (IBM) - scribe: Thomas: allows templates to add constraints on an abstract Compute node
[10:26] Matt Rutkowski (IBM) - scribe: Simon: can be downloaded and reviwed (part of TOSCA 7)
[10:26] Matt Rutkowski (IBM) - scribe: Simon: can continue review at next week's meeting
> Alternative Encodings of TOSCA Service Templates
> ------------------------------------------------
>
> Key: TOSCA-7
> URL: http://tools.oasis-open.org/issues/browse/TOSCA-7
> Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
> Issue Type: Improvement
> Components: Spec
> Affects Versions: V1.1_CSD01
> Reporter: Derek Palma
> Assignee: Krishna Raman
> Fix For: V1.1_CSD01
>
>
> At the last (Jan 26) TC meeting there was some discussion about Alternative Encodings of TOSCA Service Templates. It may be useful to augment the draft to explicitly address this issue so it is clear that TOSCA is not confining itself to only XML encodings.
> Below is some text which captures some of these ideas:
> Alternative Encodings of TOSCA Service Templates
> The Topology and Specification for Cloud Applications (TOSCA) is a metamodel which specifies the core concepts, entities, relations and constraints required for defining IT services. This metamodel is encoded in this specification using XML Schema and related standards. Service Templates are instances of entities compliant with the TOSCA metamodel endcoded in XML following the syntactic rules governed by XML Schema and XML Specification.
> In order to further applicability and facilitate adoption, the TOSCA TC acknowledges the diversity of clouds, offering a diversity of languages and frameworks, with their respective user bases, and anticipates the need to represent Service Templates in encodings other than XML (e.g. YAML, JSON) as well as the need for API implementations in multiple languages that can create and manipulate Service Templates serializing to/from these alternative encodings. Implementations of alternative encodings should adhere to the TOSCA semantics in order to consume/produce semantically valid Service Templates in a specific encoding and enable translations to/from the canonical XML encoding.
> Because all alternative encodings must abide by the TOSCA semantics, they can only diverge in how they represent their alternative encoding. For example, two YAML implementations may be able to consume and produce a valid Service Template XML, but may encode the Service Template differently in YAML. These diverging YAML implementations can still interoperate by translating to XML. However, if YAML interoperability is desired a set of translation rules between canonical XML and YAML need to be agreed upon.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]