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>
|
|
Upstream has dropped the now EOL stable/kilo branch, the SRCREV
however still exists in master so simply switch to master to fix
do_fetch.
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>
|
|
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
|
|
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
This is the initial update to the kilo branches and SRCREVs for some
of the core projects.
These are known to NOT work, due to SSLv3 issues with oe-core, and
missing config/dependencies.
Incremental updates will fix issues with the components, but they are
best done in-tree, rather than sitting on a huge pile of changes.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
syncing the core components to the latest juno hashes. We also introduce
new packages and update others to meet the juno requirements.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Instead of having a central file or group of files to
describe what data resources should be monitored. The
content of these files will depend on what core system
monitoring is used ((e.g. Nagios or Monasca).
It's desirable to have each recipe describes what
it wants be monitored in generic way such that various system
monitors can understand and convert these into their format.
If a recipe wishes to register itself to system monitor, it
inherits monitor bbclass and use MONITOR_SERVICE_PACKAGES and
MONITOR_SERVICE_<package name> to indicate what processes
should should be monitored. Also MONITOR_CHECKS_<package name>
variale can be used to pass list of scripts which will be run
on target and if any of these scripts fail then will report.
Eventually monitor.bbclass will be expanded to allow recipe
to describe more complicated information passed down to
system monitor (e.g. Nagios or Monasca)
Signed-off-by: Vu Tran <vu.tran@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>
|
|
Along with this update, we also fix a bug with nova and neutron port types.
this patch will be removed once it is fixed in the upstream project.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Several packages utilize the keystone package service/user addition
services recently added. The data passed to this service depends on
the value assigned to CONTROLLER_IP (used as KEYSTONE_HOST), however,
bitbake is not able to automatically determine this dependency so
several tasks which should be rerun to create updated package postinst
scripts are not run when CONTROLLER_IP is modified. Adding the
necessary vardeps ensure these tasks are rerun and now adjustments
made to CONTROLLER_IP are reflected in the generated packages.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Instead of creating tenant/user/role and service/endpoint for all
openstack services in keystone postinstall, now each of the services
creates its own keystone identities by queueing them up in its postinstall
to a file /etc/keystone/service-user-setup. service-user-setup
script, when run as the last postinstall, calls identity.sh with keystone
identity parameters to create necessary identities for the services.
Signed-off-by: Andy Ning <andy.ning@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Barbican tests fail because white space is not being properly parsed
by the iso8601 python package. This fix updates the barbican code
using a patch file to strip white space from the date before passing
it to the is8601 package for parsing.
Signed-off-by: Keith Holman <Keith.Holman@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Barbican expects configuration files for its tests to be in the same
location as they appear in the source tree. However, during
deployment configuration files are put into the /etc/barbican
directory. This fix patches the tests to find the configuration files
in the directory they are placed by the barbican recipe.
Signed-off-by: Keith Holman <Keith.Holman@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
uWSGI defaults to a maximum packet size of 4096 bytes. This
is too small to support working with PKI tokens that are now default
in Keystone. The size of the packets within Barbican are dependent
on both the size of the Keystone token and the size of the secret to
be stored & retrieved. Increasing the buffer size to the maximum
allowed by uWSGI allows Barbican to support the largest possible
secrets.
Signed-off-by: Keith Holman <Keith.Holman@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Issue: US-34303
Barbican source code comes with scripts that are intended to control
the service. Added previously was a script for this same purpose
that is placed into init.d that integrates more consistently with
the system. This makes the need for these scripts redundant. This
patch removes the scripts being put into the final system package.
Signed-off-by: Keith Holman <Keith.Holman@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
management of secrets
Introduce the barbican package: https://wiki.openstack.org/wiki/Barbican, to
support the management of keys and secrets on an OpenStack system.
The barbican api service can be started with the packaged initscript, and has
been validated against the barbican quick start guide.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|