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