Open Stack

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