Update master for stable/2026.1
Add file to the reno documentation build to show release notes for stable/2026.1.
Use pbr instruction to increment the minor version number automatically so that master versions are higher than the versions on stable/2026.1.
Sem-Ver: feature Change-Id: Ide31abb46e0ec2d995296fc03e42df5800007be3 Signed-off-by: OpenStack Release Bot infra-root@openstack.org Generated-By: openstack/project-config:roles/copy-release-tools-scripts/files/release-tools/add_release_note_page.sh
版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802047560号
Team and repository tags
openstacklib
Table of Contents
Overview
The openstacklib module is a part of OpenStack, an effort by the Openstack infrastructure team to provide continuous integration testing and code review for Openstack and Openstack community projects not part of the core software. The module itself is used to expose common functionality between Openstack modules as a library that can be utilized to avoid code duplication.
Module Description
The openstacklib module is a library module for other Openstack modules to utilize. A thorough description will be added later.
This module is tested in combination with other modules needed to build and leverage an entire Openstack software stack.
Setup
Installing openstacklib
Usage
Classes and Defined Types
Defined type: openstacklib::db::mysql
The db::mysql resource is a library resource that can be used by nova, cinder, ceilometer, etc., to create a mysql database with configurable privileges for a user connecting from defined hosts.
Typically this resource will be declared with a notify parameter to configure the sync command to execute when the database resource is changed.
For example, in heat::db::mysql you might declare:
Some modules should ensure that the database is created before the service is set up. For example, in keystone::db::mysql you would have:
** Parameters for openstacklib::db::mysql: **
password_hashPassword hash to use for the database user for this service; string; required
dbnameThe name of the database string; optional; default to the $title of the resource, i.e. ‘nova’
userThe database user to create; string; optional; default to the $title of the resource, i.e. ‘nova’
hostThe IP address or hostname of the user in mysql_grant; string; optional; default to ‘127.0.0.1’
charsetThe charset to use for the database; string; optional; default to ‘utf8’
collateThe collate to use for the database; string; optional; default to ‘utf8_general_ci’
allowed_hostsAdditional hosts that are allowed to access this database; array or string; optional; default to undef
privilegesPrivileges given to the database user; string or array of strings; optional; default to ‘ALL’
Defined type: openstacklib::db::postgresql
The db::postgresql resource is a library resource that can be used by nova, cinder, ceilometer, etc., to create a postgresql database and a user with configurable privileges.
Typically this resource will be declared with a notify parameter to configure the sync command to execute when the database resource is changed.
For example, in heat::db::postgresql you might declare:
Some modules should ensure that the database is created before the service is set up. For example, in keystone::db::postgresql you would have:
** Parameters for openstacklib::db::postgresql: **
password_hashPassword hash to use for the database user for this service; string; required
dbnameThe name of the database string; optional; default to the $title of the resource, i.e. ‘nova’
userThe database user to create; string; optional; default to the $title of the resource, i.e. ‘nova’
encodingThe encoding use for the database; string; optional; default to undef
privilegesPrivileges given to the database user; string or array of strings; optional; default to ‘ALL’
Defined type: openstacklib::service_validation
The service_validation resource is a library resource that can be used by nova, cinder, ceilometer, etc., to validate that a resource is actually up and running.
For example, in nova::api you might declare:
This defined resource creates an exec-anchor pair where the anchor depends upon the successful exec run.
** Parameters for openstacklib::service_validation: **
commandCommand to run for validating the service; string; required
service_nameThe name of the service to validate; string; optional; default to the $title of the resource, i.e. ‘nova-api’
pathThe path of the command to validate the service; string; optional; default to ‘/usr/bin:/bin:/usr/sbin:/sbin’
providerThe provider to use for the exec command; string; optional; default to ‘shell’
triesNumber of times to retry validation; string; optional; default to ‘10’
try_sleepNumber of seconds between validation attempts; string; optional; default to ‘2’
Defined provider for openstack_config: ini_setting
It provides an interface to any INI configuration file as they are used in Openstack modules.
You use it like this:
It has the standard features of the upstream puppetlabs’
inifilemodule as it’s a direct children of it. Furthermore it can transform a value with some function of you’re choice, enabling you to get value that get filled at run-time like anuuid.For an example of how that’s working you can have a look at this review
Defined provider for openstack_config: ruby
This one has the same basic features as the ini_setting one but the ability to transformation the value. It offers another feature, though. It can parse array. What it enables one to do is to parse this correctly:
On the opposite side if you put that:
in your manifest, it will properly be written as the example above.
To use this provider you use this:
and define you type with
:array_matching => :all. An example of such provider isnova_config. Have a look for inspiration.Implementation
openstacklib
openstacklib is a combination of Puppet manifest and ruby code to delivery configuration and extra functionality through types and providers.
Limitations
The python-migrate system package for RHEL 6 and below is out of date and may fail to correctly migrate postgresql databases. While this module does not handle database migrations, it is common to set up refresh relationships between openstacklib::db::postgresql resource and the database sync exec resource. Relying on this behavior may cause errors.
Development
Developer documentation for the entire puppet-openstack project.
Contributors
Release Notes
Repository