anvil/docs/source/topics/features.rst

Features

• Multi distribution installs via a single tool
• A set of configuration files (in yaml format) that shows common/component/distribution configurations

- Supports the following actions on the various of OpenStack components.

1. Installing: downloading, installing dependencies (pypi and distribution packaging specifics) and configuring component files and symlinks
2. Starting: starting of the components sub-programs with the needed configuration via the common daemon model (with a pid, stderr and stdout file set)
3. Stopping: stopping of the previously started components
4. Uninstalling: removing installed configuration, undoing of installed files/directories, and removing of packaging to get back to an initial 'clean' state
5. Testing: running each components unit tests (and in the future performing a simple set of integration tests)
6. Packaging: creating a basic set of packages for the desired distributions
7. Status: checking the status of the running components sub-programs

• Supports dry-run mode (to see what would happen)
• Tracking of all actions taken by a component via tracking like files (mainly for uninstall, but useful for analysis)
• Written in python so it matches the style of other OpenStack components.

- Code decoupling (thus encouraging re-use by others)

1. Components/actions are isolated as individual classes (and so on). This decouples component installation from the action and decoupling of the commands/packages/pips the component will use to install itself from the component...
2. Supports installation personas that define what is to be installed, thus decoupling the 'what' from the 'how'.

- Extensively documented distribution specifics (also decoupled)

1. See the conf/distros directory for examples

• Progress resuming so that when you install you can ctrl+c ./smithy and resume later (where applicable).

- Extensive logging (and debug mode)

1. All commands ran are logged, all configuration files read/write...

- Package/pip tracking

1. Each components pip-requires and test-requires are mapped to (and checked against) the distribution package or a pip package which can provide that requirement.
2. This allows for installations to use the distributions native packages (when applicable) as well as provides a list of pips which should be packaged by that distribution before the given OpenStack release is stabilized.
3. This also allows for releases anvil to track exactly how (and what packages and what mapping) is needed for a given anvil release tag (which will map to a given OpenStack release tag), thus freezing what is needed for that release.