[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 24th April 2013
Meeting Minutes 24th April 2013
Attendees:
Rackspace Hosting, Inc. Roshan Agrawal Member
US Department of Defense (DoD) Michael Behrens Voting Member
Software AG, Inc. Bhaskar Reddy Byreddy Voting Member
Oracle Mark Carlson Voting Member
Oracle Martin Chapman Chair
Cloud4SOA Panagiotis Gouvas Voting Member
Cloudsoft Corporation Limited Alex Heneveld Voting Member
Oracle Anish Karmarkar Voting Member
Oracle Ashok Malhotra Voting Member
Rackspace Hosting, Inc. Adrian Otto Secretary
Oracle Gilbert Pilz Voting Member
Red Hat Krishna Raman Voting Member
Fujitsu Limited Tom Rutt Voting Member
JumpSoft Charles Tupitza Voting Member
Software AG, Inc. Prasad Yendluri Voting Member
Intro:
Krishna assumes scribe duties.
Roll: Attendees listed above: 14 of 16 (88%) - We are quorate
Discussing Agenda. Anish comments we are close to deciding on Parameter schemes. Would be nice to complete it. Perhaps we should reorder to get status.
No objections to adopting agenda
Minutes:
17th April 2013 F2F Minutes: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201304/msg00079.html
No comments on minutes
Motion: Gil moves to accept minutes. Adrian seconds.
No objections. Minutes pass.
Administrivia:
Next F2F
Martin: we need to start settling on next F2F location. Duncan suggested Denver area on week of 10th July or Portland around 26th of July.
Anish has concerns with week of July 26th because there are overlaps with other F2F meetings and OSCON.
F2F will be focussed on interop. Question asked if people will be ready with prototypes by 2nd week of July.
General agreement to stick with original plan of Denver 8-10 July.
Martin Will confirm the first date with Duncan.
CAMP Twitter.
Last week we had a discussion on twitter account. Gil volunteered to manage the account.
Duncan also nominated.
Gil: Tweditors
Gil: must add this to my CV
Motion: Gil moved to accept nomination of Duncan and Gil as OASIS CAMP twitter editors. Alex seconds.
No discussion. No objections. Motion passes.
MartinC: twitter guidelines: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201304/msg00077.html
Anish Karmarkar: Dos:
1) News/blog items about CAMP (unless they are grossly misrepresenting CAMP or have a clear negative bias)
2) Factual items about CAMP TC (eg: new draft published, interop event, f2f)
3) Announcements of CAMP talks
4) Product or impl availability/announcement pointers
Don'ts:
1) Blatant self promotion
2) Blatant company-specific marketing
3) Opinions, especially that are anti-anything
Anything controversial the editors should get TC's approval (eg: any tweet that says CAMP is better than 'X').
Gil: "if you can't say something nice, don't say anything at all"
Gil: pretty simple
Motion: Adrian motions to accept the twitter guidelines. Martin will put them in TC repository. Anish seconds
No discussion and no objections. Motion passes.
Alex Heneveld (Cloudsoft): for those with short memories (viz twitter users): it's @camp_oasis
New Issues:
https://tools.oasis-open.org/issues/browse/CAMP-63 TypeDefinitions for CAMP-defined types
Gil describes the issue.
Motions: Gil moves that we open CAMP-63. Adrian seconds.
Gil suggests priority P2.
Adrian prefers P3
P3 agreed.
Motion passes w/o to open 63 as a P3
https://tools.oasis-open.org/issues/browse/CAMP-64 Are Requirements global resources, or specific to application Compontent templates
Tom describes the issue.
CAMP-64 marked as Spec Component.
Alex thinks its not a questions we need to answer as this does not add any interop issues.
Questions if requirement can be shared amongst multiple components.
Anish: This may have relevance to PDP as well.
Alex Heneveld (Cloudsoft): actually i agree with what anish is about to say (i think). there are valid cases where the requirement would be shared.
Alex Heneveld (Cloudsoft): ... so i contradict myself ...
Tom motions to open CAMP-64 as P3. Gil seconds.
Gil thinks it should be P2 or P1.
Passed w/o, open CAMP-64 as P2.
Issue Disscussion:
https://tools.oasis-open.org/issues/browse/CAMP-30 Parameter Scheme
Anish was looking for a status update. Do we need parameter metadata given that we have attribute metadata. What should the default behavior be.
Adrian will make a pass and prepare it for vote next week.
PDP issues:
https://tools.oasis-open.org/issues/browse/CAMP-3 How do application packages get uploaded into the cloud?
https://tools.oasis-open.org/issues/browse/CAMP-4 Need a formal specification of the PDP format
Alex Heneveld (Cloudsoft): Gil notes there is something odd about the things we manage (webapp etc) being "types". I agree.
Alex thinks we should use example to show the broad applicability of the spec.
Should also take a look at HEAT DSL and see if we can converge
Gil: +1 on the idea that "types" (e.g. "com.example.java:WAR") should be elevated out of the PDP discussion
Adrian and Alex would like deployment plan to be in YAML.
Deployment plan may be in JSON. Gil is concerned with adding another parser requirement since YAML and JSON are pretty close in capabilities.
Adrian Otto (Rackspace): recognize that ALL YAML parsers also support JSON
MartinC: cant someone just do a json to yaml pretty printer
Gil: SnakeYAML isn't nearly as nice as Jackson - just sayin'
Mark Carlson (Oracle): My concern is with generating the output of the PDP. Do I need a toYAML() method in addition to my toJSON?
....What about regularity between what we put on the wire and what we put in the file?
Alex Heneveld (Cloudsoft): @Mark it can return JSON
Alex Heneveld (Cloudsoft): JSON is valid YAML
Alex Heneveld (Cloudsoft): yaml 1.1 is fine
Alex Heneveld (Cloudsoft): i think
Mark Carlson (Oracle): @alex - what exactly are the YAML syntax (over and above JSON) elements that we need?
Alex Heneveld (Cloudsoft): we just need quite basic yaml
Gil: SnakeYAML supports 1.1
Alex Heneveld (Cloudsoft): or yaml1.2
Gil: not 1.2
Adrian Otto (Rackspace): http://yaml.org/spec/1.2/spec.html
Alex Heneveld (Cloudsoft): @mark - dropping requirement for quotes and curly braces, and supporting spaces for containment and hyphens for lists
Alex Heneveld (Cloudsoft): @mark - i don't see people using references or tags or other fancy things
Mark Carlson (Oracle): I need to think about this some more
Alex Heneveld (Cloudsoft): ... what i'm saying is i don't see people caring about the other things too much
Alex Heneveld (Cloudsoft): see e.g. https://github.com/ahgittin/heat-hot-dsl-prototyping/blob/master/alex1/wordpress.template
Gil concerned that YAML doesn't have an standardized spec like JSON does
Tom Rutt (Fujitsu)1: what is the standard referencd for JSON?
MartinC: as long as its to a fixed version and not to http://yaml.org
Alex Heneveld (Cloudsoft): http://yaml.org/spec/1.2/spec.html is pretty widely referenced already
Anish: OASIS doesn't restrict us to any particular kind of reference.
Alex Heneveld (Cloudsoft): @tom json is http://www.ietf.org/rfc/rfc4627.txt
Gil: tom: RFC4627
Tom Rutt (Fujitsu)1: thanks
Alex: For wire standards JSON is used. Where as for human readability JSON is not attractive. Initially people will be writing this by hand.
..... For the model we are considering, they could write JSON and it will be valid YAML.
Gil: +1 to Alex's comments about the DP being the part that developers "see"
Roshan (Rackspace): @ Alex: agree, good point.
Martin: Questions about how difficult is it to convert between YAML and JSON.
Adrian: YAML and JSON can be translated from one to other but YAML has fewer characters and uses sparing to indicate scope so braces are implicit rather than explicit.
Anish Karmarkar: http://yaml.org/spec/1.2/spec.html#id2759572
Alex: There are some things on the fringes like tags and long quotes that wont convert to JSON but we probably wont need that.
Adrian Otto (Rackspace): Adoption is very important. If we can simplify PDP by using YAML, that may help adoption.
Anish Karmarkar: interesting to note that YAML says: "JSON's RFC4627 requires that mappings keys merely SHOULD be unique, while YAML insists they MUST be."
.... -- the same decision that we came to here in this TC
Adrian Otto (Rackspace): yes, we did.
Alex Heneveld (Cloudsoft): +1 adrian+anish, we can resolve other aspects of pdp without yaml question
Discussing CAMP-4 proposal of Zip
Alex presents the proposal in JIRA.
Adrian: If we look at OVF as an example. it specifies how signing works. Do we want to go into that level of detail?
Anish: will pull specific Zip version out and send it to list.
Roshan: Are we going to limit authors to on boarding new applications only or also support updates.
That should probably be another issue.
Roshan: Add application source code to list of application content files bullet point.
Alex Heneveld (Cloudsoft): Roshan: add source code to list of app content file. +1
Martin worried about interoperability if we leave bullet point 2 too loose.
Anish Karmarkar: zip reference: http://www.pkware.com/documents/casestudies/APPNOTE.TXT
MikeB likes to have a digest on the zip as long its on the contents on the ip file. Also important to specify the digest type
Alex moves to adopt the proposal as is with the amendment from Roshan that source code be added to list.
Alex Heneveld (Cloudsoft): withdraw motion
Alex Heneveld (Cloudsoft): will repost as new issue, with correction and normative ref to zip
Adrian Otto (Rackspace): I'd like to ask for two changes: 1) use camp.yaml,
... 2) Some way to standardize signing/digest to ensure interop. We can do this with a reference to OVF.
AOB:
Stragglers.
Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]