OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Draft Minutes 22nd May 2013

Minutes 22nd May 2013


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


    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


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
         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)
     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


    Stragglers: no squeaks

Meeting adjourned

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]