Open Stack

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.

On 29 June 2015 at 17:22, Joshua Harlow <harlowja at outlook.com> wrote:

> Is the V3 api going to be a task API like nova desires (someday it will
> happen in nova to)?
>
> 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 ...)
>
> Dulko, Michal wrote:
>
>> That’s right, it might be painful. V3 API implememtation would be also a
>> hard, because then we would need different manager behavior for requests
>> from V2 and V3… So maybe we need some config flag with deprecation
>> procedure scheduled?
>>
>> *From:*Duncan Thomas [mailto:duncan.thomas at gmail.com]
>> *Sent:* Monday, June 29, 2015 2:46 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [cinder][oslo] Locks for create from
>> volume/snapshot
>>
>> On 29 June 2015 at 15:23, Dulko, Michal <michal.dulko at intel.com
>> <mailto:michal.dulko at intel.com>> wrote:
>>
>>     There’s also some similar situations when we actually don’t lock on
>>     resources. For example – a cgsnapshot may get deleted while creating
>>     a consistencygroup from it.
>>
>>      From my perspective it seems best to have atomic state changes and
>>     state-based exclusion in API. We would need some kind of
>>     currently_used_to_create_snapshot/volums/consistencygroups states to
>>     achieve that. Then we would be also able to return VolumeIsBusy
>>     exceptions so retrying a request would be on the user side.
>>
>> I'd agree, except that gives quite a big behaviour change in the
>> tenant-facing API, which will break clients and scripts. Not sure how to
>> square that circle... I'd say V3 API except Mike might kill me...
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150629/4539b50d/attachment.html>