| Age | Commit message (Collapse) | Author |
|---|
|
The use of chef was never complete, had isses with updating binary
database files and had a cumbersome implementation. Since we are using
Ansible in meta-overc we are dropping the use of chef here and will
look to being at par with meta-overc by using Ansible if/when we get
time to look at runtime configuration in meta-cloud-services.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Fixes:
base_contains is deprecated, please use bb.utils.contains instead.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Per 5181ec2259eba5f4d3ec8516ea693bbc94481cf3 [openvswitch: rename
openvswitch-controller] and f7dcf5bce94064d32e6d07f9385fbff02e2a86f2
[openvswitch: enable systemd support] on meta-virtualization we remove
references to openvswitch-controller. This was never intended to be
something that should be installed. So removing this from the
packagegroup and chef.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
With changes made to the identity class, the postinstall
scripts no longer register users and services with keystone.
Instead, the registration is put inside the file
/etc/keystone/service-user-setup by the postinstall scripts.
Executing /etc/keystone/service-user-setup then registers
the users and services with keystone through /etc/keystone/identity.sh.
Therefore, executing just the postinstall scripts is not enough
enough to properly bring up the stack. However, executing
/etc/init.d/run-postinsts does both.
In addition, we are executing scripts within run-deploy in the
current shell environment so that the user can see all the updates
to the databases on the terminal.
Signed-off-by: Mustapha Lansana <Mustapha.Lansana@windriver.com>
|
|
The functionality the following files provide are now implemented in
openstackchef class, they are no longer needed in the deploychef package.
Signed-off-by: Mustapha Lansana <Mustapha.Lansana@windriver.com>
|
|
Spelling mistake correction and sentence restructuring to the
header section in recipe file.
Signed-off-by: Mustapha Lansana <Mustapha.Lansana@windriver.com>
|
|
The deploychef package has been adapted to implement the
run-time functionality required by decentralized openstackchef
class.
It does this by executing a script (deploychef) which instruct chef-solo
to recreate configuration files from all template files placed
at
/opt/deploychef/cookbooks/openstack/templates/default
by openstackchef class at build-time.
The deploychef init script run-level is lower than run-postinsts
script, which runs all openstack post-install scripts at first boot.
The deploychef script makes a call to run-chefsolo script,
which then creates openstack configuration files from all template
files mentioned above as directed by a recipe file.
This enables us to reconfigure an openstack image on first-boot,
thereby, updating the image with environment variables like IP address.
Like the template files above, there is a list of all default
variables used by the services in an openstack installation.
These variables, like the templates files above are created by
the openstackchef class and saved to a file under deploychef
directory at:
/opt/deploychef/cookbooks/openstack/attributes/default.rb
Whenever it's desired to reconfigure an openstack deployment
with an updated value of any of the variables in the attributes file
above, the script file run-deploychef should be executed to
reconfigure the stack as shown below.
cd /opt/deploychef
./run-deploychef
Signed-off-by: Mustapha Lansana <Mustapha.Lansana@windriver.com>
|
|
The deploychef package enables us to reconfigure an openstack
installation at run-time. It does this with the help of chef-solo,
by first creating a set of template files from openstack services'
configuration files. The template files are then passed on to chef-solo
at run-time. Finally, chef-solo recreates the services' configuration
files from the template files at run-time; this enables us to reconfigure
openstack services with dynamic run-time environment variables.
This patch set consist of files with helper functions which enables
deploychef to recreate the template files for the respective openstack
services.
Later on in this commit series, the files in this patch set
will be deleted, because the functionality they provide will be
provided by openstackchef class.
Signed-off-by: Mustapha Lansana <Mustapha.Lansana@windriver.com>
|
|
Deploychef package reconfigures an openstack installation.
These are helper files used by the deploychef package to bring the
system down and back up again before, and after chef-solo has generated
our desired configuration files from template files.
Later on in this commit series, the *-list files will be replaced with
dynamically generated *-list files by openstackchef. In addition,
the script files will be adapted to support openstackchef.
Signed-off-by: Mustapha Lansana <Mustapha.Lansana@windriver.com>
|
|
The deploychef package uses chef-solo to reconfigure an openstack
installation by converting services' configuration files to template
files. The attributes file defines the constants chef-solo uses to generate
configuration files/scripts. The recipe file describes how those
files/scripts should be created. The config and .json files
are input to chef-solo and describe location of files.
Later in this series, the attributes file will be replaced by a
dynamically generated attributes file. In addition, the recipe file
will change to accommodate changes to deploychef in order to support
openstackchef.
Signed-off-by: Mustapha Lansana <Mustapha.Lansana@windriver.com>
|
|
The current openstack build bakes a number of variables into openstack
services' configuration files at build-time. This makes it impossible
to deploy an openstack image built for one run-time environment into a
different run-time environment.
The deploychef package uses chef-solo to enable the re-use of an
openstack image in different run-time environments.
The attached patch set is deploychef package recipe and init script
files. The script deploychef.init gives us the ability to make a copy of
the postinstall script before they are tainted. This enables us to create
chef-solo templates out of the untainted postinstall scripts.
The template files are then used to recreate the postinstall script
whenever the stack needs to be reconfigured at run-time.
Signed-off-by: Mustapha Lansana <Mustapha.Lansana@windriver.com>
|
Mark Asselstine
Mustapha Lansana