Age | Commit message (Collapse) | Author |
|
Signed-off-by: Josep Puigdemont <josep.puigdemont@enea.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
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>
|
|
basename -s is not unviversally supported, so we switch to something
more standard.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The meta-python version is taking precedence, so we pin the version to the
one in meta-openstack.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The meta-python pexpect version was being preffered and masking errors
in the download location. So we switch to the pypi location and we
can once again download.
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>
|
|
The following nova commit:
commit 5cacad3508570ce70b1f9ef620e0508169687fda
Author: Gary Kotton <gkotton@vmware.com>
Date: Tue Jun 3 03:44:40 2014 -0700
Deprecate neutron_* configuration settings
Create a new section in the configuration file called 'neutron'.
Move all of the neutron_* configuration settings to this section.
DocImpact
The table below has the changes:
+---------------------------------+-------------------------+
| 'DEFAULT' Section | 'neutron' Section |
|---------------------------------|-------------------------|
| neutron_url | url |
| neutron_url_timeout | url_timeout |
| neutron_admin_username | admin_username |
| neutron_admin_password | admin_password |
| neutron_admin_tenant_id | admin_tenant_id |
| neutron_admin_tenant_name | admin_tenant_name |
| neutron_region_name | region_name |
| neutron_admin_auth_url | admin_auth_url |
| neutron_api_insecure | api_insecure |
| neutron_auth_strategy | auth_strategy |
| neutron_region_name | region_name |
| neutron_ovs_bridge | ovs_bridge |
| neutron_extension_sync_interval | extension_sync_interval |
| neutron_ca_certificates_file | ca_certificates_file |
+---------------------------------+-----------------------=-+
Means that we need to create a [neturon] section, move and rename
our configs appropriately.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Updating components and support utilities for the juno 2014.2 update.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The upstream project is concerned with a bug in empty schemes with
2.7.3. But since Yocto is 2.7.3 and we get an empty scheme via websockify,
no VNC consoles are possible.
Rather than upreving python (big change), we aren't being hit by the
referenced bug, so we simply make sure that the condition can never
be true.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Juno nova requires 0.6.x for websockify, so we do the update.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Juno removes support for the unified OVS and linuxbridge plugins. So
we switch to the ml2 OVS plugin.
This involves configuration and packaging changes.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
We have three changes in a single commit:
- A runtime substition fix controller IP values
- When the substitions were moved for chef integration, the chef
disabled path wasn't tested. This meant that %CONTROLLER_IP% remained
in the final config files, and broke keystone startup.
- The addition of oathlib to keystone depedencies
- oauthlib is a juno dependency
- A temporary patch to the apache httpd front end modules
- At times keystone would fail to load via apache due to the inability to
load localcontext from oslo. To work around these sporadic failures, an
explicit import was added to the http front end module. This will be
removed in the future.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
To support iscsi backends, cinder uses rtslib-fb.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
In the juno release, keystone depends on oauthlib, so we introduce the
recipe.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Integrate oslo.rootwrap to meet juno dependencies for core projects
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
oslo rootwrap was missing from the DEPENDS of these core projects.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Horizon had a rather large set of duplicated DEPENDS, to work around
bitbake evaluation order issues. We can now unify the DEPENDS into
a single list, and leave RDEPENDS to deal with arch specific
differences.
We also add missing horizon juno dependencies.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Updating the horizon dependent packages to the juno-rc2 required versions
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Include monitoring packagegroups into various openstack
packagegroups.
Monitoring feature can be turned on by including the following
in local.conf
OPENSTACK_EXTRA_FEATURES += "monitoring"
There are various different system monitoring recipes
(e.g. Nagios or Monasca) provide packagegroup-monitoring-xxxxx.
To choose what system monitoring to use set the following in
local.conf
PREFERRED_PROVIDER_virtual/monitoring = "packagegroup-nagios-monitoring"
Signed-off-by: Vu Tran <vu.tran@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>
|
|
Although the use of PRINC is deprecated in later versions of Yocto it
may still be used and if you are using this layer with older Yocto it
is recommended for use in bbappends. It is therefore expected to
work. PRINC expects a non-numeric prefix followed by a numeric value,
as can be seen in base.bbclass
pr_prefix = re.search("\D+",pr)
prval = re.search("\d+",pr)
if pr_prefix is None or prval is None:
bb.error("Unable to analyse format of PR variable: %s" % pr)
Failing to stick to this convention yields a parsing error when you
attempt to use PRINC:
ERROR: Unable to analyse format of PR variable
Adding the non-numeric prefix allows PRINC use in bbappends to
function correctly.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
|
|
Ceilometer requires oslo.serialization and kazoo (plus its depdencies), so
we add them here, and ceilometer-api works again.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
keystone: move initscript install to before fixups
There are sed operations being performed on the sysvinit script .. but the
script wasn't being installed until after that block of code. We relocate
the install of the script to above any fixups, and everything works again.
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 class provides the framework to reconfigure openstack
at run-time. These services are inheriting openstackchef so that
script file(s), specified in the respective recipe file,
using the variables below are restarted by the decentralized
openstackchef class framework when reconfiguring openstack:
INITSCRIPT_PACKAGES: The list of init-scripts to start/stop when
reconfiguring openstack.
INITSCIPT_NAME_x: The name of the init-script mentioned above.
INITSCRIPT_PARAMS_X: This parameter defines the run-level and
priority for the init-script. However, the only parameter in this
variable that is of interest to openstackchef class is the priority of
the init-script.
Changes to none of the above variables is shown by this patch set,
however, it's to point out that openstackchef makes the assumption
that these variables are set in the service's recipe file.
Failure to set these variables, could lead to the service not
working properly after the stack is re-configured.
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 openstack services' configuration
file(s) exposed to it.
The following services are inheriting the openstack class
and then exposing a set of configuration files to the class.
The configuration files are assumed to have been installed in the image
in the service's WORKDIR and are exposed to openstackchef by assigning
them to the variable CHEF_SERVICES_CONF_FILES.
For legacy reasons, the string OPENSTACKCHEF_ENABLED is defined in
openstackchef class, but it can be overwritten to an empty string in
a .bb, .class, .bbapend or local.conf file when openstackchef support
is not desired. This enables all of these services to be built without
openstackchef support. In addition, it prevents the recipes for these
sevices from substituting the placeholders in their configuration
files when inheriting openstackchef.
However, since services like python-glance and python-cinder install some
of their configuration files to the image directory during the
substitution, it means that these files at not installed when the
substitutions are not required.
Therefore, we have taken the liberty to install those missing configuration
files before the check for whether or not substitutions should be made,
without having any side effect on when the substitutions are required.
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.
In making template files out of configuration files, openstackchef
makes a simple placeholder/value substitution in the configuration files.
However, it provides a mechanism for services inheriting the class
to define a special shell callback function which can do more than
a simple placeholder/value substitution. This special callback
function is exposed to openstackchef by assigning it to the variable
CHEF_SERVICES_SPECIAL_FUNC. And the name of the file passed back to the shell
callback function as an argument is set to the variable
CHEF_SERVICES_FILE_NAME by openstackchef. In this patch set, only
python-neutron and python-glance recipe files makes special
substitutions.
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>
|
|
Openstack-base class is inheriting openstackchef class
Since we want openstackchef post-rootfs function to be called
after rootfs creation for all openstack images, openstack-base
class need to inherit openstackchef class.
In addition, we want the node names; compute/controller
to be reconfigurable to other variables beside
compute/controller in /etc/hosts file at run-time, and be consistent
with node names used for compute/controller in all openstack installation.
Signed-off-by: Mustapha Lansana <Mustapha.Lansana@windriver.com>
|
|
This class provides a framework for recipes(packages) to register
their configuration files with the deploychef package. This class
works together with the deploychef package. This implementation
makes it possible for the deploychef package, with the help of
chef-solo, to recreate registered configuration files at run-time.
Only services that inherit this class and register their configuration
files are re-configurable at run-time; and by configurable, we mean to
make chefsolo templates out of their configuration files and to be aware
of the list of daemons that need to be killed/started at run-time.
Therefore, openstackchef class requires the recipes/classes inheriting
it to advertise their configuration files, list of start/stop daemons
and finally a special callback function when necessary.
In order to avoid duplication of common placeholders and
substitution across the various recipes inheriting this class,
we keep a dictionary of common placeholders and substitutions,
but rely on the recipes to define the values these placeholders take
at run-time.
See the description at the top of the class files (openstackchef.bbclass
and openstackchef_inc.bbclass ) for more details.
This class makes chef-solo template files out of the configuration
files exposed to it by the recipes.
The resulting templates are stored at
/opt/deploychef/cookbooks/openstack/templates/default.
on the resulting rootfs.
It also creates a file containing a set of chef-solo default template
values known as attributes in chef-solo world. The default values are
provided by the recipes and classes inheriting this class.
The chefsolo attributes file is stored at
/opt/deploychef/cookbooks/openstack/attributes/default.rb
at the end of rootfs creation process.
At run-time, the deploychef package whose package files are stored
at '/opt/deploychef', makes a call to chef-solo.
Chef-solo in turn uses the attributes and templates files to overwrite
the configuration files for services like neutron, nova, swift, etc..
that registered configuration files with openstackchef class
at build time. See accompanying documentation for further explanation.
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>
|
|
"task-ceph" package group is renamed to "packagegroup-ceph"
so update any file in meta-cloud-services layer that uses
"task-ceph"
Signed-off-by: Vu Tran <vu.tran@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
This commit changes all required configurations to use keystone running
on apache. The following packages configurations were modified for
keystone running on apache: python-neutron, python-nova, tempest,
python-swift, python-rally, python-heat, python-glance,
python-cinder, python-ceilmoeter, python-horizon.
Signed-off-by: Liam R. Howlett <Liam.Howlett@WindRiver.com>
|