Fix typos/grammar in two doc files
Change-Id: Ie798bbb17edcd4ab3da2beccbed5d259a9239296
This commit is contained in:
parent
5c25c7c51b
commit
fa60f5a608
@ -5,7 +5,7 @@ Adding your own distribution
|
|||||||
====
|
====
|
||||||
|
|
||||||
This little ``HOWTO`` can be used by those who wish to
|
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
|
or unsupported operating system (so that it can be
|
||||||
supported).
|
supported).
|
||||||
|
|
||||||
@ -13,17 +13,17 @@ Diving in!
|
|||||||
----------
|
----------
|
||||||
|
|
||||||
First you have to have a little background on `anvil` and
|
First you have to have a little background on `anvil` and
|
||||||
how it operates. So lets dive in and learn a little on how
|
how it operates. So let's dive in and learn a little on how
|
||||||
we can add in your own distribution support.
|
we can add in your own distribution support.
|
||||||
|
|
||||||
**smithy**
|
**smithy**
|
||||||
The main shell script that bootstraps the needed dependencies
|
The main shell script that bootstraps the needed dependencies
|
||||||
for anvil to be able to start (including items such as termcolor,
|
for anvil to be able to start (including items such as termcolor,
|
||||||
progressbar and netifaces). The code here is written in bash shell
|
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.
|
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
|
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.
|
are bootstrapping rhel (and how we are detecting rhel) for an example.
|
||||||
|
|
||||||
@ -35,14 +35,15 @@ we can add in your own distribution support.
|
|||||||
determine if the provided yaml file will work in the given running
|
determine if the provided yaml file will work in the given running
|
||||||
distribution. Other keys are used to identify which packaging class
|
distribution. Other keys are used to identify which packaging class
|
||||||
to use (ie ``packager_name``) and how to map a component name to
|
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
|
when an install action occurs). The ``commands`` section can be used to
|
||||||
`house` arbitrary commands which may vary between operating systems (such
|
`house` arbitrary commands which may vary between operating systems (such
|
||||||
as the ``pip`` executable name)
|
as the ``pip`` executable name)
|
||||||
|
|
||||||
**When to adjust the distro:** If a suitable distribution already exists (which may be the case
|
**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
|
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.
|
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
|
**When to add a new file:** If no suitable distribution exists (which may be the case
|
||||||
@ -62,11 +63,11 @@ we can add in your own distribution support.
|
|||||||
|
|
||||||
**anvil/packaging**
|
**anvil/packaging**
|
||||||
The modules in this folder will be referenced in your **conf/distros** yaml file and will control
|
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
|
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
|
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.
|
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.
|
**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
|
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 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.
|
||||||
|
@ -4,22 +4,22 @@
|
|||||||
Summary
|
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.
|
dependencies into a complete package-oriented system.
|
||||||
|
|
||||||
It automates the git checkouts the OpenStack components, analyzes & builds there
|
It automates the git checkouts of the OpenStack components, analyzes & builds their
|
||||||
dependencies and the components themselves into packages. It then can install
|
dependencies and the components themselves into packages. It can then install
|
||||||
from the package repositories it created, perform configuration and start, stop,
|
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
|
(and dependencies) with the help of anvil configuring the components to work
|
||||||
correctly for the developers needs. After the developer has tested out their
|
correctly for the developer's needs. After the developer has tested out their
|
||||||
features or changes they can then stop the OpenStack components, uninstall the
|
features or changes they can stop the OpenStack components, uninstall the
|
||||||
packages and bring back their system to a pre-installation/pre-anvil state.
|
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
|
The distinguishing part from devstack_ (besides being written in Python and not
|
||||||
shell), is that after building those packages (currently rpms) the same packages
|
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
|
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).
|
tools such as chef_, salt_, or puppet_ (to name a few).
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user