|Age||Commit message (Collapse)||Author||Files||Lines|
We only create the /etc/puppet/modules symlinks during image building,
so as we update the openstack-puppet-modules RPM during the lifecycle
of a deployment, the symlinks can get out of date and some modules
This patch adds modulepath for puppet deployments, getting rid of the
need for our Puppet modules to be symlinked from /etc/puppet/modules. If
there are some already symlinked, they will take precedence. Also
modules installed from source to /opt/stack/puppet-modules will take
precedence over packaged modules in /usr/share/openstack-puppet/modules.
This moves the ringbuilder puppet code to puppet-tripleo
and migrates to the composable services format.
This patch wires in a new for Mitaka Heat feature
that allows us to dynamically include a set of nested
stacks representing individual services via a Heat resource chain.
Follow on patches will use this interface to decompose the controller
role into isolated services.
Co-Authored-By: Steve Hardy <firstname.lastname@example.org>
This patch wires in ringbuilder.pp so that it is always
asserted like the other manifests and it fixes the misaligned
step sequencing in calling our overcloud controller manifests.
Previously it was called as a separate software deployment outside of
the hiera step sequence. This made things confusing in
controller-post.yaml since the deployment names didn't align
with the step hiera variables after step 3. Now that we call it
just like the other modules it should make gradually moving this
code to puppet-tripleo more straightforward as well.
Also adds an environment file which can be passed to heat stack-create
to enable debugging.
This patch bumps the HOT version for the overcloud
to Kilo 2015-04-30. We should have already done this
since we are making use of OS::stack_id (a kilo feature)
in some of the nested stacks. Also, this will give us access to
the new repeat function as well.
This patch adds support for using the Heat resource registry
so that end users can enable pacemaker. Using this approach
allows us to isolate all of the pacemaker logic for the
controller in a single template rather than use conditionals
for every service that must support it.