<div dir="ltr">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).<div><br></div><div>The puppet-designate change to support this can be found here:  <a href="https://review.openstack.org/#/c/197172/">https://review.openstack.org/#/c/197172/</a></div><div><br></div><div>The supporting puppet-designate_ext module can be found here: <a href="https://github.com/twc-openstack/puppet-designate_ext">https://github.com/twc-openstack/puppet-designate_ext</a></div><div><br></div><div>The basic approach is to split the module dependency chain into 3 phases:</div><div><br></div><div> * install begin/end</div><div> * config begin/end</div><div> * service begin/end</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div>