I certainly don't see any value there. You need to come up with a
non-strawman argument.
Configuration management is about consistency. Every system is like every
other system to the extent that is possible. Where it is not possible, you
describe that difference in the manifests such that it affects the minimum
number of systems. If, because of a mistake in your design, you later need
to go through and change everything, you've got a couple alternatives:
1) Do the change in two stages, where in the first stage you make the
change while at the same time removing any relevant Notify/Subscribe
clauses, and then after that is applied, you put the Notify/Subscribe
clauses back.
2) Make your change in the manifests and use a tool like Func or
MCollective or whatever to make the real change everywhere.
3) Trust that a rolling restart of your services is OK (because if it's
not, then you've probably screwed everything up even worse than you think).
4) Learn how to use selectors, quite possibly combined with
inline_templates or better yet, real data sources like Hiera, to limit the
changes.
Personally, I've done one green field Puppet implementation and two
retrofits, and guess what? I've wanted to fix file ownership/group/mode in
the first month of all three, and after that never needed to go back and do
that, and the initial fixups were due to mistakes on my part (like failure
to set reasonable defaults for File{}s in a module).
On Thu, Jun 14, 2012 at 12:29 PM, Jo Rhett <jrh...@netconsonance.com> wrote:
> On Jun 14, 2012, at 8:51 AM, David Schmitt wrote:
>
> When something changes the service has to be notified.
> When the service should not be restarted, puppet should not be running or
> the Service%restart parameter should be set to /bin/true.
>
>
> That's far too black/white for any real world scenario. Puppet not running
> just means it will catch it when it is, so that's not useful. And setting
> the restart parameter to bin/true would prevent content changes from
> restarting the process which defeats the purpose.
>
> You don't see any value in letting a service definition decide which
> things it cares to subscribe to -- like content, versus mode?
>
> --
> Jo Rhett
> Net Consonance : net philanthropy to improve open source and internet
> projects.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
