Comments/corrections welcome.
Martin.
--
Martin Chapman | Standards Consultant
Mobile: +353 87 179 0627
ORACLE Ireland
Oracle is committed to developing practices and products that help protect the environment |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes of Nov 2012 F2F
Comments/corrections welcome. Martin. --
|
Meeting Minutes.
Face to Face Meeting 6 thru 8th November 2012, Oracle HQ, Redwood Shores, CA, USA
Attendance:
Name Company Role
Behrens, Michael US Department of Defense (DoD) Voting Member
Byreddy, Bhaskar Reddy Software AG, Inc. Voting Member
Carlson, Mark Oracle Voting Member
Chapman, Martin Oracle Chair
Durand, Jacques Fujitsu Limited Voting Member
Grange, Keith JumpSoft Member
Heneveld, Alex Cloudsoft Corporation Limited Voting Member
Jilk, David Standing Cloud, Inc. Voting Member
Johnston-Watt, Duncan Cloudsoft Corporation Limited Voting Member
Karmarkar, Anish Oracle Voting Member
Kunze, Tobias Red Hat Voting Member
Luster, Eugene US Department of Defense (DoD) Member
Malhotra, Ashok Oracle Voting Member
Miller, Rich Cloudsoft Corporation Limited Member
Mischkinsky, Jeff Oracle Voting Member
Moberg, Dale Axway Software Observer
Otto, Adrian Rackspace Hosting, Inc. Member
Pilz, Gilbert Oracle Voting Member
Rutt, Tom Fujitsu Limited Voting Member
Song, Zhexuan Huawei Technologies Co., Ltd. Voting Member
Tupitza, Charles JumpSoft Voting Member
Yendluri, Prasad Software AG, Inc. Voting Member
Intro:
Jeff assumes scribing duties.
Roll call: Listed above.
Meeting is quorate 17 out of 21 Voting Members.
Agenda Review;
Duncan Johnston-Watt (Cloudsoft): Are you going to send out a recap of each day?
The raw chat log will be emailed out at the end of each day for those on the phone.
Motion: Malhotra, 2nd Song - Move to adopt agenda as posted. Passed without objection.
Minutes:
Minutes 23rd Oct: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201210/msg00019.html
Motion: jeffm, 2nd anish - move to adopt draft minutes https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201210/msg00019.html as distributed
Passed w/o
Action Items:
ACTION-20121023-0: Chet to set up JIRA for the CAMP TC. DONE
ACTION-20121023-1: Martin to set up a poll to determine regular call times. DONE
Issues Processing:
Martin goes over presentation on proposed issues resolution process: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47250/CAMP%20TC%20Proposed%20Issues%20Process%20v6.ppt
mark: wants to add a state to issues which say whether or not there is a resolution
Discussion about whether or not to do that — decision is not to change that part of the process
possible standing rules:
All transitions except re-opening an issue require a (regular) majority vote
re-opening requires a 2/3's majority
Mark Carlson (Oracle): Since it is difficult to add states in Jira, Mark would instead like to see proposals (even at a high level) in order to move from the "New" state to the "Open" state.
upon a successful transition vote, the chair will update all state transitions in jira with the exception of Resolved->Applied which the editors will do
note: the transition from Resolved->Applied also does not require a vote — i.e. its purely done by the editors
Motion: m:anish s:mark The CAMP TC adopts the following as standing rules (1-4):
(1) Adopt the lifecycle diagram presented by martin.
(2) Chair is responsible for applying all state transitions except resolved->applied, which will be handled by the editors
(3) All transitions except resolved->applied and reopen require majority approval.
(4) Reopening an issue requires 2/3rd majority.
Passed w/o
Overview of CAMP 1.0
Anish presented an overview of CAMP 1.0 as contributed by several members.
Presentation at: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201211/msg00041.html
General discussion and q&a session took place.
Tobias Kunze take over scribe duties.
Demo:
Gil presented a demo of the CAMP spec, though not complete and not 100% spec compliant.
Adrian asked whether we should prohibit deletion of assembly templates while assemblies instantiated from them are running. Discussion ensued.
Discussion: what does "portability" mean? Does it include application portability or are we just talking about portability of the management api?
Discussion ensues
w.r.t plaform componnets, Tobias points out that there is a parallel discussion within the TOSCA TC, where it has been decided to move such issues (i.e. what PlatformComponents to d fine vs. how to define them) into a "Best Practices" section and concentrate on the "how".
Dave Jilk: To summarize my comment: The spec should provide enough detail to enable vendors to assist portability regarding platform components and parameters; but not to get into the actual details of platform components or even their classification.
Michael Behrens: Simple is good. Beyond specific attributes for portability, etc.... perhaps by using something along the lines of a platform service MIME type, we could have a simple way to let ADE's express a way to request services (database, messaging, web, etc).
gilbert.pilz: Between the extremes of "too simple" and "too complicated" - "too simple" is the safer option, if you want the spec to gain adoption
Adrian Otto (Rackspace): my comment was that interoperability is something that a specification alone probably does not solve. It will need more, including registries of common solutions, open source software for reference implementations, or other implements. We should try to focus CAMP on the "just enough" we need in the spec, that could be s trengthened by a surrounding ecosystem to further the interoperability goals.
General agreement that "humble" and "just enough" were good goals.
New Issues:
Anish had copied the remaining issues for CAMP 1.0 devlopment over into JIRA, and marked them as new as per out issues process.
There is a discussion on whether to accept issues during the review or to wait after we review with more time
https://tools.oasis-open.org/issues/browse/CAMP-1
Motion: Gil moves to accept and open CAMP-1, seconded by Jeff
Discussion of motion.
Adrian points out that having these discussions today has intrinsic educational value independent of whether CAMP-1 has merit
metadata is mentioned on line 356 of the submission spec and lines 474, 488, and 519, 715, 762, etc. so, yes, our spec does talk about metadata
Jeff Mischkinsky: why does it matter whehter or not metadata is mentioned?
gilbert.pilz: (MarkC asserted that "nowhere in our spec do we talk about metadata")
Jeff Mischkinsky: right - and i don't understand how it is relevant
gilbert.pilz: because Anish's issue mentions metadata
Jeff Mischkinsky: this just a general description of an rather generic issue - if we are going to parse every issue description in this kind of minute detail — lets just shoot ourselves now
Mark Carlson (Oracle): I think Anish made a good argument that we need something "new" and a new term for it
Mark Carlson (Oracle): we can decide later whether it is called metadata or something else
Discussion has been terminated in fairly civil manner
Motion passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-10
Motion: Ahsok moves to open CAMP-10, Anish seconds
we need to upload the OpenStack extensibility presentation
Passed w/o
ACTION-20121106-0: Adrian to upload the openstack presentation (or email a link) in relation to CAMP-10
http://tools.oasis-open.org/issues/browse/CAMP-14
How are supported formats discovered
Motion: Anish moves to open, Dave seconds.
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-2:
What is the purpose of the "Definition" attribute?
Motion: Anish moves to open, Gil seconds, no discussion, no objection
passed w/o
Motion: Tobias moves to accept proposal in CAMP-2, Anish seconds
the spec says "This attribute contains the definition of the AssemblyTemplate represented in some format, such as XML, that contains the metadata necessary for the platform to deploy the Application."
Jacques opposes the motion
Discussion regarding possibly tabling the motion so newcomers have more time
The issue refers to Section '7'. In the OASIS submission version is in section '5'. The issue CMAP-2 decription should be updated accordingly
Motion fails due to lack of support
http://tools.oasis-open.org/issues/browse/CAMP-3:
How do application packages get uploaded into the cloud?
Motion: Anish moves to open, Tobias seconds
some discussion around wrong section references
Passed w/o motion carries
http://tools.oasis-open.org/issues/browse/CAMP-4
Need a formal specification of the PDP format
Motion: m:Tobias s:Ashok to open Camp-4
Passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-5
Suggest to simplify {Application,Platform} Component {Requiremnets,Capability}
Motion: m:Tobias s:Prasad to open Camp-5
Passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-6
Are application components independent of assemblies?
Motion: m:Anish s:Tobias to open camp-6
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-7
The type "Snapshot" is not defined
Motion: m:Anish s:Ashok open camp-7
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-8
Support a hierarchical model of platform components at runtime (or typed relationships between such components)
http://tools.oasis-open.org/issues/browse/CAMP-9
Support sensors and effectors on components via API
Will hold off on issue until Cloudsoft is in attendance.
http://tools.oasis-open.org/issues/browse/CAMP-11
Expression of Scaling Policy
Adrian Otto (Rackspace)1: Service providers implementing a CAMP platform would like to be able to offer auto-scale as a feature. Provide some facilities that allow a policy to be expressed within the platform, perhaps when an application assembly is instantiated, that will describe which policy should be used for managing that assembly.
... Furthermore, we would like to be able to allow CAMP to manage an auto-scale policy so that those service providers can offer the service in a way that allows that policy to be portable between CAMP platforms.
Motion: m:Anish s:David open camp-11
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-12
Clarify Scope of Application Components
Motion m:Gil s:Ashok open camp-12
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-13
Media Type "type" argument not compatible with Python request parsers
Motion: m:Anish s:Tobias to open camp-13
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-15
Use message-id and profile rather than uri and namespace
Motion: m:Tobias s:Anish to open camp-15
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-16
Introduce non-Java use cases and/or examples
Motion: m:Jeff s:Anish to open camp-16
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-17
Figures should be redrawn
Motion m:Gil s:Tobias open CAMP-17
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-18
API Authentication/Authorization not clear and should leave scope for other auth mechanisms
Motion: m:Ashok s:Tobias open camp-18
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-19
SSL Cipher Suite
Motion m:Ashok s:Charles to open camp-19
Tobias would like to see SSL/TLS outside the spec entirely.
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-20
Failure to deploy when dependencies are not resolved is not workable
Motion: m:Gil s:Tobias open camp-20
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-21
Clarify that App Developers/Admins cannot assume what the Assembly Template tree looks like until post-deploy
Motion m:Gil s:Anish open camp-21
Tobias is against this issueas stands.
Issue titrle rephrased to "clarify whether ... can assume..."
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-22
Requirement resources are problematic
Motion: m:Charles s:David to open camp-22
Lots of discussions
passed 8 yes 2 no.
http://tools.oasis-open.org/issues/browse/CAMP-23
Merge Capability and Template resources
Heated discussion around requirements and capabilities in general, mutual non-understanding among the TC
Motion: m:Gil s:Jeff open camp-23
passed 9 yes 1 no
http://tools.oasis-open.org/issues/browse/CAMP-25
Refine link structure
Motion: m:Tobias s:Charles open camp-25
Anish to update the issue with references/proposal from Drupal
passed w/o
http://tools.oasis-open.org/issues/browse/CAMP-24
Assembly Template and Assembly trees are not analogous
Motion m:Gil s:Tobias open camp-24
passed w/o
End Day one
Start day Two
Prasad assumes scribing duties.
Topic: Discussion of Major Arch. issues
Will change order of discussion slightly to relfect times people are present and interest levels.
Arch issue 1. Platform Deployment Package
Gil driving the discussion based on his write up: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201211/msg00039.html
discussing resource models & dependencies
two models for the contents of the PDP
Mark: missing arrows in the assembly model (in CAMP specific artifacts) to link CAMP artifacts with platform specific artifacts. Need to be able to corelate them
Anish: We have not defined a format for the PDP. Need to spec a format that all must support
.. slightly different from the issue being discussed but need to address this
PDP may not contain runtime attributes. You may need to ask some of these to be created by the platform and not serilaize all nodes and props from the assembly
Tobias: Against the second version in Gil's proposal.
.......Adamant #1 is right way to model PDP
Ashok: Wanted to say the same thing as Tobias. Also, in the 2nd it is very abstract notation Do not know how to deal with it
Gil: We need to define that
Tobias: We need to describe what we have and what we need. This is the Application Components and our requirements. It may include Platform
..... Components IFF we (the application authors/owners) happen to know what PC exist on a platform.
Martin: People have different use cases in mind when they model these
..e.g. uploading a deployable app onto a platform with code artifact and deployment plan vs moving app from platfrom a to platform b
... will the PDP form be the same or different to address these two different usecases?
Adrian: Agree with Anish that PDP is different from just serialized resources . E.g. the files in there are not URLs that PDP needs
Mark : Every resource has a uri attribute, so serializing does allow you to hook the links in the resources to other serialized resources even if the export of
.... a PDP does not change these in the serialization.
There needs to be a way to express parameters in the PDP. E.g. when file is deployed there might be customization and such properties associated with it
Mark: We could also specify how to substitute unique identifiers for URIs in the serialization.
Mark : We also have this problem when exporting from an ADE to a CAMP cloud.
Gil: Notion of familiar & unfamiliar platforms for developers of app / PDPs
Adrian : Can not express everything in API calls
Prasad: Suggest we distinguish clearly in our use of the term CAMP as in the standard CAMP vs CAMP as in a specific PaaS.
....It is confusing to put this in context subjectively
Tobias: Discussion appears to be about simplicity (desired) and not so much about whether or not accompany a
....PDP with meta information (which both scenarios envision)
Mark: May be we should visit this issue when we have other pertinent issues resolved as Gil's proposal assumes certain things
Anish: PDP is a PPDP protable PDP??
We should not insert any platform specific properties in PDP
Mark: How a provider does things internally can differ radically from what they expose through the CAMP interface. The whole idea of a standard is have
... something that can be mapped, not one that punts on any management at all.
... There are resources in CAMP that are under the complete control of the application admin and ones that are under the complete
... control of the provider.
.... Have resources that are partially under control/instrumented-by both will lead to many of the issues we have open.
Gil: If you have a specific platfrom related properties, you must include something like a target platfrom URI in the PDP. In that case it is not a PPDP
Adrian: We do not have concept of dictionary or registry - we do not enable mapping resources, capabilities and requirements from platfrom to platform
When you move from platform A to B , you may need to use the API to query the PDP, fiddle with it and create a new PDP specific to platfrom B
Tobias: explained that we need to be able to express e.g. that our applications consists of parts {A, B} and that e.g. A needs {p, q} and B {r, s, t}.
.... Now if platform X has magic middleware that provides {p, ..., t} in one single piece, it is free to run the app that way, but it still needs to
... expose A and B as different components. What this should illustrate is (1) that CAMP doesn't require any commitment to specific granularity;
...it's just that if the owner says she has {A, B}, they need to be visibile as such. This should also
... illustrate that (2) the meta information required could be as simple as p = "php", q = "java7" etc.
Adrian: In my last comment I mentioned that the spec has no dictionary, and there is no standalone registry of resources types. In the absence of these
...things, it may be difficult to move an application (assembly) from one PaaS to another. Portability will require either some common
... understanding of standard (specific) resource types, OR it requires a way for the individual (or tool) moving the application to make a
... mapping (relation) between what the application needs and what the target PaaS provides. Ideally this
... should be possible without significantly reconstructing the [P]PDP file. Ideally, some common types are known, or a mapping can me
... offered at the time the [P]PDP is created so that it will be deployable on the target PaaS.
Martin: summarizes the discussion. Close the discussion on the issue for the time (F2f). To be revisited later
Arch Issue 6: Canonical Platform Services
Mark Carlson presents on the topic: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201211/msg00047.html
Jacques: Different ways to implement components on a platform. Does the component definition include how it is implemented
Jacques: This Capability model sems very simplistic
.... you may have more constraints like this property cannot have this value with this other property etc.
Martin - we need ways to describe what you need at deployement at runt-time etc.
Anish: A capability is a resource on the platform. When I do a GET on the resource, how do I know is a capability?
Mark: If we have MIME type for it, we will be able to identify based on that
Gil: Requirements & capabilities must match 1 to 1
Anish: I found a better answer to my question. A way to know a resource is a capability w/o knowing the mIME type.
... When I traverse the platform graph, you get a set of URIs one of them is for an arra of capabilities.
... So, you know you are traversing a capability when you walk down that array chain
Ashok: Why not generalize this. Capabilty & requirements are an object type ...
Jeff: I am not sure if that is that simple..
If the vocabulary is defined outside the standard, how can the standard talk about it?
Anish: If want to standardize this, I do not want it to be part of the core spec
Martin: Even a container?
Anish / Martin: Yes. Container, environment or whatever
Anish: allow people to impliment and comply with CAMP even if they not agree pr align with capabilities and requirements
Do not want to link conformance to CAMP to conformance to any platform component
Adrian: Spec could be more specific and simpler. Too much freedom leads to complexity
If we leave it all empty and not say anything also not good. Too much or too little does not lead to interoperability. Choose a middle groud.
Dave: We do not want to build an API wrapper. Need to have some semantic value
Tobias: Arguing strongly in favor of not dealing with functional interfaces and specific types and interoperability. Defining types might be relegated to a .... "best practices" document and held non-normative. I'd also like to point out that this is the approach that the TOSCA TC has chosen to follow.
... As a result, we'd be stepping on that TC's toes if we'd decide to define our own types
gilbert.pilz: does "Node.JS" == "node.js" ?
Mark will supply a concrete proposal associated with the Jira issue proposing a "Runtime Environment" Platform COmponent
Zhexuan assumes scribing duties.
Arch Issue 2: MIME types
Adrian lead a discussion and outlined options documented in https://tools.oasis-open.org/issues/browse/CAMP-13
prasad: "type" : "Assembly" seems generic and applicable to other domians. Somehow CAMP context needs to be reflected in here
Mark: drawback: need to look at message body to identify type
... if we have subtype, we need to parse body no matter what
Anish: we are using #1 now, #3 does not give benefits, #4 need too many visits to IANA, like #2, value of type can be more complicated than string, and no need to register.
Martin: we can define "type" in our spec, support #2
Anish: what is the advantage to put the information in header?
MarkC: can use header to filter response
Tobias: header should define format only
Martin: you need to parse to check validity anyway, should not be an issue
MarkC: can use header to pre-parsing and accelerate the handling process
Time to vote
A straw poll indicated string support for option 2
Motion: Anish Karmarkar: s: Ashok Use option 2 (with an addition of moving the 'type' parameter into the json body) in Adrian's 1st comment on issue 13 as the direction for .... resolution of issue 13 and direct adrian to write up a full resolution.
Adrian: take into consideration: #2 has a side effect for version negotiation
passed w/o
ccissue-13 is assigned to Adrian, need further discussion on how to define type, MarkC, Anish are willing to help
Arch Issue 3: Extensibility
Anish introduced the ideas, details in his write-up: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201211/msg00032.html
Martin: we are defining rules how to add new resources, but not new resources
MarkC: we do not have to say anything
Anish: explained potential extensibility points
important: how to discovery/query, indicate, and manage extensions
Mark: We need to back off and understand what the goal is here. I think it would be something like "allow basic interoperability, but allow for extensions .... that don't break that"
JeffM: difference between discovery and indication?
Anish: indication means a part is an extension and ready for discovery
JeffM: discover/query/indicate are the same thing, TC must do that
Anish: like to have an informal poll for opinions
Adrian: without extensibility, we are stuck with whatever we generate. We should allow community to extend as they like. OpenStack vs. CloudStack ... as an example
Mark: I would like us to focus on additional management functionality, and how to add that, both for future versions of CAMP, as well as for vendor ...specific needs.
Adrian: query is necessary if no registry exists
MarkC: focus on extensions where the spec will become incompatible
Jacques: setting up base rules how to extend
Gil: the group seems to agree with the proposal
ark Carlson (Oracle): X- has been deprecated
Anish: one example: use x- for extension
Mark Carlson (Oracle): com.orgname.<AttributeName>
Mark Carlson (Oracle): <AttributeName> can be further broken down and managed by orgname
related CAMP issues: 1, 10, 14
CAMP issue 10 -> assigned to Anish, Adrian will contribute.
Arch Issue 5: Simpler resource model
Gil presents the points he made in the document: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201211/msg00040.html
Martin: agree with gil, no need for application components
Tobias: application components may have different requirements
Michael Behrens: UML diagram might be helpful to show relationships.
MartinC: Michal I agree but there are a lot of uml doubters around here
Ashok: gave an example of application components
MarkC: spec says that we can just instantiate one application component for various applications, assembly components do not have this capability
Gil: make the things complicated
Mark: Here is the text in the current spec:
"An application is composed of a set of Application Components that depend on one or more Platform Components. Examples of Application Components include Ruby gems, Java libraries, and PHP modules. Application Components may also include non-code artifacts such as datasets and collections of identity information.
Application Components may also interact with other Application Components. Thus, an Application Component has two different sets of dependencies. It depends on the Components provided by the platform, and depends on services provided by other Application Components"
Anish: application components are useless as for now, no semantics linked with application components
Adrian: use case: a sql database for different version of applications, how to define this sql component
Martin: explain the relationship between assembly and application components
Adrian: is it possible to have components with different management in the same assembly
Tobias: not for now, but do have use cases for that
Michael Behrens: Has links (URLs) been discussed for components of an assembly?
Charlie: questions: do we allow application components running independently
Anish: should we allow assembly to have dependence on a platform component from different assembly? issue to figure out
Gil: application component represents management of a module, detailed hidden in CAMP. In this model, it is not an atomic thing.
Martin: application has no meaning as an independent thing
MarkC: this is a bug in spec, we should clearly define application components and their behavior
Only need it when we have different life cycle
Tobias: messy, assembly is just a group of things, always use assembly even with one component
....lifecycle points to assembly only
Anish: this is not about management of things, should not be in spec
Ashok: we need application component, may have different lifecycle
JeffM: this discussion is meaningless.
jeffm: not that the discussion is meaningless, but that constructing arguments based upon the parsing of the exact words in the DRAFT spec is somewhere between not useful ....and meaningless. Instead the argument should be what do we want the spec to do and the model to be
Martin: three solutions, 1) Tobias' option, assembly is just a collection of things; 2) assembly points to components but not include; 3) no .... difference between components and assembly;
for 2) lifecycle is on assembly; for 3) individual component has its own lifecycle
Tobias: assembly should not point to platform components
MarkC: in this setting, application component is always needed
Tobias used a PHP example to explain the concept of assembly, components, etc.
Platform components may have different lifecycle
Gil: no decision, but a rough consensus on Q4
Martin: nothing from this discussion will lead to spec change, need more concrete issues that trigger spec changes
Tobias: looks like an orchestration issue
Martin: raise an issue to investigate it, Adrian will open it
End of Day 2
Day 3
Dave Jilk assume scrive duties
slight Agenda re-jig. Alex to present his two issues that we passed since he was not here on day one.
New Issues (part 2):
https://tools.oasis-open.org/issues/browse/CAMP-8
Hierarchical model of platform components
Dave: seems like it's too much detail and would never result in portability
Alex: more about reporting on the details
Alex: want to understand shape of what the platform is running
Adrian: nothing stopping platforms from using extensibility model to expose this info
Adrian: has nothing to do with portability of app
Alex: *does* have to do with portability and management - if I can't drill down I will struggle to manage
Alex: ok to go with extensibility
Alex: Update issue with discussion and close - aim for 2.0
Adrian: be sure to get the extensibility model right to be able to handle this
Motion: Alex: motion to close issue camp-8, Anish seconded.
passed w/o
https://tools.oasis-open.org/issues/browse/CAMP-8
Support sensors and effectors on components via API)
Alex: go beyond simple attributes to full JMX operations
Martin: how does it fit with REST resource model?
Adrian: similar to an open case (camp-11) - this is one proposal how to implement.
Alex: don't mean JMX implementation - more the idea.
Motion: m: Alex s: Ashok to open Camp-9 for purpose of developing concrete proposal.
Adrian: suggest web hooks
Mark: App would need to expose information through CAMP - this is tricky
Adrian: don't need to define this, platform can support
Mark: slippery slope - outside scope of charter
Alex: +1 out of band, implementation can support without CAMP specifying how (it just ends up exposed as attributes)
MartinC: i think this is about the spec defining some enabling mechanisms
Ashok: can just be the application's business
Alex: application can always expose management on its own channel, would be nice to expose through CAMP
Tobias: sympathetic to the cause - really not much about monitoring in current spec
Tobias: let resources expose whatever they want, look at extending to app components
Martin: worth exploring enabling mechanisms as to how to achieve this.
Tobias: 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
passed w/o
Arch Issue 4: Platform Specific Lifecycle Management
Gil presenting lifecycle management document: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201210/msg00028.html
Martin: Do not assume that transitions are camp things
Martin: lots of assumptions in spec, agree we need to clarify
Adrian: Mark: describing the need for a distinction between required and optional states.
Adrian: 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.
Jacques: yes to extensibility of the set of "transitions" (but an impl should not alter the semantics of CAMP-defined ones - possibly "add" semantics though)
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.
Adrian assumes scribe duites.
Martin: Discussion about relating the lifecycle to the resource model.
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.
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.
Mark: Explains that the protocol/API should enumerate all possible completion states.
Mark: Actually Mark is saying that "other stuff can happen" before and in between our defined, standardized states.
.... SO mandating that an operation immediately transition to another defined state means the vendor cannot do any intermediate states
Discussion about what may be allowed in state transitions
On Q1:
Motion: m: Jeff s: Gil moves to create and open an issue: Should CAMP surface the names of the application states?
passed w/o
Motion: m: Jeff s: Jacques to resolve in principle that CAMP will define a normative set of application states and their names.
passed w/o
Martin: recognize that the solution must not preclude an extensibility solution
Motion: m: Martin s: Anish create+open a new issue about lifecycle extensibiity
Passed w/o
Q2: Should CAMP allow the creation of multiple Assembly instances from the same Assembly Template
DIscussion
Gil agrees to create an issue for this question with a proposal for clarifying this
Agreement in discussion that the answer to Q2 should be yes
It is also related to passing parameters upon creating an assembly
Adrian will submit an issue for that subject.
Gil assumes scribe duties.
Topic: Spec testing
Presentation by Jacques Durand (Fujitsu) on testing protocols: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201211/msg00065.html
MartinC: source for some of Jacques material is at: https://wiki.oasis-open.org/tab/TestingPolicy
and https://wiki.oasis-open.org/tab/TestabilityGuide
Tom Rutt (Fujitsu): the spec should have clear normative statements of the conformance requirements which can be referenced by the test assertions
Tom Rutt (Fujitsu): any statement in the spec which uses rfc 2119 wording could be the normative source
discussion on the how to integrate test assertions with the spec document
Tom Rutt (Fujitsu): sca does list the normative requirments in a separate annex. this is nice, but should not be required all the time
Adrian: 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).
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
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.
Motion: M: Anish Karmarkar S: Ashok Malhotra Move to create Test Assertion document in parallel with the main specification document.
Passed w/o
[exact details of this tdb once we decide on editors etc]
Note there was no decision yet on test cases/test suite, just that we will at least write test assertions hand in hand with the specification.
Topic: Administration
Regular meeting times: The doodle poll launched after the innauguaral meeting (various times on a tuesday) failed to reach a conclusion i.e. no time suited all the key people of the TC.
Martin will set up a doodle poll with the following options and a decision will be mode on the next call:
Mondays @ noon pt, weds @ 9:30am, weds @ 10am pt
Next meeting will be Wednesday, November 14th, at 10 am Pacific
Discussion on next f2f. Will try for a three month scedule at first - so aiming for end jan early feb
Adrian will look into whether he can host. Jacques and Zhexuan may also be able to host.
First working draft
One contribution posted: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47277/CAMP_v1.0.doc
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.
passed w/o
ACTION-20121108-0: Martin Chapman to request a specification template from the TC admin
Motion: m: Jeff, s: Anish appoint Adrian Otto secretary of the TC
passed w/o
MarkC will volunteer to be specification editor
Anish volunteers to be the editor of "all three" specifications (main spec, test assertions, test suite)
Martin: we haven't agreed to write a test suite document, so only two documents at present.
Jacque volunteers to be an editor on the test assertion document
Adrian volunteers for the editing team
Martin: Chair's intent is to no micro manage - have one team for all docs and let the team manage who works on what.
Motion: m: Mark: s: Jecques: To create an editing team of Mark, Anish, Jacques and Adrian
Jeff objects to the presence of two Oracle people on the editing team
(discussion on the nature of the documents and the functions of the editing team)
Motion: M: Jeff S: Anish - table the motion
scribe: VOTE: 6 yes, 1 abstain
passed - motion is tabled.
AOB:
Chair thanks everyone for a very prodcutive first F2F.
Meeting Adjourned
------------------------
Summary of New and Outstanding Action Items:
ACTION-20121106-0: Adrian to upload the openstack presentation (or email a link) in relation to CAMP-10
ACTION-20121108-0: Martin Chapman to request a specification template from the TC admin
------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]