Open Stack

Last year I put together a virtualenv patch for the Designate puppet
module, but the patch was too invasive of a change and too opinionated to
be practical to merge.  I've taken another shot at this with the approach
of implementing well defined hooks for various phases of the module. This
should  allow external support for alternative ways of installing and
running services (such as virtualenv, and docker).  I think this patch is
now mostly ready for some outside reviews (we'll be running the virtualenv
support in production soon).

The puppet-designate change to support this can be found here:
https://review.openstack.org/#/c/197172/

The supporting puppet-designate_ext module can be found here:
https://github.com/twc-openstack/puppet-designate_ext

The basic approach is to split the module dependency chain into 3 phases:

 * install begin/end
 * config begin/end
 * service begin/end

Each of these phases have a pair of corresponding anchors that are used
internally for dependencies and notifications.  This allows external
modules to hook into this flow without having to change the module.  For
example, the virtualenv support will build the virtualenv environment
between the designate::install::begin and designate::install::end anchors.
Additionally, the virtualenv support will notify the
designate::install::end anchor.  This allows other resources to subscribe
to this anchor without needing to know if the software is being installed
as a package, virtualenv, or docker image.

I think this approach could be applied mostly as is to at least some of the
existing modules with similar levels of changes.  For example, horizon,
keystone & heat would probably be fairly straightforward.  I suspect this
approach would need refinement for more complex services like neutron and
nova.  We would need to work out how to manage things like external
packages that would still be needed if running a virtualenv based install,
but probably not needed if running a docker based install.  We would
probably also want to consider how to be more granular about service
notifications.

I'd love to get some feedback on this approach if people have time to look
it over.  We're still trying to move away from using packages for service
installs and I'd like to figure out how to do that without carrying
heavyweight and fragile patches to the openstack puppet modules.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150713/db8dfe3a/attachment.html>