Rename config => system-config in docs
We are renaming the openstack-infra/config repo to openstack-infra/system-config. This patch edits the docs files. Change-Id: Ic594f1b5438a400fb6c1071c3045adb7a0b7e441
This commit is contained in:
Anita Kuno
parent
864d6a4e89
commit
8549f5d29e
|
|
@ -18,7 +18,7 @@ Documentation
|
|||
==============
|
||||
|
||||
The documentation presented at http://ci.openstack.org comes from
|
||||
git://git.openstack.org/openstack-infra/config repo's docs/source. To
|
||||
git://git.openstack.org/openstack-infra/system-config repo's docs/source. To
|
||||
build the documentation use
|
||||
|
||||
$ tox -evenv python setup.py build_sphinx
|
||||
|
|
|
|||
|
|
@ -51,7 +51,8 @@ master_doc = 'index'
|
|||
project = u'OpenStack Project Infrastructure'
|
||||
copyright = Markup(u'2012-2014, OpenStack Infastructure Team'
|
||||
u' - see the <a href="https://git.openstack.org/cgit/'
|
||||
u'openstack-infra/config/">config git repo</a> for details')
|
||||
u'openstack-infra/system-config/">system-config git repo'
|
||||
u'</a> for details')
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
|
|
|
|||
|
|
@ -39,9 +39,9 @@ def file_role(name, rawtext, text, lineno, inliner,
|
|||
:param content: The directive content for customization.
|
||||
"""
|
||||
|
||||
ref = ('https://git.openstack.org/cgit/openstack-infra/config/tree/%s'
|
||||
% text)
|
||||
linktext = 'config: %s' % text
|
||||
ref = ('https://git.openstack.org/cgit/openstack-infra/'
|
||||
'system-config/tree/%s' % text)
|
||||
linktext = 'system-config: %s' % text
|
||||
node = nodes.reference(rawtext, linktext, refuri=ref, **options)
|
||||
return [node], []
|
||||
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ New Project Creation
|
|||
====================
|
||||
|
||||
Gerrit project creation is now managed through changes to the
|
||||
openstack-infra/config repository. :ref:`jeepyb` handles
|
||||
openstack-infra/system-config repository. :ref:`jeepyb` handles
|
||||
automatically creating any new projects defined in the configuration
|
||||
files.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ At a Glance
|
|||
* :file:`modules/openstack_project/manifests/jenkins.pp`
|
||||
* :file:`modules/openstack_project/manifests/jenkins_dev.pp`
|
||||
:Configuration:
|
||||
* :file:`modules/openstack_project/files/jenkins_job_builder/config/`
|
||||
* :config:`jenkins/jobs`
|
||||
:Projects:
|
||||
* http://jenkins-ci.org/
|
||||
* :ref:`zuul`
|
||||
|
|
@ -37,13 +37,13 @@ Overview
|
|||
|
||||
A large number and variety of jobs are defined in Jenkins. The
|
||||
configuration of all of those jobs is stored in git in the
|
||||
openstack-infra/config repository. They are defined in YAML files
|
||||
that are read by :ref:`jjb` which configures the actual jobs in
|
||||
openstack-infra/project-config repository. They are defined in YAML
|
||||
files that are read by :ref:`jjb` which configures the actual jobs in
|
||||
Jenkins.
|
||||
|
||||
Anyone may submit a change to the openstack-infra/config repository
|
||||
that defines a new job or alters an existing job by editing the
|
||||
appropriate YAML files. See :ref:`jjb` for more information.
|
||||
Anyone may submit a change to the openstack-infra/project-config
|
||||
repository that defines a new job or alters an existing job by editing
|
||||
the appropriate YAML files. See :ref:`jjb` for more information.
|
||||
|
||||
Because of the large number of builds that Jenkins executes, the
|
||||
OpenStack project favors the following approach in configuring Jenkins
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ At a Glance
|
|||
Adding a List
|
||||
=============
|
||||
|
||||
A list may be added by adding it to the ``openstack-infra/config``
|
||||
A list may be added by adding it to the ``openstack-infra/system-config``
|
||||
repository in ``modules/openstack_project/manifests/lists.pp``. For
|
||||
example:
|
||||
|
||||
|
|
|
|||
|
|
@ -36,9 +36,9 @@ apply`` but first some bootstrapping needs to be done.
|
|||
|
||||
First want to install these from puppetlabs' apt repo. We have not yet migrated
|
||||
to puppet 3, so we pin puppet to 2.x. There is a script in the root of the
|
||||
config repository that will setup appropriate pinning and install the puppet
|
||||
client. After that installing the puppetmaster and hiera (used to maintain
|
||||
secrets on the puppet master).
|
||||
system-config repository that will setup appropriate pinning and install the
|
||||
puppet client. After that installing the puppetmaster and hiera (used to
|
||||
maintain secrets on the puppet master).
|
||||
|
||||
Please note: Fedora F19 and Ubuntu Raring and above cannot successfully run an
|
||||
OpenStack-CI puppetmaster due to new Ruby and older Puppet not being
|
||||
|
|
@ -47,7 +47,7 @@ compatible, so be sure to use an older release - e.g. Ubuntu Precise.
|
|||
.. code-block:: bash
|
||||
|
||||
sudo su -
|
||||
git clone https://git.openstack.org/openstack-infra/config /opt/config/production
|
||||
git clone https://git.openstack.org/openstack-infra/system-config /opt/config/production
|
||||
/opt/config/production/install_puppet.sh
|
||||
apt-get install puppetmaster-passenger hiera hiera-puppet
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ At a Glance
|
|||
* https://git.openstack.org/cgit/openstack-infra/storyboard-webclient
|
||||
* https://git.openstack.org/cgit/openstack-infra/puppet-storyboard
|
||||
:Configuration:
|
||||
* :file:`modules/openstack_project/files/review.projects.yaml`
|
||||
* :config:`gerrit/projects.yaml`
|
||||
* :file:`modules/openstack_project/files/storyboard/superusers.yaml`
|
||||
:Bugs:
|
||||
* https://storyboard.openstack.org/#!/project/456
|
||||
|
|
@ -43,9 +43,10 @@ manage OpenStack infrastructure systems.
|
|||
Configuration
|
||||
=============
|
||||
|
||||
Much of StoryBoard's default configuration is managed from within infra/config
|
||||
itself. To add a project, admin, or modify a team, please follow the
|
||||
instructions below.
|
||||
The default superusers configuration of StoryBoard is managed from within
|
||||
infra/system-config. The rest of the configuration is on projects-config.
|
||||
To add a project, admin, or modify a team, please follow the instructions
|
||||
below.
|
||||
|
||||
Adding a Project to StoryBoard
|
||||
------------------------------
|
||||
|
|
@ -59,7 +60,7 @@ Projects loaded into StoryBoard are handled from the same file that drives our
|
|||
gerrit projects. Adding a new project is as simple as modifying a single
|
||||
file and adding the line ``use-storyboard: true``:
|
||||
|
||||
``/modules/openstack_project/files/review.projects.yaml``::
|
||||
``:config:`gerrit/projects.yaml```::
|
||||
|
||||
- project: openstack-infra/storyboard
|
||||
description: OpenStack Task Tracking API
|
||||
|
|
@ -73,7 +74,7 @@ StoryBoard administrators are handled from a single configuration file, and
|
|||
are identified by OpenID. To add a new administator, simply add their
|
||||
Launchpad OpenID string and email as follows:
|
||||
|
||||
``/modules/openstack_project/files/review.projects.yaml``::
|
||||
``:config:`gerrit/projects.yaml```::
|
||||
|
||||
- openid: https://login.launchpad.net/+id/LOLPONIES
|
||||
email: pinkie.pie@example.com
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ collaborate on code reviews.
|
|||
The configuration of every system operated by the infrastructure team
|
||||
is managed by Puppet in a single Git repository:
|
||||
|
||||
https://git.openstack.org/cgit/openstack-infra/config
|
||||
https://git.openstack.org/cgit/openstack-infra/system-config
|
||||
|
||||
All system configuration should be encoded in that repository so that
|
||||
anyone may propose a change in the running configuration to Gerrit.
|
||||
|
|
@ -24,19 +24,19 @@ Making a Change in Puppet
|
|||
|
||||
Many changes to the Puppet configuration can safely be made while only
|
||||
performing syntax checks. Some more complicated changes merit local
|
||||
testing and an interactive development cycle. The config repo is
|
||||
structured to facilitate local testing before proposing a change for
|
||||
review. This is accomplished by separating the puppet configuration
|
||||
into several layers with increasing specificity about site
|
||||
configuration higher in the stack.
|
||||
testing and an interactive development cycle. The system-config repo
|
||||
is structured to facilitate local testing before proposing a change
|
||||
for review. This is accomplished by separating the puppet
|
||||
configuration into several layers with increasing specificity about
|
||||
site configuration higher in the stack.
|
||||
|
||||
The `modules/` directory holds puppet modules that abstractly describe
|
||||
the configuration of a service. Ideally, these should have no
|
||||
OpenStack-specific information in them, and eventually they should all
|
||||
become modules that are directly consumed from PuppetForge, only
|
||||
existing in the config repo during an initial incubation period. This
|
||||
is not yet the case, so you may find OpenStack-specific configuration
|
||||
in these modules, though we are working to reduce it.
|
||||
existing in the system-config repo during an initial incubation period.
|
||||
This is not yet the case, so you may find OpenStack-specific
|
||||
configuration in these modules, though we are working to reduce it.
|
||||
|
||||
The `modules/openstack_project/manifests/` directory holds
|
||||
configuration for each of the servers that the OpenStack project runs.
|
||||
|
|
@ -60,13 +60,13 @@ simply by providing a different manifest file instead of site.pp.
|
|||
the root user.
|
||||
|
||||
As an example, to run the etherpad configuration on your own server,
|
||||
start by ensuring git is installed and then cloning the config Git
|
||||
repo::
|
||||
start by ensuring git is installed and then cloning the system-config
|
||||
Git repo::
|
||||
|
||||
sudo su -
|
||||
apt-get install git
|
||||
git clone https://git.openstack.org/openstack-infra/config
|
||||
cd config
|
||||
git clone https://git.openstack.org/openstack-infra/system-config
|
||||
cd system-config
|
||||
|
||||
Then copy the etherpad node definition from manifests/site.pp to a new
|
||||
file (be sure to specify the FQDN of the host you are working with in
|
||||
|
|
@ -83,8 +83,8 @@ the node specifier). It might look something like this::
|
|||
since it is not installed yet. You should be able to comment out the logic
|
||||
safely.
|
||||
|
||||
Then to apply that configuration, run the following from the root of the config
|
||||
repository::
|
||||
Then to apply that configuration, run the following from the root of the
|
||||
system-config repository::
|
||||
|
||||
./install_puppet.sh
|
||||
./install_modules.sh
|
||||
|
|
@ -92,9 +92,9 @@ repository::
|
|||
|
||||
That should turn the system you are logged into into an etherpad
|
||||
server with the same configuration as that used by the OpenStack
|
||||
project. You can edit the contents of the config repo and iterate as
|
||||
needed. When you're ready to propose the change for review, you can
|
||||
propose the change with git-review. See the `Gerrit Workflow wiki
|
||||
project. You can edit the contents of the system-config repo and
|
||||
iterate as needed. When you're ready to propose the change for review,
|
||||
you can propose the change with git-review. See the `Gerrit Workflow wiki
|
||||
article <https://wiki.openstack.org/wiki/GerritWorkflow>`_ for more
|
||||
information.
|
||||
|
||||
|
|
@ -156,7 +156,7 @@ following practices must be observed for SSH access:
|
|||
OpenStack machines should be kept to a minimum.
|
||||
* OpenStack Infrastructure machines must use puppet to centrally manage and
|
||||
configure user accounts, and the SSH authorized_keys files from the
|
||||
openstack-infra/config repository.
|
||||
openstack-infra/system-config repository.
|
||||
* SSH keys should be periodically rotated (at least once per year).
|
||||
During rotation, a new key can be added to puppet for a time, and
|
||||
then the old one removed. Be sure to run puppet on the backup
|
||||
|
|
@ -270,9 +270,9 @@ Launching New Servers
|
|||
=====================
|
||||
|
||||
New servers are launched using the ``launch/launch-node.py`` tool from the git
|
||||
repository ``https://git.openstack.org/openstack-infra/config``. This tool is
|
||||
run from a checkout on the puppetmaster - please see :file:`launch/README` for
|
||||
detailed instructions.
|
||||
repository ``https://git.openstack.org/openstack-infra/system-config``. This
|
||||
tool is run from a checkout on the puppetmaster - please see :file:`launch/README`
|
||||
for detailed instructions.
|
||||
|
||||
.. _cinder:
|
||||
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ advisable during the initial testing of the setup.
|
|||
|
||||
There are several triggers that gerrit will match to alter the
|
||||
formatting of comments. The raw regular expressions can be seen in
|
||||
`gerrit.pp <https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/manifests/gerrit.pp>`_.
|
||||
`gerrit.pp <https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/gerrit.pp>`_.
|
||||
For example, to have your test results formatted in the same manner as
|
||||
the upstream Jenkins results, use a template for each result matching::
|
||||
|
||||
|
|
|
|||
|
|
@ -27,8 +27,8 @@ wiki.openstack.org runs off of Wikmedia Foundation deployment branches.
|
|||
This was done to ease the pain of managing Mediawiki extensions. The
|
||||
foundation branches come with git submodules that refer to known good
|
||||
versions of extensions. Much (but not all) of the configuration is in
|
||||
puppet in the ``openstack-infra/config`` repository. Mediawiki upgrades
|
||||
are currently performed manually.
|
||||
puppet in the ``openstack-infra/system-config`` repository. Mediawiki
|
||||
upgrades are currently performed manually.
|
||||
|
||||
Mediawiki Upgrades
|
||||
==================
|
||||
|
|
|
|||
Loading…
Reference in New Issue