<div dir="ltr">Do we know what is so hated about the glance task API? Tasks and entity queues give the required exclusion, if you accept that tasks can fail if previous tasks in the queue can cause things to be pulled out from under it.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 29 June 2015 at 17:22, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@outlook.com" target="_blank">harlowja@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is the V3 api going to be a task API like nova desires (someday it will happen in nova to)?<br>
<br>
If so then it seems like a natural fit for this (aka submit a request, get back a task json object that can be polled on, one of those polling states it reports back is 'WAITING' or 'BLOCKED' or ...)<br>
<br>
Dulko, Michal wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
That’s right, it might be painful. V3 API implememtation would be also a<br>
hard, because then we would need different manager behavior for requests<br>
from V2 and V3… So maybe we need some config flag with deprecation<br>
procedure scheduled?<br>
<br></span>
*From:*Duncan Thomas [mailto:<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>]<br>
*Sent:* Monday, June 29, 2015 2:46 PM<br>
*To:* OpenStack Development Mailing List (not for usage questions)<br>
*Subject:* Re: [openstack-dev] [cinder][oslo] Locks for create from<span class=""><br>
volume/snapshot<br>
<br>
On 29 June 2015 at 15:23, Dulko, Michal <<a href="mailto:michal.dulko@intel.com" target="_blank">michal.dulko@intel.com</a><br></span><span class="">
<mailto:<a href="mailto:michal.dulko@intel.com" target="_blank">michal.dulko@intel.com</a>>> wrote:<br>
<br>
    There’s also some similar situations when we actually don’t lock on<br>
    resources. For example – a cgsnapshot may get deleted while creating<br>
    a consistencygroup from it.<br>
<br>
     From my perspective it seems best to have atomic state changes and<br>
    state-based exclusion in API. We would need some kind of<br>
    currently_used_to_create_snapshot/volums/consistencygroups states to<br>
    achieve that. Then we would be also able to return VolumeIsBusy<br>
    exceptions so retrying a request would be on the user side.<br>
<br>
I'd agree, except that gives quite a big behaviour change in the<br>
tenant-facing API, which will break clients and scripts. Not sure how to<br>
square that circle... I'd say V3 API except Mike might kill me...<br>
<br></span>
__________________________________________________________________________<span class=""><br>
OpenStack Development Mailing List (not for usage questions)<br></span><span class="">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</span></blockquote>
<br>
__________________________________________________________________________<span class="im HOEnZb"><br>
OpenStack Development Mailing List (not for usage questions)<br></span><div class="HOEnZb"><div class="h5">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Duncan Thomas</div>
</div>