I managed to have a booboo tonight by restarting a process which really shouldn't be. What I ran into was that a mode change caused subscribe to fire and the process to restart.

Is it just me, or should subscribe/notify only fire on content changes?

Also given that "replace" only affects file contents, this means that you can never change the mode of a file for new installs only, either.  So it's always a risk of restarting a process.

And when I slapped myself over the head on this, I seemed to remember a discussion about making this granular. But I've searched and searched and I can't find the discussion. Can someone clue-by-4 me, or did I misremember this?

And if I did misremember, can anyone think of a reason that I shouldn't file a bug over this issue?  I have thought and thought and I just can't find a situation where I think that changing the mode should cause a refresh.  Owner or group in some circumstances, but not many. I think that the default should be content only, with an option to say "any attribute".

--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

its just you :P

sounds like replace should maybe be expanded to also support giving
other properties the same treatment perhaps?

I can think of a few, but really any case where a files mode out of the
box from say RPM prevent some other service from functioning because it
relies on this file.  File mode change -> dependant service restart.

Lots of daemons ship files like accessible only by $daemon:$daemon when
what we need is $daemon:$otherdaemon or maybe $daemon:$group_of_daemons.
You want to notice $otherdaemon that it can now read that file etc

On Jun 13, 2012, at 1:50 AM, R.I.Pienaar wrote:

Good point. I outright stole and p0wned your words here for http://projects.puppetlabs.com/issues/14998

--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

Hi,

On 06/13/2012 10:57 AM, Jo Rhett wrote:

(I don't think that's what 'pwning' means ;-)

This idea makes me somewhat unconfortable. I get the feeling that this
change would be a lot more fundamental than one might think.

To puppet, each and every resource has one (more or less complex) state,
and puppet either accepts this state or sees need to change it. If
changed, fire a notify to all subscribers. That's it.

What you're suggesting is a differentiation that has never existed in
this context (afaik). I'm not sure I feel good about opening this door -
I can easily see it become a gateway for lots of unintended effects to
trip users up.

As for your original problem, I don't see a good way of safeguarding
against this in puppet. Personally, I refrain from having puppet restart
services unless they are quite "safe", i.e. unlikely to stop working for
some reason. Usually I don't want to run the risk of having unattended
restarts at more or less random times, so for critical services - my
advice is to just do those by hand (or mcollective).

Cheers,
Felix

On Jun 14, 2012, at 12:22 AM, Felix Frank wrote:

How so?  The variable would allow the user to be explicit. As it stands now, I suspect most people would be surprised.

I am also very disconcerted about the issues involved in setting up new files.  You can never, ever, EVER change the mode of a newly installed file without restarting services on all existing machines.  That doesn't make any sense.

That's good for you, not good for us.  Having the variable would allow both of us to meet our needs, whereas not having the variable means that we must work your way.

--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

On 06/14/2012 12:39 PM, Jo Rhett wrote:

Maybe so, but if nothing else, current behaviour is very consistent,
which I consider a very redeeming quality.

One problem scenario I can see is users defining defaults for this
parameter, with the usual scoping behaviors that can easily confuse
(especially new) users.

I don't really understand your scenario. There is a new config file for
service X. It gets installed from a package, presumably the X package
itself. How are service restarts immediately after package installation
problematic?

On Jun 14, 2012, at 4:18 AM, Felix Frank wrote:

I am building new systems with a default file which is initialized just once. It looks like this

file { 'my-app.cfg':
    ensure => file,
    owner  => root,
    group => root,
    mode => 0644,
    replace => false,
    notify => Service['my-app'],

So when we first change the file the service is notified and restarted. Nice.  

Now, a few years down the road, we want to start initializing new systems like this:

    group => myapp,
    mode => 0664,

If we set this parameter, it will modify all existing files and restart the service on all existing hosts. This means, in essence, that I can't use a File object to do this, I must do it with an Exec to avoid the notify happening.  This is very non-optimal. If File is so limited that we must use Execs instead, I think we're missing the point of having a native File type.

--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

Hi,

On 06/14/2012 03:13 PM, Jo Rhett wrote:

I don't mean to be stubborn, but I still think this is a non-issue.

Puppet is not really meant to be used mainly for provisioning - it's for
managing the state of system configurations. I'm aware that in the real
world, there are a lot of situations when you want to modify your
provisioning process, but not interfere with existing installations. But
puppet is not and has never been very well suited for handling these
occurences.

So the "right" approach here is to ignore the mode in puppet, and adjust
your provisioning process to take care of it.

No, this is not very helpful advice ;-)

Regards,
Felix

On Jun 14, 2012, at 6:29 AM, Felix Frank wrote:

This type of functionality is not only possible, it is documented as intended for this purpose in the replace parameter. You are again falling down the rabbit hole of "I don't do it that way, so you shouldn't either."

The change I am requesting would be a trivial change, and would allow that kind of functionality. It wouldn't break you, so I don't see why you are objecting so hard.

--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

On 06/14/2012 03:44 PM, Jo Rhett wrote:

Huh, I was not aware of this parameter, to be honest. And I'd admit that
you do have a point saying that it's not sensible to limit this to file
content only but

this is a pretty severe allegation at which I do take offense.

I concur that the current feature set is a dangerous trap, but I find
the very idea of the replace parameter more questionable than its
semantical details.

But that's just me. I won't argue this point much further, I'm much more
curious about what the community thinks on the matter.

Felix

I agree.

To puppet, each and every resource has one (more or less complex) state,

Special cases are *always* problematic.  They are prone to bugginess, they
make systems harder to understand, and they tend to trip up the unwary.  
With respect to the last, I do think that the current behavior is less
likely to surprise users than the proposed one.  Right now, you only have
to know one rule about event firing: if any managed property is changed by
Puppet, then an event is fired.  Adding exceptions would make it easier to
surprise users.

Consider also how the proposed change might affect resources that subscribe
to the File in question instead of being notified by it.  It is not evident
in *their* declarations how the target resource is configured.  Would they
still receive all the events they ever did (so that there is an
inconsistency between the conditions triggering notifications and those
triggering subscriptions) or would events be filtered for forms (so that
subscribers can't tell what conditions will trigger events without
scrutinizing the target resource, wherever it might be declared)?

If finer grained event-handling behavior is desired, then it should be
implemented as a general-purpose facility instead of as a one-off special
case.  For instance, it is conceivable that a future version of Puppet
would allow for some kind of filter to be installed on notification and
subscription relationships, to control which events are passed through
based on which resource properties changed.  I don't imagine that could
happen before v3.1, however, if then.

As for your original problem, I don't see a good way of safeguarding

I concur, and I do not favor implementing resource-specific special rules
to provide such a safeguard.  If it's essential to your operation, however,
then you (Jo) have the source, so you can implement the behavior change you
want for your own site.  If you are prepared to contribute a patch to
Puppetlabs then that would even make it more likely that the change would
be accepted into the core (over Felix's objections and mine).

John

On 14.06.2012 16:09, Felix Frank 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.

Best Regards, David

On Jun 14, 2012, at 8:51 AM, David Schmitt wrote:

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.

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 14.06.2012 21:29, Jo Rhett wrote:

No. I'm saying that either you need to manage (outside of puppet) when
your services restart OR you don't care when your services restart.

In the first case I'd want to run puppet with --noop for
consequence-checking and only run it "hot" in a maintenance window. In
the second case the whole discussion is moot anyways.

Best Regards, David

You could conceivably combine that general idea with tags, so as to apply
only changes considered safe on most puppet runs, but allow everything to
be applied together in maintenance windows.  Getting the tags (only) in the
right places could be tricky, and you would need to carefully weigh the
consequences, but it should be possible to do what you want this way.

John

On Thu, Jun 14, 2012 at 11:20 AM, jcbollinger <John.Bollin...@stjude.org>wrote:

Like most other posters so far I think that this would be such
a fundamental change that it should come in a major version if anything.  I
wouldn't be opposed to the idea of being able to filter on parameters when
doing a subscribe/notify, maybe a filter meta-parameter along the line of
filter => ['source', 'owner' ], but like most people I feel this adds a lot
of complexity for very little gain.  I would prefer to simply schedule the
puppet run that changes the mode and causes a service restart to occur out
of hours and take the restart downtime.  I feel it keeps things simple to
retain the existing concept of notify.

Thanks,

On Jun 15, 2012, at 12:35 AM, David Schmitt wrote:

I find this odd, since more than 90% of the parameters that puppet provides for configuration management meet the same basic need that you are saying shouldn't be done.  I could easily rewrite your statement as:

 No. I'm saying that either you need to manage (outside of puppet) when your (resource) are updated OR you don't care when your resources are updated.
        --schedules handles this

No. I'm saying that either you need to manage (outside of puppet) when where an exec is run OR you don't care whether an exec is run.
        --onlyif and --unless handle this.

No. I'm saying that either you need to manage (outside of puppet) whether a resource is updated OR you don't care whether a resource is updated.
        --require handles this

I could go on and on and on.  What I propose is entirely in line with the functionality of puppet today.

I find this whole discussion very interesting, in that it shows just how small of a team most puppet sites are.  I can't fathom modifying a template to push out a change, and being able to prevent that puppet client from picking up the change before the next maintenance window. It's just not possible in any reasonably sized site.

I'm thinking of sites where you edit a policy and two seconds later someone on a different team "kicks" the host for an entirely different reason. And perhaps they should have used a tag to limit what they kicked, but perhaps they forgot. Or perhaps their module depends on yours so they so added your module as a tag.

And if you --noop the resource, it can actually prevent anything in their module from making the changes they are trying to activate.

Puppet schedules do not allow for real maintenance windows.  You can't limit which days of the week, for instance.

I'm being serious here -- what I propose is entirely in line with what puppet does today, ensure consistency, and what you are proposing is that puppet shouldn't be involved in maintaining consistency.

--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

On Jun 15, 2012, at 7:16 AM, jcbollinger wrote:

Unfortunately you can't use tags to limit whether or not something happens. I have a bug open on this. I'd love to say "only take this action when a tag is set" but this doesn't work.  The only thing you can do is put *EVERY* tag inside the puppet.conf for every host except the tags you want to use to limit actions.  At even this fairly small install I'm working on right now, the total tag list is well over 200 entries and growing 8-10 a day.  Maintaining that tag list for puppet.conf isn't impossible, but would be very difficult.

It's very bizarre in that we have a function tagged() but it only checks if the resource itself is tagged a certain way. I suspect this is only useful in defines which can be called from multiple points.

http://projects.puppetlabs.com/issues/11148

--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

On Jun 15, 2012, at 10:00 AM, Ashley Penney wrote:

Not all things can be restarted after they are operating.  Some things need to be initialized restarted, and then never restarted again unless there is a good reason (like a configuration change). Saying "oh just restart it anyway makes no sense".  Why have refreshonly => true if that was so?

But your main argument is:

It's an odd phenomena, in that this wouldn't affect anyone not using the filter at all, but because they don't see a need for it they will object to someone else having the functionality.

--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

No, but you don't need that for this purpose.

What you describe would indeed be unreasonably difficult to maintain, but
you don't need to do that.  You can instead assign some for-purpose tag of
your choosing (e.g. "safe") to all resources you consider safe to modify at
any time.  Then you only have to worry about that one tag.  Moreover, you
then control what is considered safe from your manifests, instead of from
nodes' local config files, and you can even switch safety on and off for
specific resources if you should ever need to do.

John

I think you are misinterpreting David.  Based on both his initial comment
and his followup clarification, he seems to be talking about how you need
to use the Puppet of today, not debating the merit of your change proposal.

You seem to be interpreting many of the responses as assertions that you
shouldn't want what you're asking for.  I don't think anyone is saying
that, at least not at the level of generality at which you responded to
David.  On the other hand, several people, myself included, have expressed
valid concerns about the specific way you suggest enabling your desired
behavior.  I cannot speak for the other participants, but so far you have
not addressed those concerns to my satisfaction.

John

I figure I should clarify a little bit.  Unless my understanding of Puppet
internals is way off it would be quite a lot of work to add the filter as
it stands.  A lot of code would have to change internally to make it
capable of filtering on parameters.  By complexity I meant code wise, not
puppet manifest/syntax wise.  I just meant that it would take a lot of
development to get it working consistently and properly as a metaparam
throughout the codebase.  It would be nice to hear from someone at
puppetlabs just how difficult this would be to add based on the 3.0
codebase.

Again, this is small-shop thinking. That's not manageable with multiple diverse teams, all of whom have different needs and different ideas of what is considered safe.  It also requires one additional tag to every resource, which would be easily 1000 lines in this site already and its still small.

if-else around tags would be a huge improvement.

On Jun 15, 2012, at 2:40 PM, jcbollinger wrote:

--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

On Jun 15, 2012, at 3:13 PM, jcbollinger wrote:

I just went back and re-read every complaint, and they can all be summed up in

1. Too much complexity for too little gain (both of which are very subjective)
2.  You shouldn't use puppet for that.

The second one requires replacing puppet with a configuration management system which can do the job, so it's an odd thing for everyone to suggest.  There hasn't been a single comment about the technical merits of this change - even from yourself.

It's also funny that everyone says "this should be a major version number change" without considering that this is exactly what I am asking, since we are on the verge of a major version number upgrade.

--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.