Tosca tc minutes 2012 06-07


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Tosca tc minutes 2012 06-07

  1. 1. Draft Minutes of OASIS TOSCA TC MeetingURL OF CALENDAR EVENT (this also has meeting attendance): June 7, 2012TIME: 12:00 noon EDTScribe: Richard Probst (SAP)Meeting was quorate: YESObservers:Cloudsoft Corporation Limited Rich MillerHewlett-Packard Bryan MurrayRoster[The co-chairs maintain the roster based on the TC Process rules. Since rights aregained/lost at the end of a meeting and the co-chairs update between meetings, the rostershould be accurate at the start of each meeting. You can view it at:]Approval of MinutesSimon Mosermoved for the below draft minutes to be approved. Seconded by Paul Lipton.Date of meeting: May 31, 2012: PASSES by unanimous consentApproved Agenda:Based on review and discussion of the proposed agenda, Simon Moser moved for the belowagenda to be approved. Seconded by Paul Lipton.Motion PASSES by unanimous consent.PROPOSED AGENDAWelcome / Roll for those who cannot record their own attendanceCo-chair appoints a scribeReview/approve draft proposed agendaReview/approve draft minutes* May 31:* Thanks to Dale Moberg for scribingEditors status report* Problems, questions, etc.Spec issues/Proposals/Bugs queue (time permitting)
  2. 2. NOTE: When practical, JIRA issues/proposals will be evaluated in the context of use cases detailed orsubtasked in TOSCA-8* TOSCA-8: (Use Case Bucket)** Issues Related to Pretty Normal PHP Application in the formation of a Service Template - TobiasKunze* TOSCA-17: (Packaging Format for TOSCA)** Follow-up on last weeks discussion.** Suggested strawpoll: consensus on eliminating Java specifics from packaging format and usingTOSCA-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: (Set of Basic Node Types for DefiningTopology Templates)* TOSCA-11: (Set of Fundamental LifecycleOperations)* TOSCA-13 (definitions of portability andinteroperability) [Subtask of TOSCA-16]* TOSCA-16 (Primer Deliverables - Uber Issue)* TOSCA-18: (Resource Requirements andCapabilities)* TOSCA-14: (Policy Languages) [subtask ofTOSCA-3]* TOSCA-3: (Grouping element for policies - UberIssue)Tabled Issues/Proposals/Bugs* TOSCA-9: (Relationship of Plans toInfrastructure)General discussion (time permitting)* REMINDER: While a general approach can be decided by motion, specific technical proposals need tobe JIRA issues* Next meeting* AOBOther Motions and Results (broken out from below):NoneMotion to Adjourn:MOTION to adjourn by Simon Moser.Second byPaul Lipton. Motion PASSES by unanimousconsent. Meeting adjourned at 1:30 PMEDT
  3. 3. Raw Chat Log:Paul Lipton (Co-Chair) C: Hi, all. Welcome to todays meeting of the TOSCA TC(starting promptly at 5 minutes after the hour)!Attendance Recording: Participants are responsible to log their attendance onthe Kavi calendar event at This page alsohas phone bridge, proposed agenda, links to resources and more. Please looknow, if you have not already done so.When you join the meeting, use this page to record your attendance byclicking "Record My Attendance". If you are not on the internet, you canrequest the co-chair to record your attendance on your behalf.PHONE BRIDGE AND WEB CONFERENCING: THIS MEETING ONLY. PLEASE SEE THE EMAILAT: Queue (we need volunteers!):Michael Schuster (21 June)Simon Moser will be running todays 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 haschanged - today we need to use a different call-in numberanonymous morphed into Bryan Haynie (VCE)Simon Moser (co-chair): morphed into Paul Zhang (Huawei)Paul Lipton (Co-Chair) C: I seem to be on mute. How do you get off mute onthis 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 GoogleChrome 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 didnt 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:* Thanks to Dale Moberg for scribing
  4. 4. Editors status report* Problems, questions, etc.Spec issues/Proposals/Bugs queue (time permitting)NOTE: When practical, JIRA issues/proposals will be evaluated in the contextof use cases detailed or subtasked in TOSCA-8* TOSCA-8: (Use CaseBucket)** Issues Related to Pretty Normal PHP Application in the formation of aService Template - Tobias Kunze* TOSCA-17: (PackagingFormat for TOSCA)** Follow-up on last weeks discussion.** Suggested strawpoll: consensus on eliminating Java specifics frompackaging 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: (Set of BasicNode Types for Defining Topology Templates)* TOSCA-11: (Set ofFundamental Lifecycle Operations)* TOSCA-13 (definitions ofportability and interoperability) [Subtask of TOSCA-16]* TOSCA-16 (PrimerDeliverables - Uber Issue)* TOSCA-18: (ResourceRequirements and Capabilities)* TOSCA-14: (PolicyLanguages) [subtask of TOSCA-3]* TOSCA-3: (Groupingelement for policies - Uber Issue)Tabled Issues/Proposals/Bugs* TOSCA-9: (Relationship ofPlans to Infrastructure)General discussion (time permitting)* REMINDER: While a general approach can be decided by motion, specifictechnical proposals need to be JIRA issues* Next meeting* AOBPaul Lipton (Co-Chair) C: Sorry about the phone bridge and web access, but Iwasnt sure Id 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 fasterthan you, Richard.scribe - Richard Probst (SAP): Simon moves to accept minutes, Paul secondsscribe - Richard Probst (SAP): minutes accepted without objection
  5. 5. scribe - Richard Probst (SAP): editor update from Thomas: work in progressbut 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 typesAlex Heneveld (Cloudsoft): Im on Chrome and its okay for me ... but thatsno guaranteeBryan Haynie (VCE): chrome works for mescribe - Richard Probst (SAP): Tobias created node templates for the elementsof his PHP use-case, using YAML (hopefully easier to parse)scribe - Richard Probst (SAP): PHP use-case expects a PaaS -- the servicetemplate references services provided by the platformscribe - Richard Probst (SAP): Tobias has not yet added relationships toservice templatescribe - Richard Probst (SAP): showed internal document how RedHat thinks ofrelationships -- 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 these14 # 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 dont understand why something that issuperfluous (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 webconference? I cant find the new link for todays meetingMatt Rutkowski (IBM)1: Simon can you please record my attendancescribe - Richard Probst (SAP): Thomas comments on issue #1 -- isnt this thesame 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 shouldPHP component be seen as a DA? PHP component is made available thru Apache aslibrary
  6. 6. Aaron(Huawei): ? I see Pauls (Co-chair) message in WebEX, but cant find thelinkPaul Lipton (Co-Chair) C: @Frank, lets go through each issue that Tobias hasidentified. Please reserve for item #6.scribe - Richard Probst (SAP): Tobias: more general issue is that elementsneed to know about components of other elementsKoertStruijk (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: - Richard Probst (SAP): Thomas thinks a node contained in a node cansatisfy the need to name components, without introducing a new top-levelconceptAaron(Huawei): @Koert: Many thanks. Got it.scribe - Richard Probst (SAP): Tobias will try to use nested nodes torepresent componentsscribe - Richard Probst (SAP): and also will try using DAs, and also doing itwith a new "component" concept, to see which works bestThomas Spatzier (IBM): So "nested" Nodes would be: NodeTemplate A (ofNodeType 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 Tobiassissuesscribe - Richard Probst (SAP): Tobias: issue 4 means a service provided by aplatform should not be modeled as DerivedFrom since it cannot be modifiedDerek Palma (Vnomic): To me point 3 means: Node Type derivation should notallow extension beyond the restricted domains of the super Node TypeFrank Leymann (IBM): Can we solve #4 by introducing a "final" attribute forproperties...?Derek Palma (Vnomic): that is one common wayscribe - Richard Probst (SAP):<scribe hat off> how would over-provisioning bemodeled?Derek Palma (Vnomic): but it really has to enforce that the domain is notexpanded. I.e. its a subset.Simon Moser (co-chair): (co-chair hat off) +1 to Franks suggestion tointroduce things like "final" on node type attributesscribe - Richard Probst (SAP): Tobias agrees a "final" attribute could be asolution to issue 4scribe - Richard Probst (SAP): Simon heard consensus on 2 and 3, agreementthat something like 4 is needed, issue 1 needs to be reviewedscribe - Richard Probst (SAP): issue 5 is more a demonstration of need thanan issuescribe - Richard Probst (SAP): Simon (with co-chair hat off) says issue 6(NodeType ID is superfluous) may apply to YAML but not to otherimplementationsThomas 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 isoptional; (2) ID is required, name is optional; (3) YAML uses name, XML usesID
  7. 7. Thomas Spatzier (IBM): The name attribute is optional and meant to be ahuman-readable name.Derek Palma (Vnomic): id guarantees uniqueness. name is not necessarilyunique. We need some notion of identity to be carried across allserializations.Frank Leymann (IBM): +1 to derekscribe - Richard Probst (SAP): Marv says names may not be uniquescribe - Richard Probst (SAP): Tobias agrees names might not be unique, whichwould be a problemMatt Rutkowski (IBM): You would have to qualify an ID as a GUID and decide ifyou 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 timedependent or not and reference approved mechanisms/algorithmsMarv Waschke (CA): Global uniqueness is always an issue. I prefer a namespace 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)KoertStruijk (CA): You might want to be able to have a group of items - ifyou reuse the same name, the id allows you to still individually address theitems. I cant think of a use case for this at the moment, though.scribe - Richard Probst (SAP): Tobias has similar reaction to some of thedetails of the packaging proposal -- remove the geek fields!Paul Lipton (Co-Chair) C: Do Service Template names really need to beglobally 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 andYAML 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 tochange the id as it moves from installation to installation.scribe - Richard Probst (SAP): Especially if you translate back and forth XMLto YAML to XML to YAMLPaul Lipton (Co-Chair) C: So, is consensus that we need to make this work onYAML 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 uniqueAlex Heneveld (Cloudsoft): what about ID="user-agent", with convention itshould be locally unique, inheriting a namespace which gives it globaluniquenessscribe - Richard Probst (SAP): Simon proposes we should open JIRA issues onmost / all of Tobiass issuesscribe - Richard Probst (SAP): Paul would prefer not to open so many tinyJIRA 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 onpurpose -- maybe only a problem when translating to YAML?scribe - Richard Probst (SAP): Tobias argues for being language-agnostic andreadable -- remove the Java-ismsMarv Waschke (CA): @alex- that would satisfy my concerns.Frank Leymann (IBM): I dont understand at all what the Java-isms are.
  8. 8. scribe - Richard Probst (SAP): Simon agrees with goal of maximizing adoption,so lets look at the proposalsFrank Leymann (IBM): The style of naming currently used in TOSCA (e.g.) canbe found in many other standards too.scribe - Richard Probst (SAP): Paul has created TOSCA-20 and asks Tobias tofill with references to todays document and todays minutesDerek Palma (Vnomic): Can we get a list of what these Java-isms are becauseat 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, butthen why not call it "name"Thomas Spatzier (IBM): ID can be a string today.Thomas Spatzier (IBM): Its of type xs:IDDerek Palma (Vnomic): We have to have a notion of identity for uniqueness. Wedont need to dictate this for specific serializations.Alex Heneveld (Cloudsoft): would it be useful to be able to refer toNodeTypes defined in other projects?Alex Heneveld (Cloudsoft): +1 ... ID and NAME serve the same function dontthey?scribe - Richard Probst (SAP): Paul asks if we should remove ID? Tobias sayseliminate 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 haveID.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 dont 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 wehave 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 mapit when translating to YAMLDoug Davis (IBM): ID should be globally unique, Name should be optional andnot 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 XMLvalidator?Alex Heneveld (Cloudsoft): can ID be something like "user-agent" ?Frank Leymann (IBM): +1 to Doug, thats in the spec todayAlex 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 shouldnt do anything with them except echo them backto clients.Alex Heneveld (Cloudsoft): thanks @Thomas. great. nice if these _files_ canbe written by a user ... if we use class-name style for IDs thats possibleharder if im expected to write 243A4E0scribe - Richard Probst (SAP): Derek says dont worry about this, justprovide a (good) translator
  9. 9. scribe - Richard Probst (SAP): from XML to YAML and vice versaDoug Davis (IBM): thats a yaml issue, not a tosca model issue, no?scribe - Richard Probst (SAP): Tobias doesnt see why we have to use XML IDsDoug Davis (IBM): maybe some serializations wont expose all fields - wouldbe a shame but thats their choice as long as those fields are optional.Thomas Spatzier (IBM): If the XSD type is xs:ID, the XML processor ensuresthat the id is unique in the document.Thomas Spatzier (IBM): For global uniqueness we have the namespace inaddition.scribe - Richard Probst (SAP): Simon: lets split the issues into those wehave consensus on and those we still need to debatescribe - Richard Probst (SAP): Paul asks Tobias to create TOSCA-21 for justhis issue 6Matt Rutkowski (IBM): Namespace does NOT guarantee uniqueness unless"authority" guarantees itTobias Kunze (Red Hat): @Thomas: but XML doesnt 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 dont need a motion to end the meeting if your atthe designated endtimeThomas 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