<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div>I have been meaning to ask you about this, so thanks for posting.</div>
<div><br>
</div>
<div>I like the approach. Definitely a lot cleaner than the somewhat hardcoded dependencies and subscriptions that are in the modules now.</div>
<div><br>
</div>
<div>Do you envision that long term the docker/venv/whatever else implementation (like you have in designate_ext) would actually be part of the upstream Puppet module? Or would we provide the hooks that you describe, and leave it up to other modules to handle
the non-package-based installs?</div>
<div><br>
</div>
<div>Mike</div>
<div><br>
</div>
<div>
<div id="MAC_OUTLOOK_SIGNATURE"></div>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:12pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Clayton O'Neill<br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)"<br>
<span style="font-weight:bold">Date: </span>Monday, July 13, 2015 at 8:34 PM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)"<br>
<span style="font-weight:bold">Subject: </span>[openstack-dev] [puppet] puppet-designate POC implementation of virtualenv and docker support.<br>
</div>
<div><br>
</div>
<div>
<div>
<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>
</div>
</div>
</span>
</body>
</html>