[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 6th November 2013
Minutes 6th November 2013
Attendees:
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
NetApp Alex McDonald Member
Vnomic Derek Palma Voting Member
Oracle Gilbert Pilz Voting Member
Fujitsu Limited Tom Rutt Voting Member
Intro:
Ashok assumes scribe duties
Roll call: 9 of 11 (81%), quorate
Alex McDonald introduces himself.
Agenda:
Gil: Put Issue 83 on top
Anish: Can we get an update on Solum?
Agenda approved with above amendments
Minutes:
6th November 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201310/msg00279.html
Anish moves to approve minutes, Gill seconds
Approved w/o objection
Action Items:
Jacques Durand: Coordinate Editing team meeting to discuss the challenges document referenced in CAMP-83
Done
Administrivia:
Martin discusses timeline and number of open issues
... 36 open issues 15 of which are PR issues
The PR issues at least need to be closed before next public review
Martin: Discusses need for scrum teams to discuss and close issues
Anish: I'm mostly available but may need to drop off for some calls
... it is a good idea
Tom Rutt (Fujitsu): what is the time slot?
Martin: 8 to 10 AM Pacific
Jacques: Suggests 3 days in a row for 1 or 1.5 hrs
... 90 minutes
Martin:calendar set for thurs, fri, mon, tues (7, 8,11, 12 nov) 8-10am
Gil Pilz (Oracle): Would like to get a working etherpad instance if we're going to be doing shared editing on proposals
Gil Pilz (Oracle): the free one's aren't very reliable
Jacques: 90 minutes is better
MartinC siri queue me;-)
Tom Rutt (Fujitsu): I can attend thur fri and tue, but not mon
Anish: Put your availability in the chat room
Alex McDonald (NetApp)1: Too new for me right now; & no availability
Ashok: I can attend Thu. Fri, Mon not Tue
Anish: If we have a plan re. which issues will be discussed when that will help
Gil Pilz (Oracle): I can attend Thu, Fri, Mon, and Tue
Jacques (Fujitsu): I can do Thu, Fri, Tue
Martin: We will have first session tomorrow
Anish Karmarkar: i can attend thu (except 9:30-10am pacific), friday and tuesday
... same callin number and password
AlexH: I'm swamped but I will be online ... ping me
Anish Karmarkar: @alexH are there specific issues you care about?
Solum update:
AlexH: Discusses Solum ... Adrian is the main guy
... people like the REST API
...no discussions on deployment plan syntax
... pretty exciting
Mark: Can you add CAMP to the Wiki
AlexH: When they start on the PDP linking back to CAMP would be good
AlexH: argues it may be better not to mention CAMP just yet
Topic: Editing team update
Gil: I pushed out WD-28
...worked on cleaning up references
New Issues:
None
Topic: Issue discussion
https://tools.oasis-open.org/issues/browse/CAMP-83 Labeling of Normative Statements is incomplete (aka overhaul V2)
Gil shares document on WebEx
... added about 20 new normative statements
Alex Heneveld: But we can (hopefully) combine plan-by-ref and plan-by-value if the plan supports references
Alex Heneveld: (To the point of this issue, it looks *good* to me to spell these steps out as separate normative statements.)
Gil Pilz (Oracle): s/On receipt of the request/Upon successfully processing the request/
Jacques (Fujitsu): "Unless the HTTP request generates an error, the Provider SHALL..."
Tom: Asks about failure wording
Anish Karmarkar: On successfully processing a request ...
Gil Pilz (Oracle): "In the non-error case, ?"
MartinC: we just need one generic statement instead of prefixing all these statements
Anish Karmarkar: or "On success, the Provider ..."
Gil: Too many things could go wrong ... hard to predict what the state will be on failure
Tom Rutt (Fujitsu): on successful http response ?
Gil Pilz (Oracle): "On successfully processing the request, ...
Anish Karmarkar: "This class of status code indicates that the client's request was successfully received, understood, and accepted."
Motion: m: Gil, s: Tom : to accept the proposal at https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51306/camp-spec-v1.1-wd28-issue83.doc as the resolution to CAMP-83 changing occurrences of "On receipt of the request" to "On successfully processing the request"
Approved unanimously
Issue-83 is resolved will appear in WD-29 which should be the basis for the scrum sessions
Anish Karmarkar: thanks jacques/gil for the hard work
https://tools.oasis-open.org/issues/browse/CAMP-149 CLONE -Open Data Center Alliance issues - Clarify "functional interface"
Gil: We have a proposal ... displays on WebEx
Martin: Is msg queue a good example here?
AlexH: Perhaps move this section later?
Anish Karmarkar: "For example, the interface used to deploy and start a user application on the platform is a management interface"
MartinC: camp is generic app management on paas - the app interface is out of scope, plus paas specific management, plus app specific management is out of scope.
Gil Pilz (Oracle): I guess it never occurred to me that anyone would ever think that the app interface was in scope
AlexH: We are not going to define mgt interfaces for these components
Gil Pilz (Oracle): I thought what as at issue was the specification of things like AMQP
Motion: m: Gil, s: Alex: resolve CAMP-149 by making Section 1.4 read:
"The interfaces exposed by the components and services in a PaaS system can be broadly split into two categories; functional interfaces and management interfaces.
Functional interfaces are those that involve the specific utility provided by that component. For example, the interface used to submit a message to a message queuing service is as a
functional interface. Management interfaces are those that deal with the administration of components. For example, the interface used to deploy and start a user application on
the platform is a management interface.
The specification of functional interfaces is out of scope for this document."
No objection. Issue-149 is resolved
https://tools.oasis-open.org/issues/browse/CAMP-44 Clarify resource type issues and API
Anish Karmarkar: so Resource will be equivalent to java.lang.Object
Alex McDonald (NetApp)1: http://web.cecs.pdx.edu/~black/publications/TR_CSE_02-012.pdf
Alex McDonald (NetApp)1: Traits are useful because they flatten the structure. http://en.wikipedia.org/wiki/Trait_%28computer_programming%29 for an overview
Discussion about conflicts in multiple inheritance
Tom Rutt (Fujitsu): +1 for gil, that is what OMG Interface inheritance requies
c/requies/requires/
Alex McDonald (NetApp)1: Traits make sure that your draw and my draw don't end up making the inherited object dumb. Not designing language, true; but language guys have
"fixed" ... this (for some value of fixed > multiple inheritance)
Alex Heneveld: @Anish - there can only be one attribute with a given name -- what you are picking are the semantics around it which is a *user* issue not the platform to choose
anything
Alex Heneveld: no objection to saying something like -- "where a type inherits from two other types which define an identical attribute, the definitions of that attribute must be
identical or compatible"
Gil Pilz (Oracle): Providers SHALL not create TypeDefinition resources that inherit from two on more TypeDefinition resources that define the same attribute unless that attribute is
inherited from a common, base type.
Anish Karmarkar: i think this can be explained very succinctly
Anish Karmarkar: this isn't new, folks have been doing this for a while. we don't need to write tomes
Anish Karmarkar: we should read the traits paper
Anish Karmarkar: but from AlexM's description, it is in line with what we are thinking
Tom Rutt (Fujitsu): Eg: a video control port interface which has a bitRateMax attribute could be inherited with a transport port intefaces with a bitRateMax attribute, if both of these mas bit rate attributes had the same semantics.
Alex Heneveld: +1 what we are doing is essentially traits -- just using the lowest-common denominator OO concepts
AlexM: Traits flattened out the structure ... simplifies things
Alex Heneveld: awesome gil
Gil: Let me create a concrete proposal
Derek Palma (Vnomic): In general, behaviors are "combinable". Attributes are not because they have arbitrary content (any text). There has to be a statement of what the client can
... expect (i.e. they must be compatible) for each attribute type.
Gil Pilz (Oracle): please email suggestions for the "very simple rule"
Gil Pilz (Oracle): I'm open to anything
Anish Karmarkar: @derek, that is the direction we are going
Gil Pilz (Oracle): we are actually being stricter than "they must be compatible"
Gil Pilz (Oracle): we're throwing our hands up at the idea of knowing what "compatible" means
Gil Pilz (Oracle): basically if TypeA has a "foo" attribute and TypeB has a "foo" attribute AND TypeA and TypeB did NOT inherit "foo" from some common type, than you cannot have a
... TypeC that inherits from both TypeA and TypeB
Gil Pilz (Oracle): CAMP doesn't care if you think your "foos" are compatible
Gil Pilz (Oracle): too bad, move them into a common sub-type then
Anish Karmarkar: this really is no different than how independently developed headers work say in HTTP
Anish Karmarkar: what we are saying is that the client has no way to figure out which one "wins"
AOB:
Stragglers: Derek.
ADJOURNED
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]