Age | Commit message (Collapse) | Author |
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
A simple demo is added
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>
|
|
Openstackchef enables us to recreate configuration files
for services in an openstack installation. It does this by
creating template file(s) out of configuration file(s) exposed
to the class by services.
The following services are inheriting the openstack class
and then exposing a set of configuration files to the class.
These services expose their configuration files to openstackchef
by assigning them to the variable CHEF_SERVICES_CONF_FILES. The files
are assumend to have been installed in the image directory under the
service's WORKDIR.
At build-time, openstackchef makes chef-solo templates out of
the registered files. And 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.
For legacy reasons, the string OPENSTACKCHEF_ENABLED is defined in
openstackchef class, but it can be overwritten in a .bb, .class,
.bbappend or local.conf file to an empty string when openstackchef
support is not desired. This enables all of these services to be built
without openstackchef support. In addition, it prevents the recipes
from substituting the placeholders in their configuration files
when inheriting openstackchef.
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>
|
|
Maintainer's of the upstream git trees for these packages have branched
the repos from which these packages were fetched.
This creates a mismatch between the SRCREV and branch name in the recipe
files.
Specify the branch name to resolve the error or update
the SRCREV to match a commit id found on master.
Signed-off-by: Mustapha Lansana <Mustapha.Lansana@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Not only do we update to meta-oe latest, we inherit the following issue
that prevents instance creation:
https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1364828
To fix the issue, we import 0003-Don-t-enforce-that-dev-already-exists.patch,
until it is integrated into the upstream package.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Removing PRINC from recipes to silence the bitbake warning about
it being a depreciated variable.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
To avoid configuration errors, we need to get the latest meta-networking
changes.
This recipe will be dropped eventually, but will stay a bit longer for
migration purposes.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Explicitly set the libexec dir to /usr/libexec for openstack
Signed-off-by: Amy Fong <amy.fong@windriver.com>
|
|
Package nss-pam-ldapd, this is a daemon enabling pam/ldap
authentication.
Signed-off-by: Amy Fong <amy.fong@windriver.com>
|
|
Add openstack specific parts of openldap.
openldap's init script initializes the data with the basic tree structures
needed for keystone - the Group, User and Role tree.
Additionally, we add two variables which can be set in local.conf,
LDAP_DN - default DN for ldap
default: "dc=my-domain,dc=com"
LDAP_DATADIR - default directory for ldap's data directory
default: "/etc/openldap-data/"
Signed-off-by: Amy Fong <amy.fong@windriver.com>
|
|
Not only must postgres depend on libxml for xml support, we need to
point at the sysroot/staging area for the header files to be found.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Using the /etc/init.d/tgtd script, allows the service be started
multiple times, but only the last instance can be stopped using
the script. This fix ensures that the service isn't running
before attempting to start the service multiple times.
Signed-off-by: Keith Holman <Keith.Holman@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Make ruby binaries more accessible by creating symlinks from
${libdir}/ruby/gems/${ruby version}/bin/ to /usr/bin
RDEPENDS needs to be package specific
coderay needs to depends on yard
Signed-off-by: Amy Fong <amy.fong@windriver.com>
|
|
Use chef-solo to help reconfigure and deployment of controller
and compute nodes. Install script downloaded from this link
(https://www.opscode.com/chef/install.sh) and the attached archives created from it.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Amy Fong <amy.fong@windriver.com>
|
|
Since oe-core introduced the autotools separated build and source
directory changes, some package builds broke.
With this change, we can build against the latest oe-core master.
It should be noted that this masks the build issues, and the bbappends
should be removed as dependency layers update or "real" fixes are
generated.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
meta-virtualization versions
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Unfortunately the use of apxs, which isn't that friendly with
separated src/build dirs, makes things tricky to acheive src/build
separation. With the use of a symlink and a few other minor tweaks we
are able to get this working.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Editing the files in ${WORKDIR} using sed or similar tools as part of
do_install means they can only be edited once. Supplying a modified
CONTROLLER_IP in local.conf and building the image again will not
result in the CONTROLLER_IP being properly updated since the
substitution placeholders will no longer exist. We therefore simply
swap the other of things, installing the configuration files first,
then editing them to swap the placeholders. This means we can run the
do_install again and again and get the results we expect.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Current Makefile will check headers on host instead of Yocto sysroot, following
error appears. Change the path of header check.
| bs_aio.c:34:20: fatal error: libaio.h: No such file or directory
| #include <libaio.h>
| ^
| compilation terminated.
Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
memcached from meta-networking had a configuration error
(cannot run tests while crosscompiling).
Upreving to 1.4.17 and fixing config error.
Signed-off-by: Amy Fong <amy.fong@windriver.com>
|
|
openstack-dashboard uses mod_wsgi to interface with apache
Signed-off-by: Amy Fong <amy.fong@windriver.com>
|
|
The lvm2 in meta-oe now deals with the readline function issues, so we
can drop the meta-cloud-services patch.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
tgtd implements status and reload, need to add this to the usage info
Signed-off-by: Amy Fong <amy.fong@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Package spice-html5
Modify python-nova to add infrastructure for nova-spicehtml5proxy
support.
Note: spice is the default
Signed-off-by: Amy Fong <amy.fong@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Commit 0460bd62663d6db4c9b6aed5edd73fb0d052ffb2 [lvm2: allow compiles
to use latest readline] forced us to use an old version of
readline. Here we backport an upstream lvm2 commit which allows us to
use new readline and drop the PREFERRED_VERSION_ for readline.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Add status/reload to sysvinit scripts
Modify tgtd to make start/stop work better (borrowed from Debian's
implementation)
Signed-off-by: Amy Fong <amy.fong@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
- make database directory to be configurable, defaulting
to /var/lib/postgres/data
- modify init scripts to create database's data directory if it doesn't
exist
Signed-off-by: Amy Fong <Amy.Fong@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Syncing to oe-core, and meta-oe master of January 30th 2014.
- introduced required new bbappends
To keep compatiblity with older versions of oe-core and meta-oe,
old bbappends are kept, but they are moved to the "dangling"
recipe group.
If any bbappend warnings show outside of the dangling recipes,
they should be investigated.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
If the prior instance of postgresql was running there
is no way to kill it after the conversion to DRBD.
This adds the corner case to stop the old daemon after
the data directory has been migrated.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
|
|
The logic was flipped in the wrong place. This makes things right and
fixes up the possibility that the symlink already exists.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
|
|
oe-core/meta-networing/meta-virtualization master
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
After moving all database creation initialization packages, we also
remove it from the RDEPENDS of the various control node recipes.
This allows images to select database initialization or skip it.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Many OpenStack modules require a first boot action to setup up users,
databases, bridges, etc. These same packages install initscripts to start
daemons and servers.
The 1st boot package post install actions immediately exit to indicate
that the action cannot be performed in the cross environment and instead
should be done on first boot. The update-rc.d post install actions are
intended to be run in the cross environment to symlink scripts into the
proper runlevels.
The early exit from the db setup routines, means that the rc files are
not linked in host cross. If the rootfs doesn't contain update-rc.d,
they also will not be set up on first boot. The end result is a system
that does not start all of its required services on boot.
To fix this, we split out db and other first boot setup tasks into
dedicated (but empty) -setup packages. These run on first boot, while
update-rc.d is left to create the proper symlinks.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
To support the execution of the chkconfig and service scripts, we need
to ensure a consistent header on the initscripts, and a consistent
environment that allows scratch files to be written.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
When postgresql installed on the target and configured with drbd the
data will live in the drbd container and the startup script must
account for the different invocation to pg_ctl, as well as checking
that the config files are properly linked into to the postgresql data
directory.
The set -e was removed because the script was exiting improperly
during the restart operation and status operations.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
|
|
Now that the /etc/init.d/postgresql script will start and stop the
database synchronously there is no need to sleep waiting for the
database to come to life or wait for it to stop.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
|
|
The daemon-start-stop script will not actually wait synchronously for
postgress to start or stop. The postgresql package provides pg_ctl
for controlling the startup and clean shutdown of the database.
This patch converts to using pg_ctl for start and stop operations.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
|