1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
General
=======
These are the Mojo specs for running deployments of Openstack. For more
information on installing and running Mojo see lp:mojo
Directoy Layouts
================
Top Level
---------
This branch contains the following top level assets:
* *specs* directory contains the specs themselves.
* *SPEC\_SUMMARY.txt* contains descriptions of each spec
* *Makefile* has targets for checking lint and generating SPEC\_SUMMARY.txt
* *helper* directory contains scripts and libraries used by the specs
spec directory
--------------
The specs fall into the following catagories:
* *dev*: Specs which are still under development (these are not lint checked)
* *full\_stack*: These perform a full openstack deployment
* *bugs*: Specs that reproduce a bug. These are useful for verifying a bugs
existence and then once the fix has landed they can be used to verify a
regression has not occured.
* *features*: These do a minimal deployment to demonstrate a new feature.
* *object\_storage*: Specs for deploying a standalone object storage environment
Tip directory
-------------
The tip directory should be used to differentiate between Openstack versions.
Example
-------
*specs/full_stack/charmhelper_upgrade/juno/*
This spec is used to do a deployment of a full Juno Openstack environment and
to test an upgrade of charmhelpers
helper directory
----------------
The helper directory contains the following:
* *bundles*: Juju deployer bundles
* *collect*: Mojo collect and repo files, used to collect branches prior to
running Juju Deployer
* *scripts*: Scripts for running lint checks etc
* *setup*: Manipulate the overcloud or provider
* *template*: An example spec
* *tests*: Tests to run against the deployment
* *utils*: Core set of utilities used by tests and setup
Spec Bulding Blocks
===================
Phase 1: Collection
-------------------
Directives: collect and repo
These specs collect the charm branches as a seperate step from deploying the
charms. Although Juju deployer can do the branch collection, having this done
as a seperate phase has a few advantages. It allows for the branches to be
manipulated prior to deployment, the charmhelper upgrade spec does exactly this
to check that a charmhelper sync will not break a deployment. It also allows
for an alternative branch location for a given charm to be clearly specified,
this is particulalry useful when an unmerged branch needs testing.
Phase 2: Deployment
-------------------
Directives: deploy
Mojo uses juju deployer to do the charm deployment. When specifying the target
to use in the bundle the ${MOJO\_SERIES} environment variable should be used in
place of the Ubuntu release version. This allows the same spec to be used for
deployments on different Ubuntu release.
deploy config=haphase1.yaml delay=0 target=${MOJO\_SERIES}-juno
Phase 3: Cloud Setup
--------------------
Directives: script
There are a number of helper scripts used to setup the cloud once it has been
deployed. In general they consist of the script to do the setup and a YAML file
of options.
* *image\_setup.py*: This script downloads guest images and uploads them to
Glance. *images.yaml* lists the images to be downloaded and
information about those images.
* *keystone\_setup.py*: Setup keystone users and roles. *keystone_users.yaml*
lists the users to be created and what roles they should
be given
* *network\_setup.py*: This sets up the SDN on the cloud. *network.yaml* describes
the SDN topology
Phase 4: Test
-------------
Directives: verify
There are a number of tests to choose from, some are specific to particular
bugs or features. However, the main tests used to verify the cloud are:
* *simple\_os\_checks.py*: This script creates guests on the cloud, associates
floating ips and then uses ssh to connect to the
cloud and verifies its hostname. This ensure that
the guest got a network and metadata on boot.
* *test\_obj\_store.py*: This script fires two streams of objects and the
object store and retireves them
* *tempest.py*: This doesn't actually exist in any real sense but will do rsn!
Phase 5: Manipulate the cloud
-----------------------------
Directives: script
There are scripts for manipulating the cloud, usually at the Juju level. These
include:
* *add_unit.py*: Use juju to add a unit to a given service
* *chaos_pony.py*: Kill, test and add units to all services
* *delete_crm_leader.py*: Delete the unit Corosync reports is the leader for a
given service
* *delete_router_home.py*: Delete the unit housing a particular Neutron router
* *delete_unit.py*: Delete a given unit
* *juju_set.py*: Juju set a kv pair for a given service
* *upgrade_all_services.py*: Perform a Juju charm upgrade on all services
* *upgrade_services.py*: Perform a Juju charm upgrade on a given service
Helper Libraries
================
There are two helper libraries in *helper/utils/*.
* *mojo_os_utils.py*: Functions for manipulating the deployed Openstack cloud.
* *mojo_utils.py*: Functions for manipulating the providor environment. Juju
add/remove unit etc
Using mojo
==========
Install mojo (Stolen from https://launchpad.net/mojo)
sudo add-apt-repository ppa:mojo-maintainers/ppa
sudo apt-get update
sudo apt-get install mojo
sudo mojo project-new --series trusty mojo-openstack-specs
sudo adduser ubuntu mojo
sudo chmod 755 /var/lib/lxc/mojo-openstack-specs.trusty && sudo chmod 755 /var/lib/lxc
mojo workspace-new --project mojo-openstack-specs --series trusty --stage full_stack/next_deploy lp:~ost-maintainers/openstack-mojo-specs/mojo-openstack-specs run1
mojo run --project mojo-openstack-specs --series trusty --stage full_stack/next_deploy lp:~ost-maintainers/openstack-mojo-specs/mojo-openstack-specs run1
|