[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 18th September 2013
Minutes 18t September 2013
Meeting Attendees
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
Vnomic Derek Palma Voting Member
Oracle Gilbert Pilz Voting Member
Fujitsu Limited Tom Rutt Voting Member
Intro:
Scribe: Tom Rutt
Roll: attendees listed above. 11 of 12 voting members, meeting is quorate.
Topic: draft agenda
https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201309/msg00089.html
Gil wants to add discussion for Issue 51
Agreed to make first issue discussion
Modified agenda approved Unan
Topic: Draft minutes
11th September 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201309/msg00086.html
Motion: m: Adrian, s: Gil move to accept minutes from 11 sept 2013 https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201309/msg00086.html
No objections minutes approved
Topic: F2F London October
Jacques: I have assumed Starting Monday noon, ending Wed noon
Anish asked to take all of Wed for the meeting.
Jacques suggested to keep the room reservation for all day Wed, meeting may formally close after morning session.
Jacques suggested starting the meeting on Monday morning.
start 9:30 AM monday morning and formally close by 1:00 PM on wednesday
Room will be available for aux sessions on Wed afternoon
Topic: CloudPlugfest Update
Mark in Santa Clara, If they get working they can do a demo thursday this week to Madrid
Virtual box making OVF file trying to get it imported into VM-Ware
Topic: Project Status Timeline
Public review closes tomorrow (19th sept)
Should consider raising bar for new issues after public review
Topic: Reference to JSON
Gil has new working draft to fix the reference to JSON patch using RFC.
CAMP 54 is applied in current WD
This also addresses one of the PR issues on references
Topic: Test assertions
Jacques posted a cleaner version of test assertions doc TA WD12: https://www.oasis-open.org/apps/org/workgroup/camp/document.php?document_id=50699
Jacques has "CAMP1.01xxxx" numbering scheme for test assertions. Have 4 integer partitions for major topics
123 test assertions currently included
The test assertions on state transitions are not completed, dependent of state management issue which is open
Besides the test assertions draft, there is a "challenges" document which still needs to be discussed before the TAs can be completed.
Some may require new issues to be posted and resolve
Topic: Chair for next weeks meeting
Adrian to be pro-tem chair for next week meeting, since Martin will be in Japan
Motion: Martin moves for Adrian as pro-tem chair, seconded by Ashok
Martin will prep the agenda, this is just to run the call.
No objections, motion passes
Topic: New issues
https://tools.oasis-open.org/issues/browse/CAMP-110 Values for "attributeType" are not clearly defined.
Gil: Need standard notation for all of the types we use for Attribute definitions
Gil moves to open 110, Adrian seconds
No objections, issue 110 opened as P2
https://tools.oasis-open.org/issues/browse/CAMP-111 consumerMutable attribute of AttributeDefinition resource should not be a required attribute
Gil: If mutable is false, consumerMutable is always false. We can make this conditional on the value of mutable
Gil moves to open camp 111, Adrian seconded
No objections, camp 111 is opened as p3
https://tools.oasis-open.org/issues/browse/CAMP-112 Consistently name URI attributes.
Could have stronger consistency requirements on use of case in URI attributes
Gil moves to open camp 112 as P3, seconded by Adrian
No objection, camp 112 opened as P3
Motion: Adrian moves to resolve camp 112 by instructing editors to have all attributes follow the pattern in proposed resolution
Seconded by Gil.
No objections, issue resolved.
Editors to work to apply resolution to issue camp 112
Topic: Camp 51
Cardinality tags are always used for the entire line in which they appear.
() used to scope vertical bar operator
Motion: Gil moves to resolve Camp 51 with proposal in JIRA 51 v4 proposal, Jacques seconded
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50650/camp-spec-v1.1-issue-51-v4.doc
No objections, Issue CAMP 51 resolved with v4 proposal
Topic: Issue CAMP 82
question from Ashok: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201309/msg00081.html
MODEL A -- One PDP, one application, no shared components
MODEL B -- Shared application components
Gil Pilz (Oracle): https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50738/Multi-tiered%20PaaS.pptx
Jacques: can application components have dependencies on application components that are already there
Gil presented his slides
MartinC: If we go model b then indeed the distinction between app and platform components almost disappear
MartinC: it just comes down to who is responsible for installing such components - the provider or the customer
If application components use other application components, they could either: be in the same assembly template in one PDP: or put them each in separate PDPs . To allow the second approach, we need to have application components in one template consume application components in another template
Solution may require asserting application components at platform level
Alex Heneveld: What about machine images ?
Alex Heneveld: They are shared.
Adrian: I do not see shared application components in use today
Sharing of components is a problem. Updating applications in place required coordinating with updates of all dependent applications
Users should have freedom to specify shared components, but the way to do this is to define them as their own platform components,
Adrian: keep simple, do not allow shared application components
Alex: already the spec permits sharing in convoluted ways. Machine Images are shared in an ecosystem.
Alex: we do not need to say a lot to allow users to share components.
Alex: I still think the best way to fix this is to take away the distinction between platform and application components.
Alex Heneveld: +1 Martin - cardinality and RBAC are questions which need addressed, but that should be a V2. for now, implementers can decide how to support this.
Alex Heneveld: the spec is very useful even if it doesn't mandate how to make something sharable.
MartinC: i disagree is a v2 issue - knowing whether something is sharable/re-entrant etc is important
MartinC: but i see the resolution being a simple attribute
Gil: question on whether CAMP has to manage the api links between application components
Ashok Malhotra (Oracle): Yes, I think we need to say something about sharing
Alex Heneveld: Martin - why? if something isn't shared with me i can't use it.
Alex Heneveld: if i see something then i can use it.
Ashok Malhotra (Oracle): OK. Then you need a mechanism to control visibility ... same thing
MartinC: who is "me"
MartinC: anyone with permissions can see everything on a platform
Jacques: The concept of lower level application components is different than having platform components available across all assemblies.
Alex Heneveld: @Ashok - *implementations* will need that i agree, but does it have to be in the API / interface ? it isn't something that i (as a consumer) needs to see.
Alex Heneveld: everything i see is visible to me. by definition.
Alex Heneveld: @Martin me = consumer
Alex Heneveld: we are an API for consumers
Alex Heneveld: an _administrator_ would be able to see everything but they are coming in via another route
Alex Heneveld: e.g. installing platform components
Alex Heneveld: the spec doesn't say how that works
Jacques: we are not far from being able to move an application component to become a platform component
MartinC: right, but how do you tell if its a singleton or not, so that your co-worker doesn't hook up to something it shouldn't
Ashok: the "platformize" operation would make a component available to everybody. However you may want to restrict the access to this new platform component
Alex Heneveld: let's step back. how does my co-worker tell what it is ?
Jacques (Fujitsu): "platformize" makes it rather visible to all accessors of THIS Platform (i.e. any assembly on this platform view)
Anish Karmarkar: my opinion is that we should focus on lifecycle scope etc and not restrict how/where dependencies are created
Tom: Platform components have different relationships and constraints regarding their use from Application Components. Any "platformize" operation would have to deal with changing all these links at run time.
Anish Karmarkar: the Q to me is should CAMP specifically allow such app comp to app comp dependencies or stay silent
Alex Heneveld: REMINDER: we are a humble spec
Gil Pilz (Oracle): this is not about whether CAMP allows a Consumer to create a Link from one ACT to another ACT
Gil Pilz (Oracle): it is about what happens when you instantiate an AT that has ACTs that are so linked
Mark Carlson (Oracle): Since CAMP is focused purely on management, what we are really talking about is the ability to enable communications between components (whether that is via a network or a language binding). If there is some underlying configuration changes and provisioning that needs to be done, then that linkage would need to be exposed through CAMP.
... the debate continues for another day...
AOB:
Stragglers : have Alex, Anish and Derek recorded.
Meeting adjourned.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]