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

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

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


Subject: 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]