I have been meaning to ask you about this, so thanks for posting. I like the approach. Definitely a lot cleaner than the somewhat hardcoded dependencies and subscriptions that are in the modules now.
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? Mike From: Clayton O'Neill Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Monday, July 13, 2015 at 8:34 PM To: "OpenStack Development Mailing List (not for usage questions)" Subject: [openstack-dev] [puppet] puppet-designate POC implementation of virtualenv and docker support. 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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
