aboutsummaryrefslogtreecommitdiffstats
path: root/meta-openstack/classes
AgeCommit message (Collapse)Author
2017-11-15python-*: fixup postinst scriptsMark Asselstine
Checking for "$D" and doing an "exit 1" now results in errors such as: [log_check] warning: %post(keystone-cronjobs-...) scriptlet failed, exit status 2 during image creation. Instead of escaping the script for "level-1" (image creation postinst) we wrap the "level-2" (first boot) postinst in an if statement. This also ensure the scriptlet in indentity.bbclass is less prone to behaving differently based on the postinsts defined in the classes which inherit 'identity'. Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2017-01-09chef: remove the use of chefMark Asselstine
The use of chef was never complete, had isses with updating binary database files and had a cumbersome implementation. Since we are using Ansible in meta-overc we are dropping the use of chef here and will look to being at par with meta-overc by using Ansible if/when we get time to look at runtime configuration in meta-cloud-services. Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2016-12-21identity: make work with python 3Mark Asselstine
dict.has_key has been deprecated for a while and officiall removed in python 3, instead we need to use 'key in'. Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2016-12-21housekeeping: replace deprecated base_containsMark Asselstine
Fixes: base_contains is deprecated, please use bb.utils.contains instead. Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2016-12-20housekeeping: drop usage of bb.data.getVar()Mark Asselstine
Similar to oe-core commit 2864ff6a4b3c3f9b3bbb6d2597243cc5d3715939 the bb.data.getVar() have been deprecated for enough time now that it has been removed. We need to switch to the new getVar() to get things working again. Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2016-09-22identity.bbclass: Fix python synthax errormortyAdrian Dudau
Signed-off-by: Adrian Dudau <adrian.dudau@enea.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2016-09-19identity.bbclass: Enforce octal literal representation in os.chmodAdrian Dudau
Python 3 changed to the explicit representation and throws errors otherwise. Signed-off-by: Adrian Dudau <adrian.dudau@enea.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2016-09-19openstackchef_inc.bbclass: Update python synthax for exceptAdrian Dudau
The synthax used is deprecated and causes errors. Signed-off-by: Adrian Dudau <adrian.dudau@enea.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2016-03-21openstackchef: add missing parameter to getVarMark Asselstine
Builds are failing with: File: 'openstackchef_inc.bbclass', lineno: 624, function: deploychef_add_file_to_FILES_PN 0620: pkg_files = "FILES_%s" % pkg 0621: ldata.setVar("OVERRIDES", "%s:%s" % (pkg_files, overrides)) 0622: bb.data.update_data(ldata) 0623: *** 0624: dest_base = d.getVar('CHEF_TEMPLATE_BASE') 0625: pkg_imagedir = d.getVar('CHEF_ROOTFS_BASE', True) 0626: #Add the packages image base directory if it does not already exist 0627: if re.search(pkg_imagedir, files) == None: 0628: #All the directory and all files in it Exception: TypeError: getVar() takes at least 3 arguments (2 given) Add the required parameter to fix the build. Chef is planned to be removed from this layer in the near future, so this change is not tested. Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2015-12-11Use a bbclass to remove argparse from requirementsJosep Puigdemont
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 "<stdin>", line 1, in <module> 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 <josep.puigdemont@enea.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2015-09-16ruby.bbclass: move to base layerMark Asselstine
In commit 1aa30310259027ebb87ee95ef914ca3de55d6a09 [puppet: move to base layer] we made puppet available to all sub-layers but since we didn't move the required ruby.bbclass we couldn't actually use it without using meta-openstack. Complete the move by moving the ruby.bbclass to the base layer. At some point I think we still want to remove ruby.bbclass from meta-cloud-services completely and use meta-ruby, but we will do that at another time. Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2015-08-10ruby.bbclass: Error fixLi xin
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 <lixin.fnst@cn.fujitsu.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2015-07-27ruby.bbclass: WARNING FixLi xin
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 <lixin.fnst@cn.fujitsu.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2015-02-19chef: make deploychef dependencies a distro featureBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@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-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-07-31identity.bbclass: update where to find run-postinsts scriptAmy Fong
It's now 99, not 98 Signed-off-by: Amy Fong <amy.fong@windriver.com>
2014-07-30aio: add support for identity.bbclassAmy Fong
Signed-off-by: Amy Fong <amy.fong@windriver.com>
2014-07-30Keystone: build time incremental/programatic user additionsAndy Ning
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 <andy.ning@windriver.com>
2014-06-18Add metadata service support to controller nodeAndy Ning
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 <andy.ning@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-05-27ruby: Use en_US instead of C localeMark Asselstine
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 <mark.asselstine@windriver.com>
2014-05-24ruby.bbclass is incompatible with older pythonAmy Fong
subprocess.check_output() doesn't exist in older python2.6* Rewriting as subprocess.Popen Signed-off-by: Amy Fong <amy.fong@windriver.com>
2014-05-24Ruby/chef solo: fixesAmy Fong
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 <amy.fong@windriver.com>
2014-05-24Ruby/chef solo: Add classes/ruby.bbclassAmy Fong
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 <mark.asselstine@windriver.com> Signed-off-by: Amy Fong <amy.fong@windriver.com>
2014-03-17Readjust the start level of openstack componentsVu Tran
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 <vu.tran@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2013-10-03openstack: create simple deployment frameworkBruce Ashfield
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 <bruce.ashfield@windriver.com>
2013-08-28nova: split into explicit compute and controller recipesBruce Ashfield
To allow unique configuration of nova for compute and controller nodes, the nova class is split into two, but packaged largely the same way. The compute and controller classes are introduced to hold configuration values and operations that are used by the common packaging routines to customize and deploy. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2013-08-28identity: Set ADMIN_PASSWORD from identity classMihai Prica
Signed-off-by: Mihai Prica <prica.mihai@gmail.com>
2013-08-28postgresql: Made the postgresql credentials configurableMihai Prica
The user and password for postgresql are defined in the identity class and are loaded by the recipes from this class. Signed-off-by: Mihai Prica <prica.mihai@gmail.com>
2013-08-28identity.bbclass: Added new classMihai Prica
Each service(nova, glance, cinder...) has its own keystone user. These users are created in a postinstall for the keystone package. This new class is used to store some of the credentials used by keystone and all packages will inherit this class and create the appropriate configuration files. Signed-off-by: Mihai Prica <prica.mihai@gmail.com>