[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes April 2013 Face to Face
Meeting Minutes 3rd CAMP TC Face to Face,
3rd thru 5th April 2013, Santa Clara, CA, USA
Attendees:
US Department of Defense (DoD) Michael Behrens Member
Software AG, Inc. Bhaskar Reddy Byreddy Voting Member
Oracle Mark Carlson Voting Member
Oracle Martin Chapman Chair
Fujitsu Limited Jacques Durand Voting Member
Cloud4SOA Panagiotis Gouvas Member
Cloudsoft Corporation Limited Alex Heneveld Voting Member
Cloudsoft Corporation Limited Duncan Johnston-Watt Voting Member
Oracle Anish Karmarkar Voting Member
Oracle Ashok Malhotra Voting Member
Rackspace Hosting, Inc. Adrian Otto Secretary
Oracle Gilbert Pilz Voting Member
Fujitsu Limited Tom Rutt Voting Member
JumpSoft Charles Tupitza Voting Member
Oracle Jeffrey West Member
Software AG, Inc. Prasad Yendluri Voting Member
Day One - 3rd April.
Intro:
Anish assumes scribe duties
Topic: roll call
13 of 16 VM present (81%), meeting is quorate.
Topic: agenda bashing
agenda for today: PDP and if we have time lifecycle discussion
thursday agenda: scaling policy, issue 30, 17, TA discussion
thrusday agenda+: liaisons (Cloud4SOA, ODCA)
friday agenda: review schedule, next f2f planning, implementation;interop plugfest planning, issue 2
friday agenda+ alignment with other specs, use cases, primer
Adrian Otto (Rackspace) : If you are interested in the ODCA documentation, reference: http://www.opendatacenteralliance.org/docs/ODCA_PAAS_Interop_UM_Rev1.0.pdf
alignment with other specs agenda topic to be discussed friday morning (alex has to leave early)
Agenda approved
Topic: meeting minutes approval
27th march 2013 minutes https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201303/msg00097.html
motion m:anish s:gil to approved minutes of 2013-03-27 call located at https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201303/msg00097.html
approved w/o
Topic: new issues
Issue 57 https://tools.oasis-open.org/issues/browse/CAMP-57
Tom explains his issue
adrian +1s the issue. was an oversight
Adrian has uploaded a proposal to make everything consistent
Tom: the proposal has a bug
motion: m:tom s:adrian to open issue 57
motion approved w/o
issue 57 is open
Topic: issue 57 proposal
Adrian Otto (Rackspace) : I move to resolve CAMP-57 with camp-spec-v1.1-wn08-issue57.doc, with one change: Section 5.5.1 adjusts Type to Link[] and
"This attribute is an array of Links to PlatformEndpoint Resources..."
Ashok Malhotra (Oracle): There is a typo in the title
+ title of section needs to say platformEndpointLinks
Michael Behrens: Good catch - paltform -> platform
Adrian Otto (Rackspace) : motion so modified
motion m:adiran s:tom to resolve CAMP-57 with camp-spec-v1.1-wn08-issue57.doc, with one change: Section 5.5.1 adjusts Type to Link[] and "This attribute is an array of Links to PlatformEndpoint Resources..." and modify the title to align with the name of the attribute
motion approved w/o
Topic: PDP discussion (issue 4)
Gil has a presentation on use cases: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48711/PDP-Use-Cases-2013-04-01.doc
gil: use case document contains usecases that we should support as well as usecases that we shouldn't.
Michael Behrens: Good discussion wrt vocabulary syntax (name/version), aliases?. Also, wrt exceptions, what would be the rest return status of auto-wiring is partially successful
(201 Created)?
Gil: 201 Created - Location header contains URL of AssemblyTemplate
Gil: GET AssemblyTemplate and look at the "lifecycleState" attribute
Gil: also keep an eye on "representationSkew"
Gil: when representationSkew goes to "NONE" you can count on the value of "lifecycleState"
Mark Carlson (Oracle): We have an example Requirement in the spec today (D.3): {
"uri": URI,
"name": String,
"type": "databaseRequirement",
"description": String,
"created": Timestamp,
"representationSkew": String, ?
"tags": [
String, +
], ?
"clusterTypes": [
String, +
],
"numberNodesRange": String,
"coreRange": String,
"memSizeRange": String,
"diskSizeRange": String,
"backupEnabled": Boolean,
"synchronousCopyEnabled": Boolean,
"partitionEnabled": Boolean,
"compressionEnabled": Boolean,
"retentionEnabled": Boolean,
"tunings": [
String, +
],
"cachingEnabled": Boolean
}
Alex Heneveld (Cloudsoft): @Mark +1 -- so i in my app component i supply such a requirement, with cachingEnabled. the platform then sorts that out against capabilities. (the fact it is a DatabaseTemplate is irrelevant.)
discussion on Gil's usecase document (detailed discussion not captured)
Mark Carlson (Oracle): Keep in mind that this is a *management* interface.
.....How the app is represented in the management interface can be completely decoupled from the underlying granularity of the implementation.
Gil: I disagree
Gil: a platform implementation cannot support a granularity of representation any finer than that of its underlying management model
Ashok Malhotra (Oracle): Maybe we should restrict PDPs to the case where they are created knowing what's available on the platform.
Gil: that means you can't take extract a PDP from one platform and attempt to register it on another platform
Ashok Malhotra (Oracle): yes
Gil: that's not good
Gil: we should at least give devs a fighting chance
MartinC : that would fail one of the propositions of camp
Ashok Malhotra (Oracle): But it will work -- no requirement/capability matching needed
Gil: granted the behavior may 99% fall back to use case 1
MartinC : being able to port an app from one provider to another is a key use case
Gil: but at least it gives you a start
Ashok Malhotra (Oracle): I understand the usecase. Just worried about whether we can support it
Gil: the fallback to use case 1 makes this possible
Mark Carlson (Oracle): One of the most basic questions someone is going ask of a new cloud is "will this cloud work for me"?
.....The answer to that question is the coupling between what the application needs and what the platform actually provides.
..... I know that this is a hard problem, but it seems pretty fundamental to what we are working on here...
Gil: but the componentization of the PDP has nothing to do with that question
Gil: whether the platform represents your application as being 3 ACTs or 1 ACT, you still need to resolve the dependencies of those components against the appropriate platform services
Mark Carlson (Oracle): The PDP import is the means by which you find out the answer to the question.
Gil: . . . and that is in line with how things work today - you can't really tell whether Engine Yard, for example, can run your app until you install it and try
Ashok Malhotra (Oracle): Don't you want to ask the question before you create a PDP? That would make life easy!
Gil: you may want to ask that question before you create the PDP, but I wouldn't count on the answer!
Gil: it may "look" like the platform supplies you everything you need, but there may be unforeseen complications
Mark Carlson (Oracle): On a blank platform where you just created the account, what you see through CAMP today is what the platform offers.
..... You have to answer the question yourself based on your own knowledge of the application's needs.
Gil: at best you can receive strong negative evidence
Ashok Malhotra (Oracle): Can I query what Platform Components it offers?
Gil: yes
Mark Carlson (Oracle): If you take a (previously created) PDP that already encapsulates what the application needs and import it to that blank platform,
..... then if the AT goes to "RUNNABLE" - the answer to the question is YES. Otherwise the answer is still "maybe"...
Ashok Malhotra (Oracle): Then I can tailor my PDP appropriately
Ashok Malhotra (Oracle): The "maybe" gives me agida!
Mark Carlson (Oracle): @ashok - my point is that I should have a PDP that "purely" just represents what my application needs without having the answer the questiona ahead of time .....for each platform
Gil: Ashok - that "maybe" is the state of the industry
Gil: nothing a humble little spec can do is going to magically change that
[lunch break change of scribes]
Meeting called to order. Adrian assumes scribe duties.
Continued discussion of the PDP
Alex raised question about AssemblyTemplates. If an AssemblyTemplate is resolved, is it possible to find the original unresolved version of that template?
Alex Heneveld (Cloudsoft): http://wiki.apache.org/couchdb/HTTP_Document_API#COPY
Alex Heneveld (Cloudsoft): "HTTP COPY"
Answer to Alex's question: no, there is no specified way of referencing the original copy of the AT resource, although an extension could be implemented to archive it at each change point.
Discussion of using an immutable model so that resources are always read-only. Our use of HTTP PATCH prohibits this model because a resource must be changed in place. It is possible however to make an extension to auto-archive the original resource, and make a reference back to it.
Alex Heneveld (Cloudsoft): "A CAMP implementation MAY use ETags (normative ref: http://tools.ietf.org/html/rfc2616) ...
Alex Heneveld (Cloudsoft): "It MAY allow lookup of historical ETag versions of resources, and it MAY specify an ETag for references to a resource. For example an Assembly created from an AssemblyTemplate v1 ..."
Alex Heneveld (Cloudsoft): W/campVersion:6
Alex Heneveld (Cloudsoft): A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
.... two entities of a resource only if the entities are equivalent and
....could be substituted for each other with no significant change in
.... semantics.
Gil revisits PDP Use cases.
we agree that use case #1 we must support.
we agree on 1.1 as well
Alex Heneveld (Cloudsoft): I am working on "user stories", some corresponding to these use cases, in a Google Doc.
Alex Heneveld (Cloudsoft): https://docs.google.com/a/cloudsoftcorp.com/document/d/1hHCHC24a6HLLqCw-h3u6spH-_o4di_oyOw5UvWvSsY0/edit
Martin makes a point that Extensions may hinder portability
Mark Carlson (Oracle): The DP part of the PDP needs to preserve the configuration attributes (contained in the templates) across platforms, not just the binaries.
MartinC : or a subset of the attributes
Jacques (Fujitsu)4: ... the DP subset also needs to preserve the "Requirements" part
MartinC : right - the requirements reify as links
Mark Carlson (Oracle): One part of extending the resources themselves as well as their representation in the DP, is by adding new attributes. That should be allowed in both cases, .... however overloading an existing attribute is fraught with problems.
Alex Heneveld (Cloudsoft): requirements contain attribute-value pairs, where the attributes are semantically meaningful to the platform and eventually to well known extension, but not the CAMP spec.
Alex Heneveld (Cloudsoft): the platform implementation knows how to evaluate requirements against capabilities. the process by which this happens is not in CAMP but should be clearly advertised to the user.
Alex Heneveld (Cloudsoft): if a requirement object includes an attribute that is not recognised it MUST NOT fulfill the requirement.
Mark Carlson (Oracle): @alex - that kind of makes requirement non-extensible... Could you consider that it is a requirement only for the platforms that support that attribute?
Ashok Malhotra (Oracle): If you want subtyping you can use XML
MartinC : no thanks
Ashok Malhotra (Oracle): I'm very amused ... adding inheritance into JSON !
Alex Heneveld (Cloudsoft): several proposals, for determining what is a requirement:
(1) 5.21 TypeDefinition could have optional attribute "isRequirement"
(2) 5.21 TypeDefinition could have optional attribute "parentType" (the only supported value at present is "Requirement")
(3) Naming convention. If "type" attribute begins "Requirement:XXX" it is a requirement.
Alex Heneveld (Cloudsoft): got a gist to play with at:
Alex Heneveld (Cloudsoft): https://gist.github.com/ahgittin/5311818
Alex Heneveld (Cloudsoft): (PDP samples)
Meeting is recessed.
Day 2: 4th April
Jacques assumes scribe duties.
Topic: Scaling Policy
Jeff West goes over Scaling presentation https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201304/msg00007/Scaling_Policy_Concepts_v1.ppt
Duncan: need to address more complex case. Should not settle for a too simple model
Duncan: that looks like ECA (event-condition-action) rules
JeffW: need decide what goes in the spec: triggers? actions? metrics?
MartinC - webex: response from Alex: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201304/msg00009.html
alex: what goes in the spec: on metrics side : we have attributes already.
... the important one: actions
JeffW: we can turn on/off our sensors. If attribute, it is always here, always have value.
martin: could a metric be a resource?
alex: V2 maybe. But we should have sensors.
adrian: CLoud specifics: utility-billed, so elasticity is essential - so in scope for us.
alex: alerts and conditions: too trivial. Need a more policy-like approach.
... more complex management logic needed.
jacques: need to look into event specs such as CADF (for Cloud auditing), as well as NIST Metrics . The policy input may cross PaaS / IaaS inputs.
... so we may need to reuse such efforts underway and not restricted to the Cloud application layer.
CADF: http://www.dmtf.org/standards/cadf
Alex Heneveld (Cloudsoft): jacques (talking while not scribing) says: there are good event frameworks -- CADF, NIST -- gaining traction (eg celiometer); the condition/alert idea is too simple
tom: metrics may need be a separate resource, not just attributes of CAMP resources
adrian: should not settle for hacks, let extensions set the right direction.
... how to actually implement it is the problem (not how to specify). May need extra service to handle this.
Ashok: what are the concrete changes/direction for CAMP, that are proposed here?
duncan: need remain above the fray. Migration may be a more interesting policy than scaling.
... danger is to boil the ocean with this problem. A problem for V2. Need to reduce P1 priority issues to 0 !
Alex Heneveld (Cloudsoft): two open questions as I see:
(A) do we leave metrics as attributes create a new attribute e.g. Component.sensors of type Link<Sensor>[], pointing to new resource type Sensor which to begin with has a value and operations, but more importantly is extensible so people can add history, turning on/off, tuning, etc (based on CADF, NIST, others) [this is open issue #9] ? ... and
(B) do we want to do similar for Policies or just let them be implemented as platform components (and let conventions emerge)
martin: challenge is what are the right minimum/enabling features in the spec. Not fall into a condition language trap.
alex: Q1: do we want a new resource for sensor? Q2: new resource type for Policy?
ashok: need be able to turn off values. Values of attr are not same as sensors.
alex: an attribute value is a kludge. need a gatherer anyway
duncan: notion of a control interface is important. Separate rule data.
JeffW: specify way that metrics are exposed. Later we may consider policies.
... sensors as a separate concept/resource.
tom: metrics not as simple as storing values. Users may need to control the metrics parameters.
... gathering metrics needs control parameters.
agree with meeting that overloading attribute is concern - so introducing sensor makes sense IMO
operations are less controversial?
how we bridge between the two (autonomic/ECA) is detail we can label "There exists some policy ..." and leave at that
martin: level of trust is important (how up-to-date is the value?). A minimum support is needed, control for later.
jacques: "action" part is still fuzzy - how far beyond CAMP scope?
JeffW: e.g. if request/sec goes down, need to tell someone. Seems like a management concept.
... CAMP could focus on representing the actions, not defining them.
duncan: actions are platform level. Sensors are a way to factor in external input as well.
JeffW: we interact with Platform anyway. Action that can be taken? could be templates parameterized.
... such actions templates can be exposed / standardized
... metrics also can be exposed
duncan: sensors call for effectors... sounds normal to deal w both the same way
Ashok Malhotra (Oracle): It's issues 9 and 11
chair: CAMP11 possibly out of scope for V1, but CAMP9 is in scope
MOTION: (Alex, Anish) move CAMP-9 to P1
Ashok Malhotra (Oracle): +1
+1
MOTION: no obj, passed.
Duncan: lets deal with extensions. We can keep what is between sensors & effectors unprescribed.
Anish: keep #11 alive
Alex: presents #11 about scaling policy
... moving away from a new type of Policy
Topic: Liaisons
Panagiotis presented an overview of CLOUD4Soa and some of its observations/lessons: link TBD
Michael Behrens: Cloud4SOA: good presentation. Please post brief to soaphub files when time permits.
martin: some parts of Cloud4SOA overlap strongly with CAMP functionality
Panagiotis: yes, these slides were drafted in 2010
... try to have at least 2 PaaS providers per core technology (Python, etc)
... harmonized API + adapters to specific platforms
... now working on reference implementation.
... SOA layer and Governance layer (SLA) on top of harmonized API
... "matchmaking" (autowiring) processes (also involving human)
... tooling: an App profile editor
... already 6 PaaS providers "harmonized"
... full public release by summer 2013
... CAMP: could be an additional adapter under the harmonized API
... common API could act as a possible validation of a ref impl of CAMP
... "interoperability is inversely proportional to market [incentive of] adoption"
... JSON should be just serialization, not impose restriction on the model.
... there is a rough consensus on security between PaaS providers currently
... who define CAMP conformance? OASIS does not provide certification services, but TC defines conformance requirements, members will do test suite
Gil assumes scribe duties.
Cloud4SOA demonstration
Topic: https://tools.oasis-open.org/issues/browse/CAMP-30 Parameter Scheme
Adrain> (reviews history of this issue and proposals)
Adrian> (reviews current proposal)
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48611/camp-spec-v1.1-wd08-issue30.doc
(Discussion about whether "parametersDefinitionURI" should be a common attribute or just add it to the resources that require it. Decision is that, because some resources have "parametersDefinitionURI" as a required atttribute and others have it as an optional attribute - it shouldn't be defined as a common attribute)
Tom> is MAP used anywhere else
Adrian> no, but it should be a common type
Anish> (has problem with description of "parametersDefinitionUri")
Adrian> (changes name to "parametersDefinitionsUri")
Adrian Otto (Rackspace): Anish, edit this: The pdpUri parameter is a required attribute in the Platform Resource because this parameter is used to create new Assembly resources upon
.... a POST to the Platform Resource. The value of the pdpUri parameter MUST refer to a ParameterDefinition Resource that describes the parameter with the required Boolean set to true.
Anish Karmarkar: parameterDefinitionsURI points to a resource that contains link to parameterDefinitions that describe parameters accepted by this resource on a POST HTTP method.
..... Each of the parameterDefinition provide metadata for the parameter as described in Section <>. The Platform resource accepts the pdpUri parameter to create new Assembly
.....resources upon a POST. Platform resource MUST point (indirectly) to a parameterDefinition resource that describe the pdpUri parameter.
..... parameterDefinitionsURI points to a resource that contains links to parameterDefinitions that describe parameters accepted by this resource on an HTTP POST method. Each of the
.....parameterDefinitions provide metadata for the parameter as described in Section <>. The Platform resource accepts the pdpUri parameter to create new AssemblyTemplate resources
.....upon a POST. Platform resource MUST point (indirectly) to a parameterDefinition resource that describe the pdpUri parameter.
..... parameterDefinitionsURI points to a resource that contains links to parameterDefinitions that describe the parameters accepted by this resource on an HTTP POST method.
..... Each of the parameterDefinitions provide metadata for a parameter as described in Section <>. The Platform resource accepts the pdpUri parameter to create new AssemblyTemplate
..... resources upon a POST. Platform resource MUST indirectly reference a parameterDefinition resource that describe the pdpUri parameter.
.....When the name of a parameter matches the name of an attribute in the resource that will be created by the POST, conforming CAMP implementations SHOULD set the value of that
.....attribute in the newly created resource to the value of the supplied parameter.
For example, if a client supplies an attribute called "name" on a POST request to an Assembly Template, the name of the resulting Assembly resource should be set to the value of that parameter.
For example, if a client supplies an attribute called "name" on a POST request to an Assembly Template, the value of the "name" attribute of the resulting Assembly resource should be set to the value of that parameter.
When the name of a parameter matches the name of an attribute in the resource that will be created by the POST, conforming CAMP implementations SHOULD set the value of that
.....attribute in the newly created resource to the value of the supplied parameter. For example, if a client supplies an attribute called "name" on a POST request to an Assembly Template,
..... the value of the "name" attribute of the resulting Assembly resource should be set to the value of that parameter.
Alex Heneveld (Cloudsoft): Parameters allow customizing Resources upon creation. Parameters MAY have the same name as an Attribute on the Resource.
..... In such cases the implementation SHOULD set the Attribute to take the value of the Parameter OR clearly document the behaviour.
(NON)RESOLUTION: Adrian will record the current state of the conversation in another draft and upload to Kavi
(break)
Alex Heneveld (Cloudsoft): btw CAMP-30 my final thoughts for the day (based o @Panagiotis) here: https://tools.oasis-open.org/issues/browse/CAMP-30?focusedCommentId=32936&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_32936
TOPIC: Test Assertions
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48758/camp-ta-v1.1-wd03-candidate.doc
Jacques> presents the latest draft (link above)
Still being drafted, new issues on the spec will be raised as discovered
Day 3 - 5th April 2013
Tom assumes scribe duties
Topic: New Issues
Issue 58 - Justification for the common "created attribute is unclear"
Anish: why is created date more important than last modified date?
Adrian: It created more problems to have it than to remove it as common attribute. Actually Last Modified is more important in many cases.
Jacques: a facility for logging would cover the case for created date. There is no use case for having a created date attribute.
Motion: m: Adrian, s: Anish moves to open Issue 58
Panagiotis: I think that last modified is more important.
Adrian moves to amend that this issue should be opened as P3 Issue. Anish seconded amendment. No objection to amendment.
Gil: Last-Modified is an HTTP header - not clear we need to put redundant info in our model
No objections to amended motion. Motion passes Issue 58 opened as P3 issue.
Adrian: content negotiation in HTTP, is enabled by a last modified header in HTTP. We could require the last modified header as a way to resolve this issue.
Anish: we should be careful to over specify the use of http in this spec.
Adrian: since most REST protocols are underspecified, we should consider adding more guidance.
Issue 59: Inconsistent definition of link attributes to point at templates used to instantiate resource types.
Anish: There are differences, assembly always has a template, but components do not always need to have a template.
Motion: m: Anish, s: Tom, moves to open Issue 58 with priority P3, and assign to Tom
Anish: The instantiated from template attribute could be optional for components, but it is always there for Assembly.
No objection to open Issue 59 as P3. Motion passes
Issue 60: ApplicationComponentCapability is not linked by any resource type.
Ashok Malhotra (Oracle): Why not pointed to from Application Component?
Anish: perhaps we could just remove this resource.
Motion: m:Tom, s: Adrian moved to open Issue 60 as P2
No objection, Issue 60 opened as P2, with Gil as owner.
Issue 61: Camp is vague about which HTTP methods each resource supports.
Motion: m: Gil, s: Adrian moves to open Issue 61 as P2 with Gil as owner.
Adrian: we could ship without this, but it would be better to include this in the spec. That is why P2 is appropriate.
Anish: we could have a section with a small table.
No objection, Issue 61 opened as P2, with Gil as owner.
Motion passes
Gil: we should clearly delineate what http methods a resource must support, but have no additional method support restrictions for resources.
Gil: However, we might want to have some resource types that have a GET only restriction.
Panagiotis: What happens if you do a put on a get only resource?
Anish: A concise table would make this more readable.
Tom: we should try to avoid negative testing assertions that the resource should reject non mandatory methods.
Topic: Planning and milestones
Review: End March - Deadline for new P1 issues End May - Start 1st PR End July - All issues closed, 2nd PR End August - Start CS ballot
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48314/CAMP%20sched.pdf
Anish: rather than a deadline for P1 issues, after this F2F we need to raise the bar for accepting a new P1 issue.
Anish: I support raising the bar to require support of more than 2/3 of TC to accept a new P1 issue.
Duncan: Any issues discovered during interop need to be dealt with. However we should be careful to avoid scope creep thru accepting new issues.
Martin: we could have a last call date after which no new issues will be accepted without a large super majority.
Adrian: we need at least one more meeting before we have the last call for P1 issues.
Adrian: all P1 and P2 issues need to be closed out before shipping spec, some P3 issues can be deferred.
Anish: Criteria for start 1st PR is closing all P1 issues. Criteria for 2nd PR is all V1.1 issues closed.
Anish: we should have an interop event in this schedule.
Adrian: test assertions may bring up bugs, resolving such bug improvement issues would be critical.
Martin: some persons but might be another person's improvement. We should treat all issues with the same criteria.
Anish: for PRs we should decouple the TA spec and the base spec. However we need the TA spec ready before a target date for interop.
Jacques: We should have the TA doc ready for review during the 1st PR for the main spec.
Martin: does main spec reference the TA spec?
Anish: we could put either in non-normative refs section, or on the cover page as "related spec" url
Anish: we need to put in dates for the TA doc in the timeline
Anish: June F2F, if during Public review, could focus on implementation/interop activities.
Martin: I do not think we should hold up the 1st PR because the TA doc is not complete. We can fill out the TA doc during the 1st PR for the base spce.
Gil: I have a concern that end of MAY for 1st PR is, under assumption that the spec is complete, is unrealistic. End of June is more realistic goal.
Anish: the 1st PR should be there to get feedback from the general community on the spec.
Martin: I think the end Aug CS ballot is the most unrealistic.
Motion: m:Anish, s: Gil: moves we have a 1st PR at end of June, with a 1st PR for TAs one month later
Anish Karmarkar: For the TA document 1st PR is end of June and all issues closed 2nd PR is end of Aug
Jacques: need to consider maximizing the PR feedback. I am concerned about how much attention people will give to TA spec if the main spec has already been reviewed. I would strive to have the TA spec reviewed at the same time as the base spec.
For interop could be done with the TAs evaluated using human eyes, rather than test tools.
Jacques: I would like to amend this motion to more closely synchronize the TA 1st PR with the base spec 1st PR.
Duncan: pushing the 1st PR back to end of June will have a knock on effect to push everything else out. However this would give a June F2F a greater importance as a focal point.
Martin: moving everything out by one month is disastrous.
Clarification: motion on table is to have TA spec 1st PR end of june, and all issues closed second PR at end of august.
amendment to Motion: m: Jacques, s: Alex amend Anish motion: 1st TA PR to be initiated sometime between 1st PR of main specification (end May) and end of June.
Alex Heneveld (Cloudsoft): please confirm: 1st PR for spec _remains_ at end of May
@Alex - That is _now_ my understanding
Alex seconds Jacques motion.
Alex Heneveld (Cloudsoft): confirming: the motion I second is that "1st TA PR initiated sometime between 1st PR of main spec and end of June"
What we are discussing is an amendment to the current timeline to add a deadline for 1st TA PR that is end of June
MarkCarlson: Keep in mind this a goal setting exercise. We can change our minds at anytime in the future based on circumstances.
And a second amendment to the timeline to add a second deadline for all TA issues to be closed by end of August
Anish Karmarkar: @alex 1st PR for spec does remain end of may regardless of the main motion or amendment
... so that a second TA PR can be initiated
Clarification the amendment is "1st PR for TA issued by the end of June"
No objections. amendment passes
Amended motion: 1st PR for TA issued by end of June.
No objection, motion passed.
Martin: is it feasible to have an implementation interop by the end of June?
Anish: we should tailor the next interop to focus on implementation
Alex: since interop will bring up new issues, be should have it between June and end of July.
Adrian: suggest Interop sessions July 8 and 9 with regular TC conf call on July 10 to discuss results from inerop.
Action Item: all members to investigate hosting July 8, 9, 10 in or near the Colorado area.
Topic: Issue list review
Martin: 8 P1 issues
Martin: issues 45 and 56 should have proposals from the editors with high priority
Alex Heneveld (Cloudsoft): discussion -- Issues 4, 45, and 9 are the high-effort ones. (PDP, normative statement overhaul, and sensors+effectors)
As group we need to resolve Camp 4
Camp 4 Adrian
Camp 3 Anish
Camp 9 Alex
Adrian: owners of P1 issues focus with priority, 4, 9, 56, 45, 55, 30, 3, 17
Duncan assumes scribe duties.
Resumed - Topic PDP
Discussing https://gist.github.com/ahgittin/5311818
Drilling down on 2-cluster.json.txt Now looking at more complex example 3-fairly-advanced-withDB-and-VM-config.json.txt
Introducing notion of "fulfilment"
Gil: What is purpose of AssemplyTemplate lined 5-12?
Alex: Illustrative in this example Highlighting lines 41-42 dependency injection
Alex: Borrowing from TOSCA concepts - adding fulfilment
Alex: PDP could just be a reference to TOSCA, Checkmate, CloudFormation or some other descriptor
Martin: PDP has to conform to a format
Alex: Valid issue but one that also affects output of server
Jacques: Is fulfilment just a link to a requirement?
Gil: Jackson or GSON would have no trouble parsing Alex's DP (camp.json)
Gil: ACT generates AC and PC requirements; PC requirement fulfilled by PCT (Picture)
Alex has posted comment https://gist.github.com/ahgittin/5311818#comment-811570
Gil: Do we need ACT -> PCT link?
Issues being raised will be addressed/discussed as part of proposal
Adrian: If we aren't an orchestration spec why are we describing what is inside an application?
Gil: Minimalist approach
Alex: This is explicit wiring only
Alex Heneveld (Cloudsoft): for reference: https://gist.github.com/ahgittin/5311818
Alex: without fulfilment you can only do toy examples
Gil: that's not necessarily an issue
Alex: Suggest we let people digest this and review at next call
Alex: Happy to write up full proposal if TC thinks this valuable having reflected on it A
drian: There is merit in this or something like it (Adrian - please elaborate)
Gil: What fulfilment teaches us is that abstract config/wiring has little or no value without this additional information (paraphrase)
Gil: Declarative
Gil: No ordering; no attempt to come up with implementation
Adrian: Three buckets: PDP Format (CAMP-4); PDP API (CAMP-3); PDP Deployment Description / Meta-DSL
PDP discussion to continue....
Topic: AOB
Stragglers none.
Meeting adjourned.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]