Open Stack

On Wed, Aug 12, 2015 at 2:15 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:

> 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.
>
I am in favor of the managed/unmanaged parameter (I don't have a preference
for the default).

Managing the state of a service is one of the most fundamental features of
puppet[1]. Downstream users of a puppet module will always expect the
module to install packages, change config files, and start services. They
are expecting puppet to do automate everything within a single node. If
they are doing maintenance and they do not want packages installed, config
files changed, or services started, they will disable puppet during the
maintenance window. While this does not appear to fit in with Infra's
workflow, it is a valid use case for downstream users and I believe it
should be allowed via a parameter. Of course documenting the unexpected
behavior is the next best thing.

Colleen

[1] https://docs.puppetlabs.com/puppet_core_types_cheatsheet.pdf

> --
> Jeremy Stanley
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20150813/c97d4ffe/attachment.html>