This commit is part of a series to retire the Packaging Deb
project. Step 2 is to remove all content from the project
repos, replacing it with a README notification where to find
ongoing work, and how to recover the repo if needed at some
future point (as in
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project).
Change-Id: I9fce77de093a2922ef3cc9484cc2880cec812cba
The rest of the code single quotes it so this code might
as well to (to follow the existing logging style).
Change-Id: Ibd2a8b49d11dcd32d9168a96950e08616ac1c54d
When testing Ironic with Futurist I found out that whe number of tasks
seriously exceed number of possible workers, the conductor goes into loop
retrying them and mostly stops reacting. Insert a short random delay before
retrying, so that the executor has chances of processing tasks before we
through more on it. Also recalculate the "now" value, as submitting a task
could take some time.
Change-Id: I8e45ddf7c87cf130028fc9fe937691968db17ee9
We say we raise when backlog goes past max size, but actually we raise when
backlogs tries to reach the max size. This patch fixes reject_when_reached to
actually allow max size to be reached, but no more.
Also adding missing unit test for reject_when_reached.
Change-Id: Ide835b6e5fd15171b9bebc7ca112b84423b39fab
Now that shutdown can be skipped (which would previously
wait for all submitted futures to be finished) we need to have
a way to know that all submitted futures have been finished
before our run method returns.
A simple countdown barrier/latch does this so ensure that we use
it in the periodic run loop to be able to only return from the
run loop when no active futures are in progress.
Change-Id: Ia3dd84ebfe2416060aaf5113cc8310a23919a3f9
The current behaviour of always shutting down the executor makes it troublesome
to use a precreated executor and makes completely impossible to use the same
executor for running PeriodicWorker itself (which is what I'm doing for Ironic).
This change adds a base class ExecutorFactory with 'shutdown' attribute
defaulting to True. It also adds a new class ExistingExecutor that takes an
existing executor and sets shutdown to False.
Change-Id: I6a574ba77439aeee46b9e154aa059098ec087308
When a future is cancelled and the result is fetched
it will raise a CancelledError which is quite useful to
be able to catch.
So to enable catching that specific exception expose it
in futurist __init__.py so that people can easily catch
it just by catching futurist.CancelledError and handling
the outcome of that.
Change-Id: I7bc1838aadcbb8cd0d635da83bb1e1b1ec761e89
To illustrate the fact that we can share code seemlessly with different
scheduling behavior, at ease with futurist. Moreover, the example code
shows how the concurrency/parallel execution can be observed from same
code, just by changing the executor. This demonstrates the power of
futurist interfaces.
Change-Id: Ifdd2a89c8cd9d06f54900960a69debc41b42ab3d
Sometimes it might be required to pass the same arguments to all
tasks collected by create (e.g. ironic passes context).
Change-Id: I7992c59e76b8b7b9101501d75cb7a53d982d07fd
Currently PeriodicWorker fails if executor raises RejectedSubmission.
This change makes it catch RejectedSubmission and RuntimeError from
executor.submit and reschedule the task as soon as possible.
Change-Id: Ifff7850c9b44ee076f428ed3a613a13e182a549d
Closes-Bug: #1532255
People implementing their own periodic tasks collection (as opposed
to using PeriodicWorker.create) need to know if something is
a periodic task without inspecting its private attributes.
This function returning True means something is safe to add
to a PeriodicWorker (will not raise ValueError).
Change-Id: Iee8da601b1bc994188c58ca459574a466270bf63
Python 3.3/2.6 support would be dropped by
Infra team from mitaka,CI would no longer be testing it,
so projects should drop it also.
Change-Id: Iaabbd65c53d71f5aa19bdca29c14ba5248d78c27
The rest of the code single quotes it so this code might
as well to (to follow the existing logging style).
Change-Id: Ibd2a8b49d11dcd32d9168a96950e08616ac1c54d
When testing Ironic with Futurist I found out that whe number of tasks
seriously exceed number of possible workers, the conductor goes into loop
retrying them and mostly stops reacting. Insert a short random delay before
retrying, so that the executor has chances of processing tasks before we
through more on it. Also recalculate the "now" value, as submitting a task
could take some time.
Change-Id: I8e45ddf7c87cf130028fc9fe937691968db17ee9
We say we raise when backlog goes past max size, but actually we raise when
backlogs tries to reach the max size. This patch fixes reject_when_reached to
actually allow max size to be reached, but no more.
Also adding missing unit test for reject_when_reached.
Change-Id: Ide835b6e5fd15171b9bebc7ca112b84423b39fab
Now that shutdown can be skipped (which would previously
wait for all submitted futures to be finished) we need to have
a way to know that all submitted futures have been finished
before our run method returns.
A simple countdown barrier/latch does this so ensure that we use
it in the periodic run loop to be able to only return from the
run loop when no active futures are in progress.
Change-Id: Ia3dd84ebfe2416060aaf5113cc8310a23919a3f9
The current behaviour of always shutting down the executor makes it troublesome
to use a precreated executor and makes completely impossible to use the same
executor for running PeriodicWorker itself (which is what I'm doing for Ironic).
This change adds a base class ExecutorFactory with 'shutdown' attribute
defaulting to True. It also adds a new class ExistingExecutor that takes an
existing executor and sets shutdown to False.
Change-Id: I6a574ba77439aeee46b9e154aa059098ec087308
When a future is cancelled and the result is fetched
it will raise a CancelledError which is quite useful to
be able to catch.
So to enable catching that specific exception expose it
in futurist __init__.py so that people can easily catch
it just by catching futurist.CancelledError and handling
the outcome of that.
Change-Id: I7bc1838aadcbb8cd0d635da83bb1e1b1ec761e89
To illustrate the fact that we can share code seemlessly with different
scheduling behavior, at ease with futurist. Moreover, the example code
shows how the concurrency/parallel execution can be observed from same
code, just by changing the executor. This demonstrates the power of
futurist interfaces.
Change-Id: Ifdd2a89c8cd9d06f54900960a69debc41b42ab3d
Sometimes it might be required to pass the same arguments to all
tasks collected by create (e.g. ironic passes context).
Change-Id: I7992c59e76b8b7b9101501d75cb7a53d982d07fd
Currently PeriodicWorker fails if executor raises RejectedSubmission.
This change makes it catch RejectedSubmission and RuntimeError from
executor.submit and reschedule the task as soon as possible.
Change-Id: Ifff7850c9b44ee076f428ed3a613a13e182a549d
Closes-Bug: #1532255
Tony Breeds