[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 27th March 2013
Meeting Minutes 27th March 2013
Attendees:
US Department of Defense (DoD) Michael Behrens 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
Oracle Gilbert Pilz Voting Member
Red Hat Krishna Raman Voting Member
Fujitsu Limited Tom Rutt Voting Member
JumpSoft Charles Tupitza Voting Member
Intro:
Alex assumes scribe duties.
Roll call: attendees listed above, 11 of 16, 68% meeting is quorate.
Agenda v2 adopted w/o objection
Minutes:
20th March 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201303/msg00062.html
Motion: m: Charlie Tupitza, s: Anish to adopt minutes 20th March 2013
Minutes of 20th adopted w/o objection
Administrivia:
Discussion about location for next week's F2F. Possible move to Oracle Santa Clara Campus (4040 Palm Drive, Santa Clara, CA).
Final choice will be communicated by email and in calendar.
Editor's Update:
none currently. expect updated versions prior to F2F, including Test Assertions.
F2F Agenda:
Walkthrough of draft by MartinC. Updated version will be circulated subsequently.
discussion of additional items for F2F
Jacques suggests alignment with other specs, e.g. TOSCA
(and relevance / composability / compatibility thereto)
Alex suggests use cases and primer
New Issues:
None
Issues Discussion:
https://tools.oasis-open.org/issues/browse/CAMP-17 : Figures should be redrawn
Tom goes presents an initial UML class diagram
some apparent inconsistencies raised
Alex Heneveld (Cloudsoft): nice job on the class diagram -- very handy
Gil: we had an issue that attempted to discuss this (nulls and empty arrays
Gil: https://tools.oasis-open.org/issues/browse/CAMP-32
Gil: "CAMP needs to say something about the serialization of null attribute values *and empty arrays*"
Gil: we closed this because it was "too controversial"
Tom will keep working on the UML
https://tools.oasis-open.org/issues/browse/CAMP-55 : Lifecycle Diagram is conflating two levels of states, leading to inconsistencies
presentation on lifecycle states by Gil
MartinC: uploaded was really the state of the pdp - which isn't really a resource so ok not to have
anish: +1 to allowing manual wiring
anish: so CAMP should allow creating a template, even if it isn't 'runnable'
Alex Heneveld (Cloudsoft): unresolved and resolved ?
Michael Behrens: Provisioned?
Alex Heneveld (Cloudsoft): "deployed" to me suggests that there are active Assembly instances
Gil: BTW - I have a whole other lifecycle to discuss, so we might want to keep moving
Jacques (Fujitsu): It is still good to be able to talk generally of what state is my "application" in a CAMP provider (as an overlay on top of concrete assemblyTemplates / assemblies lifecycles): "my application is uploaded/deployed/active etc."
Alex Heneveld (Cloudsoft): (as just said) like the idea of indicating whether something is ready for use, but concerned about complexity of computing whether something is runnable, exposing the "resolve" process, etc. perhaps this is something we should stay silent on for the moment.
MartinC: the problem is what is an application - the code, all the running instances, etc etc
MartinC: many different interpretations
Alex Heneveld (Cloudsoft): PS: how is the "resolve" operation invoked?
MartinC: is it an operation? its a state transition, it could get triggered many ways
Alex Heneveld (Cloudsoft): @MartinC good point. but -- are there any such triggers we describe in the spec? i think these two states are an opinion on how camp might be implemented -- a good opinion, but not the only opinion; and this is something where i don't think we need to enforce an opinion.
Alex Heneveld (Cloudsoft): an alternative wrt AssemblyTemplate would be to expose a "ready" attribute to indicate whether it can be instantiated. some CAMP impls could always say ready=true. others could introduce resolve triggers etc.
Gil: The optional Suspended state represents an Application that has been suspended. During this state the Application is unavailable to its clients and does not process any requests.
This specification does not specify whether the suspension is done at full scale with all its existing resources allocated, or scaled back with minimum resources necessary to preserve its runtime context, or something in between. An implementation can specify scale at which suspension is done or allow clients to specify the scale of suspension via extensions. The scale at which the suspension is done affects resource utilization and therefore cost during the suspension phase. It also affects the time it takes to resume processing client requests at roughly the same rate as before suspension.
Gil: note the "optional"
MartinC: maybe finished is a better name - its finished but the resource is still there, but no running code
MartinC: deleted means resource and code is gone
Alex Heneveld (Cloudsoft): @Gil - so could this be a boolean isSuspended instead of a fixed enum of states?
Michael Behrens: I agree: Having a number of boolean states might be good, vice a state-model.
MartinC: we agreed to define a normative list of state names
MartinC: but we also agree its extensible
Jacques (Fujitsu): As far as Assembly states are concerned: to avoid rat-hole app semantics discussions, just define the states in a black-box manner: what they mean for users.
Alex Heneveld (Cloudsoft): i think CAMP stay silent on whether AssemblyTemplates can be deleted, for now
Alex Heneveld (Cloudsoft): good list of questions
Alex Heneveld (Cloudsoft): @Gil - extending "ResourceState" makes sense if we can interrogate isRunning, isSuspended as attributes on those states
Alex Heneveld (Cloudsoft): (immutable attributes on the ResourceState i mean)
CAMP 4 : http://tools.oasis-open.org/issues/browse/CAMP-4
Gil: @Alex - not quite getting you
discussion over email and in issue, but no proposal. deferred to F2F.
Gil: are you saying that all extension states should be represented as sub-states of the CAMP-defined states?
Alex Heneveld (Cloudsoft): @Gil - yes, if extension states are to be useful, they need to be registered, and consumer needs to be able to determine whether app is running (or whether template is instantiable)
CAMP 30 - deferred
AOB:
Stragglers: None
Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]