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

Use a bbclass to remove argparse from requirements

2015-12-11T17:11:31+00:00

argparse is required by some of the CLI applications of openstack. The module is provided by python 2.7, however python-distribute (used in fido), is not able to find it: Python 2.7.9 (default, Oct 27 2015, 18:12:55) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pkg_resources >>> pkg_resources.get_distribution('argparse') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/site-packages/distribute-0.6.49-py2.7.egg/pkg_resources.py", line 338, in get_distribution if isinstance(dist,Requirement): dist = get_provider(dist) File "/usr/lib/python2.7/site-packages/distribute-0.6.49-py2.7.egg/pkg_resources.py", line 217, in get_provider return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0] File "/usr/lib/python2.7/site-packages/distribute-0.6.49-py2.7.egg/pkg_resources.py", line 698, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.7/site-packages/distribute-0.6.49-py2.7.egg/pkg_resources.py", line 596, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: argparse >>> import argparse >>> This patch adds a class that when inherited will remove argparse from requirements.txt. Also with this patch, those python modules used by openstackclient inherit the class. Signed-off-by: Josep Puigdemont Signed-off-by: Bruce Ashfield

ruby.bbclass: Error fix

2015-12-11T17:11:29+00:00

When build the recipes which inherit ruby,ERROR will occur as following: ERROR: QA Issue: non debug package contains .debug directory: json path /work/core2-64-oe-linux/json/1.8.3-r0/packages-split/json/usr/lib/ruby/ gems/2.2.0/extensions/x86_64-linux/2.2.0/json-1.8.3/json/ext/.debug/generator.so [debug-files] So modify ruby.bbclass. Signed-off-by: Li Xin Signed-off-by: Bruce Ashfield

ruby.bbclass: WARNING Fix

2015-07-27T13:56:42+00:00

When build the recipes which inherit ruby,WARNING will occur as following: WARNING: QA Issue: mixlib-log: Files/directories were installed but not shipped in any package: /usr/lib/ruby/gems/2.2.0/build_info /usr/lib/ruby/gems/2.2.0/extensions Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install. [installed-vs-shipped] So modify ruby.bbclass Signed-off-by: Li Xin Signed-off-by: Bruce Ashfield

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