[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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]