[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: raw chat lof day 1 jan 2013 f2f
Adrian Otto (Rackspace): \
Adrian Otto (Rackspace): The Voice Conference code is: 3005864
Adrian Otto (Rackspace): The US Access number is 1 866-682-4770
Tobias Kunze (Red Hat): Good morning everyone
MartinC - webex: Meeting Number: 598 770 660
Meeting Password: 2267
https://oracleconferencing.webex.com/oracleconferencing/j.php?J=598770660&PW=NZDFmYzZlMDI2
jeffm: are u taking attendance yet?
Adrian Otto (Rackspace) (scribe): Meeting Commenced
Adrian Otto (Rackspace) (scribe): Roll Call
Adrian Otto (Rackspace) (scribe): 70% attendance: Meeting is quorate.
Adrian Otto (Rackspace) (scribe): Review of day 1 agenda
Adrian Otto (Rackspace) (scribe): Anish raises issue of target launch date for our v1.1 effort. Oasis Standard is one milestone we can aim for. We want to be at that point within 1 year, and we are a few months in. Suggests working back from a target date.
Adrian Otto (Rackspace) (scribe): We plan to address this subject during the part of our meeting when we discuss the relative priority of the open issues.
Adrian Otto (Rackspace) (scribe): High priority issues should have target dates assigned so we can plan progress in order to meet the milestone.
Adrian Otto (Rackspace) (scribe): No objections to modified agenda.
Adrian Otto (Rackspace) (scribe): Agenda approved.
Adrian Otto (Rackspace) (scribe): Agenda was not modified from the version in email.
Adrian Otto (Rackspace) (scribe): correction: Agenda has a modification. Martin will update, and copy/paste it here in the chat.
Duncan Johnston-Watt: Long term workplan discussion to be added to agenda
MartinC : Submitter's message
Draft Agenda ....
-- Dr. Martin Chapman
Event Title: 2nd CAMP F2F
Agenda
Times are US Central Time
Wednesday 21st January
09:00
Intro, Roll, Scribes
Agenda bashing
Minutes 16th January 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201301/msg00040.html
Administrivia
Editing Team update
New issues
10:30
Break
11:00
General extensibility discussion kicked off by Gil: https://www.oasis-
open.org/apps/org/workgroup/camp/email/archives/201301/msg00044.html
See email thread
12:30
Lunch
13:30
Specific extensibility issues:
https://tools.oasis-open.org/issues/browse/CAMP-1 Need a way to get metadata for a particular resource
https://tools.oasis-open.org/issues/browse/CAMP-10 API+Model Extensions
https://tools.oasis-open.org/issues/browse/CAMP-14 How are supported formats discovered
15:00
Break
15:30
https://tools.oasis-open.org/issues/browse/CAMP-38 resourceState attribute needs clarification
Other lifecycle issues?
17:30
Thursday 22nd January
09:00
Test Assertions Discussion - Jacques to lead
10:30
Break
11:00
Liaison - presentation on OCCI (time to be confirmed)
Note that since OASIS doesn't allow non members to make contributions, and material and discussion must be restricted to publicly
available information only.
12:30
Lunch
13:30
TC timeline and planning
15:00
Break
15:30
Open Issue Prioritization - exercise to categorize into P1 (must fix), P2 (should fix), P3 (nice to fix)
17:30
Friday 23rd January
09:00
Issues discussion in priority order.
10:30
Break
11:00
Work plan, wrap up
12:30
END
Adrian Otto (Rackspace) (scribe): Gilbert Pilz motions to approve the minutes from Jan 16, 2013
Adrian Otto (Rackspace) (scribe): Second by Tom Rutt
Adrian Otto (Rackspace) (scribe): Martin asks if the text based minutes format is acceptable by the members.
Adrian Otto (Rackspace) (scribe): the format is indicated to be fine.
Adrian Otto (Rackspace) (scribe): no discussion on minutes
Adrian Otto (Rackspace) (scribe): no objections
Adrian Otto (Rackspace) (scribe): minutes from Jan 16, 2013 are approved.
Adrian Otto (Rackspace) (scribe): No administrivia to discuss.
Adrian Otto (Rackspace) (scribe): Editors produces a CSD package, a zip file containing Word, PDF, and HTML formats. The CSD publication process by the TC Admin is now underway.
Adrian Otto (Rackspace) (scribe): WD02 will be used for any modifications from this point.
Adrian Otto (Rackspace) (scribe): https://www.oasis-open.org/committees/download.php/47987/camp-spec-v1.1-wd02.zip
Adrian Otto (Rackspace) (scribe): Jacques requests that TC members review the draft of the test assertions document prior to discussion tomorrow. It is a 14 page document.
Adrian Otto (Rackspace) (scribe): Discussion of new issues: https://tools.oasis-open.org/issues/browse/CAMP-14
Adrian Otto (Rackspace) (scribe): Gilbert Pilz: Motion to open issue CAMP-14
Adrian Otto (Rackspace) (scribe): Adrian Otto seconds motion
Adrian Otto (Rackspace) (scribe): no objections
Adrian Otto (Rackspace) (scribe): issue carried, CAMP-14 is open.
Adrian Otto (Rackspace) (scribe): Action Item for Martin C: Check that all associated issues are appropriately allocated to the spec.
Adrian Otto (Rackspace) (scribe): Correction: New issue CAMP-39 is opened, not CAMP-14
Adrian Otto (Rackspace) (scribe): Discussion of new issue: https://tools.oasis-open.org/issues/browse/CAMP-40
Adrian Otto (Rackspace) (scribe): Tobias Kunze speaks in support of the issue
Adrian Otto (Rackspace) (scribe): Anish K speaks in support of the issue
Adrian Otto (Rackspace) (scribe): Jacques suggests that another related issue exists. Resources created under one API version may need to be accessible from other API versions. Tom Rutt asks if CAMP-40 is concerned with this scope of the issue. Gilbert Pilz confirms that Jacques' issue is beyond the scope of CAMP-40.
Adrian Otto (Rackspace) (scribe): Gilbert Pilz motions to open CAMP-40
Adrian Otto (Rackspace) (scribe): Motion seconded by Duncan Johnston-Watt
Adrian Otto (Rackspace) (scribe): No discussion
Adrian Otto (Rackspace) (scribe): No objections
Adrian Otto (Rackspace) (scribe): CAMP-40 is now open.
Adrian Otto (Rackspace) (scribe): Break time. Resume in 20 minutes (10:35 US/Central)
Adrian Otto (Rackspace) (scribe): Break time concluded.
MartinC : Topic: General extensibility discussion kicked off by Gil:
Adrian Otto (Rackspace) (scribe): Gil begins a discussion on Extensibility
MartinC : https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201301/msg00044.html
Adrian Otto (Rackspace) (scribe): Anish suggests that the spec outline rules/boundaries that extensions must follow in order to remain compliant.
Mark Carlson (Oracle): As I said in the email thread. We need a conformance statement that disallows "incompatible" extensions, along with the spec text that normatively illustrates *how* to extend CAMP compatibly.
anish: +1
anish: all oasis spec requires a 'conformance' section -- this should go there
MartinC : extensions must not contradict the specification.
Charlie Tupitza JumpSoft: Please speak towards the Microphone. it is very hard to hear words..
Duncan Johnston-Watt: It is not an extension if it breaks the core spec - conformance should capture this obviously - but there is a separate issue which is whether extensions collide with one another ... not sure we can solve this in general case?
Adrian Otto (Rackspace) (scribe): Consensus reached that Extensions must not contradict the spec.
Adrian Otto (Rackspace) (scribe): Considerable support for the idea that mandatory Extensions should not be allowed. Active discussion of this point.
Duncan Johnston-Watt: +1
Adrian Otto (Rackspace) (scribe): Jacques suggests that extensions should be allowed, provided they to not fail the base set of test assertions.
Adrian Otto (Rackspace) (scribe): s/to/do/
Duncan Johnston-Watt: +1 - that is one aspect of conformance (compliance?) with spec
Adrian Otto (Rackspace) (scribe): Anish suggests that extensions mandated by a service provider will be required. The absence of this requirement will be impossible because not enough is included in CAMP to make a useful PaaS service work.
Adrian Otto (Rackspace) (scribe): Discussion of Extensions that would be common among multiple implementations. Gil indicates we should not call that a Standard Extension.
Jacques (Fujitsu): There is a "business" contract, where a Provider may require mandatory extensions to be used. But that is out of scope of CAMP spec. These could be concretized as "CAMP profiles" (e.g. Java platforms). As far as conformance is concerned, there should be a core way to conform (core test suite) that is not violated by any extension (no test regression)
Tom Rutt (Fujitsu): We need to distinguish two concepts: Vendor extensions within the scope of the standard API, vs. mandatory extensions to the Standard API. The second concept is the one which causes feasability problems for testing the standard API
Mark Carlson (Oracle): We might learn from the way the SNIA is extending CDMI.http://www.snia.org/tech_activities/publicreview/cdmi lists several extensions that are not made "standard" until multiple implementations are demonstrated. Then and only then they are moved into a future version of the standard.
anish: we also have to be mindful of what our charter says wrt 'out of scope':
anish: "Facilities and interfaces that are programming language-specific and/or platform-specific (e.g. .Net, Java EE). "
Adrian Otto (Rackspace) (scribe): Gil suggests some terminology to refer to a grouping of related extensions. We should refer to this as a Feature.
Adrian Otto (Rackspace) (scribe): Break for lunch. Resume in 1 hour. 1:15 PM US/Central
Alex Heneveld (Cloudsoft): I have posted some vocab for "extension types" as a comment at https://tools.oasis-open.org/issues/browse/CAMP-10
Scribe: ping
Scribe: Meeting resumes after a lunch
TheScribe: Specific extensibility issues:
TheScribe: https://tools.oasis-open.org/issues/browse/CAMP-1 Need a way to get metadata for a particular resource
jeffm: that was me dialing in
TheScribe: concrete proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47367
TheScribe: Anish> (presents concrete proposal)
Tobias Kunze (Red Hat): How about we simply name this "metadata=yes"?
Tobias Kunze (Red Hat): I agree with Alex, "_PaaSRT" feels "ugly"
TheScribe: Anish> this proposal needs work - it is a hold-over from the collaboration days
TheScribe: Adrian> the lists of attributes is not identified by types
TheScribe: Anish> you can't use an extension unless you know its semantics - since you have to look those up in any case, don't see the point of listing types, etc.
TheScribe: ... could add a URL that tells you where to get the documentation
TheScribe: ... could add a URL that tells you where to get the documentation
TheScribe: Alex> issue description discusses "resources" and "resource types"
TheScribe: ... need a way to navigate the types that are exposed in the system
TheScribe: ... maybe that should be a top-level resource e.g. "apiDocs"
TheScribe: ... also a need a way to get the per-instance list of all the attributes that have values
TheScribe: ... or cases where instances have more attributes than their type
TheScribe: ... or cases where instances have more attributes than their type
TheScribe: Gil> why are you telling me about attributes and types that are defined in the spec - I know they exist
TheScribe: Anish> makes it easier to process these lists in a mechanical way if you don't have to special case the types and attributes that are defined in the spec
TheScribe: Gil> also uncomfortable with the idea of instances that contain attributes that are not defined by their type
TheScribe: ... don't see the point of defining such a thing as a "resource type" if we don't play by the rules of what we have defined that concept to mean
TheScribe: Jacques> are the underscores around the _PaaSRT_ query parameter, a CAMP convention?
TheScribe: Anish> don't want to conflict with other query parameters, but name is the least important thing
TheScribe: Jacques> if it is "nice" to get the names of all the spec-defined attributes, it is similarly "nice" to get type information on the attributes
TheScribe: Tom> is there some way to get "all" the metadata in one shot?
TheScribe: Anish> you have to think about how you are going to retrieve and use the metadata
TheScribe: Anish> w/regards to an "apiDocs" resource, I'd like to see more detail on how you would use this to get a list of types or a list of the attributes supported by a type
TheScribe: Adrian> (goes to the glass)
TheScribe: Anish> you need the ability to discover the list of the supported attributes for a type before any instances of that type exist
TheScribe: ... w/regards to instance attributes beyond those of the attributes for a type, CAMP defines a resource-model - not clear how useful this is if we don't conform to the types we define
TheScribe: (goes to the glass)
TheScribe: Anish> we have a decision to make: query paramater or URL patterns?
TheScribe: Martin> could support two different queries - one that gives you back a list of "everything" and another that gives you back just a list of the stuff that's not defined in the spec
TheScribe: ... begs the question of namespacing - separating one extension from another
TheScribe: Alex> seems like we have a lot of big, open questions
TheScribe: ... need to bottom-out this 'type' discussion
TheScribe: ... defining a new type every time I want to do something like add monitoring attributes is onerous
TheScribe: Mark> whatever scheme we come up with, I'd like it to deal with specializing Platform Components
TheScribe: ... need to figure out how to do "specialization by sub-classing"
MartinC : we could use Avro IDL http://avro.apache.org/docs/current/idl.html
TheScribe: (general discussion)
MartinC : (if one was a pervert)
TheScribe: Adrian> (goes to the glass)
TheScribe: Adrian> we don't need to define fixed URI stems (e.g. ".../api/versions"), just need to define attributes in Platform that give your the URL of the thing you are looking for
TheScribe: ... e.g. "versionURI" : "http://whatever/whatever/versions";, "typesURI" : "http://whatever/whatever/types";, ...
TheScribe: Anish> below "types" you can define a URI pattern that says "assembly" will get you the metadata for the Assembly resource type
TheScribe: ... I'm beginning to prefer this over query parameters
TheScribe: ... is there anybody who thinks this is a bad idea
jeffm: sounds like a good idea
Alex Heneveld (Cloudsoft): straw poll request: do people prefer (A) Theoretical REST where you don't know any URL's except the main endpoint, and you traverse well-known-labelled links; or (B) Practical RESTful API style where the URL format is defined e.g. /resource/R1/xxx/; ... or (C) both
jeffm: actually, i think as long as there is a well defined way to get the metadata, it probably doesn't matter that much how its done
TheScribe: Anish> spec should do A, implementations can do B (thus making them C)
TheScribe: Anish> we don't have any type hierarchy (resource types and sub-types) in the spec right now
TheScribe: Jeff> don't think it matters that much whether you chose A or B (C would be awful), as long as there is a well-defined way to get the information
TheScribe: ... don't worry about REST purity, developers don't care
TheScribe: ... doing both is the worst of all possible worlds
TheScribe: ... except for "either or"
TheScribe: Alex> I'm going to take away my objection to 'B' - 'A' is beneficial to the provider (can spread things out) but it is harder for the developer (e.g. curl | grep | curl | grep) so 'B' is more developer friendly
TheScribe: Anish> like 'A' more and more (turtles all the way down) - provider can recurse as far they feel is beneficial
TheScribe: ... with 'B' you can only recurse as far as CAMP defines a pattern
TheScribe: Jeff> what is the difference between traversing well-kown links and pre-defined URI patterns
TheScribe: Alex> 'A' makes it easier to federate
TheScribe: Alex> 'A' is more flexible that 'B' - 'A' can be used to subsume an implementation that previously used 'B' without breaking any clients that depend on the URI patterns
Alex Heneveld (Cloudsoft): BTW I have opened https://tools.oasis-open.org/issues/browse/CAMP-44 to clarify our use of types
TheScribe: awesome
TheScribe: https://tools.oasis-open.org/issues/browse/CAMP-10 API+Model Extensions
TheScribe: Adrian> (refresh of the issue)
MartinC : http://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json
TheScribe: Adrian> need to enable de-centralized development CAMP extensions
Tobias Kunze (Red Hat): Suggestion: add a reserved "extensions" key to EVERY resource whose value is a dictionary where every vendor can use their name to add their extension
TheScribe: ... proability of two people picking the same prefix is remote but the probability of two people picking "serverID" as an attribute name is fairly high
Tobias Kunze (Red Hat): example: { ..., "extensions": { "com.redhat": { "mykey": "myval", ...}}}
TheScribe: Adrian> that's conistent with my suggestion
TheScribe: ... this works for extensions, but it doesn't work for attributes
anish: javascript variable name validator: http://mothereff.in/js-variables
TheScribe: Martin> don't see much difference between this and flat names like "com.redhat.mykey"
Tobias Kunze (Red Hat): the difference is that "com.redhat.key1", ..., "com.redhat.key-n" could be potentially large and hard to read
TheScribe: Alex> seems to be sympathy for the use of domain names - despite the syntactic headaches they may cause for dynamic languages
TheScribe: Adrian> recommend stock ticker symbol (if you have one) otherwise use your domain name
Alex Heneveld (Cloudsoft): Suggestion: Extension attributes on well known types SHOULD be prefixed by a domain name. Custom types SHOULD be prefixed by a domain name. Standard attributes on a custom type SHOULD NOT be prefixed by a domain name.
TheScribe: Gil> can we separate the issues? (1) separator characters (2) name basis
TheScribe: Alex> underbars
TheScribe: e.g. "com_redhat"
Jacques (Fujitsu): testability: as long as a normative spec req can be tested just by (a) a hard-coded condition on message content, or (b) a consistency condition between message(s) content (say a metadata query followed by an instance query), then we'r OK testwise. What we don't want is to have to go read an external doc or resource to figure whether a message is correct.
TheScribe: DIRECTIONAL RESOLUTION: "com_redhat_foo" (not "com.redhat:foo", really not "com.redhat.foo", really, really not "com.redhat_foo")
Jacques (Fujitsu): OpenStack extensions:
Jacques (Fujitsu): New elements and attributes. Extensions may add additional data elements or
attributes to existing MIME types.
New resources. Extensions may define entirely new API resources.
New parameters. Extensions may introduce new query parameters to existing
resources.
New headers. Extensions may define new HTTP headers.
New verbs. Extensions may introduce support for an HTTP verb (PUT, POST) to an
existing core resource.
New media types. Extensions may define entirely new representation types for
existing resources.
New actions. Extensions may define new actions on existing resources.
New states. Extensions may introduce new states in an API state machine.
Other capabilities. Extensions may define other general API capabilities. For example,
the ability to edit an otherwise uneditable attribute.
Tom Rutt (Fujitsu): for coffee lovers check out http://summitcountyvoice.com/2012/11/09/global-warming-puts-wild-arabica-coffee-plants-at-risk/
Jacques (Fujitsu): issue #14
MartinC : https://tools.oasis-open.org/issues/browse/CAMP-14
Jacques (Fujitsu): issue #14
MartinC : https://tools.oasis-open.org/issues/browse/CAMP-14
TheScribe: Back from break
TheScribe: https://tools.oasis-open.org/issues/browse/CAMP-14 How are supported formats discovered
TheScribe: DIRECTIONAL RESOLUTION: If a provider claims to provide a particular format, *every* resource available through the tree rooted in "Platform" MUST be available in that format
TheScribe: Gil> strawman (similar to proposals for versions and types) add a "formatsURI" to Platform that references a catalog resource of format names (e.g. "JSON", "XML") and links to descriptions of those formats
TheScribe: Adrian> list JSON
TheScribe: https://tools.oasis-open.org/issues/browse/CAMP-38 resourceState attribute needs clarification
TheScribe: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47943/camp-38-2013-01-18.doc
Jacques (Fujitsu): "READY" for what? (isn't "CREATED" good enough?)
MartinC : sysnonyms Jacques
Jacques (Fujitsu): if we need to know the details of resource-level ops, tasks or jobs are better, less ambiguous.
Mark Carlson (Oracle): Creating, Ready, Busy, Error, and Destroying are a great example of an underlying resource state machine that I mentioned. For ResourceReady it would be either the YES or NO values.
MartinC : cloud job control language!
Mark Carlson (Oracle): There are some resources that are always there (like Platform) - they have no other state attribute - they are Always ResourceReady=true. Cannot create, cannot delete, and should never be in any error state....
Jacques (Fujitsu): in favor of CAMP defining a basic binary status at resource level: OK / not OK (to use). Anything more will call for terminology trouble... (and if a Provider wants to give more info, a "jobs status" capability can be optionally added)
Jacques (Fujitsu): or a log capability.
Mark Carlson (Oracle): I think maybe we should defer this issue until we have a worked example.
Alex Heneveld (Cloudsoft): controlStatus: CREATING, READY, ERROR, DESTROYING
MartinC : meeting recessed
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]