OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Draft Minutes 1st May 2013


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

    Mark Carlson assumed scribe duties.

    Roll: Attendees listed above: 12 of 15 (80%), quorate
       TomR: do we want to discuss CAMP-60?
       Martin: Added to the agenda
       Martin: any objections to approving the agenda?
       Agenda approved w/o

   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?

     ... 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


        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]