kevinheyer/bootstrap-vz
1
0
Fork 0
mirror of https://github.com/kevingruesser/bootstrap-vz.git synced 2025-08-22 18:00:35 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Move developers intro into bootstrapvz/ as README

Browse source
This commit is contained in:
Anders Ingemann 2015-04-16 23:26:21 +02:00
parent e3f511f8e8
commit 03f8d231e2
2 changed files with 52 additions and 51 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

49
bootstrapvz/README.rst Normal file
View file

@ -0,0 +1,49 @@
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:
::
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.

54
docs/developers/index.rst
View file

@ -1,61 +1,13 @@
Developers
============
==========
.. toctree::
:maxdepth: 1
:hidden:
contributing
switches
api/index
taskoverview
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:
::
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.
.. include:: ../../bootstrapvz/README.rst