[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]