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
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
openstackchef.bbclass
=========
When an openstack image is built for a CONTROLLER, COMPUTE or allinone,
there are build-time variables that are hard-coded into the image.
These hardcoded variables need to be provided up front at
build time and cannot be changed easily at run-time.
What this means is that an image built for a specific deployment
environment cannot be easily deployed to another environment.
Openstackchef class enables openstack related services like, nova, postgresql,
neutron, etc to be re-configured at run-time. This means that if all the
services of an openstack installation inherits the openstackchef class,
openstackchef can successfully re-configure an openstack installation.
For example, at build time, many of the openstack services need to know ahead of
time, the IP address of the node on which CONTROLLER and COMPUTE will be deployed.
Once this IP address is built into the image, it cannot be changed at runtime.
In other words, if you build a CONTROLLER image for a machine with IP address
of 192.168.7.2, you cannot use that image on a machine with a different IP address.
This is very restrictive, since it does not allow the re-use of CONTROLLER/COMPUTE
images.
Openstackchef.bbclass facilitates the reuse of openstack images across multiple
machines. It does this by providing a mechanism for openstack related services
to register all configuration files that have run-time dependent variables like IP
address in them.
By inheriting openstackchef, and registering these configuration files
with openstackchef, the services are no longer tied to a specific
run-time environment. This is because, openstackchef makes it possible
for the registered configuration files to be recreated at run-time when
any of the environment variables changes.
The configuration files are registered with openstackchef by assigning
them to the variable CHEF_SERVICES_CONF_FILES in the recipe file.
See example below for barbican:
CHEF_SERVICES_CONF_FILES :="\
${sysconfdir}/${SRCNAME}/vassals/barbican-api.ini \
${sysconfdir}/${SRCNAME}/vassals/barbican-admin.ini \
"
Openstackchef makes chef-solo templates out of
the registered files. At run-time, the deploychef package
makes a call to chef-solo, which in-turn use the template files
to recreate the registered configuration files.
Also see additional description in the openstackchef.bbclass header.
In addition to the simple placeholder/value substitution that is
done by the openstackchef class when creating the templates,
there are times when recipes need to do morethan a simple placeholder
substitution. For cases like these, openstackchef provides a mechanism for
the recipes to provide a special callback function. Openstackchef class
then makes a call to this special callback function to do any additional substitution.
The special shell callback function is registered with openstackchef by
assigning it to the variable CHEF_SERVICES_SPECIAL_FUNC.
The python-neutron recipe defines a special function and specifies it
as shown below.
CHEF_SERVICES_SPECIAL_FUNC := "deploychef_services_special_func"
Whenever the configuration files of any openstack service
changes, the service usually needs to reload the configuration file.
The list of scripts/priority levels responsible for restarting
the service when its configuration files change are assumed to
be provided by the following variables:
INITSCRIPT_PACKAGES
INITSCRIPT_NAME_x or INITSCRIPT_NAME
INITSCRIPT_PARAMS_x or INITSCRIPT_PARAMS
Here is an example of how python-barbican specifies these variables.
INITSCRIPT_PACKAGES = "${SRCNAME}"
INITSCRIPT_NAME_${SRCNAME} = "barbican-api"
INITSCRIPT_PARAMS_${SRCNAME} = "${OS_DEFAULT_INITSCRIPT_PARAMS}"
In addition, there are services that might need to be restarted but does
not necessary have a configuration file. These services can also advertise
themselves to openstackchef with the above variables.
However, failure to provide appropriate values for the above variables after
registering a set of configuration files for an openstack service will
lead to the service not working properly.
Dependencies
------------
This class depends on the deploychef package for run-time implementation of
the class. However, the end user does not have to do anything about this
dependency, because it's resolved at build time and all deploychef package
files are automatically included on the rootfs of resulting image.
Openstackchef class creates the template files used by the deploychef package
to reconfigure an openstack node.
Deploychef executes chefsolo at run-time to recreate
the configuration files for openstack services from template files
created by openstackchef.bbclass at build time.
Chefsolo in turn uses the attributes and templates files to overwrite
the configuration files for services like neutron, nova, swift, etc..
that had registered their configuration files with openstackchef class
at build time.
The base directory for the deploychef package is /opt/deploychef.
There are many files that goes into the re-configuration of an
openstack deployment, however, two are worth mentioning.
1 . Default variables in openstack and the values they hold can be found in:
/opt/deploychef/cookbooks/openstack/attributes/default.rb
2. A shell script file that should be executed to reconfigure the stack
on CONTROLLER, COMPUTE or allinone nodes.
/opt/deploychef/run-deploychef
The script file above should be executed when any of the run-time environment
variables found at /opt/deploychef/cookbooks/openstack/attributes/default.rb
is changed.
Run-time
-------
Allinone: An allinone node boots-up with openstack re-configured and all services
accessible either through the command-line or through horizon.
CONTROLLER & COMPUTE:
Both CONTROLLER and COMPUTE nodes boots-up with their respective IP address
updated using the IP address on the interface of the machine on which they run.
For the CONTROLLER, you should be able to access horizon at this point. However,
both the CONTROLLER and COMPUTE are not aware of each other at this point.
For them to be made aware of each other, we need to inform the COMPUTE node of
the location of the CONTROLLER node, similarly, we need to inform the CONTROLLER
node about the location of the COMPUTE node.
In order to accomplish this on each node, edit IP address field in the file
/opt/deploychef/cookbooks/openstack/attributes/default.rb
On the CONTROLLER node, change COMPUTE's IP address to the IP address
of the machine on which you have openstack COMPUTE deployed.
Assuming COMPUTE's IP address was set to "192.168.7.4" at build-time and the
current IP address of the machine on which you have COMPUTE deployed is
"128.224.149.164". Then the line
default["COMPUTE_IP"] = "192.168.7.4"
should be changed to
default["COMPUTE_IP"] = "128.224.149.164"
Now cd into the base directory of deploychef and execute the script
'run-deploychef'.
cd /opt/deploychef
./run-deploychef
Note: It's important that you 'cd' into /opt/deploychef when running
run-deploychef script, because this script makes a call to chefsolo which
references files from /opt/depoychef base directory.
Wait for the script to finish executing and you are shown the prompt.
In a similar vein, repeat the above process on the COMPUTE node, but this
time, it's the CONTROLLER's IP address you will be changing. Leave the COMPUTE's
IP address as is.
Assuming CONTROLLER's IP address was set to "192.168.7.2" at build-time and the
current IP address of the machine on which you have CONTROLLER deployed is
"128.224.149.162". Then the line
default["CONTROLLER_IP"] = "192.168.7.2"
should be changed to
default["CONTROLLER_IP"] = "128.224.149.162"
Again 'cd' into the base directory of deploychef and execut the script
'run-deploychef'.
cd /opt/deploychef
./run-deploychef
At this point, both COMPUTE and CONTROLLER have been configured and should be
communicating with one another.
Maintenance
-----------
This class is maintained by Wind River Systems, Inc.
Contact <support@windriver.com> or your support representative for more
information on submitting changes.
Building with openstack.bbclass
-------------------------
This class should be inherited by recipe/class files of openstack services in order
for the functionality described above to work.
If any component of openstack is left out, that component will
not work correctly when the stack is reconfigured at run-time, and as a result,
the openstack deployment will not work.
License
-------
Copyright (C) 2014 Wind River Systems, Inc.
The right to copy, distribute or otherwise make use of this software may
be licensed only pursuant to the terms of an applicable Wind River license
agreement. No license to Wind River intellectual properly rights is granted
herein. All rights not licensed by Wind River are reserved by Wind River.
Source code included in tree is under the LICENSE
stated in class file (.bbclass file) unless other stated.
|
