[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 1st May 2013
Attendees: US Department of Defense (DoD) Michael Behrens Voting Member Oracle Mark Carlson Voting Member Oracle Martin Chapman Chair Fujitsu Limited Jacques Durand Voting Member Cloudsoft Corporation Limited Alex Heneveld Voting Member Cloudsoft Corporation Limited Duncan Johnston-Watt Member Oracle Anish Karmarkar Voting Member Oracle Ashok Malhotra Voting Member Rackspace Hosting, Inc. Adrian Otto Secretary Vnomic Derek Palma Member Oracle Gilbert Pilz Voting Member Red Hat Krishna Raman Voting Member Fujitsu Limited Tom Rutt Voting Member JumpSoft Charles Tupitza Voting Member Intro: Mark Carlson assumed scribe duties. Roll: Attendees listed above: 12 of 15 (80%), quorate Agenda: TomR: do we want to discuss CAMP-60? Martin: Added to the agenda Martin: any objections to approving the agenda? Agenda approved w/o Minutes: 24th April 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201304/msg00103.html MOTION: Gil: Move to approve the minutes from April 24th. Anish: second the motion Martin: Minutes approved Passed w/o Discussion of face to face in Broomfield, CO, 8-10 July 2013 Martin: Any objections to making this the plan of record? Martin: no objections, will confirm with Duncan and add to Kavi calendar Editing team update: Anish: WD09 includes 50 and 57. Issues list updated. Change log updated. Anish: when should we publish CSD03? Anish Karmarkar: CAMP CSD link: http://docs.oasis-open.org/camp/camp-spec/v1.1/ Adrian: any progress on CAMP-09 Gil? Gil: close of business today No significant change to warrant a new CSD - need to consider timing of public review for next CSD. New Issue https://tools.oasis-open.org/issues/browse/CAMP-65 describe PDP format and contents MOTION: Gil: Move to open 65 (Adrian seconds) MartinC: as p1 Martin: CAMP 65 is opened with a P1 passed w/o Issue Discussion: https://tools.oasis-open.org/issues/browse/CAMP-30 Parameter Scheme Adrian is going through proposal document Anish: CAMP 50 - already prohibits duplicate keys in JSON objects Anish: question about requiring POST if the attribute is implemented - isn't it always required? Adrian: this is for Platform Component Template. Anish: what are you doing with the POST? Starting the component? Adrian: depends on the definition of the Parameter Adrian: this is on the creation of a Platform Component and the definitions of the parameters used in the creation. Anish: concerned about documenting how the POST works. Will open a new issue. Mark: extensions are overriding the behaviour of attributes, but they cannot be incompatible with the specification defined behaviour Jacques: concerned about the SHOULD term. Jacques: trying to change an immutable can throw an error or might be ignored. MartinC: it either MUST set the value or MUST provide documentation Anish: need enable common behavior, but Alex brought up an example of parameter value where new parameter names make client interactions more complex. ...So should be able to define specific semantic values. Gil: the "clearly documented" language is not enforceable Gil: prefer to use "should" language, without saying the reasons Gil: immutable attributes still have to assume an initial value at creation time - this is done through parameters Jacques (Fujitsu): @gil: agree that "unless documented by Provider" is fuzzy... that's the one part that should be tighten up MartinC: "clearly" is not testable MartinC: documentation can be tested for Alex: also prefer "should" rather than "must" document clearly Jacques: just remove "unless documented otherwise" language Jacques: for read-only, the USER should not be allowed to override Martin: this ability is needed for attributes in multiple places and should be allowed Alex Heneveld (Cloudsoft): @jacques -- in many cases this is supplying initial values e.g. for an Assembly, by .... POSTing to an AssemblyTemplate. we are NOT changing the value of the thing we are talking to Alex Heneveld (Cloudsoft): does that make that side of things more acceptable? MOTION: Resolve issue CAMP 30 with proposal in Jira as modified by Adrian on the call. (1st Gil, 2nd Alex) Martin: any objections? Martin: CAMP-30 is resolved. Passed w/o Alex Heneveld (Cloudsoft): Adrian: the correct casing is "pdpUri" Anish: can we talk about CAMP-65 now? Gil: The key words ?MUST?, ?MUST NOT?, ?REQUIRED?, ?SHALL?, ?SHALL NOT?, ?SHOULD?, ?SHOULD NOT?, ?RECOMMENDED?, ?MAY?, and ?OPTIONAL? in ... this document are to be interpreted as described in [RFC2119]. https://tools.oasis-open.org/issues/browse/CAMP-65 describe PDP format and contents Alex presents his proposal Krishna: valid YAML instead of valid JSON Gil: leave it for now Adrian: strike the line if we will not support them Derek: what about sizes? Alex: went with ZIP because it is standard, prefer TAR personally Adrian: if 4GB limit, it needs to be documented, and how to work around it Anish Karmarkar: +1 to exploring this concern This is why DMTF went with TAR for OVF files - with boot disk images, 4GB is easily exceeded Alex Heneveld (Cloudsoft): Need to change text so that "Platform accepts ZIP" rather than "it MUST be ZIP". Ashok Malhotra (Oracle): Wikipedia: The maximum size for both the archive file and the individual files inside it is .... 4,294,967,295 bytes (2321 bytes, or 4 GiB minus 1 byte) for standard .ZIP, and 18,446,744,073,709,551,615 bytes (2641 bytes, or 16 EiB minus 1 byte) for ZIP64. Anish: "such as" language does not specify anything normatively Derek Palma (Vnomic): I believe OVF is a tar format Derek Palma (Vnomic): .ova @derek - yes Alex: will update the document Attempting edits on the fly.... Alex Heneveld (Cloudsoft): CHANGING Alex Heneveld (Cloudsoft): A PDP file shall be a ZIP archive [ZIP] containing the following files: Alex Heneveld (Cloudsoft): TO Alex Heneveld (Cloudsoft): The platform MUST accept as the PDP a ZIP archive [ZIP] containing the following files: Alex Heneveld (Cloudsoft): The platform MUST accept as a PDP a ZIP archive [ZIP] containing the following files: Alex Heneveld (Cloudsoft): The platform MUST accept a PDP supplied as a ZIP archive [ZIP] containing the following files: Adrian Otto (Rackspace): yes, OVF is a TAR format archive, and makes reference to GZIP compression Anish: need to clean up the wording to tighten the language around conforming PDPs and conforming platforms Jacques: the PDP "might" be a ZIP file, but could include other archive formats. Adrian Otto (Rackspace): we should change the reference from ZIP to ZIP64 to address the size limit Adrian Otto (Rackspace): or use TAR like OVF does Jacques: the PDP is actually the files, not the archive format Anish Karmarkar: +1 to Alex Michael Behrens: Section 4 would be good for overall description. Alex: we need to allow other archive formats Jacques: switch around the wording to describe the PDP as the files, etc. and separately define which archive formats are acceptable. Alex: need to require one and make others optional Anish: if we don't prohibit it, it's already allowed Derek Palma (Vnomic): It seems like Zip should be declared the canonical/normative format Alex Heneveld (Cloudsoft): PDP is an archive containing following files: Alex Heneveld (Cloudsoft): ... Alex Heneveld (Cloudsoft): The platform MUST accept PDP supplied as ZIP. IT MAY accept other formats. Anish: already have a statement regarding the platform (section 4, second sentence) - so in 4.1 just talk about the PDP format of files and metadata Michael Behrens: Note: CAMP MIME type in future? (different issue) Gil: need to go off and turn the crank on a new version offline Tom: separate out the concerns and tighten them up Anish Karmarkar: is ZIP64 backward compatible with ZIP? Martin: agree with need to tighten up, especially "such as" lists Issue 65 will be deferred until a new proposal is available https://tools.oasis-open.org/issues/browse/CAMP-60 ApplicationComponentCapability is not linked by any resource Type Tom discusses proposal Tom: just add an array of links for now, we can decide to remove capabilites later Gil: can't we just get rid of Application Component Capabilites Jacques (Fujitsu): could we just consider "componentCapability" ? which might be used to express capability for any component Mark: can get rid of both ACC and ACRs Alex: OK to defer the "getting rid" discussion and just go with the current proposal Tom: this addresses the original issue, the "getting rid" discussion should be a different issue. Jacques (Fujitsu): Tom just wants to have a pretty diagram. MOTION: Alex: motion to accept the proposal to resolve CAMP 60 - seconded by Tom Alex Heneveld (Cloudsoft): +1 pretty diagram CAMP 60 is resolved passed w/o Tom Rutt (Fujitsu): need a new issue to get rid of both application component capabilities and requirements together. Alex: would like to have a side discussion on PDP - will send a Doodle poll to the list. Anish: other issues need forward progress also. Gil: if people haven't been watching the mailing list, from the perspective of a Java impl of CAMP, YAML 1.1 vs. JSON is a non-issue AOB: Duncan Johnston-Watt (Cloudsoft): @Chair - joined to confirm F2F arrangements in July @duncan we approved the July meeting so please confirm arrangements. Stragglers: Duncan Meeting adjourned.