Draft Minutes of OASIS TOSCA TC MeetingURL OF CALENDAR EVENT (this also has meeting attendance): https://www.oasis-open.org/apps/org/workgroup/tosca/event.php?event_id=32586DATE: June 7, 2012TIME: 12:00 noon EDTScribe: Richard Probst (SAP)

Meeting was quorate: YES

Observers:

Cloudsoft Corporation Limited Rich Miller

Hewlett-Packard Bryan Murray

Roster [The co-chairs maintain the roster based on the TC Process rules. Since rights are gained/lost at the end of a meeting and the co-chairs update between meetings, the roster should be accurate at the start of each meeting. You can view it at: http://www.oasis-open.org/apps/org/workgroup/tosca/members/roster.php]

Approval of MinutesSimon Moser moved for the below draft minutes to be approved. Seconded by Paul Lipton. Date of meeting: May 31, 2012: https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/46146/TOSCA%20TC%20Minutes%202012-05-31.docxMotion PASSES by unanimous consent

Approved Agenda:

Based on review and discussion of the proposed agenda, Simon Moser moved for the below agenda to be approved. Seconded by Paul Lipton. Motion PASSES by unanimous consent.

P R O P O S E D   A G E N D A

Welcome / Roll for those who cannot record their own attendance

Co-chair appoints a scribe

Review/approve draft proposed agenda

Review/approve draft minutes

* May 31: https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/46146/TOSCA%20TC

%20Minutes%202012-05-31.docx

* Thanks to Dale Moberg for scribing

 

Editors status report 

* Problems, questions, etc. 

 

Spec issues/Proposals/Bugs queue (time permitting)

NOTE: When practical, JIRA issues/proposals will be evaluated in the context of use cases detailed or

subtasked in TOSCA-8* TOSCA-8: http://tools.oasis-open.org/issues/browse/TOSCA-8 (Use Case Bucket)

** Issues Related to Pretty Normal PHP Application in the formation of a Service Template - Tobias Kunze* TOSCA-17: http://tools.oasis-open.org/issues/browse/TOSCA-17 (Packaging Format for TOSCA) 

** Follow-up on last week's discussion. 

** Suggested strawpoll: consensus on eliminating Java specifics from packaging format and using

TOSCA-extended ZIP format?  General discussion: What are the primary remaining meta-language (spec only) gaps? Continued: Spec issues/Proposals/Bugs queue (time permitting)* TOSCA-12: http://tools.oasis-open.org/issues/browse/TOSCA-12 (Set of Basic Node Types for Defining Topology Templates) * TOSCA-11: http://tools.oasis-open.org/issues/browse/TOSCA-11 (Set of Fundamental Lifecycle

Operations) 

* TOSCA-13 http://tools.oasis-open.org/issues/browse/TOSCA-13 (definitions of portability and

interoperability) [Subtask of TOSCA-16]

* TOSCA-16 http://tools.oasis-open.org/issues/browse/TOSCA-16 (Primer Deliverables - Uber Issue)

* TOSCA-18: http://tools.oasis-open.org/issues/browse/TOSCA-18 (Resource Requirements and

Capabilities) 

* TOSCA-14: http://tools.oasis-open.org/issues/browse/TOSCA-14 (Policy Languages) [subtask of

TOSCA-3]

* TOSCA-3: http://tools.oasis-open.org/issues/browse/TOSCA-3 (Grouping element for policies - Uber

Issue) 

 

Tabled  Issues/Proposals/Bugs

* TOSCA-9: http://tools.oasis-open.org/issues/browse/TOSCA-9 (Relationship of Plans to Infrastructure)

 

General discussion (time permitting)

* REMINDER: While a general approach can be decided by motion, specific technical proposals need to

be JIRA issues

* Next meeting

* AOB

Other Motions and Results (broken out from below):

None

Motion to Adjourn:

MOTION to adjourn by Simon Moser. Second by Paul Lipton. Motion PASSES by unanimous consent. Meeting adjourned at 1:30 PM EDT

Raw Chat Log:

Paul Lipton (Co-Chair) C: Hi, all. Welcome to today's meeting of the TOSCA TC (starting promptly at 5 minutes after the hour)!

Attendance Recording: Participants are responsible to log their attendance on the Kavi calendar event at http://www.oasis-open.org/apps/org/workgroup/tosca/event.php?event_id=32585. This page also has phone bridge, proposed agenda, links to resources and more. Please look now, if you have not already done so.

When you join the meeting, use this page to record your attendance by clicking "Record My Attendance". If you are not on the internet, you can request the co-chair to record your attendance on your behalf.

PHONE BRIDGE AND WEB CONFERENCING: THIS MEETING ONLY. PLEASE SEE THE EMAIL AT: https://www.oasis-open.org/apps/org/workgroup/tosca/email/archives/201206/msg00005.html

Scribe Queue (we need volunteers!): Michael Schuster (21 June)

Simon Moser will be running today's meeting.anonymous1 morphed into Dale Moberg, AxwatDale Moberg, Axwat morphed into Dale Moberg, Axwayanonymous morphed into Simon Moser (co-chair)Simon Moser (co-chair): Hello everybodySimon Moser (co-chair): Please note that the teleconference information has changed - today we need to use a different call-in numberanonymous morphed into Bryan Haynie (VCE)Simon Moser (co-chair): https://www.oasis-open.org/apps/org/workgroup/tosca/email/archives/201206/msg00005.htmlanonymous morphed into Paul Zhang (Huawei)Paul Lipton (Co-Chair) C: I seem to be on mute. How do you get off mute on this bridge (and hi)?Aaron(Huawei): Can anyone tell me what the access code is for the meeting?Paul Lipton (Co-Chair) C: Also, the web conference did not work with Google Chrome for me, FYI*.Thomas Spatzier (IBM): @Paul: try *6Simon Moser (co-chair): 12533845Simon Moser (co-chair): is the access codePaul Lipton (Co-Chair) C: Tried *6 and it didn't work. Will dial in again.Aaron(Huawei): Thanksanonymous morphed into Doug Neuse (CA)Richard Probst (SAP) morphed into scribe - Richard Probst (SAP)scribe - Richard Probst (SAP): meeting is quorateSimon Moser (co-chair): P R O P O S E D A G E N D AWelcome / Roll for those who cannot record their own attendanceCo-chair appoints a scribeReview/approve draft proposed agendaReview/approve draft minutes* May 31: https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/46146/TOSCA%20TC%20Minutes%202012-05-31.docx* Thanks to Dale Moberg for scribing Editors status report * Problems, questions, etc. Spec issues/Proposals/Bugs queue (time permitting)

NOTE: When practical, JIRA issues/proposals will be evaluated in the context of use cases detailed or subtasked in TOSCA-8* TOSCA-8: http://tools.oasis-open.org/issues/browse/TOSCA-8 (Use Case Bucket)** Issues Related to Pretty Normal PHP Application in the formation of a Service Template - Tobias Kunze* TOSCA-17: http://tools.oasis-open.org/issues/browse/TOSCA-17 (Packaging Format for TOSCA) ** Follow-up on last week's discussion. ** Suggested strawpoll: consensus on eliminating Java specifics from packaging format and using TOSCA-extended ZIP format?

General discussion: What are the primary remaining meta-language (spec only) gaps?

Continued: Spec issues/Proposals/Bugs queue (time permitting)* TOSCA-12: http://tools.oasis-open.org/issues/browse/TOSCA-12 (Set of Basic Node Types for Defining Topology Templates) * TOSCA-11: http://tools.oasis-open.org/issues/browse/TOSCA-11 (Set of Fundamental Lifecycle Operations) * TOSCA-13 http://tools.oasis-open.org/issues/browse/TOSCA-13 (definitions of portability and interoperability) [Subtask of TOSCA-16]* TOSCA-16 http://tools.oasis-open.org/issues/browse/TOSCA-16 (Primer Deliverables - Uber Issue)* TOSCA-18: http://tools.oasis-open.org/issues/browse/TOSCA-18 (Resource Requirements and Capabilities) * TOSCA-14: http://tools.oasis-open.org/issues/browse/TOSCA-14 (Policy Languages) [subtask of TOSCA-3]* TOSCA-3: http://tools.oasis-open.org/issues/browse/TOSCA-3 (Grouping element for policies - Uber Issue) Tabled Issues/Proposals/Bugs* TOSCA-9: http://tools.oasis-open.org/issues/browse/TOSCA-9 (Relationship of Plans to Infrastructure) General discussion (time permitting)* REMINDER: While a general approach can be decided by motion, specific technical proposals need to be JIRA issues* Next meeting* AOB

Paul Lipton (Co-Chair) C: Sorry about the phone bridge and web access, but I wasn't sure I'd have connectivity.Paul Lipton (Co-Chair) C: Simon kindly provided both.Paul Lipton (Co-Chair) C: Paul seconds motion to approve agendascribe - Richard Probst (SAP): Simon moves agenda, Paul secondsscribe - Richard Probst (SAP): agenda accepted without objectionPaul Lipton (Co-Chair) C: @Richard, just wanted to see if I could type faster than you, Richard. scribe - Richard Probst (SAP): Simon moves to accept minutes, Paul secondsscribe - Richard Probst (SAP): minutes accepted without objectionscribe - Richard Probst (SAP): editor update from Thomas: work in progress but nothing to discuss this weekscribe - Richard Probst (SAP): continue discussion on TOSCA-8Paul Lipton (Co-Chair) C: Wanna put this in the web conference?scribe - Richard Probst (SAP): Tobias has been mapping his use-case to TOSCA, has come up with about 9 node types

Alex Heneveld (Cloudsoft): I'm on Chrome and it's okay for me ... but that's no guaranteeBryan Haynie (VCE): chrome works for mescribe - Richard Probst (SAP): Tobias created node templates for the elements of his PHP use-case, using YAML (hopefully easier to parse)scribe - Richard Probst (SAP): PHP use-case expects a PaaS -- the service template references services provided by the platformscribe - Richard Probst (SAP): Tobias has not yet added relationships to service templatescribe - Richard Probst (SAP): showed internal document how Red Hat thinks of relationships -- they have operationsscribe - Richard Probst (SAP): Tobias has identified 9 issuesPaul Lipton (Co-Chair) C: # ISSUES8 # 9 # 1 Node Type components need to be addressable, either via interfaces or10 # in a more structured way. Component role must be understood (e.g. 11 # what is PHP, what is ZF)12 # Suggest to introduce "Component" as a technical term, denoting the,13 # well, components of a NodeType. Also, suggest that these 14 # components are addressed using period (".") as a separator15 # 2 Some NodeTypes are "abstract", e.g. "myapp". Static files (kind of)16 # become part of *staticserver and Code (kind of) becomes part of17 # *zendserver.php18 # 3 "Require"/"Provide" is a much more flexible mechanism than just19 # referencing NodeTypes with "DerivedFrom".20 # 4 The inheritance aspects of the "DerivedFrom" element need to be21 # complemented with a separate, immutable form that occurs when a22 # NodeType is provided by the platform. E.g.23 # 5 When a NodeType is provided, the ability to express requirements24 # (e.g. applying to resource allocation or specific run modes) becomes25 # important26 # 6 The NodeType ID field is superfluous27 # 7 NodeTypes should have a "Version" field28 # 8 NodeTypeProperties need "name", "value", and optionally maybe "type"29 # 9 Naming and capitalization is odd, e.g. "NodeTypeProperties" vs30 # "requestURI" vs "name"31Frank Leymann (IBM): Comment: I don't understand why something that is superfluous (item #6) results in an issue.Paul Lipton (CA) A morphed into Paul Lipton (Co-chair) AAaron(Huawei): execue me, but could anyone tell me the link for web conference? I can't find the new link for today's meetingMatt Rutkowski (IBM)1: Simon can you please record my attendancescribe - Richard Probst (SAP): Thomas comments on issue #1 -- isn't this the same as Deployment Artifact?scribe - Richard Probst (SAP): at least the concept is already the sameanonymous morphed into Rich Millerscribe - Richard Probst (SAP): Tobias agrees this seems similar, but should PHP component be seen as a DA? PHP component is made available thru Apache as libraryAaron(Huawei): ? I see Paul's (Co-chair) message in WebEX, but can't find the linkPaul Lipton (Co-Chair) C: @Frank, let's go through each issue that Tobias has identified. Please reserve for item #6.scribe - Richard Probst (SAP): Tobias: more general issue is that elements need to know about components of other elementsKoert Struijk (CA): Lotus Live:

1. Go to the URL - http://www.webdialogs.com2. Click 'Join a Meeting' button in the top right corner of the page3. Enter the Conference ID 12043044. Enter your name and email address5. Click the 'Log In' buttonPaul Lipton (Co-Chair) C: @Aaron, see email at: https://www.oasis-open.org/apps/org/workgroup/tosca/email/archives/201206/msg00005.htmlscribe - Richard Probst (SAP): Thomas thinks a node contained in a node can satisfy the need to name components, without introducing a new top-level conceptAaron(Huawei): @Koert: Many thanks. Got it.scribe - Richard Probst (SAP): Tobias will try to use nested nodes to represent componentsscribe - Richard Probst (SAP): and also will try using DAs, and also doing it with a new "component" concept, to see which works bestThomas Spatzier (IBM): So "nested" Nodes would be: NodeTemplate A (of NodeType a) -> contains relationship -> NodeTemplate B (of NodeType b)scribe - Richard Probst (SAP): <scribe hat off> +1 to Requires/Provides !Alex Heneveld (Cloudsoft): +1 require/provide definitelyscribe - Richard Probst (SAP): Paul asks to test consensus around Tobias's issuesscribe - Richard Probst (SAP): Tobias: issue 4 means a service provided by a platform should not be modeled as DerivedFrom since it cannot be modifiedDerek Palma (Vnomic): To me point 3 means: Node Type derivation should not allow extension beyond the restricted domains of the super Node TypeFrank Leymann (IBM): Can we solve #4 by introducing a "final" attribute for properties...?Derek Palma (Vnomic): that is one common wayscribe - Richard Probst (SAP): <scribe hat off> how would over-provisioning be modeled?Derek Palma (Vnomic): but it really has to enforce that the domain is not expanded. I.e. it's a subset.Simon Moser (co-chair): (co-chair hat off) +1 to Franks suggestion to introduce things like "final" on node type attributesscribe - Richard Probst (SAP): Tobias agrees a "final" attribute could be a solution to issue 4scribe - Richard Probst (SAP): Simon heard consensus on 2 and 3, agreement that something like 4 is needed, issue 1 needs to be reviewedscribe - Richard Probst (SAP): issue 5 is more a demonstration of need than an issuescribe - Richard Probst (SAP): Simon (with co-chair hat off) says issue 6 (NodeType ID is superfluous) may apply to YAML but not to other implementationsThomas Spatzier (IBM): In TOSCA in the current spec, we state that the fully-qualified name (QName) of a NodeType is built from targetNamespace and id. Therefore it is required.scribe - Richard Probst (SAP): Tobias: 3 choices: (1) name is required, ID is optional; (2) ID is required, name is optional; (3) YAML uses name, XML uses IDThomas Spatzier (IBM): The name attribute is optional and meant to be a human-readable name.Derek Palma (Vnomic): id guarantees uniqueness. name is not necessarily unique. We need some notion of identity to be carried across all serializations.Frank Leymann (IBM): +1 to derekscribe - Richard Probst (SAP): Marv says names may not be unique

scribe - Richard Probst (SAP): Tobias agrees names might not be unique, which would be a problemMatt Rutkowski (IBM): You would have to qualify an ID as a GUID and decide if you want it URI based or notPaul Lipton (Co-Chair) C: @Marv, did you say id may not be unique, either?Matt Rutkowski (IBM): or a UUID for instancesPaul Lipton (Co-Chair) C: gotchaMarv Waschke (CA): @Matt Exactly!Matt Rutkowski (IBM): then you would have to decide if the UUIDs are time dependent or not and reference approved mechanisms/algorithmsMarv Waschke (CA): Global uniqueness is always an issue. I prefer a name space approach, myself.scribe - Richard Probst (SAP): Tobias proposes to replace ID with human-readable name, to remove 1 "geek field"Matt Rutkowski (IBM): Then TOSCA would have to decide who the "authority" would be (DNS may not work)Koert Struijk (CA): You might want to be able to have a group of items - if you reuse the same name, the id allows you to still individually address the items. I can't think of a use case for this at the moment, though.scribe - Richard Probst (SAP): Tobias has similar reaction to some of the details of the packaging proposal -- remove the geek fields!Paul Lipton (Co-Chair) C: Do Service Template names really need to be globally unique (just wonderin')? Paul Lipton (Co-Chair) C: I mean names within a Service Template. I guess so, if you were to import, for example.scribe - Richard Probst (SAP): Derek says that translation between XML and YAML need to be handled carefully to preserve what is guaranteed to be uniqueMarv Waschke (CA): If templates are to be shared, it seems awkward to have to change the id as it moves from installation to installation.scribe - Richard Probst (SAP): Especially if you translate back and forth XML to YAML to XML to YAMLPaul Lipton (Co-Chair) C: So, is consensus that we need to make this work on YAML and on XML side? Does this need to be a JIRA issue?Paul Lipton (Co-Chair) C: Oops! Somebody just asked the same thing. Alex Heneveld (Cloudsoft): ID=1 is not likely be globally unique Alex Heneveld (Cloudsoft): what about ID="user-agent", with convention it should be locally unique, inheriting a namespace which gives it global uniquenessscribe - Richard Probst (SAP): Simon proposes we should open JIRA issues on most / all of Tobias's issuesscribe - Richard Probst (SAP): Paul would prefer not to open so many tiny JIRA issues -- maybe just aggregate as 1scribe - Richard Probst (SAP): Thomas says issue 8 is already in the specscribe - Richard Probst (SAP): Thomas says capitalization (issue 9) was on purpose -- maybe only a problem when translating to YAML?scribe - Richard Probst (SAP): Tobias argues for being language-agnostic and readable -- remove the Java-ismsMarv Waschke (CA): @alex- that would satisfy my concerns.Frank Leymann (IBM): I don't understand at all what the Java-isms are.scribe - Richard Probst (SAP): Simon agrees with goal of maximizing adoption, so let's look at the proposalsFrank Leymann (IBM): The style of naming currently used in TOSCA (e.g.) can be found in many other standards too.scribe - Richard Probst (SAP): Paul has created TOSCA-20 and asks Tobias to fill with references to today's document and today's minutesDerek Palma (Vnomic): Can we get a list of what these Java-isms are because at the XML level they are not obvious to me.

Frank Leymann (IBM): +1 to Derekscribe - Richard Probst (SAP): Paul asks re consensus on issues 6 thru 9scribe - Richard Probst (SAP): Tobias likes idea of making ID a string, but then why not call it "name"Thomas Spatzier (IBM): ID can be a string today.Thomas Spatzier (IBM): It's of type xs:IDDerek Palma (Vnomic): We have to have a notion of identity for uniqueness. We don't need to dictate this for specific serializations.Alex Heneveld (Cloudsoft): would it be useful to be able to refer to NodeTypes defined in other projects?Alex Heneveld (Cloudsoft): +1 ... ID and NAME serve the same function don't they?scribe - Richard Probst (SAP): Paul asks if we should remove ID? Tobias says eliminate either name or IDSundaresh(CA) : Agree with Tobias. Remove IDscribe - Richard Probst (SAP): Marv agrees with TobiasDerek Palma (Vnomic): Currently we have ID and display name. We have to have ID.Thomas Spatzier (IBM): name is optionalDoug Davis (IBM): why not keep a user-friendly "name" ?Frank Leymann (IBM): IDs are for uniqueness, Names are for humansDoug Davis (IBM): exactlyFrank Leymann (IBM): names are optional, if you don't like them, omit thenMatt Rutkowski (IBM): I disagreeDoug Davis (IBM): names do not need to be unique at allMatt Rutkowski (IBM): Names and IDs are necessaryFrank Leymann (IBM): Many XML based standards work exactly the same as we have it in TOSCA todayMatt Rutkowski (IBM): Please see comments I made abovescribe - Richard Probst (SAP): Derek says we need ID in XML, and we can map it when translating to YAMLDoug Davis (IBM): ID should be globally unique, Name should be optional and not requirement for it to be unique. Make it clear that Name is for humans.Matt Rutkowski (IBM): +1 DougMatt Rutkowski (IBM): GUID at the very leastscribe - Richard Probst (SAP): Tobias asks if ID is required by XML validator?Alex Heneveld (Cloudsoft): can ID be something like "user-agent" ?Frank Leymann (IBM): +1 to Doug, that's in the spec today Alex Heneveld (Cloudsoft): best of both worldsThomas Spatzier (IBM): @Alex: Yes, it can.Doug Davis (IBM): to me "Name" goes along with a "description" type of field - for humans - provider shouldn't do anything with them except echo them back to clients.Alex Heneveld (Cloudsoft): thanks @Thomas. great. nice if these _files_ can be written by a user ... if we use class-name style for ID's that's possible harder if i'm expected to write 243A4E0 scribe - Richard Probst (SAP): Derek says don't worry about this, just provide a (good) translatorscribe - Richard Probst (SAP): from XML to YAML and vice versaDoug Davis (IBM): that's a yaml issue, not a tosca model issue, no?scribe - Richard Probst (SAP): Tobias doesn't see why we have to use XML IDsDoug Davis (IBM): maybe some serializations won't expose all fields - would be a shame but that's their choice as long as those fields are optional.Thomas Spatzier (IBM): If the XSD type is xs:ID, the XML processor ensures that the id is unique in the document.Thomas Spatzier (IBM): For global uniqueness we have the namespace in addition.

scribe - Richard Probst (SAP): Simon: let's split the issues into those we have consensus on and those we still need to debatescribe - Richard Probst (SAP): Paul asks Tobias to create TOSCA-21 for just his issue 6Matt Rutkowski (IBM): Namespace does NOT guarantee uniqueness unless "authority" guarantees itTobias Kunze (Red Hat): @Thomas: but XML doesn't force you to do it that wayscribe - Richard Probst (SAP): Simon moves to adjourn, Paul secondsMatt Rutkowski (IBM): the discussion of GUID is too XML centricDoug Davis (IBM): btw - you don't need a motion to end the meeting if your at the designated endtime Thomas Spatzier (IBM): But nice to leverage features of the XML processor.scribe - Richard Probst (SAP): adjourned without objectionMatt Rutkowski (IBM): it should be more about a unique reference mechanismAlex Heneveld (Cloudsoft): bye all