[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft minutes 13th November 2013
Minutes 13th November 2013
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
Oracle Gilbert Pilz Voting Member
Fujitsu Limited Tom Rutt Voting Member
Software AG, Inc. Prasad Yendluri Voting Member
Intro:
Roll Call: Voting Members: 11 of 12 (91%) meeting is quorate
Topic: Agenda approval
Redfining the order of the issues discussion
Anish Karmarkar: discussing CNAs first would be good
add new issue: https://tools.oasis-open.org/issues/browse/CAMP-150
Approved as modified.
Minutes:
6th November 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00041.html
Correction needed the minutes approved were for the 30th october 2013.
Motion Gil, s: Ashok approve minutes of the 6th fixing the reference to past minutes to 30th October 2013
Passed w/o
Topic: Scrum sessions notes availabale - informal so no need to approve:
Session 1: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00051.html
Session 2: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00078.html
Session 3: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00094.html
Anish: observes the meetings were very useful
Topic: Action Items
None
Topic: Editing Team Update
Gil: Pushed out WD 29: https://www.oasis-open.org/apps/org/workgroup/camp/document.php?document_id=51313
Jacques: New version of test assertions doc by next week
New Issue:
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
Anish Karmarkar: note, we do have a high bar for new issues
MartinC: 2/3 majority
Gil: Need to fix this sooner than later
.. proposing this to be a P1 issue
Alex Heneveld: +1 we need to do this
Use a multi-part data format
Adrian Otto (Rackspace): +1 this is a good improvement and will aid adoption. I think forming and approving a proposal for this will not be difficult.
Anish: Things will look complicated on the wire due to multi-part but
...you are not dealing with raw messages but APIs etc. May be ok
Anish Karmarkar: agree with @adrian, proposal would be easy
Motion: Gil moves to open 150 as P1 second Adrian
No objections. 150 is open
Issue Discussion:
Martin: Summarized the issues into 3 groups (some errors)
Anish Karmarkar: my suggestion: deal with P1 first then the CNA group
We have two P1s with proposal 86 & 80
Issue: https://tools.oasis-open.org/issues/browse/CAMP-86
modified proposal in JIRA: [YAML 1.1] Oren Ben-Kiki, Clark Evans, Brian Ingerson, "YAML Ain't
Markup Language (YAML) Version 1.1, 2005-10-18" http://yaml.org/spec/1.1/ .
Also archived at: http://xml.coverpages.org/yaml-spec-v1.1-archive-copy.html
Motion to resolve 86 with the proposal in Jira: mov: Adrian: Sec: Tom
Motion Approved w/o
Issue: https://tools.oasis-open.org/issues/browse/CAMP-80
Gil: Presents the issue..
Anish Karmarkar: this should be easy. We now have multiple URLs to post to. By ref is
always json. By value is based on what you are posting: yaml has yaml media-type, zip has the appropriate zip media type and so on
Anish Karmarkar: note that this may change based on resolution of 150
Anish Karmarkar: with the introduction of multipart
Anish Karmarkar: in which case would just talk about the root part in the multipart
Anish Karmarkar: the nice thing about multipart is that by-ref and by-value are equivalent as both can now have parameters
.. and proposed resolution
Anish: likes the proposal but issue 150 might change it ..
Alex: Likes the proposal
MOTION: Gil: Moves to resolve issue 150 the proposal in Jira S: Tom
Approved w/o
Issues with proposals to close with no action:
Issue: https://tools.oasis-open.org/issues/browse/CAMP-147
Issue: https://tools.oasis-open.org/issues/browse/CAMP-143
Issue: https://tools.oasis-open.org/issues/browse/CAMP-114
Issue: https://tools.oasis-open.org/issues/browse/CAMP-88
Issue: https://tools.oasis-open.org/issues/browse/CAMP-84
Issue: https://tools.oasis-open.org/issues/browse/CAMP-79
Issue: https://tools.oasis-open.org/issues/browse/CAMP-42
Issue: https://tools.oasis-open.org/issues/browse/CAMP-11
All above are P2s
P3:
https://tools.oasis-open.org/issues/browse/CAMP-69
Issue: https://tools.oasis-open.org/issues/browse/CAMP-59
Issue: https://tools.oasis-open.org/issues/browse/CAMP-27
Ashok: Scaling Policy, Alex talked about sending us an example.
Alex: I am happy to send the example, we can keep the issue open but I don't think it belongs in the spec
Ashok: I am happy to close the issue but like see the example AI
Motion: Ashok moves to close all the issues listed above with no action, second: Anish
issus: 147, 148, 114, 88, 84, 79, 42, 11, 69, 59, 27
Motion approved w/o objections
Issue: https://tools.oasis-open.org/issues/browse/CAMP-62
Gil: Explains the issue and proposal
MartinC: note this was an action from the scrum so the proposal was not agreed in the scrum per see
Anish: we are stuck with JSON types and
... The order is relevant
...if the client or provider does not maintain that order unexpected things can happen wrt issue resolution, should we just stay silent?
Tom: Sympatise with Gil. But..
What is the scope of this across multiple HTTP requests?
Anish: You are asking reg. reboots and patch etc. We already say you should do conditional updates
.... You do a get prior to update but, if things change (e.g. reboot after get) if not
.... sure resources are in the same order, you should do a conditional update, i.e. update only if things are the same as befopre.
Adrian: I am not clear on the problem..
Anish Karmarkar: i'm more inclined to CNA this
Anish Karmarkar: don't mess with the order
Gil: the issue stems from my impl. experience
Anish Karmarkar: if you mess with the order bad things will happen
Adrain: Are you providing advise but not placing restrictions in the spec?
GiL: I am asking for restrictions
Adrin: why use soft lang. like advise..
Anish: We have already said order is relevant (saying something restrictive already)
.. we already have a strong language
Alex: This has never been an issue before but it might become ..
It is technically not necessary but, this should go in the primer not the spec
we should state the problem more precisely..
discussing tweaking proposal text
Gil: contemplates aloud the wisdom of putting in the spec or in a primer
Anish Karmarkar: if we wanted to say something stronger (as suggested by Adrian) we could
...say: "Providers SHALL preserve the order of the elements in JSON arrays across HTTP requests when there is no change to the array"
Tom: the last sentence (the advise) should not be part of the spec, it is the confusing part
Anish Karmarkar: or something like that
Gil: suggests to close with no action and take it up in the primer
MOTION: Gil: Moves to close issue 62 with no action. Second: Adrian
Approved w/o objections. Isues 62 is close with no action
Issue: CAMP 74 https://tools.oasis-open.org/issues/browse/CAMP-74
Gil: Elaborates the issue
Tom: section 2.3 needs to be updated
Tom Rutt (Fujitsu): need to update 2.3
Anish Karmarkar: i like this proposal
Anish Karmarkar: this is a very clever way
Anish Karmarkar: it reduces the number of ways to do the same thing
Anish Karmarkar: to one
Tom Rutt (Fujitsu): change sentence under fig 2-6 On platforms that choose to support Plans,
... a CAMP Consumer can create a Plan resource by uploading either a PDP or a Plan file to the
.... Plans resource URI using an HTTP POST request.
Tom Rutt (Fujitsu): to
Tom Rutt (Fujitsu): On platforms that choose to support Plans, a CAMP Consumer can create
.... a Plan resource by uploading either a PDP or a Plan file to the Assemblies resource URI using an HTTP POST request.
Gil: Still need to update the proposal
MOTION: Gil: motions to approve Jira proposal with Toms' suggested modification above, Second: Tom
Approved w/o objections. Issue 74 is resolved.
TOPIC: AOB
Straggler: none
Meeting Adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]