[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 4th June 2014
Meeting Minutes 4th June 2014
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
Rackspace Hosting, Inc. Adrian Otto Chair
Vnomic Derek Palma Voting Member
Oracle Gilbert Pilz Voting Member
Fujitsu Limited Tom Rutt Voting Member
Software AG, Inc. Prasad Yendluri Voting Member
Intro:
Scribe: Anish
Roll: Attendees listed above. 10 of 10 (100%) Meeting is quorate.
Agenda: https://www.oasis-open.org/apps/org/workgroup/camp/event.php?event_id=36492
agenda approved w/o change
Topic: Approval of minutes
https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201405/msg00019.html
Motion: m:Gil s:Anish approve minutes of 2014-05-28 located at https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201405/msg00019.html
motion approved w/o
Topic: Adminitrivia
3 open issues on the spec, 2 p2 and 1 p1
Topic: editing update
no update; no new draft
Topic: new issues
no new issues
Topic: Issue 171 https://tools.oasis-open.org/issues/browse/CAMP-171
Proposal in Jira
gil walks through his proposal
Jacques: new normative requirement is a MAY that is essentially a MUST for the provider
Gil: sounds like PR76 is an analog of PR8, but no analog of PR7
... we do say in PR12 that the only thing that the consumer can put in the body of the req is what is in the select_attr
... PUT means replace, what more do we need to say?
Tom Rutt (Fujitsu): Administrative Detail: Both PR-47 and PR-12 are copied into the test assertions CSD01. We need to have a way of tracking that changes to requirements in CAMP get reflected into the TA
Tom: any change to normative stmt or new normative stmt needs to figure into the TA doc
Adrian Otto (Rackspace): 4XX status code is not a specific code
Adrian Otto (Rackspace): in the proposed text for 6.5
Adrian Otto (Rackspace): 400 Bad Request is the right response
need to make sure that absence of an attr in the body but when it is present in select_attr means deletion
Gil: PR-25 covers it
happy with PR-25
Adrian thinks the 400 is the right status code
Gil: need to fix it one way or another. Currently inconsistent
Gil: will fix it everywhere to make it 400
... and update the TAs
Adrian: we should make all the client status codes specific
Gil: don't need an analog to PR-47. PR12 & 13 cover it
Jacques: concern is that we are still expecting the server to support it
we need to say that the server must support PUTs with select_attr
Gil: in that case we need the same wrt PR-08
Martin: PR-47 covers the case for requiring servers to support GET with select_attr, we just need one for PUT
Gil: may be a way out of this is to not try to match what we say for PUT (with what we say for GET)
... will create a v2 for this
Martin: may need a new issue for 4XX or address this in the proposal
ACTION: Gil to generate a v2 proposal for issue 171
Topic: issue 172
https://tools.oasis-open.org/issues/browse/CAMP-172 consider specifying a generic 'version' characteristic for use in ServiceSpecifications
Derek talks about using an expression language
Gil: Adrian - does OpenStack use any expression language like this?
martin: would prefer to use an existing expression language
Alex Heneveld: i'd like to have this (versioning) in time. but we don't yet even define types so it feels like premature weight.
http://www.ietf.org/rfc/rfc2254.txt
osgi uses semantic versioning, similar to what Derek as outlined and they use LDAP query strings
Alex Heneveld: i expect most implementers will follow maven/osgi/sem-ver anyway, but there will be other issues, i think it should gestate first.
Gil: would like to find out if OpenStack has a solution for this
Alex: would want this in fullness of time; need to have agreement on types, version is a property of these types
... better off to let folks define types and versioning for those type
... when things mature we can include it in v2 of the spec
... concerns about getting in wrong
Gil: this is a chicken-egg problem
... by not specifying anything there is a higher chance of various types/versioning not interoperating. Think of this as seeding the direction
Tom: Alex what did you mean by 'types'. Are they user's types or spec types?
Alex: i mean artifact, service and requirement types
... all sorts of things will have versions (specs, platform, components etc)
... will take a while to figure out the best practices for versioning
... we are better off not doing this in the main spec, but in implementation, best practices, primer etc
... for now and then later uptake it in .next version of the spec
Gil: to answer Tom's Q, the version we are talking about is specifying characteristics provided by the platform provider
... the customer has an app and wants specify exactly what it needs from the platform. For example MySql version
... if everyone has a different way of saying verison 5.1 or greater the we lose portability
Tom Rutt (Fujitsu): maybe get back to two sequences of intervals for inclusion and exclusion
... we can take a small step to make things easier
AlexH: what version is AWS on? how do I specify that
Gil: in this case you would not specify a version
... this is where we have to chose the right level of conformance (SHALL/SHOULD/MAY)
... it would be helpful to have *a* way of doing things
Alex: folks may specify different ways of specifying their notation
Derek: the pt. that concerns me is -- specifying the version is quite important and without that it is difficult to work with
... not having it nailed down is tough. I may have to make different plans for different platform. From a portability point of view it is important
... Are we talking about different usecases
Martin: I agree with Alex in that we may not necessarily know what we are doing here. But Derek is saying that we need to examine the usecase and figure out what kind of expression language we need. But I would rather point to an existing language. OR do a analysis of what's the minimum we can get away with
Alex: version will be important for what we do. But I do think versioning and matching is upto the type-definer
... you have described Maven/OSGi vesioning. But if I'm dealing with Ubuntu, it is different. Or I might want a Linux kernel that is even or odd.
... we need to examine the various types that we will be dealing with and how they do versioning. But it is an important goal.
Derek: the Q is do you want to have a canonicalized syntax or leave it to the types
Alex: I think 90% can be canonicalized, but products that use "marketing" version (10%) may be difficult
Derek: for me, if I can't specific version or range it is not useful
Alex: this is something that type designers need to think about
Martin: this is P2 issue, we need to get a direction. At least whether we are going to address it, postpone it etc
no response
Martin: we'll have to come back to it another time. More thinking needs to be done
Gil: seems like a semi-consensus that we want to defer it
Topic: issue 169
https://tools.oasis-open.org/issues/browse/CAMP-169 CLONE -Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)
Gil: didn't get around to this
... next week
Topic: AOB
none
Stragglers: Tom, Jacques, Derek.
Meeting adjouned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]