[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]