Re: Offer operation reconciliation discussion notes

> What are the next steps for moving this forward, Jie James, the next step is to create a design doc for this. Looks like we're aligned on the high level approach. On Wed, Aug 30, 2017 at 11:40 AM, Jie Yu wrote: > + Gaston and Greg > > Who might be working on this. > >

Re: Offer operation reconciliation discussion notes

+ Gaston and Greg Who might be working on this. On Tue, Aug 29, 2017 at 6:59 AM, James DeFelice wrote: > What are the next steps for moving this forward, Jie? I'm very interested > in seeing status updates for operations land sooner than later. > > On Wed, Aug 23, 2017 at

Re: Offer operation reconciliation discussion notes

Please can the "reason" be the reason for the failure and NOT the reason the message was sent, e.g. "RECONCILIATION" On Wed, Aug 23, 2017 at 1:58 PM Yan Xu wrote: > Yeah a reason for failed operations is probably useful for all resource > operations. It looks like the

Re: Offer operation reconciliation discussion notes

Yeah a reason for failed operations is probably useful for all resource operations. It looks like the task-style status update is still the best approach. --- @xujyan On Wed, Aug 23, 2017 at 11:40 AM, Jie Yu wrote: > We should continue the

Re: Offer operation reconciliation discussion notes

We should continue the discussion here: I think I forgot to mention one important reason that I went for the operation based reconciliation API proposal. For new operations like CREATE_VOLUME/CREATE_BLOCK, not only we need to know the end result (the resources) if it's successful, we also need to

Offer operation reconciliation discussion notes

Hi, We had a discussion on some very early proposal (see the attached slides) on providing feedback for offer operations (e.g., CREATE/DESTORY, RESERVE/UNRESERVE, etc.) with a bunch of folks from the community. Here are the notes I captured in the meeting: - One alternative approach