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

chef: make deploychef dependencies a distro feature

2015-02-20T03:50:09+00:00

Signed-off-by: Bruce Ashfield

add generic monitor framework

2014-09-30T18:30:18+00:00

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_ to indicate what processes should should be monitored. Also MONITOR_CHECKS_ 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 Signed-off-by: Bruce Ashfield

openstack-base: support for openstackchef to hook into rootfs creation

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

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

openstackchef: decentralized openstack-chef class implementation

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

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

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

2014-07-31T15:57:23+00:00

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

aio: add support for identity.bbclass

2014-07-30T04:50:59+00:00

Signed-off-by: Amy Fong

Keystone: build time incremental/programatic user additions

2014-07-30T04:50:59+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