Sound then you ask, how does such a thing occur, well ask yourself how
you'd know not to scheduler a contractor on the 23rd when your house
gets demolished on the 21st. You'd probably be keeping a piece of paper
around that says XYZ task is scheduled on ABC date, and before adding a
new one you'd make sure that it doesn't conflict with any of the planned
ones. Sounds like something that could be stored in a database (or a
text file, or other...); of course it can get a-lot more complex (aka
jeez that sounds like a query planner in way) but let's not go there
right now :-P
Joshua Harlow wrote:
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 <[email protected]
<mailto:[email protected]>> 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:[email protected]
<mailto:[email protected]>]
*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 <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
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:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
