OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Draft Minutes 6th November 2013

Minutes 6th November 2013

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


      Ashok assumes scribe duties
      Roll call: 9 of 11 (81%), quorate

      Alex McDonald introduces himself.


      Gil:  Put Issue 83 on top
      Anish:  Can we get an update on Solum?
      Agenda approved with above amendments

  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


      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:

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
      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 

      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"


      Stragglers: Derek.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]