[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [camp] Draft Minutes F2F 23-25 January 2013
Sorry forgot to record Gershon Janssen for the roll. See Diff below. >-----Original Message----- >From: Martin Chapman >Sent: 28 January 2013 17:44 >To: camp@lists.oasis-open.org >Subject: [camp] Draft Minutes F2F 23-25 January 2013 > >Face to Face Meeting Minutes, 23rd - 25th January 2013 > Rackspace Hosting Inc, San Antonio, Texas, USA > >Attendees: > >Agrawal, Roshan Rackspace Hosting, Inc. Member >Behrens, Michael US Department of Defense (DoD) Voting Member >Carlson, Mark Oracle Voting Member >Chapman, Martin Oracle Chair >Durand, Jacques Fujitsu Limited Voting Member >Heneveld, Alex Cloudsoft Corporation Limited Voting Member Janssen, Gershon Individual Voting Member >Johnston-Watt, Duncan Cloudsoft Corporation Limited Voting Member >Karmarkar, Anish Oracle Voting Member >Kunze, Tobias Red Hat Voting Member >Malhotra, Ashok Oracle Voting Member >Miller, Rich Cloudsoft Corporation Limited Voting Member >Mischkinsky, Jeff Oracle Voting Member >Otto, Adrian Rackspace Hosting, Inc. Secretary >Pilz, Gilbert Oracle Voting Member >Rutt, Tom Fujitsu Limited Voting Member >Tupitza, Charles JumpSoft Voting Member >Yendluri, Prasad Software AG, Inc. Voting Member > > >Intro: > > Adrian assumes scribe duties. > > Roll Call: listed above, meeting is quorate > > Agenda: > > 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. > > We plan to address this subject during the part of our meeting when we >discuss the relative priority of the open issues. > High priority issues should have target dates assigned so we can plan >progress in order to meet the milestone. > Agenda modified wrt timings and people's availability. > Add item Long term workplan discussion to be added to agenda > No objections to modified agenda. > > Agenda approved. > > Minutes: > > Minutes 16th January 2013: https://www.oasis- >open.org/apps/org/workgroup/camp/email/archives/201301/msg00040.html > > Motion: m: Gilbert Pilz, s: Tom Rutt: motions to approve the minutes >from Jan 16, 2013 > Martin asks if the text based minutes format is acceptable by the >members. > The format is indicated to be fine. > > no discussion on minutes > passed w/o > > Action Items: > > Action-201301-16-0: Martin to place web-ex and conference bridge details >on the Kavi calendar and agenda for F2F > > Done > > > No administrivia to discuss. > >Editor's update: > > 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. > https://www.oasis-open.org/committees/download.php/47987/camp-spec-v1.1- >wd02.zip > WD02 will be used for any modifications from this point. > > Jacques requests that TC members review the draft of the test assertions >document prior to discussion tomorrow. It is a 14 page document. > >Discussion of new issues: > > https://tools.oasis-open.org/issues/browse/CAMP-39 > Motion: m: Gilbert Pilz, s: Adrian Otto: Motion to open issue CAMP-39 > Passed w/o CAMP-14 is open. > > Action Item for Martin C: Check that all associated issues are >appropriately allocated to the spec. > [Done, they are!] > > https://tools.oasis-open.org/issues/browse/CAMP-40 > Tobias Kunze speaks in support of the issue > Anish K speaks in support of the issue > 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. > > Motion: m: Gilbert Pilz, s: Duncan Johnston-Watt motions to open CAMP-40 > No discussion > Passed w/o, CAMP-40 is now open. > >Topic: General extensibility discussion kicked off by Gil: > > Gil begins a discussion on Extensibility > https://www.oasis- >open.org/apps/org/workgroup/camp/email/archives/201301/msg00044.html > > 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. > > 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? > > Consensus reached that Extensions must not contradict the spec. > Considerable support for the idea that mandatory Extensions should not be >allowed. Active discussion of this point. > Duncan Johnston-Watt: +1 > > Jacques suggests that extensions should be allowed, provided they do not >fail the base set of test assertions. > Duncan Johnston-Watt: +1 - that is one aspect of conformance (compliance?) >with spec > 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. > > 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 feasibility 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). " > > Gil suggests some terminology to refer to a grouping of related extensions. >We should refer to this as a Feature. > > Alex Heneveld (Cloudsoft): I have posted some vocab for "extension types" as >a comment at https://tools.oasis-open.org/issues/browse/CAMP-10 > >Gil assumes scribe duties > > Specific extensibility issues: > > https://tools.oasis-open.org/issues/browse/CAMP-1 Need a way to get >metadata for a particular resource > > concrete proposal: https://www.oasis- >open.org/apps/org/workgroup/camp/download.php/47367 > 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" > Anish> this proposal needs work - it is a hold-over from the collaboration >days > Adrian> the lists of attributes is not identified by types > 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. > ... could add a URL that tells you where to get the documentation > Alex> issue description discusses "resources" and "resource types" > ... need a way to navigate the types that are exposed in the system > ... maybe that should be a top-level resource e.g. "apiDocs" > ... also a need a way to get the per-instance list of all the attributes >that have values > ... or cases where instances have more attributes than their type > Gil> why are you telling me about attributes and types that are defined in >the spec - I know they exist > 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 > Gil> also uncomfortable with the idea of instances that contain attributes >that are not defined by their type > ... 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 > Jacques> are the underscores around the _PaaSRT_ query parameter, a CAMP >convention? > Anish> don't want to conflict with other query parameters, but name is the >least important thing > 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 > Tom> is there some way to get "all" the metadata in one shot? > Anish> you have to think about how you are going to retrieve and use the >metadata > 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 > Adrian> (goes to the glass) > Anish> you need the ability to discover the list of the supported attributes >for a type before any instances of that type exist > ... 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 > (goes to the glass) > Anish> we have a decision to make: query paramater or URL patterns? > 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 > ... begs the question of namespacing - separating one extension from another > Alex> seems like we have a lot of big, open questions > ... need to bottom-out this 'type' discussion > ... defining a new type every time I want to do something like add >monitoring attributes is onerous > Mark> whatever scheme we come up with, I'd like it to deal with specializing >Platform Components > ... need to figure out how to do "specialization by sub-classing" > > (general discussion) > Adrian> (goes to the glass) > 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 > ... e.g. "versionURI" : "http://whatever/whatever/versions", > "typesURI" : "http://whatever/whatever/types", ... > Anish> below "types" you can define a URI pattern that says "assembly" will >get you the metadata for the Assembly resource type > ... I'm beginning to prefer this over query parameters > ... 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 > Anish> spec should do A, implementations can do B (thus making them C) > Anish> we don't have any type hierarchy (resource types and sub-types) in >the spec right now > 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 > ... don't worry about REST purity, developers don't care > ... doing both is the worst of all possible worlds > ... except for "either or" > 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 > Anish> like 'A' more and more (turtles all the way down) - provider can >recurse as far they feel is beneficial > ... with 'B' you can only recurse as far as CAMP defines a pattern > Jeff> what is the difference between traversing well-kown links and pre- >defined URI patterns > Alex> 'A' makes it easier to federate > 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 > >https://tools.oasis-open.org/issues/browse/CAMP-10 API+Model Extensions > > Adrian> (refresh of the issue) > MartinC : >http://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json > 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 > ... 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", ...}}} > > Adrian> that's conistent with my suggestion > ... this works for extensions, but it doesn't work for attributes > anish: javascript variable name validator: http://mothereff.in/js-variables > 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 > Alex> seems to be sympathy for the use of domain names - despite the >syntactic headaches they may cause for dynamic languages > 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. > Gil> can we separate the issues? (1) separator characters (2) name basis > Alex> underbars 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. > > 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. > > > > >Camp-14: https://tools.oasis-open.org/issues/browse/CAMP-14 How are >supported formats discovered > > 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 > 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 > Adrian> list JSON > >CAMP-38: https://tools.oasis-open.org/issues/browse/CAMP-38 resourceState >attribute needs clarification > > 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. > 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) > ... 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 > > >DAY 2 - 24th January 2013 > > >Duncan Johnston-Watt assumes scribe duties > > Re-jig of agenda times > Camp 38 (Gil) and Camp 10 (Adrian) proposals to be discussed after the break >at 11.00 Draft proposals for Camp 9 & 42 (Alex) to be added to discussion >after break at 11.00 > > Martin to post links to PPT and draft into chat room > > Jacques > Recap on purpose of testing (https://wiki.oasis- >open.org/tab/TestingPolicy) - > 1. Validating a specification > 2. Verifying an implementation > > MartinC : Jacques presentation from November: > https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47418/CAMP- >Testing.ppt > MartinC : camp-ta editors draft outline: > https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47838/camp- >ta-v1.1-wd01b-candidate.doc > > Ref 1: Developing test suite alongside development of spec helps tease out >gaps/inconsistencies/ambiguity > Ref 2: Three aspects conformance with spec; interoperability with other >implementations; maintenance > > Adrian > Will we have test tools? Or just documentation? > Anish > Undecided. > MartinC > Table issue for planning session. > Anish > Would like test suite to be a "product" of TC > Developing test suite might impact timeline for TC > Jacques > It can be an important contribution to certification program > Roshan > Conformance does not guarantee interoperability > MartinC > Extensions could affect interoperability (as discussed yesterday) > Anish > Interop "fest" is one way of figuring this out. Other TCs have >found this useful. > Jacques > Two aspects. Operations to be exercised and analysis of results > Jacques > Illustrated with Slide 13 from PPT - SUT stands for System Under >Test > Phase 1: Test Operations (a) against an SUT in isolation (conformance); >(b) against multiple SUTs in matrix (interop); and (c) maintenance testing > Phase 2: Execution trace input into analyzer which compares these with >test assertions and generates report > Jacques > Now showing Slide 4 > Jacques > Role of test assertions - these are derived from test suite and >address one or more normative statements in spec (act as a bridge between > ... two teams - spec authors and test suite authors) > Roshan > Does this imply there is a reference client executing the >operations > Jacques > Although test assertions are intended to be abstracted away from >implementations there will need to be a client > Anish > In other standards work we tag statements in spec > Anish > Cross reference test assertions against these statements > Jacques > Referencing WSI document > Tom Rutt (Fujitsu): wsi BP 2.0 http://ws-i.org/Profiles/BasicProfile-2.0- >2010-11-09.html > Jacques > Embedded links to test assertions embedded in spec and vice versa > Duncan > This looks like a maintenance headache > Anish > Wants to introduce Software Component Architecture (SCA) as a >cleaner way of dealing with this > Anish > Here is the link http://docs.oasis-open.org/opencsa/sca- >assembly/sca-assembly-1.1-spec.pdf > See for example Section 3 and Appendix C > Anish > Here is the test assertions doc http://docs.oasis- >open.org/opencsa/sca-assembly/sca-assembly-1.1-test-assertions-cd01.pdf > See for example 1.1 (format) and 2.1 > Jacques is now walking us through first example in 2.1 Section 4 > Adrian > Source referenced for a Assertion ID should be specific > IE Source should be a normative statement (or list of statements) > Tom > Important to note that it is in the test assertion that we specify >the actual target > Anish/MartinC > In this example we are testing a constraint that cannot be >captured in schema > Adrian Otto (Rackspace): The preferred style: > Adrian > Suggests a terser style > Adrian Otto (Rackspace): Assertion ID = TA-10 > Adrian Otto (Rackspace): Source = S-12 > Adrian Otto (Rackspace): Prerequisites: TA-9 must pass > Adrian Otto (Rackspace): so, no zeropad for numbers and we use a short >prefix of TA- or S- to indicate which references are sources (S) or test >assertions (TA) > Jacques > Adrian has highlighted important point that TAs may have other TAs >as prerequisites > > Switching to CAMP TC test assertions draft > Jacques is discussing 3.1 Example > Roshan> Section references will change? > Tom > Will be replaced by Tags to address this > (Context - NormativeSource) > Anish > ,ar > Anish > Large number of targets? > Tom > Target should thing that is subject of test (which may not be >SubjectUnderTest) > Tom Rutt (Fujitsu): The Predicate operates on the "target". The target may >be an artifact which was generated by the SUT. > > MartinC : from: http://docs.oasis- >open.org/templates/TCHandbook/ConformanceGuidelines.html > MartinC : Conformance Target an artifact such as a protocol, document, >platform, process or service, which is the subject of Conformance Clauses and >Normative Statements. > There may be several Conformance Targets defined within a specification, >and these targets may be diverse so as to reflect different aspects of a > specification. For example, a protocol message and a protocol engine may >be different targets. > MartinC : this is intended to be different from a testing target - but i >agree with tom the using "target" for both can be confusing > > Rich > What assumptions (if any) are we making about implementing these >tests - using automation tools? Standardizing on reports? etc > Jacques > Good question. While the TAs are abstract they need to be easy to >implement. > Jacques > SUT (Provider) to be treated as black box - hence focus on >messages > Tom > Which in turn means we need to think about feasibility of the TAs >(messages will need to be generated, PDPs created etc etc) > Alex > TAs should be consumable by automated test engine ideally - example >we are looking at (second one in 3.1 in draft) > ... fits this model better > Anish > Need to make a decision - are we going to adopt tagging (following >sca-assembly approach) > MartinC > granularity of tagging is still important > > MartinC > Need to wrap up test assertions discussion and decide on tagging >so that authors can proceed > MartinC > Rewrite of spec also required / implied by decision > Adrian > To submit issue > MartinC > normative statements need to be labelled (scope of labelling may >vary) in order to feature in a test assertion > MartinC > Discussion of RFC/ISO to be part of discussion of new issue CAMP- >45 Normative Statement overhaul (added by Adrian) > > Now considering https://tools.oasis-open.org/issues/browse/CAMP-45 > > Motion: m: Adrian, s: Anish moves to open CAMP-45 > Gil > Figuring out what we mean by consistent style is part of resolving >this issue > Sidebar: MartinC agreed to log issue re conformance target versus testing >target > Discussion regarding ensuring spec is acceptable as ISO standard > No further discussion > Passed w/o, CAMP-45 opened > > Now resuming test assertions discussion > > Jacques is discussing second example in 3.1 > This is more general (parameterized) version of original example > Adrian > Would this TA still hold wrt extensions? If so how? > Jacques > Needs further discussion > Now considering 3.2 Protocol Test Assertions > Jacques > Ideally we would like to obtain meta-data in the same way EG via >a plain GET > Tom > Normative source here is no longer just a label but includes >derivation for testing purposes > Jacques > Derivation is the correct term > >Jacques Durand assumes scribe duties > >Topic: Review of TC Timeline > > Anish: need to establish exit criteria > chair: typically, CS level: every feature need be implemented twice > Adrian: test suite relationship? conformance requirement? > Adrian: how do we define "feature"? > Adrian: (read charter) TC defines exit criteria. At minumum: 2 >interoperable impl of both kinds (COnsumer/Provider) must impl every mandatory >feature, etc... > jacques: implicitly, interoperable exchanges assume they are agreed to be >conforming (according to test assertions) > test assertions will be a CS > > Duncan: CloudOpen is coming up - could be the event where we publicize CAMP >(Sept 16-1) > See http://events.linuxfoundation.org/events/cloudopen > > Anish: mandatory vs optional: a "feature" will map to several normative >reqs. > Duncan Johnston-Watt (Cloudsoft): Sounds like there is general agreement >that interoperability testing has to be scenario-based (Adrian, Anish et al) > ... testing: we created scenarios exercising specific features > Duncan: keep the bar to a feasible level (don't want to miss exit criteria >because of high bar) > ... a core set of features / reqs could be defined. > chair: optionality of behavior not same as optionality of support. > > Anish: publish early & often... > chair: 3 delivery lines (internal + external): (1) main spec, (2) test >assertions, (3) implementations/interops > chair: 1st PR: all P1 issues resolved is a prereq > Testing = {TA document + test scenarios + test suite } > the TA document timeline must be most closely tied to core spec timeline - >but may lag behind a couple weeks. > Tom: interop demo does not rely on the [conformance] test suite ? > Anish: any interop exercise must be validated by test scenarios and comply >with test assertions > chair: plugfest 1 : around 1st PR time, plugfest 2: > qualifies for exit criteria. > roshan: implementations should be more precisely scheduled on the tmeline: >we need to plan for having qualifying two impl. > chair: who is implementing? > Adrian: Rackspace focusing for now on the actual underlying functions - not >so much on [CAMP] API. The API priority level is less than the layer >underneath. > ...RSpace may decide to make it an open-source project too. > > A fork of the original OSS can be considered as a separate implementation? > chair: we can change the charter if needed (without breaking the spirit of >the law) > ... deadline we work on: CS approval. > > Duncan: tentative: early September for CS. Meaning 7 month for tech work. > anish: end of May for 1st PR? > > chair: proposed timeline: > ... 1st April= closing deadline for P1 issues > ... 1st June: 1 PR startd > ... 1st August: all issues on JIRA closed, 2nd PR > ... 1st September: CS ballot started > > .. candidate F2F dates: 1st week april, mid-July, > ... OS is off chart for now (tentative 1Q 2014) > ... CS (Committee Spec) plan for early September approval. > >topic: issue prioritization > > From now on when we open an issue we will assign a ing issues, we'll assign >priority. > p1 = Must fix, p2 = should fix, p3= nice to fix > > We agreed that in JIRA p1= critial, p2=major, p3=minor - we will not use >other priority sates. > We also agreed that task = editorial task > > ... considering "open" issues only: 29 issues > camp#1: > > critical (P1) > > critical (P1) > > Gil yawning > > task = editorial task > > so: camp#1= "critical(P1) + task) > > Gil displays a prioritization proposal. > > #1,4,10,14 are related > ... along with #39: all about extensibility. > ... proposed to be P1. > #26: proposed to be P3 > camp#11: proposed to be P2 > > MOTION: Alex, s: Gil that we adopt the proposal priority and owner >assignments as follows: > ===== #1: P1 > ===== #3: P1, Anish > ===== #4: P1, adrian > ===== #5: P2, Gil > ===== #9: P2, Alex > ===== #10: P1, adrian (+ change title "extension scheme") > ===== #11: P2, Alex > ===== #14: P1, Gil > ===== #16: P3, ? > ===== #17: P1, Tom > ===== #18: P2, Gil > ===== #19: P3, adrian > ===== #20: P2, Gil > ===== #21: P1, Gil > ===== #22: P2, Gil > ===== #23: P2, Gil > ===== #26: P3, Mark > ===== #27: P3, Gil > ===== #28: P2, adrian (link to #10) > ===== #29: P2, Gil > ===== #30: P1, adrian > ===== #31: P2, jacques > ===== #34: P1, adrian > ===== #36: P1, adrian > ===== #37: P2, Mark > ===== #28: P2, Gil > ===== #39: P1, adrian > ===== #40: P2, gil > ===== #45: P1, editors > ... end of motion > > > no objection, passed w/o > >Topic: new issues > > > https://tools.oasis-open.org/issues/browse/CAMP-41 > Duplicate of 34 > Motion: m: Anish, s: Adrian MOVES to close 41 as a dup of 41 > No discuss/obj. Passed w/o > > https://tools.oasis-open.org/issues/browse/CAMP-42 > (alex) discussed: Tobias has reservations > MOTION: m: alex, s: adrian) to open as P2, assign to alex. > passed w/o > > https://tools.oasis-open.org/issues/browse/CAMP-43 > issue will be duplicate of adrian's > MOTION: m: adrian, s: alex to close 43 as a dup of #4. > passed w/o > > https://tools.oasis-open.org/issues/browse/CAMP-44 > adrian: discovery for types could address this? maybe > tom: clarify the issue (resource type) > MOTION: m: alex, s:duncan), to open camp 44, linked to #39 and #1, with P3 >level > Passed w/o > > https://tools.oasis-open.org/issues/browse/CAMP-46 > MOTION: m: tom, s: anish: to open camp 46, P2 level, assigned to Jacques. > passed w/o > > Topic: issue technical discussion > > topic: camp #10 https://tools.oasis-open.org/issues/browse/CAMP-10 > adrian: discuss his proposal > anish: if use HTTP URL, similar restriction is required. Can drop the >section. > adrian: extensions will always be used (e.g. needed by auth) > ... consensus that the notion of "prefix" (for attr names) is not a key >concept in CAMP, just a best practice to avoid name collisions. > Alex Heneveld (Cloudsoft): Where an extension wishes to support one or more >additional formats, these formats MUST be supported for all resources defined >in the spec. > jacques: import/export ops may have to deal with different formats than the >one(s) claimed to be supported. > discussion on not exceeding the scope of the spec. > discussion about difference between "features" and "extensions" (different >data structure?) > adrian to repost an updated proposal (camp #10), for candidate motion >tomorrow. > > topic: camp #38 https://tools.oasis-open.org/issues/browse/CAMP-38 > discussion on the "control status" values, and meaning. > Mark Carlson (Oracle): The controlStatus attribute expresses certain >restrictions on this resource based on underlying activities as shown in Table >X below. > jeffm: I think anish is correct > adrian: error state has value in a distributed system > Tom Rutt (Fujitsu): perhaps "representationStatus" is a better name for this >common attribute rather than "controlStatus" > Mark Carlson (Oracle): The controlStatus attribute expresses certain >restrictions on this resource based on underlying activities as shown in Table >X below. > Mark Carlson (Oracle): The activityStatus attribute expresses certain >restrictions on this resource based on underlying activities as shown in Table >X below. > > chair: #38 needs more work on proposal. > > chair: meeting recessed for the day. > >Day 3 > >Mark Carlson assumes scribe duties > > Adrian: Need to nod on issue 39, plus update proposals for 10 and 14. > Adrian: also added a comment on another issue > > > CAMP-9 https://tools.oasis-open.org/issues/browse/CAMP-9 > Alex: propose a generic "operations" attribute with OperationName:Link >entries > Alex: Get fetches a ResourceOperation resource type with description and >map values > Alex: POST invokes the operation, taking a map for parameters > Adrian: needs to work for extensions as well. > Anish: would they be the same link? > Alex: the client doesn't care > Adrian: could get operations metadata the same way as CAMP-1 > Gil: do operations by updating the resource directly > Gil: see comment I added to the issue. Put all the sensors in a sub >resource that is not affected by the effectors changing > Alex: It's more clear with specific URLs > Tobias Kunze (Red Hat): +1 on Gil's comment > Jacques: Are URIs well formed and non-opaque? > Tobias Kunze (Red Hat): Consensus so far was that URLs are HATEOAS > Tobias Kunze (Red Hat): ie opaque > Alex: we should continue to NOT dictate the URL structure > Tom: URLs are not identities. The data is "state". I like PATCH for >operations. > Tom: what happens when you do a GET against the operation URL? > Tom: in support of Alex's proposal > Tobias: makes sense to keep things fine grained at the lowest level. > Jacques (Fujitsu): in a world where there is a large number of similar >objects (dtabases...), > ... single-URI resources + actions-as-parameter, make sense. But here, >"resources" are different kind of objects, > ... probably smaller scale than DB records/objects. The operation-as- >resource approach flexibility can make more sense. > >Meeting recessed for public OCCI presentation > > OCCI slides: https://docs.google.com/presentation/d/122sQ-lQzeBadyFoeED- >h341Dh8fqJQZChk6QQLm-0M0/edit > > Meeting is recalled from OCCI recess > > >Issue Discussion: > > CAMP-42: https://tools.oasis-open.org/issues/browse/CAMP-42 > Alex has an updated proposal. > Propose query parameters to scope what is returned > Martin: split out the two issues? > Alex: it can get very complicated > Jacques: is this convention used elsewhere? > Alex: have not copied it from somewhere else... > Adrian: investigate byte-range as a way to get number of characters, but if >you want to count records that would be a useful addition > Jacques: separate what you are selecting and what is returned for your >selection > anish/ adrian, the accept-range header is a server-side header, which tells >the client what it can do with ranges. > ... Range is the correct http client-side header to request a specific byte- >range > Gil: may have implications on how we structure the resources for >metrics/affectors > Martin: need normative definition for RegEx > Alex to consider discussion and should proceed with a more details concrete >proposal along the proposed lines > > > CAMP-30: https://tools.oasis-open.org/issues/browse/CAMP-30 > Adrian: soliciting feedback on the proposal in the issue comment > Anish: this doesn't allow instance attributes that are not in the Template > Anish: have a special attribute in the template that lists all the Assembly >attributes that are parameterizable > Adrian: will update the proposal > Roshan: did not see a way to create some attributes > Adrian: revised proposal will make that clear > Jacques: support for writable on the instance type gives us what we need > Adrian: how is that supplied over and above the value in the template? > CAMP 30 should proceed with a more detailed concrete proposal along these >lines, discussion closed for now > > > CAMP-14: https://tools.oasis-open.org/issues/browse/CAMP-14 > Adrian: took out reference to deployment plan as being an XML file > Adrian: added a supported formats URI in 5.6 Platforms > Adrian: added 5.17 Format resource > MartinC : CAMP-2 What is the purpose of the Definitions attribute? has >already been resolved - editors need to apply > Adrian: if you have a formats URI, there must be at least the JSON format >defined > Adrian: this allows you to not have to special case the existing format when >multiple exist > Gil: the version is too cute. Just have a new format for the two versions > Gil: what will the client do with the version information? > Adrian: it will match it's search for what it is coded for > Adrian: example is if my format needs to break with older clients of it > Adrian: Formats is a singleton that collects all the format resources > Anish: we are establishing a pattern of always creating new resources for >finding extensible lists > Adrian: since Discovery is done so rarely, this prematurely optimizes for a >good reason > Jeff: JSON should always be the first element > Adrian: added text to require this > Adrian: deleted text that looked like a normative statement to use content >negotiation > Adrian: should we end the name of these attributes with "Uri"? - no >disagreement > > MOTION (m:adrian s:gil) use camp-14-2013-1-24-r4.doc to resolve issue CAMP- >14 > Adrian Otto (Rackspace): Correction for the doc referenced by the prior >motion: > https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48022/camp- >14-2013-01-24_r4.doc > Passed w/o > > >Meeting wrap up: > > > Proposed next face to face April 4th-5th. 15 people. Possible Portland, OR >or San Jose, CA > Alex Heneveld (Cloudsoft): 3rd, 4th, and 5th > Alex Heneveld (Cloudsoft): Martin says he would welcome a perm co-chair if >anyone is interested and available. > > Chair is requesting pro-tem chair for 6th Feb 2013 > Rich Miller (Cloudsoft): Ah. Got it. Tom is co-chair pro tem for meeting >in 2 weeks (?). Independent question is a standing Co-Chair. Will discuss >with Duncan and others. > > Motion: m:Martin, s: Anish: appoint Tom Rutt appointed interim Pro-Tem >chair for the meeting on February 6th 2013 > Passed w/o > > >Any Other Business: > > The Chair and fellow TC members thanks Rackspace for the excellent hosting, >tour of "the Castle", and for dinner on the Riverwalk. > Duncan Johnston-Watt (Cloudsoft): +1 > >Meeting Adjourned. > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that generates >this mail. Follow this link to all your TCs in OASIS at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]