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 3rd July 2013


Meeting Minutes 3rd July 2013

 Attendance	
Voting Members: 8 of 13 (61%) (used for quorum calculation) 

Attendees : 

Oracle			Martin Chapman	Chair
Oracle			Anish Karmarkar	Voting Member
Oracle			Ashok Malhotra	Voting Member
Rackspace Hosting, Inc.	Adrian Otto	Secretary
Vnomic			Derek Palma	Voting Member
Oracle			Gilbert Pilz	Voting Member
Red Hat			Krishna Raman	Member
Fujitsu Limited		Tom Rutt		Voting Member
JumpSoft			Charles Tupitza	Voting Member


Topic: Intro:

       Tom assumes scribe duties

      Roll: listed above,  8 of 13 (61%), meeting is quorate
      Topic: Agenda
      Anish: re Issue discussion, could take issue 4 before others
      No objections to agenda

Topic: Minutes:
 
     26th June 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201306/msg00080.html 
   
      Gil moves to accept minutes of the 26th June, Anish seconded
      No objections, agenda approved.

Topic: Administrivia
      Confirm numbers for face to face, 8 People
      Mail to Jodi Henly to get added to the allocation
      Adrian, Anish, Martin, Tom, Duncan, Alex, Gil
      will need people to call in

      Topic: F2F Agenda

           Outline agenda:  https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201307/msg00003.html 

           Goal to resolve as many P1 issues as possible
           Formal decisions during 1:30 - 3:30 Mountain time telecon
            Bridge available as needed outside of the official 2 hr period

 
      Topic: WD 13 and WD 14
   
           WD13 applies Camp 3, and WD14 changes the model figures in section 2 to add pdpURI attribute, change bars against WD12
          WD14:  https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201307/msg00001.html 
          Tom updated the pictures based on wd13 changes - kept the redline.
           Editors to coordinate figure upadates per WD release.

Topic: New Issues:

      https://tools.oasis-open.org/issues/browse/CAMP-71    optionality of 'pdpURI' attribute in AssemblyTemplate is inconsistent
         presented by Gil
      Adrian: continue to have this as an optional attribute, because assembly templates could be created in other ways.
      Anish: Optional, but there are conditions which require its presence
      Gil moves to open 71 as minor issue, Anish seconded
      No objections, Camp-71 is opened


Topic: Issue Discussions.

      https://tools.oasis-open.org/issues/browse/CAMP-4   Need a formal specification of the PDP format  

       Continue PDP discussion.
       Latest from Gil: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201307/msg00005.html 
      Gill Proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49783/camp-spec-v1.1-wd12-issue-4-v6.doc 
      Gill explained changes from previous proposals
      Types -> artifactType, RequirementType, CharacteristicType
      Three different type spaces; artifactType, requirementType, characteristicType
       Adrian: I think this is an improvement
        Gil: I want to have this stuff put into a new working draft
      Anish: If we have agreement on this call, we could accept this proposal, with understanding that any issues Alex may have can be subject of further issues.
      Martin: while we seem close, we could wait until the F2F to accept the resolution formally.  We could record this as a directional resolution, allowing tweaks next weeek.
      Derek: I assume this would be the PDP format for the plug fest
      Anish: I see this as an acceptable baseline for further refinements
      Gil: I would like to get it into a WD, so we could use it for the plug fest as being a little bit firmer
      Adrian: lets address this at F2F, even though I doubt much will change.
      
     Topic: Camp-56

        https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49648/camp-spec-v1.1-wd12-confClause-CAMP56.doc 

      martin went thru the proposal from Jacques:
      Anish: The overall approach seems good, with three conformance classes, provider, consumer, pdp package.  We could go back to the main spec and use these three terms wherever the rfc conformance keywords are used in a normative manner.
      This conformance section would not have to repeat the requirements for conformance, because they would be stated throughout the spec.
      Adrian: Why is this section 2.
      Anish: this is because this is not an integrated proposal, it will go into the end of the spec.
      Adrian: I agree with Anish's proposal to use these conformance class terms in the formal requirements using the RFC 2119 terms
      Martin: +1, would we use "consumer" or "PAAS Consumer" is the only question
      Martin: we need to agree the terms, then refactor them into the spec.
      Martin: I do not want to use the word profile.
     Adrian Otto (Rackspace): Martin made the point that a "PaaS Provider" may be more appropriately named "CAMP Provider". Same applies to "PaaS Consumer" -> "CAMP Consumer"
     Adrian Otto (Rackspace): I agree that change is appropriate
      Gil pointed out that he has other comments on the JIRA issue which need discussion before we accept a proposal formally.

      Agreement to use CAMP Provider, CAMP Consumer, PDP Package appropriately in the normative statements throughout the spec using RFC 2119 keywords;

      Topic: Issue 9      

      http://tools.oasis-open.org/issues/browse/CAMP-9  Support sensors and effectors on components via API
      Martin went thru the proposal from Alex quickly
      Ashok asked that we defer this until next week.
      Adrian: This proposal needs to be consistent with other similar solutions with plural resources.   This is not consistent with what we have done with extensions and types.
      Gil: I dislike using resources to represent operations.  It is inconsistent with the rest of the API which are things acted on.  On operations is different.
      Anish: some confusion on use of wording "resource being acted on" throughout the proposal
      Anish: is this operation resource a description, or the actual operation endpoint to invoke it
      Adrian Otto (Rackspace): Anish is concerned with the use case of federating operations to other systems/servers. The proposal does not make it clear if that's supported.
      Tom: there seem to be several ways to do "operation invocations" in REST
      Ashok: these operations do not seem to be in our resource model.  This required further thinking
      Anish Karmarkar13: @adrian i like your phrase better: 'federated operations' -- should have used it
      Ashok: we can have value changes for attributes of resources make things happen, but this seems to be something else.  The CAMP Resource in this case may not have control of the thing being changed.
      Target to get this resolved next week.

AOB:

  Stragglers: no squeaks.

Meeting Adjourned.


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