aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)Author
2015-09-10python-django-appconf: use correct hashesjunoJosep Puigdemont
Signed-off-by: Josep Puigdemont <josep.puigdemont@enea.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-12-18hiera: add recipe for hiera 1.3.4YangHaibo
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-12-18facter: add recipe for facter 2.3.0YangHaibo
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-12-18puppet: add recipe for puppet 3.7.3YangHaibo
A simple demo is added Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-12-03trove: switch to basename <file> <suffix>Bruce Ashfield
basename -s is not unviversally supported, so we switch to something more standard. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-11-25core: update to stable/juno release branchesBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-11-18meta-openstack: prefer pexpect 3.3Bruce Ashfield
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>
2014-11-18python-pexpect: fix download locationBruce Ashfield
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>
2014-11-17core: update to juno 2014.2 + dependenciesBruce Ashfield
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>
2014-11-17nova: update configuration settingsBruce Ashfield
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>
2014-11-11core: add juno (2014.2) dependenciesBruce Ashfield
Updating components and support utilities for the juno 2014.2 update. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-11-10trove: update core package and dependencies to juno -rc2Bruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-11-05nova: allow empty schemes at python 2.7.3Bruce Ashfield
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>
2014-11-05websockify: update to 0.6.0Bruce Ashfield
Juno nova requires 0.6.x for websockify, so we do the update. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-10-27neutron: move from OVS unified to OVS ml2 pluginBruce Ashfield
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>
2014-10-21keystone: update for Juno rc1Bruce Ashfield
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>
2014-10-21horizon/libs: introduce jquery-ui for juno requirementsBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-10-21cinder/libs: add rtslib-fbBruce Ashfield
To support iscsi backends, cinder uses rtslib-fb. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-10-21keystone/libs: introduce oauthlibBruce Ashfield
In the juno release, keystone depends on oauthlib, so we introduce the recipe. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-10-21oslo: add rootwrapBruce Ashfield
Integrate oslo.rootwrap to meet juno dependencies for core projects Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-10-21nova/cinder/ceilometer: adding missing oslo dependenciesBruce Ashfield
oslo rootwrap was missing from the DEPENDS of these core projects. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-10-21horizon: reorder and update dependenciesBruce Ashfield
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>
2014-10-21horizon: update dependencies for juno rc2Bruce Ashfield
Updating the horizon dependent packages to the juno-rc2 required versions Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-10-17clients: update to juno release candidate versionsBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-10-17horizon: update to juno -rc1 candidateBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-10-17bootstrap-scss: introduce to meet horizon juno dependenciesBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-10-17core: update to juno-rc1 candidate releaseBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-10-14lxc: update bbappend to match meta-virtualization package versionBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-10-14libvirt: update bbappend to meta-virtualization latestBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-09-30add monitoring packagegroup into openstack buildVu Tran
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>
2014-09-30add generic monitor frameworkVu Tran
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>
2014-09-29housekeeping: Add a non-numeric PR prefix to allow PRINC in bbappendsMark Asselstine
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>
2014-09-29ceilometer: update to juno dependenciesBruce Ashfield
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>
2014-09-29keystone:Bruce Ashfield
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>
2014-09-26deploychef: use /etc/init.d/run-postinsts to execute scriptsMustapha Lansana
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>
2014-09-26openstack: restart daemons exposed by the following services in openstackMustapha Lansana
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>
2014-09-26cinder/glance/neutron: support for openstackchef classMustapha Lansana
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>
2014-09-26openstack: add support for openstackchef class to servicesMustapha Lansana
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>
2014-09-26openstack-base: support for openstackchef to hook into rootfs creationMustapha Lansana
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>
2014-09-26openstackchef: decentralized openstack-chef class implementationMustapha Lansana
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>
2014-09-26deploychef: result of adapting deploychef to openstackchef classMustapha Lansana
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>
2014-09-26deploychef: non functional changes to deploychef packageMustapha Lansana
Spelling mistake correction and sentence restructuring to the header section in recipe file. Signed-off-by: Mustapha Lansana <Mustapha.Lansana@windriver.com>
2014-09-26deploychef: adaptation of deploychef to support openstackchefMustapha Lansana
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>
2014-09-26deploychef: make chef-solo templates for openstack servicesMustapha Lansana
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>
2014-09-26deploychef: helper script and configuration filesMustapha Lansana
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>
2014-09-26deploychef: configure chef-solo for deploychef packageMustapha Lansana
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>
2014-09-26deploychef: makes chef-solo templates from openstack conf filesMustapha Lansana
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>
2014-09-26chef: resolve mismatch between branch name and SRCREVMustapha Lansana
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>
2014-09-24update to use new packagegroup-cephVu Tran
"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>
2014-09-22keystone: Change packages configuration to use apache keystone.Liam R. Howlett
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>