linux/meta-cloud-services.git/meta-openstack/classes, branch icehouse

identity.bbclass: update where to find run-postinsts script

2014-07-31T15:56:59+00:00

It's now 99, not 98 Signed-off-by: Amy Fong

aio: add support for identity.bbclass

2014-07-30T14:46:56+00:00

Signed-off-by: Amy Fong

Keystone: build time incremental/programatic user additions

2014-07-30T14:46:55+00:00

Instead of creating tenant/user/role and service/endpoint for all openstack services in keystone postinstall, now each of the services creates keystone identities by itself in its own postinstall. The exiting identity.bbclass has been re-written so that each of the individual postinstalls will queue up keystone identity creation in /etc/keystone/service-user-setup at runtime. And service-user-setup will be run as the last postinstall to create keytstone identities for all the services. Signed-off-by: Andy Ning

Add metadata service support to controller node

2014-06-18T19:08:11+00:00

The metadata service is working as the following: - metadata is being served by nova-api on controller at port 8775. - VM instance requests metadata by 169.254.169.254 (eg, curl http://169.254.169.254/latest/meta-data) - metadata request comes to neutron-ns-metadata-proxy on controller in dhcp network name space. - neutron-ns-metadata-proxy forwards the request to neutron-metadata-agent through a unix domain socket (/var/lib/neutron/metadata_proxy). - neutron-metadata-agent sends the request to nova-api on port 8775 to be serviced. To support metadata service, neutron-ns-metadata-proxy is baked into the controller image. Also neutron-metadata-agent startup script (/etc/init.d/neutron-metadata-agent) and config file (/etc/neutron/metadata_agent.ini) are added to start up metadata agent at system initialization. dhcp_agent.ini and nova.conf are updated as well. A README.metadata is added in the Documentation/ directory. Signed-off-by: Andy Ning Signed-off-by: Bruce Ashfield

ruby: Use en_US instead of C locale

2014-05-27T20:28:33+00:00

If a builder doesn't have the C locale an error can occur: | DEBUG: Executing shell function do_compile | /bin/sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8) | ERROR: While executing gem ... (ArgumentError) | invalid byte sequence in US-ASCII | WARNING: ..../mime-types-1.25.1-r0/temp/do_compile/run.do_compile.5389:95 exit 1 from | LANG="C.UTF-8" LC_ALL="C.UTF-8" gem build $gem | ERROR: Function failed: do_compile (see ..../mime-types-1.25.1-r0/temp/do_compile/log.do_compile.5389 for further information) Use the en_US locale instead which tends to be more widely available and from the looks of things usually recommended. Signed-off-by: Mark Asselstine

ruby.bbclass is incompatible with older python

2014-05-24T04:27:14+00:00

subprocess.check_output() doesn't exist in older python2.6* Rewriting as subprocess.Popen Signed-off-by: Amy Fong

Ruby/chef solo: fixes

2014-05-24T04:27:14+00:00

Make ruby binaries more accessible by creating symlinks from ${libdir}/ruby/gems/${ruby version}/bin/ to /usr/bin RDEPENDS needs to be package specific coderay needs to depends on yard Signed-off-by: Amy Fong

Ruby/chef solo: Add classes/ruby.bbclass

2014-05-24T04:27:13+00:00

In order to build chef we create a new ruby.bbclass to handle packaging ruby gems. The gem install technique we make use of avoids dependency issues which are not easily worked around yet care must be taken to ensure runtime dependencies are properly listed. Signed-off-by: Mark Asselstine Signed-off-by: Amy Fong

Readjust the start level of openstack components

2014-03-17T18:24:31+00:00

Currently all the openstack components have default start level of 20. There are other services such as glusterfs, rabbbitmq, database... are also starting at the same start level. On some platform, this can cause racing condition between services which in turn causes some of openstack components not started. By adjusting the openstack components start level to higher will ensure that system services start in the determistic way. Signed-off-by: Vu Tran Signed-off-by: Bruce Ashfield

openstack: create simple deployment framework

2013-10-03T05:15:42+00:00

To facilitate the creation of a simple OpenStack configuration with a single control and compute node, several things should be known at build time (since in this simple configuration, we are not using dhcp, or other name resolution techniques): - The IP of control node - The IP of the compute node - The IP of the node being built From these values, the OpenStack components and support applications (databases, access control, etc) are configured, as well as simple name resolution generated at build time. A single "hosts" bbclass should be provided with the following values: COMPUTE_IP ?= "192.168.7.4" COMPUTE_HOST ?= "compute" CONTROLLER_IP ?= "192.168.7.2" CONTROLLER_HOST ?= "controller" MY_IP ?= "${CONTROLLER_IP}" MY_HOST ?= "${CONTROLLER_HOST}" The above example is for a control node, using the runqemu default addresses. The openstack-base.bbclass is responsible for generating /etc/hosts and /etc/hostname. Any image type that requires these values at boot tiem, should inherit this class to allow its rootfs post population hooks to run and generate the required configuration. Signed-off-by: Bruce Ashfield