Open Stack

Change https://review.openstack.org/168306 for puppet-zuul came to
my attention earlier today when it merged. After a quick discussion
on IRC, Spencer proposed a revert which I approved so that we can
get a little more discussion going about this topic.

First, I'm really sorry I didn't see and weigh in on it sooner (it's
not like I didn't have time, it was ~4.5 months old). Second, we've
grown lots of new core reviewers and I'm thrilled they're reviewing
and approving changes, and I don't want to discourage that in any
way, so thank you to those of you who did review that change.

In the past, not using ensure=>running on services in our Puppet
modules was intentional, particularly for more stateful services,
especially for services which trigger other (possibly remote)
actions and have a potential to make a mess. It's pretty likely that
those of us who were around for the earlier discussions about it
failed to write it down anywhere obvious, leading others to assume
it's a bug/oversight. I see a couple of obvious solutions though
there are no doubt others:

1. Document in each module where we do this, at least in the readme
and probably also in an inline comment around the service
definition, that it's that way on purpose. Optionally, make the
ensure conditional on a class parameter that defaults to unmanaged
in case some downstreams want to use Puppet like a service manager.

2. Similar managed/unmanaged parameter, but make it default to
running and override the default to unmanaged in our
::openstack_project classes. This means that we cease consuming our
modules with the same defaults as downstream users, however if it
turns out that our OpenStack Infra root sysadmins really do have a
very different preference from the majority of our downstream
consumers then at least we can be clear about that.
-- 
Jeremy Stanley