[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 11th December 2013
Minutes 11th December 2013
Attendees:
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
NetApp Alex McDonald Member
Rackspace Hosting, Inc. Adrian Otto Secretary
Oracle Gilbert Pilz Voting Member
Red Hat Krishna Raman Voting Member
Meeting Statistics
Quorum rule 51% of voting members
Achieved quorum yes
Individual Attendance Contributing Members: 8 of 36 (22%)
Voting Members: 8 of 12 (58%) (used for quorum calculation)
Company Attendance Contributing Companies: 5 of 16 (31%)
Voting Companies: 4 of 7 (57%)
Intro:
Scribe: Anish Karmarkar
Chair: Martin Chapman
Topic: Roll, Voting Members: 8 of 12 (58%) Quorate
Topic: Agenda bashing
two new issues created after the agenda was posted; and proposals for few issues
Gil: will like to discuss schedule
Martin: standing item under administrivia
No objections to approving the agenda; agenda approved
Topic: minutes of 2013-12-04
4th December 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201312/msg00011.html
Motion: m:Gil s:Adrian Accept the minutes of 2013-12-04 as posted at https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201312/msg00011.html
no objections
minutes approved
Topic: administrivia
5 open issues
4 potential new issues
Gil: our timeline needs updating; were supposed to go PR a week ago
Martin: schedule needs updating
... next week we should look at issues that don't have a proposal and think about closing things down
... don't see us doing much over the holiday period
... next PR probably in mid jan
CS ballot in feb
Adrian: are calls on 25th dec and 1st jan cancelled; have we adjusted our schedule/cal for that
Martin: yes they are cancelled
anish: slippage not a bad thing since we have gotten feedback from Solum and this makes the spec more adoptable
ACTION: gil to update the timeline
martin: plan for a PR motion on 15th jan
Jacques: how many meetings before that?
martin: 3 meetings
jacques: I'll plan accordingly for the TA doc; the TA doc should be ready then; we should plan for TA PR too
martin: the TC admin would need some time to do their magic; around week of 27th jan
... so end of PR on feb 15
Adrian Otto (Rackspace): thanks, makes sense now
martin: potentially have a CS motion on 26th feb
... this would be a TC admin e-ballot lasting a week
Topic: Editing team update
Adrian: generated WD33; 8 small edits, all of them are ed. omissions from CAMP-150 that were in WD32; did make a mistake as I did not accept the changes -- so WD33
diffs are from WD31; ignore WD32
Gil: did you put wd33 in CD4 branch?
Adrian: no
Gil: will fix it
Jacques: made progress on TA; more extensive clean up; this is a moving target; deleted 33 TAs; 28 new TAs; 36 TA edits
... still have remaining normative tags are covered (about 15/20)
... have a feeling that this won't require new TAs
... have to catch up with WD33
... confident that we'll have a sync-ed up TA doc if I can get 2 afternoons free; probably by next wed
Topic: new issues
from the comments list have extracted two issue: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201312/msg00018.html
https://tools.oasis-open.org/issues/browse/CAMP-153 Two approaches to identify services in a DP?
Gil: we have two ways for specifying services
... the issue question why we have two ways; the author prefer service specification as a top level construct
Motion: m:Adrian s:Gil moves to open issue 153 as a P3 issue
Adrian: I have started writing an example using our DP format. I found that using the style of service as a top-level element makes a lot of sense. So I support this issue
no objection
motion approved w/o
Adrian Otto (Rackspace): https://etherpad.openstack.org/p/solum-demystified line 167
Adrian Otto (Rackspace): that's an example of how fulfillment is used to anchor the two together
Gil Pilz (Oracle): "satisfied"
Gil Pilz (Oracle): "satisfied_by" ?
Adrian Otto (Rackspace): yes
Adrian Otto (Rackspace): satisfied_by works fine.... that should be in a concrete proposal for this issue
Topic: issue 154 https://tools.oasis-open.org/issues/browse/CAMP-154 python atrifact
Gil: not really an issue; maybe material for primer
... it is up to the platform to decide this
MartinC: im hearing a close no action, and add to the list of primer issues
Adrian Otto (Rackspace): 154 can be resolved with a response to the question to the comment submitter
MartinC: we only resolve issues that require spec edits
Adrian Otto (Rackspace): it can be closed
Adrian Otto (Rackspace): what is the position of the present TC members with respect to working on a primer as a work product for CAMP?
anish: we should just create a component called Primer
martin: no motion for a primer; this would require adding a new deliverable
Adrian Otto (Rackspace): I move to close camp154 with no action
motion: m:adrian s:anish close camp 154 w/ no action
motion approved w/o
Adrian Otto (Rackspace): I will respond to the comment submitter with guidance
Adrian Otto (Rackspace): and will take an action item accordingly
ACTION: martin to annotate 154 JIRA with a comment that this is primer material
Topic: issue 155 https://tools.oasis-open.org/issues/browse/CAMP-155 attribute_definition resource is modeled incorrectly
Gil: the problem is that we have a resource that has an attribute that has an attribute definition. Such an attr def will contain the constrains (mutable etc). The problem is that
these constrains are not part of the attr definition, but a contract with the containing resource
... all we really need is name, syntax and semantics
Another resource that uses the same attribute may have different constraints. This requires creating two different attr definitions.
... this is awkward and cludgy. Now that you have type inheritance. This makes it worse as now there would be two different attributes of same name with different definition,
... with the only difference being optionally
AlexM: i would like to consider rolling this under CAMP-44
... both of them are describing the same problem
Gil: that are related but different. Haven't seen any proposal for 44 say that the attribute definitions has to be the same URI
AlexM: this is an issue of "sameness"
Adrian: TC voted to open 44 under a narrow scope than what is in 155
AlexM: fine w/ me as long as this is acked
Motion: m:Gil s:Anish Open 155 as a P2
no discussion
motion approved w/o
Agreement to link this to CAMP-44
Topic: issue 156 https://tools.oasis-open.org/issues/browse/CAMP-156 does every component resource need to link back to an assembly resource?
Gil: trying to catch up to the great refactoring that happened in London
... We have an attribute on a component that points back to the assembly resource that is at the root of the tree
... this would be true if every application component pointed to an assembly
... imagine a deep bushy tree of components
... could go either way, asking the Q
Anish: this is about lifecycle
... the backpointer tells you which assembly's lifecycle this is coupled too
Jacques: we need to decide the usecase we are targetting
... alternative is to use forward link
... back pointer excludes the possibility to use it by more than one assembly
Gil: the issue is multiple assemblies using a component
Martin: if we allow sharing, if you have a back pointer then it blesses one assembly as the master
... this is a question of do we need the backpointer
... if you do ref counting then that solves the problem. Don't see the usecase for the backpointer
Anish: this is really about lifecycle; i would like to figure out which assembly i have to kill to get rid of a misbehaving component
Gil: now think AlexH's view of how to model a shared component is probably right
MartinC: anish this assumes ownership - if a component is subsequently shared why is one assembly blessed
... using a separate component for usage of a service for every assembly is not a bad way to solve this
Martin: if we allow shared components, then I don't see why the original assembly that created the component should make the shared component go away
Gil Pilz (Oracle): you need to differentiate between the notion of sharing an underlying service and a 'component' resource appearing in the trees of two assemblies
anish: fine w/ opening the issue. would need discussion to resolve this
Gil Pilz (Oracle): CAMP absolutely needs to support the notion of two applications sharing a common service
Gil Pilz (Oracle): but CAMP doesn't necessarily need to support that concept using a single, shared 'component' resource
Motion: m:jacques s:Ashok open the issue 156 as P2
no discussion
Adrian: i would like to suggest that this be opened as P3; no need to block PR for this
Jacques: fine with that; willing to amend
Motion changed to opening the issue as P3
motion approved w/o
Topic: issue 157 https://tools.oasis-open.org/issues/browse/CAMP-157 Normative Tags Challenges, and other issues arising from aligning TAs to WD33+
Jacques: most/all of the subissues are editorial; part of the TA clean up
... 5 subissues
... 1st one: left over verbage; editorial
... 2nd one: needs clean up in normative tag table; some rows that are not present in main spec
3rd one: need to align 'type' values; there is 'plan' and 'extension'; this is a question do we need to align this?
Gil: it is not describing the plan resource, it is describing the extension resource
... it is a direction reference to 7.2
... there is a description of resource called extension
... 5.14.1 -- may be we need some text there
... but nothing wrong
... could be made clearer
Jacques: in that case this is editorial
Jacques: subissue 4/5 are stale cross-refs
Motion: m:anish s:jacques open 157 as P3
no discussion; no objection
motion approved w/o
motion: m:anish s:jacques resolve issue 157 by directing the editors to fix this (we trust them)
not discussion
motion approved w/o
Topic: issue 150 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
Gil explains his proposal
Adrian Otto (Rackspace): do we need a reference to what a Multi-part MIME message is?
Adrian Otto (Rackspace): Content-Disposition is an RFC2616 facility for doing exactly this
Gil Pilz (Oracle): RFC6266
http://tools.ietf.org/search/rfc6266
AlexM: should look at rfc 6266
MartinC: 6266 references 2616
Alex McDonald (NetApp): "multipart/form-data" isn't covered by RFC6266. Begging your pardon.
rfc1806 is the content-disposition header rfc
Scribe-Anish should have looked at this before the call; ducks
gil: sounds like we need to give ppl another week.
Please read for next week!
Topic: issue 44 https://tools.oasis-open.org/issues/browse/CAMP-44 Clarify resource type issues and API
Anish gives v brief overview. Please read for next week!
Topic: AOB
straggler roll: Alex H is straggling today.
Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]