Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
It's now 99, not 98
Signed-off-by: Amy Fong <amy.fong@windriver.com>
|
|
Signed-off-by: Amy Fong <amy.fong@windriver.com>
|
|
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>
|
|
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>
|
|
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>
|
|
subprocess.check_output() doesn't exist in older python2.6*
Rewriting as subprocess.Popen
Signed-off-by: Amy Fong <amy.fong@windriver.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Mihai Prica <prica.mihai@gmail.com>
|
|
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>
|
|
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>
|