[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 11th March 2015
Meeting Minutes 11th March 2015
Attendees
US Department of Defense (DoD) Michael Behrens Member
Oracle Martin Chapman Chair
NetApp Don Deel Member
Fujitsu Limited Jacques Durand Voting Member
Cloudsoft Corporation Limited Alex Heneveld Voting Member
Oracle Anish Karmarkar Member
JPMorgan Chase Bank, N.A. Michael Norman Member
Rackspace Hosting, Inc. Adrian Otto Secretary
Vnomic Derek Palma Voting Member
Oracle Gilbert Pilz Voting Member
Fujitsu Limited ` Tom Rutt Voting Member
Software AG, Inc. Prasad Yendluri Voting Member
Intro:
Date: 2015-03-11
Chair: Martin Chapman
Scribe: Anish
Topic: roll
8 of 9 (88%) Meeting is quorate
topic: agenda bashing
agenda approved
Minutes:
28th January 2015: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201501/msg00005.html
MOTION: m:Gil s: Prasad approve minutes of 2015-01-28 as posted at https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201501/msg00005.html
motion approved w/o
Topic: Adminstrivia
Selecting a new TC Chair: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201503/msg00001.html
Call for nominations. Selection by TC vote or web ballot as appropriate.
MOTION: m: Adrian s:Tom nominate Anish to be the chair of the TC replacing Martin, who is resigning
Adrian: recognize Martin's services and leadership to the TC. Appreciated
Martin: this requires a Full Majority
... i.e., majority of all voting members regardless of whether they are on the call or not
(an unopposed motion with no abstentions at a quorate meeting meets the full member vote criteria)
motion approved w/o
Martin: will finish this meeting and new chair will be in place after this meeting
Topic: implementation status
Gil: in solum, one can now create apps by posting a ref to a plan/assembly resources
... next tasks is PDP support and storing artifacts in Swift
Adrian: Swift is the blob store in OS
Alex: no new dev in Brooklyn, but still using CAMP
New issues:
Issue CAMP-175 https://issues.oasis-open.org/browse/CAMP-175
Alex explains the issue
Gil: would like to see an example of this
Alex: CAMP should not model my artifact, it should model the runtime
Gil: this seems like just a name change
Alex: folks don't need to know the CAMP artifact concepts
... just want to point to the war file
... the benefit of having artifact section is having a higher level entry point
... we may not need it
Martin: what do we want to do w/ this issue--open it and ask Alex to provide examples
MOTION: m:Adrian s:Alex open issue CAMP-175
motion approved w/o
Issue priority P3
Issue CAMP-176 https://issues.oasis-open.org/browse/CAMP-176
Alex explains the issue
Martin: a new synonym would be a normative change
Tom: is this a first example of a synonym? A new concept. A concern for me
General preference to not have synonym
MOTION: m:Gil s:Tom open issue CAMP-176
motion approved w/o
issue opened
priority P2
general agreement on priority being P2
Issue CAMP-177 https://issues.oasis-open.org/browse/CAMP-177
Tom Rutt (Fujitsu): assembly -> application, and plan -> template, or something like that
Mike Norman is the one who opened issue 177
Chair apologies for confusing Don Deel with Michael Norman
Alex explains the issue
MikeN: may be worthwhile to postpone discussion till later
... possibly additional issues/solutions could be raised. Dealing with how to integrate this with a GUI
Gil: no objections to opening the issue. But do question some of the assumptions in the issue
MOTION : m:Gil s:Alex open issue CAMP-177 as P1
motion approved w/o
Issue CAMP-177 is open
Topic: issue CAMP-176 discussion
Adrian Otto (Rackspace): +1 o Gil's proposal to rewrite the xxx_types to "type"
Gil: propose getting ride of "artifact_type" "service_type" "requirement_type" and using just "type". The context makes it clear
Martin: the current solution makes it clear that you don't mix things
Tom: keep it the same or do what Gil suggests. Don't like synonyms.
Anish: both of those solution require us to go through another PR. We should consider whether this change is important enuf.
[Chair note - any changes to the spec require us to go back to WD -> CSD -> PR...]
Anish: one solution is backward compatible the other isn't, but introduces a new concept
Gil: we don't have to do this in the context of CAMP 1.1, we could do this for CAMP 1.2
Adrian Otto (Rackspace): when you make a backward incompatible change, the best practice is to bump up the version. Just make the resulting work CAMP 1.2.
Martin Chapman: agreed
Alex: glad to have meetings again, lot of pent of issues. My thinking was that this would be for 1.2
... it would be nice to have 1.1 compatible with 1.2
... little bit of agony to do that (and perhaps deprecate it), but may be worthwhile
Tom: i'll like to see a proposal wrt synonyms
... wrt backward compatibility it would not be backward compat on receiving side
Gil: would prefer not to introduce synonyms
... every plan has a version number in it. Perfectly possible to have a provider support 1.1 and 1.2
Martin Chapman: i think its more important for plans to be forward compatible
alex heneveld (cloudsoft): @Tom - my ideal is that v1.1 plans could be immediately valid also as v1.2 plans. (i am not expecting v1.2 plans being read by a v1.1 api...)
Tom: need to work more on this
Gil: i can put together a proposal for this--would be a service and replace for xxx_type
Proposals required for this issue (hint..hint Alex&Gil)
Topic: AOB
stragglers: Don, Tom, Derek, MikeN, MikeB
MikeN introduces himself
TC/Chair welcomes MikeN esp. fresh pair of spec-eyes and impl-hands
MikeN: main model is good and abstract
... struggling w/ the serialization aspects
Motion: m:anish s:Adrian Thank Martin for his leadership and services as Chair since the TC's inception
motion approved w/o
Chair blushes and thanks the TC members for being cordial and cooperative throughout the life of the TC.
Topic: meeting schedules
old and new chairs to discuss new schedule for the TC
Meeting Adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]