x/anvil
Code Issues Proposed changes

Fix typos/grammar in two doc files

Browse Source 
Change-Id: Ie798bbb17edcd4ab3da2beccbed5d259a9239296
This commit is contained in:
Éric Araujo 2014-01-16 05:39:41 -05:00
parent 5c25c7c51b
commit fa60f5a608
2 changed files with 24 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
docs/source/topics/dev_notes/addingowndistro.rst
View File

@ -5,44 +5,45 @@ Adding your own distribution
====
This little ``HOWTO`` can be used by those who wish to
add-on to anvil to be able to support there own distribution
add-on to anvil to be able to support their own distribution
or unsupported operating system (so that it can be
supported).
Diving in!
----------
First you have to have a little background on `anvil` and
how it operates. So lets dive in and learn a little on how
First you have to have a little background on `anvil` and
how it operates. So let's dive in and learn a little on how
we can add in your own distribution support.
**smithy**
The main shell script that bootstraps the needed dependencies
for anvil to be able to start (including items such as termcolor,
progressbar and netifaces). The code here is written in bash shell
script so that it can execute in an enviornment without the
script so that it can execute in an environment without the
needed prerequisites.
**When to adjust:** Adjust the boot strapping functions in this file to install
**When to adjust:** Adjust the bootstrapping functions in this file to install
any needed prerequisites for your operating system to run anvil. Look at how we
are bootstrapping rhel (and how we are detecting rhel) for an example.
**conf/distros**
This set of yaml files contains definitions for what packages,
This set of yaml files contains definitions for what packages,
what pip to package mappings and what code entrypoints are used
when setting up a given component. The critical key here is the
``platform_pattern`` key which is used as a regular expression to
determine if the provided yaml file will work in the given running
distribution. Other keys are used to identify which packaging class
to use (ie ``packager_name``) and how to map a component name to
its action classes (ie ``action_classes/install`` will be constructed
its action classes (i.e. ``action_classes/install`` will be constructed
when an install action occurs). The ``commands`` section can be used to
`house` arbitrary commands which may vary between operating systems (such
as the ``pip`` executable name)
**When to adjust the distro:** If a suitable distribution already exists (which may be the case
for many rhel variants), just go ahead and add-on to the regular expression your pattern. Ensure
that your regular expressionmatches the output of the following command: ``python -c "import platform; print(platform.platform())"``
that your regular expression matches the output of the following command:
``python -c "import platform; print(platform.platform())"``
which is what anvil uses internally to match a given yaml file to a given distribution.
**When to add a new file:** If no suitable distribution exists (which may be the case
@ -53,20 +54,20 @@ we can add in your own distribution support.
**anvil/distros**
These are typically subclasses of components that may override generic functionality to correct
for a given distribution doing or requiring something different to occur before/after or during
an install or other action.
an install or other action.
**When to adjust:** Feel free to add-on your own subclasses here as needed to handle any special actions
that your new distribution may require and make sure you reference those classes/entrypoints
that your new distribution may require and make sure you reference those classes/entrypoints
in your **conf/distros** yaml file so that the correct subclass will be used. The rhel distro has a good set
of examples that overload various key points so that rhel can work correctly.
**anvil/packaging**
The modules in this folder will be referenced in your **conf/distros** yaml file and will control
how to install packages (ie using yum and pip) and how to uninstall those same packages. This code will also
get activated when a 'package' action occurs which currently will cause the necessary actions to occur to
create a rpm ``spec`` file which can be used with the ``rpmbuild`` command.
how to install packages (i.e. using yum and pip) and how to uninstall those same packages. This code will also
get activated when a 'package' action occurs which currently will cause the necessary actions to occur to
create a RPM ``spec`` file which can be used with the ``rpmbuild`` command.
**When to adjust:** If needed it should be simple to look at the packaging interface and add your own.
After adding make sure you reference them in your **conf/distros** yaml file so that the correct subclass will be used. If you are going
to want to create package files from the installed code then you will need to hook-in to a file similar
to the rpm module that exists there.
to the RPM module that exists there.

18
docs/source/topics/summary.rst
View File

@ -4,22 +4,22 @@
Summary
===============
Anvil is a forging tool to help build OpenStack components and there
Anvil is a forging tool to help build OpenStack components and their
dependencies into a complete package-oriented system.
It automates the git checkouts the OpenStack components, analyzes & builds there
dependencies and the components themselves into packages. It then can install
It automates the git checkouts of the OpenStack components, analyzes & builds their
dependencies and the components themselves into packages. It can then install
from the package repositories it created, perform configuration and start, stop,
restart and uninstall the components and there dependencies as a complete system.
restart and uninstall the components and their dependencies as a complete system.
It allows a developer to setup environment using the automatically created packages
It allows a developer to setup an environment using the automatically created packages
(and dependencies) with the help of anvil configuring the components to work
correctly for the developers needs. After the developer has tested out their
features or changes they can then stop the OpenStack components, uninstall the
correctly for the developer's needs. After the developer has tested out their
features or changes they can stop the OpenStack components, uninstall the
packages and bring back their system to a pre-installation/pre-anvil state.
The distinguishing part from devstack_ (besides being written in python and not
shell), is that after building those packages (currently rpms) the same packages
The distinguishing part from devstack_ (besides being written in Python and not
shell), is that after building those packages (currently RPMs) the same packages
can be used later (or at the same time) to actually deploy at a larger scale using
tools such as chef_, salt_, or puppet_ (to name a few).