[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 22nd May 2013
Minutes 22nd May 2013
Attendees:
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
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:
Gil assumes scribe duties
ROLL CALL: Attendees listed above, Voting Members: 12 of 15 (80%), meeting is quorate.
TOPIC: Agenda
Martin: any comments? additions?
Martin: any objections to approving agenda?
Agenda approved as posted.
TOPIC: Minutes from May 8th, 2013
8th May 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201305/msg00024.html
Martin: any motion?
<awkward pause>
MOTION: Anish: moves to adopt the minutes of May 8th, 2013, Alex: seconds
Martin: any discussion?
Martin: any objections?
MOTION PASSES: Minutes Approved
TOPIC: Administrivia
Martin: I sent out a ballot for the July meeting
... response was woeful
... only 7 responders, 4 of whom indicated they would be attending
... only Oracle and Cloudsoft
Anish Karmarkar i didn't not respond to the ballot. apologies. i'll attend
Alex: didn't notice I needed to vote until ballot closed
Tom: I will attend by phone, if not in person
Adrian: I will be there as well
Anish: me too
Krishna Raman (Red Hat): I will attend by phone as well
Martin: Anish, Adrian, Tom (maybe)
Martin: will update Duncan with numbers
TOPIC: Next weeks meeting:
Martin: I will be on vacation next week - need pro tem chair
Adrian: I will volunteer
Martin: I will try to set up the agenda, etc.
No objections for Adrian to act as pro tem chair for the 29th May meeting.
TOPIC: Project Status
Martin: we sill have a logjam
... we are slipping
... we were planning on doing our first PR in the beginning of June
... that is 1.5 weeks away
... doesn't look like we are going to make that
... seems that the blocking issue is PDP
... do the people involved with that issue have any estimate on when they will wrap this up?
Adrian: PDP should only take 2 more weeks
Anish Karmarkar: issue 3, strictly speaking, isn't about PDP format
Re-asses timeline in two weeks.
TOPIC: Editing Team Update
Adrian: no new drafts
... did we close an issue on 5/8? (8th of may to us Europeans)
Gil: yes, issue on "created" CAMP-58
Adrian: so we can produce a draft with that resolution
TOPIC: New Issues
None
TOPIC: Issues
CAMP 3, 4, 65
Martin: can someone summarize what has been happening on the ad hoc calls?
Alex: (summarizing) we have components and requirements
... contention whether requirements are typed or not
... need another work session
Adrian: next week is short due to U.S. holiday
Alex: tomorrow? in the morning US time?
Tom: there is an SCA call tomorrow
Alex: 2pm eastern?
Krishna: I would like to be on this call
All: 3pm Eastern
Alex: I will send out an invite
Anish Karmarkar i, very likely, won't be able to do that, but go ahead without me. I'm in UTC+5:30 TZ right now
TOPIC: CAMP-3
Anish: CAMP-3 isn't directly related to CAMP-4/CAMP-65
... we could discuss this
Adrian: agreed
Martin: is there something concrete to discuss, or is this directional?
Anish: directional as I don't want to waste time editing when there isn't consensus on the direction
... we've been back and forth on this a couple of times
Martin: can you talk to the directional proposal?
Anish: probably best to talk about my last email
MartinC: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201305/msg00060.html
Adrian: I replied to your email that we should just post the PDP in the body and get back a link to the AT
... did you respond?
Anish: yes, I did
Anish: maybe we should talk about the problem we are trying to solve
... in our spec we talk about how to register a PDP that is already uploaded somewhere
... I was trying to solve the "by value" problem - the "by reference" problem is already solved
... people kept asking "If I'm doing a POST, why can't I include the PDP in the body of that POST?"
... Adrian, are you asking to POST the DP?
Adrian: not necessarily
Anish: complete PDP is in the POST?
Adrian: don't want the Location header of the PDP, want the Location header of the created AT
Anish: (reviews email)
https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201305/msg00060.html
Adrian Otto (Rackspace): depends whether we want to support multiple archive formats (TAR, ZIP, etc).
... Multipart could have JSON that specifies the attached archive file, as a mime encoded part.
Adrian Otto (Rackspace): we would need to use Content-Type to specify which format the archive is in.
Gil: "by reference" allows us to eliminate (2) branch
Adrian: agree with Gil, we don't want to be a blob store
... is goal to eliminate 2-step process, or is goal to provide some way to upload PDP?
Anish: we don't know how big PDPs may be and we don't know how long the register operation may take
... if combo upload+register is the only way to register, things could get difficult
... 2-stop process breaks operation into more manageable chunks
... but there are plenty of protocols for uploading and managing content
... agree that ability to do "by reference" eliminates need for (2) - but thought there may be people that still wanted that
Adrian Otto (Rackspace): Chunked encoding is a common technique for handling large POST requests.
Jacques (Fujitsu): CAMP does not have to choose *one* way to upload PDPs. CAMP could describe 2 or 3 preferred ways.
.... Providers would advertise which ones they support. Consumers can always adapt.
Adrian: need way to specify the format of the PDP
Anish: I support "POST and return location of AT"
Ashok: I'm going to argue for a separate register operation
... register is where your requirements get matched up with platform components
... this could get complicated (specialized tooling, etc.)
... I want the requirement/capability matching in its own operation
Anish: what do you mean by a separate register operation?
... we already have a separate register operation in the spec (by value)
Adrian Otto (Rackspace): he meant by reference.
... if you eliminate (2) from my directional proposal, you have an inline/by-value register operation
Ashok: I don't want the upload and the register operation to be bound together
Anish: you don't want a single "here are the bits, please register them"
Ashok: I want to (a) upload then (b) register
Anish: we have that in the spec today, you use the "pdpURI" to specify where you have uploaded the PDP
Tom: are we just talking about how you get the URI for the POST?
Anish: "register" is an operation in our lifecycle that results in the creation of an Assembly Template
Ashok: this is where requirements and capabilities get matched up
Adrian: do AssemblyTemplates have an attribute that shows you where the PDP came from?
Tom: not now
Anish: we have discussed the need for such a thing
Adrian: if we had that, you could work with that to re-register the same PDP
Adrian Otto (Rackspace): Is an Assembly Template required to include a pdpUri indicating what PDP was used to create it?
... If so, you could POST by value, and be able to re-try the register operation if it fails, adjust it with PATCH, try again, etc.
Anish: if I want to clone an AT and customize it, that would help
Anish Karmarkar: you *may* do the req-cap resolution at registration time
Anish Karmarkar: but you should not have to
Anish Karmarkar: you may do it just before start
Anish Karmarkar: or you may leave it unsatisfied and have it done manually by the admin
(misc. discussion)
(discussion about when the resolution of requirements against capabilities occur)
Anish: seems like we are honing in on option (3)
... anybody like option (1)?
Gil: only thing to say for it is that it is easier to write simple HTML that does that
Jacques: why do we need to specify a single way to upload?
Anish: question is about the format of the request to "register by value"
... more choices == less interoperability
... I would prefer 1
Jacques: 10 request format is too many, but 2 might not be
Gil: Alex pointed out that (1) is a pain for non-browser clients. Let's go with (3) and , if we've got it wrong, we can refactor.
Jacques: if we agree on one option - it should not preclude doing others
Jacques (Fujitsu): ... I do not favor (1) more than others - I understand the trade-offs.
Anish: We have extensibility all over this spec. Nothing in my proposal would prohibit supporting other request formats.
Adrian takes over as Chair as Martin is having VOIP woes.
MartinC: thanks adrian - i can hear ok but obviously no one can hear me properly
TOPIC: CAMP-65
Adrian Otto (Rackspace): https://tools.oasis-open.org/issues/browse/CAMP-65
Gil: Oracle talked about the idea of multiple PDP formats (ZIP, GZIP, TAR, TGZ, etc.) and we think it is overkill
Ashok: which one/
Gil: use a spinner - it is inconsequential which one you pick - as long as you pick one
Adrian: TAR is lowest common denominator
... if you are picking one, use that
TOPIC: CAMP-17
Tom: we could quickly go through the diagrams
Adrian: OK -let's do that
MartinC: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49137/CampIssue17-ModelChanges-r1.docx
MartinC: i like the meta-data bit - most of teh extension points are here
MartinC: i thought m..m considered harmful
AOB:
Stragglers: no squeaks
Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]