mirror of
https://github.com/kevingruesser/bootstrap-vz.git
synced 2025-08-22 18:00:35 +00:00
f62c8ade99
Up until now I didn't see the point of using spaces for indentation. However, the previous commit (a18bec3) was quite eye opening. Given that python is an indentation aware language, the amount of mistakes that went unnoticed because tabs and spaces were used at the same time (tabs for indentation and spaces for alignment) were unacceptable. E101,W191 have been re-enable in the tox flake8 checker and the documentation has been modified accordingly. The following files have been left as-is: * bootstrapvz/common/assets/extlinux/extlinux.conf * bootstrapvz/common/assets/init.d/expand-root * bootstrapvz/common/assets/init.d/generate-ssh-hostkeys * bootstrapvz/common/assets/init.d/squeeze/generate-ssh-hostkeys * bootstrapvz/plugins/docker_daemon/assets/init.d/docker * bootstrapvz/providers/ec2/assets/bin/growpart * bootstrapvz/providers/ec2/assets/grub.d/40_custom * bootstrapvz/providers/ec2/assets/init.d/ec2-get-credentials * bootstrapvz/providers/ec2/assets/init.d/ec2-run-user-data * docs/_static/taskoverview.coffee * docs/_static/taskoverview.less * tests/unit/subprocess.sh
49 lines
2 KiB
ReStructuredText
49 lines
2 KiB
ReStructuredText
How bootstrap-vz works
|
|
----------------------
|
|
|
|
Tasks
|
|
~~~~~
|
|
At its core bootstrap-vz is based on tasks that perform units of work.
|
|
By keeping those tasks small and with a solid structure built around
|
|
them a high degree of flexibility can be achieved. To ensure that
|
|
tasks are executed in the right order, each task is placed in a
|
|
dependency graph where directed edges dictate precedence. Each task is
|
|
a simple class that defines its predecessor tasks and successor tasks
|
|
via attributes. Here is an example:
|
|
|
|
.. code-block:: python
|
|
|
|
class MapPartitions(Task):
|
|
description = 'Mapping volume partitions'
|
|
phase = phases.volume_preparation
|
|
predecessors = [PartitionVolume]
|
|
successors = [filesystem.Format]
|
|
|
|
@classmethod
|
|
def run(cls, info):
|
|
info.volume.partition_map.map(info.volume)
|
|
|
|
In this case the attributes define that the task at hand should run
|
|
after the ``PartitionVolume`` task — i.e. after volume has been
|
|
partitioned (``predecessors``) — but before formatting each
|
|
partition (``successors``).
|
|
It is also placed in the ``volume_preparation`` phase.
|
|
Phases are ordered and group tasks together. All tasks in a phase are
|
|
run before proceeding with the tasks in the next phase. They are a way
|
|
of avoiding the need to list 50 different tasks as predecessors and
|
|
successors.
|
|
|
|
The final task list that will be executed is computed by enumerating
|
|
all tasks in the package, placing them in the graph and
|
|
`sorting them topologically <http://en.wikipedia.org/wiki/Topological_sort>`_.
|
|
Subsequently the list returned is filtered to contain only the tasks the
|
|
provider and the plugins added to the taskset.
|
|
|
|
|
|
System abstractions
|
|
~~~~~~~~~~~~~~~~~~~
|
|
There are several abstractions in bootstrap-vz that make it possible
|
|
to generalize things like volume creation, partitioning, mounting and
|
|
package installation. As a rule these abstractions are located in the
|
|
``base/`` folder, where the manifest parsing and task ordering algorithm
|
|
are placed as well.
|