linux/meta-cloud-services.git/meta-openstack/recipes-support, branch dizzy-juno

tgt: update to v1.0.37

2015-07-14T18:38:19+00:00

Signed-off-by: Daniel Badea Signed-off-by: Bruce Ashfield

salt: upgrade to 2015.5

2015-06-01T16:12:53+00:00

python-request is now only a dependency of salt-cloud. Signed-off-by: Alejandro del Castillo Signed-off-by: Bruce Ashfield

salt: add recipe for salt

2015-06-01T16:12:49+00:00

Signed-off-by: Alejandro del Castillo Signed-off-by: Bruce Ashfield

openldap: drop bbappend

2015-05-21T18:58:54+00:00

The bbappend in meta-openstack breaks the meta-oe recipe's do_install_append, so we drop it for now. This assumes that the default recipe and install is sufficient for users. Signed-off-by: Bruce Ashfield

iproute2: remove patch already applied

2015-05-21T18:49:23+00:00

Remove the patch 0003-Don-t-enforce-that-dev-already-exists.patch as the similar patch exist in poky git repo added by commit 673bb3cffc1fdedb7c25178233c8699650194545 Author: Roy.Li Date: Wed Oct 29 14:01:07 2014 +0800 Signed-off-by: Tudor Florea Signed-off-by: Bruce Ashfield

hiera: add recipe for hiera 1.3.4

2014-12-18T17:59:52+00:00

Signed-off-by: Bruce Ashfield

facter: add recipe for facter 2.3.0

2014-12-18T17:59:52+00:00

Signed-off-by: Bruce Ashfield

puppet: add recipe for puppet 3.7.3

2014-12-18T17:59:52+00:00

A simple demo is added Signed-off-by: Bruce Ashfield

deploychef: use /etc/init.d/run-postinsts to execute scripts

2014-09-26T13:09:22+00:00

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

openstack: add support for openstackchef class to services

2014-09-26T13:09:22+00:00

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