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 13th November 2013

Minutes 13th November 2013


Software AG, Inc.			Bhaskar Reddy Byreddy	Voting Member
Oracle				Mark Carlson	Voting Member
Oracle				Martin Chapman	Chair
Fujitsu Limited			Jacques Durand	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
Fujitsu Limited			Tom Rutt		Voting Member
Software AG, Inc.			Prasad Yendluri	Voting Member


      Roll Call:  Voting Members: 11 of 12 (91%) meeting is quorate
      Topic: Agenda approval

             Redfining the order of the issues discussion
             Anish Karmarkar: discussing CNAs first would be good
             add new issue: https://tools.oasis-open.org/issues/browse/CAMP-150 
             Approved as modified.


      6th November 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00041.html 
          Correction needed the minutes approved were for the 30th october 2013.
          Motion Gil, s: Ashok approve minutes of the 6th fixing the reference to past minutes to 30th October 2013
          Passed w/o

      Topic: Scrum sessions notes availabale - informal so no need to approve:

           Session 1: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00051.html 
           Session 2: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00078.html 
           Session 3: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00094.html 

            Anish: observes the meetings were very useful
Topic: Action Items


Topic: Editing Team Update

      Gil: Pushed out WD 29: https://www.oasis-open.org/apps/org/workgroup/camp/document.php?document_id=51313 
      Jacques: New version of test assertions doc by next week

New Issue:

       https://tools.oasis-open.org/issues/browse/CAMP-150  mechanism for creating an Assembly (or Plan) by value (i.e. POSTing the contents of a PDP or Plan file) is difficult to use
      Anish Karmarkar: note, we do have a high bar for new issues
      MartinC: 2/3 majority
      Gil: Need to fix this sooner than later
      .. proposing this to be a P1 issue
      Alex Heneveld: +1 we need to do this
      Use a multi-part data format
      Adrian Otto (Rackspace): +1 this is a good improvement and will aid adoption. I think forming and approving a proposal for this will not be difficult.
      Anish: Things will look complicated on the wire due to multi-part but 
      ...you are not dealing with raw messages but APIs etc. May be ok
      Anish Karmarkar: agree with @adrian, proposal would be easy
      Motion: Gil moves to open 150 as P1 second Adrian
      No objections. 150 is open

Issue Discussion:

      Martin: Summarized the issues into 3 groups (some errors)
      Anish Karmarkar: my suggestion: deal with P1 first then the CNA group
      We have two P1s with proposal 86 & 80

      Issue:  https://tools.oasis-open.org/issues/browse/CAMP-86 

        modified proposal in JIRA: [YAML 1.1] Oren Ben-Kiki, Clark Evans, Brian Ingerson, "YAML Ain't             
       Markup Language (YAML) Version 1.1, 2005-10-18" http://yaml.org/spec/1.1/ .          
      Also archived    at: http://xml.coverpages.org/yaml-spec-v1.1-archive-copy.html 
         Motion to resolve 86 with the proposal in Jira: mov: Adrian: Sec: Tom
         Motion Approved w/o

      Issue: https://tools.oasis-open.org/issues/browse/CAMP-80 

      Gil: Presents the issue..

      Anish Karmarkar: this should be easy. We now have multiple URLs to post to. By ref is       
      always json. By value is based on what you are posting: yaml has yaml media-type, zip has        the appropriate zip media type and so on
      Anish Karmarkar: note that this may change based on resolution of 150
      Anish Karmarkar: with the introduction of multipart
      Anish Karmarkar: in which case would just talk about the root part in the multipart
      Anish Karmarkar: the nice thing about multipart is that by-ref and by-value are equivalent as both can now have parameters
      .. and proposed resolution
      Anish: likes the proposal but issue 150 might change it ..
      Alex: Likes the proposal

      MOTION: Gil: Moves to resolve issue 150 the proposal in Jira S: Tom
      Approved w/o

Issues with proposals to close with no action:

      Issue: https://tools.oasis-open.org/issues/browse/CAMP-147 
      Issue:  https://tools.oasis-open.org/issues/browse/CAMP-143 
      Issue: https://tools.oasis-open.org/issues/browse/CAMP-114 
      Issue: https://tools.oasis-open.org/issues/browse/CAMP-88 
      Issue: https://tools.oasis-open.org/issues/browse/CAMP-84 
      Issue: https://tools.oasis-open.org/issues/browse/CAMP-79 
      Issue: https://tools.oasis-open.org/issues/browse/CAMP-42 
      Issue: https://tools.oasis-open.org/issues/browse/CAMP-11 
      All above are P2s
      Issue: https://tools.oasis-open.org/issues/browse/CAMP-59 
      Issue: https://tools.oasis-open.org/issues/browse/CAMP-27 
      Ashok: Scaling Policy, Alex talked about sending us an example.
      Alex: I am happy to send the example, we can keep the issue open but I don't think it belongs in the spec
      Ashok: I am happy to close the issue but like see the example AI
      Motion: Ashok moves to close all the issues listed above with no action,     second: Anish
      issus: 147, 148, 114, 88, 84, 79, 42, 11, 69, 59, 27

      Motion approved w/o objections
Issue: https://tools.oasis-open.org/issues/browse/CAMP-62 

      Gil: Explains the issue and proposal
      MartinC: note this was an action from the scrum so the proposal was not agreed in the scrum per see
      Anish: we are stuck with JSON types and 
       ...  The order is relevant
      ...if the client or provider does not maintain that order unexpected things can happen   wrt issue resolution, should we just stay silent?
      Tom: Sympatise with Gil. But..
      What is the scope of this across multiple HTTP requests?
      Anish: You are asking reg. reboots and patch etc. We already say you should do conditional updates
      .... You do a get prior to update but, if things change (e.g. reboot after get) if not      
       .... sure resources  are in the same order, you should do a conditional update, i.e. update only if things are the same as befopre.
      Adrian: I am not clear on the problem..
      Anish Karmarkar: i'm more inclined to CNA this
      Anish Karmarkar: don't mess with the order
      Gil: the issue stems from my impl. experience
      Anish Karmarkar: if you mess with the order bad things will happen
      Adrain: Are you providing advise but not placing restrictions in the spec?
      GiL: I am asking for restrictions
      Adrin: why use soft lang. like advise..
      Anish: We have already said order is relevant (saying something restrictive already)
      .. we already have a strong language
      Alex: This has never been an issue before but it might become ..
      It is technically not necessary but, this should go in the primer not the spec
      we should state the problem more precisely..
      discussing tweaking proposal text
      Gil: contemplates aloud the wisdom of putting in the spec or in a primer
      Anish Karmarkar: if we wanted to say something stronger (as suggested by Adrian) we could      
       ...say: "Providers SHALL preserve the order of the elements in JSON arrays across        HTTP requests when there is no change to the array"
      Tom: the last sentence (the advise) should not be part of the spec, it is the confusing part
      Anish Karmarkar: or something like that
      Gil: suggests to close with no action and take it up in the primer
      MOTION: Gil: Moves to close issue 62 with no action. Second: Adrian
      Approved w/o objections. Isues 62 is close with no action

      Issue: CAMP 74     https://tools.oasis-open.org/issues/browse/CAMP-74 

        Gil: Elaborates the issue
          Tom: section 2.3 needs to be updated
          Tom Rutt (Fujitsu): need to update 2.3
          Anish Karmarkar: i like this proposal
          Anish Karmarkar: this is a very clever way
          Anish Karmarkar: it reduces the number of ways to do the same thing
         Anish Karmarkar: to one
         Tom Rutt (Fujitsu): change sentence under fig 2-6 On platforms that choose to support Plans,           
          ... a CAMP Consumer can create a Plan resource by uploading either a PDP or a Plan file to the            
         .... Plans resource URI using an HTTP POST request.
         Tom Rutt (Fujitsu): to
          Tom Rutt (Fujitsu): On platforms that choose to support Plans, a CAMP Consumer can create
            .... a Plan resource by uploading either a PDP or a Plan file to the Assemblies resource URI using   an HTTP POST request.

      Gil: Still need to update the proposal

      MOTION: Gil: motions to approve Jira proposal with Toms' suggested modification above, Second: Tom
      Approved w/o objections. Issue 74 is resolved.


      Straggler: none

Meeting Adjourned

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