From: MartinC [mailto:noreply@soaphub.org]
Sent: 09 November 2012 00:04
To: martin.chapman@oracle.com
Subject: oasis-camp: Chat Transcript - sent by: MartinC
Chat transcript from room: oasis-camp
2012-11-08 GMT-08:00
[09:13] anonymous morphed into Dave Jilk
[09:16] Dave Jilk morphed into scribe
[09:32] anonymous morphed into Prasad
[09:42] Anish Karmarkar: ping
[09:44] gilbert.pilz: ack
[09:45] scribe: call to order by martin at 9:44am PT
[09:45] scribe: alex to present two issues this morning
[09:46] scribe: camp-8 (hierarchical model of platform components)
[09:50] scribe: Dave: seems like it's too much detail and would never result in portability
[09:50] scribe: Alex: more about reporting on the details
[09:50] scribe: Alex: want to understand shape of what the platform is running
[09:52] scribe: Adrian: nothing stopping platforms from using extensibility model to expose this info
[09:52] scribe: Adrian: has nothing to do with portability of app
[09:53] scribe: Alex: *does* have to do with portability and management - if I can't drill down I will struggle to manage
[09:53] scribe: Alex: ok to go with extensibility
[09:54] scribe: Alex: Update issue with discussion and close - aim for 2.0
[09:54] scribe: Adrian: be sure to get the extensibility model right to be able to handle this
[09:55] scribe: Alex: motion to close issue camp-8, Anish seconded. No objection to close camp-8
[09:56] scribe: Next issue Camp-9
[09:56] scribe: (support sensors and effectors on components via API)
[09:57] scribe: Alex: go beyond simple attributes to full JMX operations
[09:58] scribe: Martin: how does it fit with REST resource model?
[09:59] scribe: Adrian: similar to an open case (camp-11) - this is one proposal how to implement.
[10:00] scribe: Alex: don't mean JMX implementation - more the idea.
[10:00] scribe: Alex: motion to leave Camp-9 open for purpose of developing concrete proposal.
[10:01] scribe: Adrian: suggest web hooks
[10:01] scribe: Ashok seconds the motion
[10:02] scribe: Correction: the motion is to open this issue, from "new" status.
[10:03] scribe: Mark: App would need to expose information through CAMP - this is tricky
[10:05] scribe: Adrian: don't need to define this, platform can support
[10:05] scribe: Mark: slippery slope - outside scope of charter
[10:06] Alex Heneveld (Cloudsoft)1: +1 out of band, implementation can support without CAMP specifying how (it just ends up exposed as attributes)
[10:07] MartinC: i think this is about the spec defining some enabling mechanisms
[10:07] scribe: Ashok: can just be the application's business
[10:08] scribe: Alex: application can always expose management on its own channel, would be nice to expose through CAMP
[10:10] scribe: Tobias: sympathetic to the cause - really not much about monitoring in current spec
[10:12] scribe: Tobias: let resources expose whatever they want, look at extending to app components
[10:12] scribe: Martin: worth exploring enabling mechanisms as to how to achieve this.
[10:13] Tobias Kunze (Red Hat): Support the CAMP-9 cause, but favor (a) keeping the exact specification of attributes to expose entirely outside of the spec and (b) extending this capability to both ACs and PCs
[10:13] scribe: No objections: CAMP-9 is open.
[10:14] MartinC: https://oracleconferencing.webex.com/oracleconferencing/j.php?J=593156882&PW=NNTBiYjMyZDM2
[10:15] scribe: Gil: Sent deck out last week.
[10:15] scribe: s/deck/document/g
[10:19] scribe: Gil presenting lifecycle management document
[10:30] scribe: Martin: Do not assume that transitions are camp things
[10:31] scribe: Martin: lots of assumptions in spec, agree we need to clarify
[10:36] Adrian Otto (Rackspace): Mark: describing the need for a distinction between required and optional states.
[10:41] Adrian Otto (Rackspace): I asked what techniques to standardize similar states among multiple vendors. Mark answered that discussion and consensus about common semantics has shown to be effective in other specification efforts.
[10:56] Jacques (Fujitsu): yes to extensibility of the set of "transitions" (but an impl should not alter the semantics of CAMP-defined ones - possibly "add" semantics though)
[11:04] scribe: coffee break after extensive discussion
[11:04] scribe: 11:05 PT
[11:19] Prasad: My humble opinions: (Q1) Should CAMP surface names of the application states? - Yes and it should make it possible to query the available states & transitions. We should also make it possible for an admin of application (deployed or being deployed onto the platform) to see and explictly effect the transition of state (in addition to any automatic transition by the platform). E.g. go from Deployed to Instatiated or Suspended to instatiated. I mean I should be able to Start & Stop my applications. I think this is an importanmt aspect of managing an application. (Q2) Should CAMP define a set of normative states & their names - Yes. The states and transitions may or match all platforms but, we should strive to account for a majority of (popular platforms). Extensibility could account for ones that do not match. (Q3): Should providers be able to automatic state transitions? - Yes and where it makes sense. May be we should permit param! eters in PDP that explictly aks that the app not go into runninbg (instatiated) unless requested by the user. The platform should return an error if it cannot handle and let the user decide? (Q4) - Should allow extensions to defined lifectcle - Yes but extensions should not conflict with or change semantics of what CAMP defined.
[11:27] Adrian Otto (Rackspace) morphed into Adrian Otto (Rackspace) [scribe]
[11:28] Adrian Otto (Rackspace) [scribe]: Martin: Discussion about relating the lifecycle to the resource model.
[11:30] Adrian Otto (Rackspace) [scribe]: Anish: Protocol may be designed to allow various state transitions. Protocol can provide hints to the client about what the expected next action(s) are for this resource.
[11:36] Adrian Otto (Rackspace) [scribe]: Jeff: Suggests we start with a resource model, and design the protocol in accordance with that. We may define higher level actions that are described by the combination of other (lower level) actions.
[11:37] Adrian Otto (Rackspace) [scribe]: Mark: Explains that the protocol/API should enumerate all possible completion states.
[11:43] Mark Carlson (Oracle): Actually Mark is saying that "other stuff can happen" before and in between our defined, standardized states.
[11:44] Mark Carlson (Oracle): SO mandating that an operation immediately transition to another defined state means the vendor cannot do any intermediate states
[11:48] Adrian Otto (Rackspace) [scribe]: Discussion about what may be allowed in state transitions
[11:59] Adrian Otto (Rackspace) [scribe]: Q1: Jeff moves to create an issue: Should CAMP surface the names of the application states?
[12:00] Adrian Otto (Rackspace) [scribe]: create+open an issue
[12:00] Adrian Otto (Rackspace) [scribe]: 2nd by Gil
[12:00] Adrian Otto (Rackspace) [scribe]: No discussion, issue is open
[12:02] Adrian Otto (Rackspace) [scribe]: Motion to resolve from Jeff: CAMP will define a normative set of application states and their names.
[12:02] Adrian Otto (Rackspace) [scribe]: 2nd by Jacques
[12:02] Adrian Otto (Rackspace) [scribe]: No discussion
[12:02] Adrian Otto (Rackspace) [scribe]: No objections
[12:03] Adrian Otto (Rackspace) [scribe]: Martin: recognize that the solution must not preclude an extensibility solution
[12:04] Adrian Otto (Rackspace) [scribe]: Martin will create+open a new issue about lifecycle extensibiity
[12:04] Adrian Otto (Rackspace) [scribe]: Motion proposed by Martin
[12:04] Adrian Otto (Rackspace) [scribe]: 2nd by Anish
[12:04] Adrian Otto (Rackspace) [scribe]: No discussion
[12:04] Adrian Otto (Rackspace) [scribe]: No objections
[12:05] Adrian Otto (Rackspace) [scribe]: Q2: Should CAMP allow the creation of multiple Assembly instances from the same Assembly Template
[12:05] Adrian Otto (Rackspace) [scribe]: DIscussion
[12:10] Adrian Otto (Rackspace) [scribe]: Gil agrees to create an issue for this question with a proposal for clarifying this
[12:10] Adrian Otto (Rackspace) [scribe]: Agreement in discussion that the answer to Q2 should be yes
[12:11] Adrian Otto (Rackspace) [scribe]: It is also related to passing parameters upon creating an assembly
[12:11] Adrian Otto (Rackspace) [scribe]: Adrian will submit an issue for that subject.
[12:11] Tom Rutt (Fujitsu): when will the testing presentation start?
[12:12] Adrian Otto (Rackspace) [scribe]: Break for lunch, 1 hour
[12:12] Adrian Otto (Rackspace) [scribe]: resume 1:15 US/Paciic
[13:19] Tom Rutt (Fujitsu): is the phon open yet
[13:19] jeffm: (Autoreply) lunch/dinner/snack -- yum, yum
[13:21] anonymous morphed into Tobias Kunze
[13:24] Mark Carlson (Oracle): Yes Tom the phone is open
[13:24] Mark Carlson (Oracle): Back from lunch now
[13:25] MartinC asked for a victim, I choose... Prasad
[13:26] MartinC asked for a victim, I choose... gilbert.pilz
[13:27] gilbert.pilz morphed into scribe
[13:27] scribe: (resuemed after lunch)
[13:28] scribe: Presentation by Jacques Durand (Fujitsu) on testing protocols
[13:28] scribe: (the testing of protocols)
[13:30] MartinC: source for some of Jacques material is at: https://wiki.oasis-open.org/tab/TestingPolicy
[13:31] scribe: (and the testing of specifications)
[13:34] MartinC: https://wiki.oasis-open.org/tab/TestabilityGuide
[13:44] Anish Karmarkar: tom?
[13:59] Tom Rutt (Fujitsu): the spec should have clear normative statements of the conformance requirements which can be referenced by the test assertions
[14:02] Tom Rutt (Fujitsu): any statement in the spec which uses rfc 2119 wording could be the normative source
[14:05] MartinC: +1 to Tom
[14:05] scribe: (discussion on the how to integrate test assertions with the spec document)
[14:08] Tom Rutt (Fujitsu): sca does list the normative requirments in a separate annex. this is nice, but should not be required all the time
[14:14] Adrian Otto (Rackspace)10: From an editor's perspective, I would like to think in terms of test assertions so the requirements in the specification are easy to test. As a developer who will implement the specification, I like the ability to see the test assertions in the context of the specification (by hyperlink would be great).
[14:14] Adrian Otto (Rackspace)10 morphed into Adrian Otto (Rackspace)
[14:16] Tom Rutt (Fujitsu): there can be requirements that are not testable by machinery. However the customer could detect that it is violated. They could assert by defect reports that the implementation does not conform
[14:28] Mark Carlson (Oracle): The high order bit here is to have a specification where the implementer has clear normative statements that result in interoperable implementations. The testability of the spec is a good goal, but should not detract from the primary purpose.
[14:36] jeffm: =q
[14:38] scribe: MOTION: M: Anish Karmarkar S: Ashok Malhotra Move to create Test Assertion document in parallel with the name specification document.
[14:39] scribe: RESOLUTION: Motion carries by unanimous consent
[14:41] scribe: (5 minute break)
[15:11] scribe: (so much for that)
[15:26] MartinC: Mondays @ noon pt
[15:26] MartinC: weds @ 9:30am
[15:26] MartinC: weds @ 10am pt
[15:30] scribe: next meeting will be Wednesday, November 14th, at 10 am Pacific
[15:31] scribe: next meeting will be Wednesday, November 14th, at 10 am Pacific
[15:32] scribe: Martin will send out a link to a Doodle poll to determine a permanent time that will be finalized at that meeting
[15:43] scribe: MOTION: M: Anish Karmarkar S: Ashok Malhotra Move to accept the submission specification and to direct the editors to apply the OASIS template and create the first working draft.
[15:44] scribe: RESOLUTION: motion accepted by unanimous consent
[15:44] scribe: ACTION ITEM: Martin Chapman to request a template from the TC admin
[15:50] Anish Karmarkar asked for a victim, I choose... Adrian Otto (Rackspace)
[15:50] Anish Karmarkar asked for a victim, I choose... Tobias Kunze
[15:50] jeffm asked for a victim, I choose... Prasad
[15:52] scribe: MOTION: appoint Adrian Otto secretary of the TC
[15:52] scribe: RESOLUTION: motion passes by unanimous consent
[15:54] scribe: Mark volunteers to be the editor of the specification document only (not the test assertions document)
[15:54] Mark Carlson (Oracle): Mark will volunteer to be specification editor
[15:54] scribe: Anish volunteers to be the editor of "all three" specifications (main spec, test assertions, test suite)
[15:55] scribe: Martin> we haven't agreed to write a test suite document
[15:55] scribe: Jacque volunteers to be an editor on the test assertion document
[15:55] scribe: Adrian volunteers for the editing team
[15:56] Mark Carlson (Oracle): Motion: To create an editing team of Mark, Anish, Jacques and Adrian
[15:57] scribe: Jacques seconds Mark's motion
[15:57] scribe: Jeff objects to the presence of two Oracle people on the editing team
[15:58] scribe: (discussion on the nature of the documents and the functions of the editing team)
[15:59] scribe: Motion: M: Jeff S: Anish table the motion
[16:00] scribe: VOTE: 6 yes, 1 abstain
[16:03] Mark Carlson (Oracle): Motion to adjourn
[16:03] scribe: ADJOURNED