| Age | Commit message (Collapse) | Author |
|---|
|
Checking for "$D" and doing an "exit 1" now results in errors such as:
[log_check] warning: %post(keystone-cronjobs-...) scriptlet failed, exit status 2
during image creation. Instead of escaping the script for "level-1"
(image creation postinst) we wrap the "level-2" (first boot) postinst
in an if statement. This also ensure the scriptlet in
indentity.bbclass is less prone to behaving differently based on the
postinsts defined in the classes which inherit 'identity'.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
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>
|
|
Several bbappends were raising 'dangling' warnings since the base
recipe version has changed without a similar change being made in this
repo. The following are renames that include a wildcard to broaden the
versions to which these bbappends will be applied to. This will
address the 'dangling' warnings while ensuring the changes made in
this repo are properly applied to the associated recipes.
For the most part the files remain unchanged, in the case of
postgresql the 'brokensep' has been removed as there exists no more S
!= B issues in the base recipe.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@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>
|
|
Removing PRINC from recipes to silence the bitbake warning about
it being a depreciated variable.
Signed-off-by: Bruce Ashfield <bruce.ashfield@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>
|
|
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>
|
|
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>
|
|
- 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>
|
|
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>
|
|
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>
|
|
The return code check after the DB user creation was inverted, which results
in false reports of errors, and post-insts that are not cleaned up.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Without adding the initscript package, postgres won't start automatically
on boot.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
When using the target installer with postgresql can end up installing
in the wrong order due to bad dependencies and cause the install
transaction to fail as follows:
====
initdb: invalid locale name ""
initdb: invalid locale name ""
initdb: invalid locale name ""
initdb: invalid locale name ""
initdb: invalid locale name ""
could not open directory "/usr/share/postgresql/timezone": No such file or directory
sh: locale: command not found
WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
/etc/init.d/postgresql: line 25: start-stop-daemon: command not found
====
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
|
|
Since we can't count on package postinst order, many components check for
a configured postgresql daemon, and if not found, initialize it.
Rather than sprinkling the knowledge of how to initialize the database
through all these packages, we create a more robust, central postgresql-init
script, and call it when any component needs the database configured.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
To allow better out of the box configuration of postgresql, two things
are required: listen on all addresses, and add explicit permissions for
the known nodes in the network.
In this change, the former is done by adding listen_addresses = '*' to the
generated postgresql configuration on first boot, as well as adding the
known compute and controller IPs to pg_hba.conf. (note: the values for these
IPs come from hosts.bbclass)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
On some targets postgresql's server processes start slowly. If they haven't
started and the admin account or other operations are attempted, they fail
with a message about not being able to communicate to the local server.
If postgres is not properly setup, then subsequent components will also fail,
since they either cannot talk to the server, or can't use the 'admin' account.
To fix this issue, we add additional sleep states, and attempt to create the
admin role 10 times, with a delay between each attempt. If we fail to contact
the server after 10 attempts, a clear message is displayed and the postinst
returns a failing return code.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The user and password for postgresql are defined in the
identity class and are loaded by the recipes from this class.
Signed-off-by: Mihai Prica <prica.mihai@gmail.com>
|
|
Signed-off-by: Mihai Prica <prica.mihai@gmail.com>
|
|
Signed-off-by: Mihai Prica <prica.mihai@gmail.com>
|
|
-The postinstall will initialize the database;
-The postgres user is needed because postgresql can't be run
as root.
-The initscript will start the service at start-up.
Signed-off-by: Mihai Prica <prica.mihai@gmail.com>
|
Mark Asselstine
Mustapha Lansana
Bruce Ashfield
Amy Fong
Jason Wessel
Mihai Prica