Open Stack

Duncan Thomas wrote:
> 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.

Sounds like certain tasks shouldn't of been accepted in the first place 
then no? Sounds like before acceptance of a piece of work there needs to 
be some verification that what is being requested doesn't conflict with 
what is underway/planned.

After all you don't try to hire a contractor to fix your plumbing on the 
23rd of the month if your house is scheduled to be demolished on the 
21st (analogies ftw)...

-Josh

>
> On 29 June 2015 at 17:22, Joshua Harlow <harlowja at outlook.com
> <mailto: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
>         <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>
>         <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Duncan Thomas
>
> __________________________________________________________________________
> 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