[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 12th November 2012
Meeting Minutes, 14 November 2012
Intro:
Scribe: Mark Carlson designated as scribe
Agenda: Agenda is approved with one small modification
Minutes:
6 - 8th November 2012 F2F Minutes: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201211/msg00073.html
Since these were only posted yesterday, will seek approval at the next meeting.
Action Items:
ACTION-20121106-0: Adrian to upload the openstack presentation (or email a link) in relation to CAMP-10
Done. Posted to JIRA
ACTION-20121108-0: Martin Chapman to request a specification template from the TC admin
Outstanding. See topic below.
Meetings:
Regular slot. Doodle poll at: http://doodle.com/xwyavhangh9m2qv5
Doodle Poll has closed and Wednesday @ 10 am PT is the winner.
Motion: m: Jeff, s: Rutt Move that we meet weekly at 10am PT for 90 min.
Passed w/o
No meeting next week (Day before US Thanksgiving Holiday)
Martin to add repeating calendar entry for weds 10am starting 28th November
Face to face update: (Adrian) proposed to host in San Antonio for 2.5-3 day event
Late January timeframe
Ashok Malhotra (Oracle): Suggest week of Jan 21
Proposed: 23rd, 24th, 25th jan 2013
No one expressed a problem with these dates, so Adrian will confirm wrt facilities etc.
TC Admin template:
To create the first working draft of the spec, the TC needs to decide on the fields in this form:
https://www.oasis-open.org/resources/tc-admin-requests/work-product-registration-template-request
Motion: m: jeff s: charles The title for the spec should be "OASIS Cloud Application Management for Platforms"
passed w/o
Anish: it will be difficult to change the abbreviation later (shows up in a lot of URLs)
Anish: still abbreviates to CAMP, so suggest we call it 1.1 or 2.0 - greater than 1.0
Gil: +1 to 1.1
Martin: version numbers do get baked into the URLs
Adrian: offline discussion on making it 1.1
Jeff: second the 1.1 proposal
Tom: consistent with other submissions called 1.0
Motion: m: jeff, s: rutt Move that the next version be 1.1. m: jeff, s: rutt
Ansih: speaking in favor, there was a similar situation, and even though the OASIS spec was not backward compatible, they still called it 1.1
passed w/o
Motion: m: Anish, s: Duncan Work product abbreviation be "camp-spec"
passed w/o
Test Assertions doc:
Tom: calling it 1.0 would be confusing
Adrian: call it 1.1 to match the spec
Jacques: agree on 1.1 and standards track, we have to state what the conformance requirements are
Anish: One title has an acronym, the other doesn't
Martin: so suggest we expand instead of abbreviating
Motion: m: anish, s: adrian: Title should be Cloud Application Management for Platforms Test Assertions version 1.0.
passed w/o
Motion: m: ansih, s: jacques that is be standards track, and be abbreviated "camp-ta"
passed w/o
New Issues:
CAMP-26: https://tools.oasis-open.org/issues/browse/CAMP-26
Mark: issue to track the "environment" Platform Component
Adrian: precedent for this from Cloud Foundry offering announced today
http://core.cloudfoundry.org/definition
Motion: m: Mark, s: Duncan: Open CAMP-26
passed w/o
Anish Karmarkar: issues 27 and 28 need to be assigned to the component 'spec'
Issue Discussion:
CAMP-24: https://tools.oasis-open.org/issues/browse/CAMP-24
Proposal from Gil: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47447/CAMP-24-2012-11-12.pdf
Adrian: seems like we are adding complexity by doing this, why?
Gil: just reflecting will of face to face. Perhaps because gathering up the dependencies at the Assembly Template layer, I lose the fine grained dependency information
Tobias: at face to face, suggested an index to the references in Assembly template.
Jacques: example of BPM engine. I can depend on this by plugging an application component.
...Want to see this use case addressed - maybe the Platform Component could be the main entry point.
Jacques: Like to separate the Assembly issue
Adrian Otto (Rackspace): I agree that we should consider if Application Components and Platform Components really need to be different types.
...I would support an approach that simply refers to them as Components, with a requirement for indicating whether they are immutable or not, and who they are provided by.
Tobias: don't like the rule that an Application Component always has to be there - it may be in an error state, etc.
Jacques (Fujitsu): About Assembly content: If a Business Process Management engine is provided as Platform Component Template, what
... status would have an application-configured version of this BPM engine (with app modules plugged-in)? If the result is an Platform Component
...and not an Appl Component , then an Assembly might still point to a Platform Component? (i.e. that is the entry point to control this deployed app)
Gil: everything links to everything else so this becomes circular
Tobias: want to make it easy as possible
Anish: just make it a precondition to starting that at least 1 ACT should be defined
Gil: Assuming that you can remove all the Application Component Templates from an Assembly Template implies that the lifecycle of Application Components (and their templates) is separate from that of Assemblys (and their templates)
Adrian Otto (Rackspace): I agree with Anish on this. It's sensible to require that an assembly must ahve at least one component in order to
... launch/start.
Gil: that seems doable
Gil: I have enough input and feedback to clarify this and come back with a new version
... will open an issue to separate out the Assembly problem
CAMP-7: https://tools.oasis-open.org/issues/browse/CAMP-7
Anish: two attributes called based-on that are declared of type shapshot, but this is not defined. The example uses Link to point to
... some other resource. This is misleading because of the description.
... Do we need this type? Do we need these attributes?
... the intention was to show what snapshot fo which assembly the template was formed from
Gil: support removing the attributes
Tobias: +1
Anish: this is just removing the attributes, not the operation
Adrian: have you already considered this from the perspective of how to support the snapshot feature?
Anish: really about the "type"
Adrian: support removing it
Charlie Tupitza JumpSoft: I support removing it for future consideration
Jacques: +1 - need to consider how realistic is it to do this anyway?
Anish: state is not part of a template
Motion: m: Anish, s: Jacques Move that we resolve CAMP-7 by removing the based-on attribute (and references) in all occurrences.
passed w/o
AOB
Gil: https://tools.oasis-open.org/issues/browse/CAMP-5
Gil: Can I overload CAMP-5 with the Assembly issue I was going to break out from CAMP-24
Martin: suggest create a more focused issue and link back to CAMP-5
Martin: any stragglers? None
Martin: next meeting is in two weeks time, and will send out invite
Meeting adjourned.
-----------
Summary of New and Open issues:
ACTION-20121108-0: Martin Chapman to request a specification template from the TC admin
Meeting Minutes, 14 November 2012
Intro:
Scribe: Mark Carlson designated as scribe
Agenda: Agenda is approved with one small modification
Minutes:
6 - 8th November 2012 F2F Minutes: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201211/msg00073.html
Since these were only posted yesterday, will seek approval at the next meeting.
Action Items:
ACTION-20121106-0: Adrian to upload the openstack presentation (or email a link) in relation to CAMP-10
Done. Posted to JIRA
ACTION-20121108-0: Martin Chapman to request a specification template from the TC admin
Outstanding. See topic below.
Meetings:
Regular slot. Doodle poll at: http://doodle.com/xwyavhangh9m2qv5
Doodle Poll has closed and Wednesday @ 10 am PT is the winner.
Motion: m: Jeff, s: Rutt Move that we meet weekly at 10am PT for 90 min.
Passed w/o
No meeting next week (Day before US Thanksgiving Holiday)
Martin to add repeating calendar entry for weds 10am starting 28th November
Face to face update: (Adrian) proposed to host in San Antonio for 2.5-3 day event
Late January timeframe
Ashok Malhotra (Oracle): Suggest week of Jan 21
Proposed: 23rd, 24th, 25th jan 2013
No one expressed a problem with these dates, so Adrian will confirm wrt facilities etc.
TC Admin template:
To create the first working draft of the spec, the TC needs to decide on the fields in this form:
https://www.oasis-open.org/resources/tc-admin-requests/work-product-registration-template-request
Motion: m: jeff s: charles The title for the spec should be "OASIS Cloud Application Management for Platforms"
passed w/o
Anish: it will be difficult to change the abbreviation later (shows up in a lot of URLs)
Anish: still abbreviates to CAMP, so suggest we call it 1.1 or 2.0 - greater than 1.0
Gil: +1 to 1.1
Martin: version numbers do get baked into the URLs
Adrian: offline discussion on making it 1.1
Jeff: second the 1.1 proposal
Tom: consistent with other submissions called 1.0
Motion: m: jeff, s: rutt Move that the next version be 1.1. m: jeff, s: rutt
Ansih: speaking in favor, there was a similar situation, and even though the OASIS spec was not backward compatible, they still called it 1.1
passed w/o
Motion: m: Anish, s: Duncan Work product abbreviation be "camp-spec"
passed w/o
Test Assertions doc:
Tom: calling it 1.0 would be confusing
Adrian: call it 1.1 to match the spec
Jacques: agree on 1.1 and standards track, we have to state what the conformance requirements are
Anish: One title has an acronym, the other doesn't
Martin: so suggest we expand instead of abbreviating
Motion: m: anish, s: adrian: Title should be Cloud Application Management for Platforms Test Assertions version 1.0.
passed w/o
Motion: m: ansih, s: jacques that is be standards track, and be abbreviated "camp-ta"
passed w/o
New Issues:
CAMP-26: https://tools.oasis-open.org/issues/browse/CAMP-26
Mark: issue to track the "environment" Platform Component
Adrian: precedent for this from Cloud Foundry offering announced today
http://core.cloudfoundry.org/definition
Motion: m: Mark, s: Duncan: Open CAMP-26
passed w/o
Anish Karmarkar: issues 27 and 28 need to be assigned to the component 'spec'
Issue Discussion:
CAMP-24: https://tools.oasis-open.org/issues/browse/CAMP-24
Proposal from Gil: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47447/CAMP-24-2012-11-12.pdf
Adrian: seems like we are adding complexity by doing this, why?
Gil: just reflecting will of face to face. Perhaps because gathering up the dependencies at the Assembly Template layer, I lose the fine grained dependency information
Tobias: at face to face, suggested an index to the references in Assembly template.
Jacques: example of BPM engine. I can depend on this by plugging an application component.
...Want to see this use case addressed - maybe the Platform Component could be the main entry point.
Jacques: Like to separate the Assembly issue
Adrian Otto (Rackspace): I agree that we should consider if Application Components and Platform Components really need to be different types.
...I would support an approach that simply refers to them as Components, with a requirement for indicating whether they are immutable or not, and who they are provided by.
Tobias: don't like the rule that an Application Component always has to be there - it may be in an error state, etc.
Jacques (Fujitsu): About Assembly content: If a Business Process Management engine is provided as Platform Component Template, what
... status would have an application-configured version of this BPM engine (with app modules plugged-in)? If the result is an Platform Component
...and not an Appl Component , then an Assembly might still point to a Platform Component? (i.e. that is the entry point to control this deployed app)
Gil: everything links to everything else so this becomes circular
Tobias: want to make it easy as possible
Anish: just make it a precondition to starting that at least 1 ACT should be defined
Gil: Assuming that you can remove all the Application Component Templates from an Assembly Template implies that the lifecycle of Application Components (and their templates) is separate from that of Assemblys (and their templates)
Adrian Otto (Rackspace): I agree with Anish on this. It's sensible to require that an assembly must ahve at least one component in order to
... launch/start.
Gil: that seems doable
Gil: I have enough input and feedback to clarify this and come back with a new version
... will open an issue to separate out the Assembly problem
CAMP-7: https://tools.oasis-open.org/issues/browse/CAMP-7
Anish: two attributes called based-on that are declared of type shapshot, but this is not defined. The example uses Link to point to
... some other resource. This is misleading because of the description.
... Do we need this type? Do we need these attributes?
... the intention was to show what snapshot fo which assembly the template was formed from
Gil: support removing the attributes
Tobias: +1
Anish: this is just removing the attributes, not the operation
Adrian: have you already considered this from the perspective of how to support the snapshot feature?
Anish: really about the "type"
Adrian: support removing it
Charlie Tupitza JumpSoft: I support removing it for future consideration
Jacques: +1 - need to consider how realistic is it to do this anyway?
Anish: state is not part of a template
Motion: m: Anish, s: Jacques Move that we resolve CAMP-7 by removing the based-on attribute (and references) in all occurrences.
passed w/o
AOB
Gil: https://tools.oasis-open.org/issues/browse/CAMP-5
Gil: Can I overload CAMP-5 with the Assembly issue I was going to break out from CAMP-24
Martin: suggest create a more focused issue and link back to CAMP-5
Martin: any stragglers? None
Martin: next meeting is in two weeks time, and will send out invite
Meeting adjourned.
-----------
Summary of New and Open issues:
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]