[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 5th June 2013
Meeting Minutes 5th 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
Cloudsoft Corporation Limited Alex Heneveld Voting Member
Oracle Anish Karmarkar Voting Member
Oracle Ashok Malhotra Voting Member
Rackspace Hosting, Inc. Adrian Otto Secretary
Vnomic Derek Palma Member
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:
Krishna assumes scribe duties
Roll: Attendees listed above, 13 of 13 (100%), meeting is quorate.
Agenda:
No objections to approving agenda
agenda approved as posted
Minutes:
29th May 2013: (revised) https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201306/msg00013.html
MOTION: Adrian moves, Tom 2nds: to adopt minutes 29th of May
No discussion or objections to approving minutes.
Minutes approved.
Action Items:
All action items completed.
Administrivia:
F2F: plugfest still a reality or shall we have a normal F2F?
Chair: Month away from the next F2F meeting. We need to start building an agenda and approximate days.
Gil, and Alex will have a server implementation ready to test. Perhaps we need a client?
Anish: Do we need 2 days for plugfest or is one day enough. Also suggests we have issue resolution day after the plugfest since we may have issues from the plugfest itself.
Alex: can intersprsed testing an issue resolution
Chair: Prefer to have predetermined time for issue resolution for members who dial in.
Alex: suggest 1/2 day for first pass of plugfest
Alex Heneveld (Cloudsoft): ^^^ then iterate (work on issues, code, and test again)
Chair to daft an agenda.
Editing Team Update:
Jacques: Working on TA. Making slower progress than expected. Hope to have complete draft in 2 weeks. Will bring up a few questions about the spec.
Anish Karmarkar: @jacques thanks for the update
Adrian: Added WD-11 which includes a resolution to CAMP-58.
MartinC: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49426/latest/camp-spec-v1.1-wd11.doc
New Issues:
https://tools.oasis-open.org/issues/browse/CAMP-68 Map Type is not needed
Anish Karmarkar: we should be able to open and resolve this issue
MOTION: Adrian motions to open CAMP-68. Tom Rutt seconds
Priority: minor
Alex: are we removing completely the idea that we dont want duplicate key names. We have attributes in a few places which would also need a similar change.
Adrian: there is nothing currently that prevents duplicate attributes.
Alex Heneveld (Cloudsoft): New issue to disallow duplicate key names
Anish: In our JSON serialization (independent of map object), did we not decide that we should not have duplicate keys? That is not represented in text
Anish: resources have attributes that get serialized as key=value pairs. Thought that we had decided to not allow duplicates in that context.
No objections to motion to open.
CAMP-68 is open
Tom moves to resolve as stated
Anish: If second half of proposal is confined to just map object then no objection.
Discussion if we should leave duplicate key removal out of the issue and limit it to just map types
MOTION: Adrian moves to resolve camp-68 by removing section 5.1.6. Tom seconds
No discussion or objections.
Issue CAMP-68 resolved
Discussing https://tools.oasis-open.org/issues/browse/CAMP-17 . Tom posted version 3 which removes map type.
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49428/CampIssue17-ModelChanges-r3-NoMap.docx
MOTION: Adrian moves to resolve CAMP-17 using r3. Tom seconds
Alex Heneveld (Cloudsoft): nice work Tom
Anish Karmarkar: indeed
Tom is uploading source of diagrams. Enterprise architect and EMF files will be included.
No discussion or objections. CAMP-17 resolved with changes in r3
Tom Rutt (Fujitsu): I uploaded the model machine readable files to https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49429/CampResourceModelFiles.zip the
EA tool is only $200 for the Professional edition, which has code generation features
Anish Karmarkar 2 issues resolved -- woo-hoo!
Discussing https://tools.oasis-open.org/issues/browse/CAMP-67
Mark pesents his proposal in JIRA
Alex Heneveld (Cloudsoft): @Mark your comment speaks of "platformComponentDependencies" --> hopefully this is s/Dependencies/Requirements/ ?
Alex Heneveld (Cloudsoft): oh no, i guess not
Alex Heneveld (Cloudsoft): can we use a fulfilled attribute on the requirement instead? would be simpler i think.
Alex: Worried that introducing dependencies and requirements might get too complicated. Might be simpler to add a fulfillment to each requirement.
Mark: Ashok suggested that in last call. Should be a separate topic from this proposal. In some cases platform may not know.
Mark: this issue makes it very explicit.
Alex Heneveld (Cloudsoft): @Mark I'm starting to get this proposal
Alex: can we simplify by just having a simple dependencies object that can have a list that refers to requirements that are ACTs or PCTs.
..... In some cases its not clear if something will be fulfilled by ACT or PCT.
Alex: Perhaps merge the 2 types of dependencies
Anish Karmarkar: what do we say about distinguishing between PCR and ACR?
Anish Karmarkar: do we need that distinction
Jacques: Like the idea of direct linkage and having explicit fulfillment. Assume that PCR could be shared across multiple ACT?
Mark: If tere is a repo supplied by the used it would be an ACR. Probably would not be allowed to use an component that someone else uploaded.
Alex: example would be an assembly template that uses a git repo. can either supply a repo (ACT) or use the platform default (PCT). Either way would fulfill requirement
Mark: if you are uploading the PDP, you know what is required and can modify the template to explicitly specify
Anish Karmarkar: this is going beyond the issue at hand -- but alex raises a good Q: as a app. creator why do I care *how* the
...requirement is satisfied. Whether it is satisfied by the ... platform or another app, is not relevant when the app creator creates a requirement
Derek Palma (Vnomic): I would like clarity on this issue
Anish: from the app creators POV, there is no need for this distinction. From a platform POV, perhaps there can be an admin who choses to rewire from PCT to ACT.
Anish: dont see a reason to distinguish between the two. +1 to Alex's point. Questions about what is the compelling reason to distinguish between to two
Jacques (Fujitsu): Could it be that the distinction between PCR and ACR - and more generally PC and AC - is more administrative than technically grounded?
..... In that case, is useful to distinguish.
Gil Pilz (Oracle): this bleeds into: https://tools.oasis-open.org/issues/browse/CAMP-29
Tom Rutt (Fujitsu): It would be a difficult thing to explain that a single requirment could be matched by either a
.....Platform Component Template or an Application Component template. .....the requirements should be one for one on platform and application sided
Mark: we have 2 types of requirements and we have reasons for that already. We could follow the link to the requirement and figure out what it is .....but dont think its possible
for platform to know which one to choose automatically.
Gil Pilz (Oracle): I wish someone would give me an example of an Application Component Template
Anish Karmarkar: i think this is a separate issue and happy to delink this from issue 67
Tom Rutt (Fujitsu): I could live with no Application component requirement and capability resources
MartinC: i thought we had agreed that in the sense we agreed that we dont hook ACs from one app with ACs in another app
Jaques: Technically there might not be much of a difference and maybe the model could be the same but just have a flag
..... which indicates the ownership (app or platform)
Tom Rutt (Fujitsu): There would be no portability problem if V1 required application component templates to just point at the needed application component templates.
..... For portability the Requirement/capability indirection is only needed for platformComponentTemplates.
Ashok: Perhaps multiple requirements may be satisfied by the same platform component.
Alex: 2 questions: Can we have the same requirement on 2 component templates. 2) Can we have 2 requirements satisfied by the same component
Alex: perhaps we should keep first one out of scope and just keep the second
Adrian Otto (Rackspace): I agree that requirements should not be shared across ACTs.
Gil Pilz (Oracle): how do I indicate that I need two Application Components to use the same instance of a Platform Component?
Jacques: would like to share a requirement object which is shared by all ACTs. Eg have a language object which specified version.
.....And want to update all ACTs at same time when changing language version.
Alex Heneveld (Cloudsoft): Jacques's use case is interesting -- we want re-use of requirement (e.g. a version) in many places. however, could we parameterise this?
Adrian Otto (Rackspace): Gil: I expect that would resolve in the AT processing by using a fulfillment.
Anish Karmarkar: ... @tom then i would just call it requirement not platform requirement
Alex Heneveld (Cloudsoft): ie use a parameter value, rather than leaning on the same requirement, which gets confusing as to whether their fulfillment should be the same
Gil Pilz (Oracle): I don't know what a fulfillment is
Alex Heneveld (Cloudsoft): +1 just "requirement"
macredcape: @Tom - the spec was that way originially.
Adrian Otto (Rackspace): Anish: that's what Alex is suggesting (he used the word Dependency)
Tom: Keep it simple and remove application component requirement/capability?
Anish Karmarkar: @adrian got it. and agree
Tom Rutt (Fujitsu): There would still be platform component requirements and capabilities
Gil: Do we need to resolve CAMP-29 before CAMP-67?
Adrian Otto (Rackspace): https://tools.oasis-open.org/issues/browse/CAMP-29
Anish Karmarkar: agree with gil. that is why i suggested we delinking them
Alex Heneveld (Cloudsoft): +1 Gil -> take Mark's suggestion, and clean it up as part of #29
Anish Karmarkar: we could just update 29 and add a link to CAMP-67
MOTION: Mark moves, Gil seconds, to resolve CAMP-67 with Marks comment dated Jun 4
Link to proposal: https://tools.oasis-open.org/issues/browse/CAMP-67?focusedCommentId=33643&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_33643
No objections. CAMP-67 resolved
AOB:
Stragglers: None
Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]