raw chat log day 2 April f2f

[Martin Chapman <martin.chapman@oracle.com>]

Alex Heneveld (Cloudsoft): ---
Alex Heneveld (Cloudsoft): good morning folks
Alex Heneveld (Cloudsoft): got a gist to play with at:
Alex Heneveld (Cloudsoft): https://gist.github.com/ahgittin/5311818
Alex Heneveld (Cloudsoft): (PDP samples)
MartinC - webex: Scxaling presentation https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201304/msg00007/Scaling_Policy_Concepts_v1.ppt
Scribe (Fujitsu): topic: Scaling Policy
Scribe (Fujitsu): Duncan: need to address more complex case. SHould not settle for a too simple model
Ashok Malhotra (Oracle): Could you minute that please.  I cannot hear too well.
Scribe (Fujitsu): Duncan: that looks like ECA (event-condition-action) rules
Scribe (Fujitsu): presenter: 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
Scribe (Fujitsu): alex: what goes in the spec: on metrics side : we have attributes already.
Scribe (Fujitsu): ... the important one: actions
Scribe (Fujitsu): presenter: we can turn on/off our sensors. If attribute, it is always here, always have value.
Scribe (Fujitsu): martin: could a metric be a resource?
Scribe (Fujitsu): alex: V2 maybe. But we should have sensors.
Scribe (Fujitsu): adrian: CLoud specifics: utility-billed, so elasticity is essential - so in scope for us.
Scribe (Fujitsu): alex: alerts and conditions: too trivial. Need a more policy-like approach.
Scribe (Fujitsu): ... more complex management logic needed.
Scribe (Fujitsu): 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.
Scribe (Fujitsu): ... so we may need to reuse such efforts underway and not restricted to the Cloud application layer.
Duncan Johnston-Watt (Cloudsoft): 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
Scribe (Fujitsu): tom: metrics may need be a separate resource, not just attributes of CAMP resources
Scribe (Fujitsu): adrian: should not settle for hacks, let extensions set the right direction.
Scribe (Fujitsu): ... how to actually implement it is the problem (not how to specify). May need extra service to handle this.
Scribe (Fujitsu): Ashok: what are the concrete changes/direction for CAMP, that are proposed here?
Scribe (Fujitsu): duncan: need remain above the fray. Migration may be a more interesting policy than scaling.
Scribe (Fujitsu): ... 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)
Scribe (Fujitsu): martin: challenge is what are the right minimum/enabling features in the spec. Not fall into a condition language trap.
Alex Heneveld (Cloudsoft): scroll please
Scribe (Fujitsu): alex: Q1: do we want a new resource for sensor? Q2: new resource type for Policy?
Scribe (Fujitsu): ashok: need be able to turn off values. Values of attr are not same as sensors.
Scribe (Fujitsu): alex: an attribute value is a kludge. need a gatherer anyway
Scribe (Fujitsu): duncan: notion of a control interface is important. Separate rule data.
Scribe (Fujitsu): jeff/presenter: specify way that metrics are exposed. Later we may consider policies.
Scribe (Fujitsu): ... sensors as a separate concept/resource.
Scribe (Fujitsu): tom: metrics not as simple as storing values. Users may need to control the metrics parameters.
Scribe (Fujitsu): ... gathering metrics needs control parameters.
Duncan Johnston-Watt (Cloudsoft): agree with meeting that overloading attribute is concern - so introducing sensor makes sense IMO
Duncan Johnston-Watt (Cloudsoft): operations are less controversial?
Duncan Johnston-Watt (Cloudsoft): how we bridge between the two (autonomic/ECA) is detail we can label "There exists some policy ..." and leave at that
Scribe (Fujitsu): martin: level of trust is important (how up-to-date is the value?). A minimum support is needed, control for later.
Scribe (Fujitsu): jacques: "action" part is still fuzzy - how far beyond CAMP scope?
Scribe (Fujitsu): jeff: e.g. if request/sec goes down, need to tell someone. Seems like a management concept.
Scribe (Fujitsu): ... CAMP could focus on representing the actions, not defining them.
Scribe (Fujitsu): duncan: actions are platform level. Sensors are a way to factor in external input as well.
Scribe (Fujitsu): jeff: we interact with Platform anyway. Action that can be taken? could be templates parameterized.
Scribe (Fujitsu): ... such actions templates can be exposed / standardized
Scribe (Fujitsu): ... metrics also can be exposed
Scribe (Fujitsu): duncan: sensors call for effectors... sounds normal to deal w both the same way
Scribe (Fujitsu): ================ break 15mn ======================
Mark Carlson (Oracle): https://twitter.com/campspec
Ashok Malhotra (Oracle): It's issues 9 and 11
Scribe (Fujitsu): chair: CAMP11 out of scope for V1, but CAMP9 is in scope
Scribe (Fujitsu): MOTION: (Alex, Anish) move #9 to P1
Ashok Malhotra (Oracle): +1
Duncan Johnston-Watt (Cloudsoft): +!
Scribe (Fujitsu): MOTION: no obj, passed.
Scribe (Fujitsu): Duncan: lets deal with extensions. We can keep what is between sensors & effectors unprescribed.
Scribe (Fujitsu): Anish: keep #11 alive
Scribe (Fujitsu): Alex: presents #11 about scaling policy
Scribe (Fujitsu): ... moving away from a new type of Policy
Scribe (Fujitsu): Topic: liaisons
Michael Behrens: Cloud4SOA: good presentation. Please post brief to soaphub files when time permits.
Scribe (Fujitsu): martin: some parts of Cloud4SOA overlap strongly with CAMP functionality
Scribe (Fujitsu): pres: yes, these slides were drafted in 2010
Scribe (Fujitsu): ... try to have at least 2 PaaS providers per core technology (Python, etc)
Scribe (Fujitsu): ... harmonized API + adapters to specific platforms
Scribe (Fujitsu): ... now working on reference implementation.
Scribe (Fujitsu): ... SOA layer and Governance layer (SLA) on top of harmonized API
Scribe (Fujitsu): ... "matchmaking" (autowiring) processes (also involving human)
Scribe (Fujitsu): ... tooling: an App profile editor
Scribe (Fujitsu): ... already 6 PaaS providers "harmonized"
Scribe (Fujitsu): ... full public release by summer 2013
Scribe (Fujitsu): ... CAMP: could be an additional adapter under the harmonized API
Scribe (Fujitsu): ... common API could act as a possible validation of a ref impl of CAMP
Scribe (Fujitsu): ... "interoperability is inversely proportional to market [incentive of] adoption"
Scribe (Fujitsu): ... JSON should be just serialization, not impose restriction on the model.
Scribe (Fujitsu): ... there is a rough consensus on security between PaaS providers currently
Scribe (Fujitsu): ... who define CAMP conformance? OASIS does not provide certification services, but TC defines conformance requirements, members will do test suite
Michael Behrens: +1 on cooperation to use CAMP as it matures, etc.  Feedback, etc.
Scribe (Fujitsu): ================ Lunch break (until 1:30pm) ======================
Mark Carlson (Oracle): The call needs to be started again...
Mark Carlson (Oracle): The call is now open ... finally...
Scribe (Gil): MEETING RESUMED
Scribe (Gil): Cloud4SOA demonstration
MartinC - webex: topic: camp-30
Scribe (Gil): TOPIC: CAMP-30
Scribe (Gil): Adrain> (reviews history of this issue and proposals)
Scribe (Gil): https://tools.oasis-open.org/issues/browse/CAMP-30
Scribe (Gil): Adrian> (reviews current proposal)
Scribe (Gil): https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48611/camp-spec-v1.1-wd08-issue30.doc
Scribe (Gil): (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)
Scribe (Gil): Tom> is MAP used anywhere else
Scribe (Gil): Adrian> no, but it should be a common type
Scribe (Gil): Anish> (has problem with description of "parametersDefinitionUri")
Scribe (Gil): 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.
Scribe (Gil): 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.
Scribe (Gil): 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.
Scribe (Gil): 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.
Scribe (Gil): 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.
Scribe (Gil): 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.
Scribe (Gil): 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): --
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.
MartinC - webex: is anyone on the bridge?
Alex Heneveld (Cloudsoft): @MarkC yt?
Scribe (Gil): (NON)RESOLUTION: Adrian will record the current state of the conversation in another draft and upload to Kavi
Scribe (Gil): (break)
Adrian Otto (Rackspace): adrianotto / gist:5315601
Alex Heneveld (Cloudsoft): thx adrian
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
Alex Heneveld (Cloudsoft): adrian's sample pdp gist:  https://gist.github.com/adrianotto/5315601
Alex Heneveld (Cloudsoft): my sample pdp gist:  https://gist.github.com/ahgittin/5311818
Scribe (Gil): TOPIC: Test Assertions
Scribe (Gil): https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48758/camp-ta-v1.1-wd03-candidate.doc
Scribe (Gil): Jacques> presents the latest draft (link above)