x/solar
Code Issues Proposed changes

Fix 80 chars wraps for docs

Browse Source 
Change-Id: I638afd0b92461266396c576abc88c14370e50c19
Signed-off-by: Bogdan Dobrelya <bdobrelia@mirantis.com>
This commit is contained in:
Bogdan Dobrelya 2016-01-19 12:13:02 +01:00
parent aea48b733e
commit bf2bb097c7
7 changed files with 111 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
doc/source/fuel_modular_tasks.rst
View File

@ -10,9 +10,11 @@ Workflow
3. Create ``/var/lib/astute directory`` on nodes
4. Run upload_core_repos task ``fuel node --node 1,2,3 --tasks upload_core_repos``
4. Run upload_core_repos task ``fuel node --node 1,2,3 --tasks
upload_core_repos``
5. Configure `/etc/puppet/hiera.yaml` and create ``/etc/puppet/hieradata`` directory on slaves
5. Configure `/etc/puppet/hiera.yaml` and create ``/etc/puppet/hieradata``
directory on slaves
\:backends\:
\- yaml
@ -25,17 +27,21 @@ Workflow
\- resource
6. Distribute keys and certs
6. Distribute keys and certs ::
scp /var/lib/astute/ceph/ceph* root@node-1:/var/lib/astute/ceph/
sh /etc/puppet/modules/osnailyfacter/modular/astute/generate_haproxy_keys.sh -i 1 -h public.fuel.local -o 'haproxy' -p /var/lib/fuel/keys/
sh /etc/puppet/modules/osnailyfacter/modular/astute/generate_haproxy_keys.sh \
-i 1 -h public.fuel.local -o 'haproxy' -p /var/lib/fuel/keys/
scp /var/lib/fuel/keys/1/haproxy/public_haproxy.pem root@node-1:/var/lib/astute/haproxy/public_haproxy.pem
scp /var/lib/fuel/keys/1/haproxy/public_haproxy.pem \
root@node-1:/var/lib/astute/haproxy/public_haproxy.pem
scp /var/lib/fuel/keys/1/haproxy/public_haproxy.crt root@node-1:/etc/pki/tls/certs/public_haproxy.pem
scp /var/lib/fuel/keys/1/haproxy/public_haproxy.crt \
root@node-1:/etc/pki/tls/certs/public_haproxy.pem
7. To use solar on Fuel master we need to use containers because of python2.6 there. Also Solar by itself relies on several services
7. To use solar on Fuel master we need to use containers because of python2.6
there. Also Solar by itself relies on several services ::
yum -y install git
@ -45,9 +51,12 @@ Workflow
docker run --name redis -d -p 6379:6379 -e REDIS_PASS=**None** tutum/redis
docker run --name solar -d -v /root/solar/solar:/solar -v /root/solar/solard:/solard -v /root/solar/templates:/templates \
docker run --name solar -d -v /root/solar/solar:/solar \
-v /root/solar/solard:/solard -v /root/solar/templates:/templates \
-v /root/solar/resources:/resources -v /root/solar/f2s:/f2s \
-v /var/lib/fuel:/var/lib/fuel -v /root/.config/fuel/fuel_client.yaml:/etc/fuel/client/config.yaml -v /etc/puppet/modules:/etc/puppet/modules \
-v /var/lib/fuel:/var/lib/fuel -v /root/.config/fuel/fuel \
_client.yaml:/etc/fuel/client/config.yaml \
-v /etc/puppet/modules:/etc/puppet/modules \
-v /root/.ssh:/root/.ssh \
--link=riak:riak --link=redis:redis solarproject/solar-celery:f2s
@ -55,7 +64,8 @@ Workflow
``docker exec -ti solar bash``
9. Prepare transport for master and nodes, generate keys, create tasks and apply composer files on nodes
9. Prepare transport for master and nodes, generate keys, create tasks and apply
composer files on nodes
./f2s/fsclient.py master 1
@ -100,10 +110,10 @@ node. Right now it takes time, so please be patient.
Fetching data from nailgun
--------------------------
Special entity which allows to fetch data from any source *before* any actual deployment.
This entity provides mechanism to specify *manager* for resources (or list them).
Manager accepts inputs as json in stdin, and outputs result in stdout,
with result of manager execution we are updating solar storage.
Special entity which allows to fetch data from any source *before* any actual
deployment. This entity provides mechanism to specify *manager* for resources
(or list them). Manager accepts inputs as json in stdin, and outputs result in
stdout, with result of manager execution we are updating solar storage.
Examples can be found at f2s/resources/role_data/managers.
Data can be fetched by solar command

3
doc/source/glossary.rst
View File

@ -104,7 +104,8 @@ transition and type of event.
Right now we are supporting 2 types of events:
1. Dependency - inserts edge between 2 changes into the deployment plan.
2. Reaction - inserts change specified in reaction and makes edge between parent and child.
2. Reaction - inserts change specified in reaction and makes edge between parent
and child.
Example ::

6
doc/source/handler_ansible.rst
View File

@ -17,7 +17,8 @@ Let's look into simple ``hosts_file/actions/run.yaml`` example ::
state: present
{% endfor %}
It's pretty much standard ansible playbook, but it is processed with jinja2 before ansible is executed.
It's pretty much standard ansible playbook, but it is processed with jinja2
before ansible is executed.
Solar will create proper inventory ::
@ -43,6 +44,7 @@ Playbook will be also created ::
line: "10.0.0.3 node0"
state: present
You may wonder about ``hosts: [{{host}}]``, we have our own :ref:`res-transports-term` so we execute ansible like this ::
You may wonder about ``hosts: [{{host}}]``, we have our own
:ref:`res-transports-term` so we execute ansible like this ::
ansible-playbook --module-path /tmp/library -i /tmp/tmpkV0U5F/tmpGmLGEwhosts_file2/inventory /tmp/tmpkV0U5F/tmpGmLGEwhosts_file2/runlNjnI3

23
doc/source/resource.rst
View File

@ -45,8 +45,10 @@ Solar currently supports following handlers:
* puppet - first version of puppet handler (legacy, will be deprecated soon)
* puppetv2 - second, improved version of puppet, supporting hiera integration
* ansible_playbook - first version of ansible handler (legacy, will be deprecated soon)
* ansible_template - second generation of ansible implementation, includes transport support
* ansible_playbook - first version of ansible handler (legacy, will be
deprecated soon)
* ansible_template - second generation of ansible implementation, includes
transport support
Handlers are pluggable, so you can write your own easily to extend
functionality of Solar. Interesting examples might be Chef, SaltStack,
@ -101,11 +103,13 @@ To do so you can use ``solar input add`` or ``solar input remove`` in Solar CLI.
Computable Inputs
-----------------
Computable input is special input type, it shares all logic that standard input has (connections etc),
but you can set a function that will return final input value.
Computable input is special input type, it shares all logic that standard input
has (connections etc), but you can set a function that will return final input
value.
.. note::
Remeber, that you need to connect inputs to have it accessible in Computable Inputs logic.
Remeber, that you need to connect inputs to have it accessible in
Computable Inputs logic.
Currently you can write the functions using:
@ -121,15 +125,18 @@ Besides that there are 2 types of Computable Inputs:
- ``full``
- all connected inputs are passed as array (python dict type) as ``R`` variable, so you have full information about input.
- all connected inputs are passed as array (python dict type) as ``R``
variable, so you have full information about input.
In addition for ``jinja`` all connected inputs for current resource are accessible as first level variables.
In addition for ``jinja`` all connected inputs for current resource are
accessible as first level variables.
Change computable input
~~~~~~~~~~~~~~~~~~~~~~~
You can change Computable Input properties by calling ``solar input change_computable`` in Solar CLI.
You can change Computable Input properties by calling ``solar input
change_computable`` in Solar CLI.
Action

23
doc/source/resource_repository.rst
View File

@ -3,7 +3,8 @@
Resource Repository
===================
Resource Repository takes care about :ref:`resource_details` definitions and it supports versioning.
Resource Repository takes care about :ref:`resource_details` definitions and it
supports versioning.
Solar CLI supports following options::
@ -12,7 +13,8 @@ Solar CLI supports following options::
destroy Destroys repository
import Imports repository to Solar
remove Removes `spec` from Solar repositories
show Shows all added repositories, or content of repository when `-r` given
show Shows all added repositories, or content of repository when `-r`
given
update Updates existing repository with new content
@ -20,22 +22,27 @@ Solar CLI supports following options::
Resource Repository spec
------------------------
`spec` is in format `{repository_name}/{resource_name}:{version_info}`, `version_info` is optional if omitted, latest (highest) will be used.
Versions are in `Semantic Versioning <http://semver.org/>` format.
`spec` is in format `{repository_name}/{resource_name}:{version_info}`,
`version_info` is optional if omitted, latest (highest) will be used. Versions
are in `Semantic Versioning <http://semver.org/>` format.
You can also use `>`, `>=`, `==`, `<`, `<=` operators to specify matches.
Resource Repository import
--------------------------
Command `solar repository import` it allows you to import existing repository or directory with resources into your system. It will traverse `source` path copy all resources definitions into repository and obviously proper structure will be automatically created.
Command `solar repository import` it allows you to import existing repository or
directory with resources into your system. It will traverse `source` path copy
all resources definitions into repository and obviously proper structure will be
automatically created.
.. note::
You may also check `--link` option to this command. It will just link repository contents
so to import you need to have proper structure before.
You may also check `--link` option to this command. It will just link
repository contents so to import you need to have proper structure before.
Resource Repository update
--------------------------
Command `solar repository update` will update repository content with new data. With `--overwrite` flag it will overwrite conflicting resources definitions.
Command `solar repository update` will update repository content with new data.
With `--overwrite` flag it will overwrite conflicting resources definitions.

5
doc/source/transports.rst
View File

@ -33,8 +33,9 @@ Currently there are following sync transports available:
Ssh host key checking
---------------------
Solar wont disable strict host key checking by default, so before working
with solar ensure that strict host key checking is disabled, or all target hosts added to .ssh/known_hosts file.
Solar wont disable strict host key checking by default, so before working with
solar ensure that strict host key checking is disabled, or all target hosts
added to .ssh/known_hosts file.
Example of .ssh/config ::

69
doc/source/tutorials/wordpress.rst
View File

@ -3,10 +3,15 @@ Wordpress tutorial
1. Introduction
---------------
In this tutorial we will create Worpdress site using docker containers. We will create one container with Mysql database, then we will create database and user for it. After that we will create Wordpress container which is running on Apache.
In this tutorial we will create Worpdress site using docker containers. We will
create one container with Mysql database, then we will create database and user
for it. After that we will create Wordpress container which is running on
Apache.
For now you can use Solar only in our Vagrant environment.
First checkout Solar repo and start vagrant. We need two virtual machines. One where Solar database and Orchestrator will run and one where we will install Wordpress and all components:
For now you can use Solar only in our Vagrant environment. First checkout Solar
repo and start vagrant. We need two virtual machines. One where Solar database
and Orchestrator will run and one where we will install Wordpress and all
components:
2. Solar installation
---------------------
@ -24,8 +29,9 @@ First checkout Solar repo and start vagrant. We need two virtual machines. One w
3. Config resource
------------------
First we need to create Solar Resource definition where global configuration will be stored. This will be a `data container` only, so it will not have any handler nor actions. Let's create base structure:
First we need to create Solar Resource definition where global configuration
will be stored. This will be a `data container` only, so it will not have any
handler nor actions. Let's create base structure:
.. code-block:: bash
@ -33,7 +39,8 @@ First we need to create Solar Resource definition where global configuration wil
mkdir /vagrant/tmp/wp_repo/wp_config
touch /vagrant/tmp/wp_repo/wp_config/meta.yaml
Open meta file `/vagrant/tmp/wp_repo/wp_config/meta.yaml` with your favorite text editor and paste the following data:
Open meta file `/vagrant/tmp/wp_repo/wp_config/meta.yaml` with your favorite
text editor and paste the following data:
.. code-block:: yaml
@ -56,7 +63,10 @@ Open meta file `/vagrant/tmp/wp_repo/wp_config/meta.yaml` with your favorite tex
schema: str!
value:
Let's go through this document line by line. `handler: none` says that this resource has no handler and no actions. In next line we define version. The most important part starts from line 3. We define there the inputs for this resource. It will be possible to configure following inputs:
Let's go through this document line by line. `handler: none` says that this
resource has no handler and no actions. In next line we define version. The most
important part starts from line 3. We define there the inputs for this resource.
It will be possible to configure following inputs:
* `db_root_pass` - Mysql root password
* `db_port` - Mysql port
@ -64,22 +74,26 @@ Let's go through this document line by line. `handler: none` says that this reso
* `wp_db_user` - database user name for Wordpress
* `wp_db_pass` - database user password for Wordpress
In schema it's defined if input will be string or integer, `!` at the end means that the input is mandatory and value cannot be empty.
In schema it's defined if input will be string or integer, `!` at the end means
that the input is mandatory and value cannot be empty.
4. Composer file
-------------------
All other required resources are already available in solar repositores: `resources` and `templates`. We will use four more resources:
All other required resources are already available in solar repositores:
`resources` and `templates`. We will use four more resources:
* resources/docker - it installs docker
* resources/docker_container - it manages docker container
* resources/mariadb_db - it creates database in MariaDB and Mysql
* resources/mariadb_user - it creates user in MariaDB and Mysql
There are three ways to create resources in Solar: Python API, CLI and Composer files. We will use the last option.
Composer file is just a simple yaml file where we define all needed resources and connections.
There are three ways to create resources in Solar: Python API, CLI and Composer
files. We will use the last option. Composer file is just a simple yaml file
where we define all needed resources and connections.
Create new file `/vagrant/tmp/wp_repo/docker.yaml`, open it and past the following data:
Create new file `/vagrant/tmp/wp_repo/docker.yaml`, open it and past the
following data:
.. code-block:: yaml
@ -143,16 +157,19 @@ Create new file `/vagrant/tmp/wp_repo/docker.yaml`, open it and past the followi
WORDPRESS_DB_PASSWORD: wp_user::user_password
WORDPRESS_DB_NAME: wp_db::db_name
In block `resources` we define... resources. Each section is one resource. Each resource definition has a following structure:
In block `resources` we define... resources. Each section is one resource. Each
resource definition has a following structure:
* id - resource name
* from - path to resource dir
* location - node where resource will be run
* values: initialization of a Resource Inputs
In `location` we define `node1`. It's name of our virtual machine resource. It's not created yet, we will do it shortly.
In `location` we define `node1`. It's name of our virtual machine resource. It's
not created yet, we will do it shortly.
In our configuration there are two formats which we use to assign values to inputs. First:
In our configuration there are two formats which we use to assign values to
inputs. First:
.. code-block:: yaml
@ -166,7 +183,9 @@ Another format is:
login_port: config::db_port
This means that input `login_port` will have the same value as input `db_port` from resource `config`. In Solar we call it Connection. Now when value of `db_port` changes, value of `login_port` will also change.
This means that input `login_port` will have the same value as input `db_port`
from resource `config`. In Solar we call it Connection. Now when value of
`db_port` changes, value of `login_port` will also change.
When all files are ready we need add created resources to solar repository:
@ -174,7 +193,8 @@ When all files are ready we need add created resources to solar repository:
solar repo import tmp/wp_repo
This command created new solar resource repository. To list resources in this repository run:
This command created new solar resource repository. To list resources in this
repository run:
.. code-block:: bash
@ -183,13 +203,18 @@ This command created new solar resource repository. To list resources in this re
5. Deploying
------------
Now it's time to deploy our configuration. When running `vagrant up solar-dev solar-dev1` you started two virtual machines. We will deploy Wordpress on solar-dev1. To do it we need to create a resource for it. We already have in repo composer file which is doing it. Just run:
Now it's time to deploy our configuration. When running `vagrant up solar-dev
solar-dev1` you started two virtual machines. We will deploy Wordpress on
solar-dev1. To do it we need to create a resource for it. We already have in
repo composer file which is doing it. Just run:
.. code-block:: bash
solar resource create nodes templates/nodes count=1
It will create all required resources to run actions on solar-dev1. You can analyze content of `templates/nodes/1.0.0/nodes.yaml` later (that's the source for `templates/nodes`). Now we create resources defined in `docker`
It will create all required resources to run actions on solar-dev1. You can
analyze content of `templates/nodes/1.0.0/nodes.yaml` later (that's the source
for `templates/nodes`). Now we create resources defined in `docker`
.. code-block:: bash
@ -211,7 +236,8 @@ To see deployment progress run:
solar orch report
Wait until all task will return status `SUCCESS`. When it's done you should be able to open Wordpress site at http://10.0.0.3
Wait until all task will return status `SUCCESS`. When it's done you should be
able to open Wordpress site at http://10.0.0.3
If it fails, before reporting a bug, please try to retry deployment:
@ -236,4 +262,5 @@ and deploy new changes
solar changes process
solar orch run-once
Using `report` command wait until all tasks finish. Wordpress should still working and new password should be used.
Using `report` command wait until all tasks finish. Wordpress should still
working and new password should be used.