| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit makes a set of small adjustments to examples.
- Rework some of the comments to be more clear.
- Add links to the original source tree file.
- Rename some of the examples to make it clear the
concept the example is intented to show.
- Move some common example functionality to the
example utility file.
Change-Id: I858e0dbf72fe8cb40a05bfdbb0857720ffb71c7f
|
| |
|
|
|
|
|
|
|
| |
Remove line containing
comment - # vim: tabstop=4 shiftwidth=4 softtabstop=4
Change-Id: I7581cc88b8de433d5609ed06c6570b0b45c13573
Closes-Bug:#1229324
|
| |
|
|
| |
Change-Id: I6f332f01d197c6ba1b02de1145714718f8aea6fb
|
| |
|
|
| |
Change-Id: I3389554dfbe67aeb8c22a78b1929798988e57bc0
|
| |
|
|
| |
Change-Id: Ic05af4d5defe26b729bd7dda3f04b790509bb155
|
| |
|
|
|
|
|
|
|
|
|
| |
Match the requirements for taskflow with
the openstack requirements (note the upstream
requirements are missing 'futures' and 'networkx')
and update the new hacking violations that were
detected due to the hacking requirement version
bump.
Change-Id: I8d1326cf2a8b1ea062f5e9aacd0c4f8261c6531a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously to run a flow client code had to put together the flow,
an engine, logbook, flowdetail, and storage backend. This commit
adds two helper functions, run() and load(), so that simplest usecase
now looks like
taskflow.engines.run(flow)
Client code may also provide configuration for storage and engine if
needed, but if not needed it just works with defaults.
Engines are loaded via stevedore, as drivers in 'taskflow.engines'
backend. Now three entry points are defined in that namespace:
- 'default', for SingleThreadedActionEngine, used by default;
- 'serial', as another synonym for SingleThreadedActionEngine;
- 'parallel', for MultiThreadedActionEngine.
Closes-bug: #1224726
Change-Id: I7f4cb5c8ff7f5f12831ddd0952c202d2fd8cd6ef
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to move away from the existing flows having their
own implementation of running, start moving the existing
flows to be patterns that only structure tasks (and impose
constraints about how the group of tasks can run) in useful
ways.
Let the concept of running those patterns be handled by an
engine instead of being handled by the flow itself. This
will allow for varying engines to be able to run flows in
whichever way the engine chooses (as long as the constraints
set up by the flow are observed).
Currently threaded flow and graph flow are broken by this
commit, since they have not been converted to being a
structure of tasks + constraints. The existing engine has
not yet been modified to run those structures either, work
is underway to remediate this.
Part of: blueprint patterns-and-engines
Followup bugs that must be addressed:
Bug: 1221448
Bug: 1221505
Change-Id: I3a8b96179f336d1defe269728ebae0caa3d832d7
|
| |
|
|
| |
Change-Id: If7154019f1cb5e723069ff35f6301fce048323b5
|
| |
|
|
|
|
|
|
|
| |
We'd like library interface to be nice and simple, which implies that
it does not involve too many underscores. Also 'execute' matches with
'revert' nicely.
Suggested-by: Anastasia Karpinska <akarpinska@griddynamics.com>
Change-Id: Iea72e6230a32665b4236a1e7d1dcc41bd56d0418
|
|
|
Add a simple linear calculator example which will
be given a few sets of tasks to do and some initial provided
data and then combine the correct ordering of that tasks
to produce an output result that then can be extracted.
Change-Id: Ica84dff67ce0a6b7699cd98effebc85c7dbd4cb2
|
