[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 10th April 2013
Meeting Minutes 10th April 2013
Attendees:
US Department of Defense (DoD) Michael Behrens Voting Member
Oracle Mark Carlson Voting Member
Oracle Martin Chapman Chair
Fujitsu Limited Jacques Durand Voting Member
Cloud4SOA Panagiotis Gouvas Voting 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
Red Hat Krishna Raman Voting Member
Fujitsu Limited Tom Rutt Voting Member
JumpSoft Charles Tupitza Voting Member
Software AG, Inc. Prasad Yendluri Voting Member
Intro:
Ashok assumes scribe duties.
Roll: 15 of 16, 93% quorate. Attendees listed above
Topic: Agenda
Add a quick debrief of F2F
Ashok: Please spend a few minutes on Scaling Policy
Martin: I will add it
Agenda approved w/o objection
Topic: Next f2f
Duncan has made offer to host on Colorado (Broomfield, CO @ Omni Interlocken Resort (potentially)
July 8-10 tentively
Topic: Timeline
Gil has updated the diagram: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48760/CAMP%20sched%202013-04-05.pdf
Goal is to have PR for TA to overlap some of the time with PR of the Spec
Topic: Minutes of F2F
April 2013 F2F: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201304/msg00037.html
Motion: Gil moves to moves accept minutes Adrian seconds
Minutes approved w/o objection
Topic: Editing Team Update
No news
Topic: Issue Discussion
Martin: Biggest ongoing issue is PDP
Gil: Alex added to my proposal
Alex: Mine is a superset
Adrian: I made some additional changes
Alex presents teh draft: https://www.oasis-open.org/apps/org/workgroup/camp/document.php?document_id=48811
Alex: Zip archive with a CAMP.JSON at the root
Adrian: Where is SPECIFICATION defined
Gil: What is containing the content?
Alex: That's the specification object. You can have more than one of those.
Gil: I view the PDP as a bag of component.
Gil: ComponentSpec?
Alex: A specification is a specification for a component
Michael: Where do we tell what to do with the specifications?
Adrian Otto (Rackspace): Have we considered only using Requirements rather than
....Specifications? This would give the platform the freedom to create any number of resources
....to address the stated Requirements, as Gil has indicated.
Michael: Is the ordring meaningful.
Alex: We don't say anything about that. Servers may want to do them in parallel
... Perhaps say order is not significant
Adrian: Why this directions rather than requirements
... if we do that the platform could satisfy several requirements with a single resource
Krishna: Requirements would be pltaform independent
Alex: Requirements can be extended
Michael Behrens: "options" would be a good name for it.
Discussion on optionality
Gil: +1 to renaming "requirements" to "dependencies" - this further reinforces the separation
....between "dependencies" (which are in the DP) and "PlatformComponentRequirement" (which is a CAMP resource)
Gil: Why did the requirement specified transitively
Alex: It does not. Both variations are possible.
Gil: Can we eliminate transitive requirements for this version?
Alex: It limits expressivity
... gives an example
... 4.3 describes the Schema
Martin: Asks about the Schema language
... if so everyone will have to write a PDP parser
Anish Karmarkar (USA): i missed the schema part. why do we need a schema?
Gil: JSON Schema is not going to be a spec soon
... parsing JSON is not a big problem
Tom Rutt (Fujitsu): I thought we were going to define our own curly brace notation for our jason pseudo schema
Alex: Not hard to parse the JSON objects ... we can do that and make it open source
Anish: Why do we need a Schema for the PDP? We don't need it for other resources.
Alex: A lot of folks will generate PDPs so it may be good to have a Schema
Tom: Test Cases will require some parsing
Adrian Otto (Rackspace): What about parameters? Do we want to allow parameters to be .... supplied when a PDP is registered, or processed?
Alex: We may need a validator for conformance testing
Anish: Not having JSON Schema is not going to be a big impediment
Adrian: Asks about parameters to the PDP to accomodate a PDP working on platforms that may have small variations
Anish: May have to use MIME if we allow parameters ... not just an argument to POST
MartinC - webex: the pdp can contain default values
Gil: The name attribute needs to be specified by a parameter
Jacques: Don't we need a file with a standard name?
Tom Rutt (Fujitsu): are we not going to need a test assertion to validate the pdp content?
Gil: if 'name' isn't specified in the DP, and you don't provide 'name' as a parameter in the ....POST to the Platform resource, there is no other choice but to make up some random
name
Anish Karmarkar (USA): @gil that is a good point
Anish: We could say that if you want to use parameters you have another way to register ...where you supply a JSON object with parameters
Anish: Parameters would be used during registration process
Alex: How do we specify what a parameter should do?
... where is the effect of parameters defined
... we may need a new convention such as anything that starts with $ in a parameter
Gil: If the PDP is a bag of components which component does the PDP take its name from
Anish Karmarkar (USA): do we need parameters for 1.1 for anything besides saying 'set the ...assembly template attribute foo to value bar'?
Anish Karmarkar (USA): this would certainly allow you to set the name
Michael Behrens: OASIS SDD: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sdd
MartinC - webex: in a pdp they are not parameters they are just values?
Gil: "The purpose of the OASIS SDD TC is to define XML schema"
Michael: It's complex
Anish Karmarkar (USA): so when you register you can say: {"pdpURI": "...", "name" : "foo"}
Martin: How do we make progress? Can we get a baseline?
Alex: I will turn this into a proposal without parameters ... perhaps that could become a baseline
Adrian: Two easy issues: How do we upload a PDP. What is the format of the PDP?
Anish Karmarkar (USA): or {"pdpURI": "...", "parameters": {"name": "foo", "whatever": "foo1"}}
Martin: Issue-3 is about uploading
MartinC - webex: i think parameters are a misnomer wrt pdp - they are initialisation values
MartinC - webex: parameters we should reserve for posting
Anish: Are parameters platform dependent ?
... or could they be din the PDP?
Alex will attempt a no-frills baseline proposal!
Anish Karmarkar (USA): did we resolve the issue about parameters?
[no]
Issue-60: ApplicationComponentCapability is not linked by any resource Type
Tom: TOSCA uses names for matching. Perhaps that enough for us too.
Gil: I think we do not need capabilities at all
... templates could require ranges of capability
... that's all we need
... I suggest we just delete capabilities
Anish Karmarkar (USA): i think the model where requirements is a narrowing of capability doesn't work for lot of cases
Jacques: Either we remove them or specify where they belong
... usecase is for libraries that may be matched by capabilities
Gil: https://tools.oasis-open.org/issues/browse/CAMP-23
... we need some meta level description of capabilities to match with capabilities
Alex: TOSCA matching is more sophisticated than just name matching
... we do not use capabilities
Tom Rutt (Fujitsu): I think the tosca capability/requirement matching is underspecified, so I am not sure what is allowed
Mark: Requirements and capabilities go hand-in-hand. So, we need to remove both if we are removing.
Gil: I don't understand why you can't match Requirements against Templates
Gil: a Platform Component Template is a recipe for creating (or using an existing) a platform service
Gil: why can't I match my application's requirements against these recipes?
Alex Heneveld (Cloudsoft): I agree with @Gil. "Capabilities" are an attempt to allow insight ...into how requirements are used to select components (templates).
Anish: In some cases the requirement is a range and the capability is a specific value.
Alex Heneveld (Cloudsoft): But they aren't well-enough specified to be worth including in the spec IMHO.
General heading towards removing. put on next weeks agenda.
AOB
Stragglers: Charles
Note we did not cover a debrief of the F2F and scaling policy discussions. Put on next weeks agenda.
Meeting Adjourned.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]