can we avoid notify/subscribe firing on a mode change?

[Jo Rhett]

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.

[R.I.Pienaar]

----- Original Message -----
> From: "Jo Rhett" <jrh...@netconsonance.com>
> To: puppet...@googlegroups.com
> Sent: Wednesday, June 13, 2012 9:33:35 AM
> Subject: [Puppet Users] can we avoid notify/subscribe firing on a mode change?
>
> 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?

its just you :P

> 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.

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

> 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".

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

[Jo Rhett]

On Jun 13, 2012, at 1:50 AM, R.I.Pienaar wrote:
> 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

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

[Felix Frank]

Hi,

On 06/13/2012 10:57 AM, Jo Rhett wrote:
> On Jun 13, 2012, at 1:50 AM, R.I.Pienaar wrote:
>> 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
>
>
> Good point. I outright stole and p0wned your words here for http://projects.puppetlabs.com/issues/14998

(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

[Jo Rhett]

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

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.

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.

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

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.

[Felix Frank]

On 06/14/2012 12:39 PM, Jo Rhett wrote:
>> 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.
>
> How so? The variable would allow the user to be explicit. As it stands
> now, I suspect most people would be surprised.

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 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.

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?

[Jo Rhett]

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.

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

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?

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.

[Felix Frank]

Hi,

On 06/14/2012 03:13 PM, Jo Rhett wrote:
>
> 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.

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

[Jo Rhett]

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

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

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.

[Felix Frank]

On 06/14/2012 03:44 PM, Jo Rhett wrote:
> This type of functionality is not only possible, it is documented as
> intended for this purpose in the replace parameter. You are again

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

> falling down the rabbit hole of "I don't do it that way, so you
> shouldn't either."

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

[jcbollinger]

On Thursday, June 14, 2012 2:22:44 AM UTC-5, Felix.Frank wrote:

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

I agree.
 

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.

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
against this in puppet.

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

[David Schmitt]

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

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

[Jo Rhett]

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?

[Brian Gallew]

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).

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[David Schmitt]

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

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

[jcbollinger]

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

[Ashley Penney]

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

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.

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,

[Jo Rhett]

On Jun 15, 2012, at 12:35 AM, David Schmitt 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.

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.

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.

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]

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

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.

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]

On Jun 15, 2012, at 10:00 AM, Ashley Penney 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.

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:

 but like most people I feel this adds a lot of complexity for very little gain. 

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.

[jcbollinger]

On Friday, June 15, 2012 1:36:41 PM UTC-5, Jo wrote:

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

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.

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.

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

 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.

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

[jcbollinger]

On Friday, June 15, 2012 1:26:08 PM UTC-5, Jo wrote:

On Jun 15, 2012, at 12:35 AM, David Schmitt 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.

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: [...]

 

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

[Ashley Penney]

On Fri, Jun 15, 2012 at 2:41 PM, Jo Rhett <jrh...@netconsonance.com> wrote:

But your main argument is:

 but like most people I feel this adds a lot of complexity for very little gain. 

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.

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. 

[Jo Rhett]

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:

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

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/6BaMhZBvO60J.

To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Jo Rhett]

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

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.

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]

On Jun 15, 2012, at 3:25 PM, Ashley Penney wrote:

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. 

I've looked at the code. It requires changing the triggers to have attributes, which is honestly a fairly trivial change and likely backwards compatible with anything today, too. Look at Puppet::Relationship.match? () -- it's accepts the idea of event types, but only has triggers for :ALL_EVENTS or :NONE.

That or else could be replaced with specific event types being passed quite easily.  Then each object would have to be modified to accept a revised syntax in the situation (optional) where only specific types are desired.

It really doesn't appear to be a large change.

[Brian Gallew]

As has already been suggested, make the change yourself, submit a patch.  You have indicated several times that this isn't that big a change.  Further, it's a change that is clearly only of benefit to you at this point, so trying to convince others to do it for you is pointless.  If you *really* want Puppetlabs to do the change for you, then buy a support contract and have them do it.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

[Ashley Penney]

On Fri, Jun 15, 2012 at 8:36 PM, Jo Rhett <jrh...@netconsonance.com> wrote:

I've looked at the code. It requires changing the triggers to have attributes, which is honestly a fairly trivial change and likely backwards compatible with anything today, too. Look at Puppet::Relationship.match? () -- it's accepts the idea of event types, but only has triggers for :ALL_EVENTS or :NONE.

That or else could be replaced with specific event types being passed quite easily.  Then each object would have to be modified to accept a revised syntax in the situation (optional) where only specific types are desired.

It really doesn't appear to be a large change.

I think the path forward at this point is probably to put together a rough patch that does what you're looking for.  In my experience the puppetlabs guys are very helpful about answering questions and helping improve patches once a pull request/issue has been raised. I'd be shocked if they didn't at least give you some solid feedback on getting this included.

Thanks,

[Felix Frank]

Jo,

this thread is starting to confuse me, I am no longer sure what you're
suggesting, precisely.

a) Make it possible to nullify notifications under certain circumstances.
b) Make it possible to ignore file owner/mode for files that exist already.

While (b) is rather tasteless to me (as is the whole "replace"
parameter), it is certainly well in line of what's possible today, so I
wouldn't object too much.
(a) is a nightmare I hope you're not invested in.

> 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.

This statement in itself is interesting as well. I believe that most
sites, large or small, don't face this particular problem at all,
because most of its incarnations are handled by manifest code control.
If a change goes to production, it better work, otherwise whoever pushed
to production has to answer for the breakage.

Of course, there may be sites that (for any number of reasons) cannot
adopt such a model(?)

On 06/15/2012 08:41 PM, Jo Rhett 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?

I don't mean to imply that we shouldn't have this whole discussion, but
the above example is hardly an argument in my humble optinion.

If you have a service that should under no circumstances be restarted
unattended, then for crying out loud, do not make it consume resource
notifications from puppet. That's begging for trouble.

Yeah, sorry for derailing this again ;-)

Best,
Felix

[David Schmitt]

On 16.06.2012 02:21, Jo Rhett wrote:
> On Jun 15, 2012, at 3:13 PM, jcbollinger wrote:
>> 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.
>
> 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.

I say "running puppet *hot* on a system *when* restarting a service
might create a booboo is a bad idea." Emphasis on *hot* and *when*. For
both emphasises, there are solutions (noop, cron, schedules,
mcollective, dssh). Using a different CM is not likely to solve that
unless you're willing to go the build-freeze-scrap route.

The core of this runs into organizational realms like "Change
Management", which are not in scope for the puppet master/agent. At the
clients I work for, Rule #1 is "do not push into production." Even some
of the outward-facing "test" systems have sensitive times when clients
are testing. Developing changes and actually applying them are two VERY
separate activities. You might want to look into git-flow to
dis-entangle development, teams, and integration.

Do the cowboy-style sites have a quicker turn-over? You bet. Do they
have the same uptime and stability requirements? Hell, no.

Best Regards, David

[Jo Rhett]

On Jun 15, 2012, at 8:21 PM, Brian Gallew wrote:

As has already been suggested, make the change yourself, submit a patch.  You have indicated several times that this isn't that big a change.  Further, it's a change that is clearly only of benefit to you at this point, so trying to convince others to do it for you is pointless.  If you *really* want Puppetlabs to do the change for you, then buy a support contract and have them do it.

As with all open source projects, your suggestion above--although phrased nicely--is an eff off suggestion.  Submitting patches that people don't agree with is a waste of time.  That's why I poll in advance, rather than waste effort on something which won't get any attention paid to it.

It's obvious this is DOA, I'm just replying to the thread in hopes people realize the fallacy of illogical arguments. (not all are, but many have been so far)

[Jo Rhett]

On Jun 18, 2012, at 12:55 AM, Felix Frank wrote:

this thread is starting to confuse me, I am no longer sure what you're
suggesting, precisely.

a) Make it possible to nullify notifications under certain circumstances.
b) Make it possible to ignore file owner/mode for files that exist already.

While (b) is rather tasteless to me (as is the whole "replace"
parameter), it is certainly well in line of what's possible today, so I
wouldn't object too much.
(a) is a nightmare I hope you're not invested in.

Well, a in the service of b -- but as a general point, I think that every notify/subscribe should be tune-able as to which things changing will cause the action to take place.

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.

This statement in itself is interesting as well. I believe that most
sites, large or small, don't face this particular problem at all,
because most of its incarnations are handled by manifest code control.
If a change goes to production, it better work, otherwise whoever pushed
to production has to answer for the breakage.

Exactly, which is why I said that the suggestions that someone edit the policy in advance and then send it out at the appropriate time make no sense at all.

If you have a service that should under no circumstances be restarted
unattended, then for crying out loud, do not make it consume resource
notifications from puppet. That's begging for trouble.

That's not what I said. I said should not be restarted for any reason other than a change in the configuration file.

Not a change in the ownership for new sites.

Not a change in the mode for new sites.

etc...

[Jo Rhett]

On Jun 18, 2012, at 2:08 AM, David Schmitt wrote:

I say "running puppet *hot* on a system *when* restarting a service might create a booboo is a bad idea." Emphasis on *hot* and *when*. For both emphasises, there are solutions (noop, cron, schedules, mcollective, dssh). Using a different CM is not likely to solve that unless you're willing to go the build-freeze-scrap route.

I'm not certain I understand your definition of "hot".  Is this normal puppet runs, puppet kick, etc.  It's also not clear to me why you think it's bad. I hear your assertation, but I don't see any explanation of why you feel it is bad.

For perspective, we routinely restart services while puppet is running "hot" (if I understood your definition there) and I'm not aware of any reason this is bad. Please educate me.

The core of this runs into organizational realms like "Change Management", which are not in scope for the puppet master/agent.

*boggle* Um, so your configuration management system is not part of your change management implementation? That's what you just said, and it makes no sense.

At the clients I work for, Rule #1 is "do not push into production." Even some of the outward-facing "test" systems have sensitive times when clients are testing. Developing changes and actually applying them are two VERY separate activities. You might want to look into git-flow to dis-entangle development, teams, and integration.

You are either saying some incredibly obvious -- like not hacking on production schemas without testing -- or something that I'm not following.  For this thread, none of these things appear to be topical. I'm not talking about how to manage changes to the production puppet policies. I'm talking about when someday a decision is made that new installations will have different rights, and after that new configuration is developed, tested and confirmed -- we should have the option of not changing the mode for existing installations.

Right now, testing and development of that change let us to the conclusion that we had to remove the file from puppet entirely. Which means that it has to be managed by a different mechanism, which means a completely different configuration management system which can incorporate that idea.

This is the meat of the problem: if this is a problem puppet shouldn't be used to handle, are you encouraging cfengine to be installed side by side with it? cfengine can handle this just fine.

[Eric Shamow]

On Monday, June 18, 2012 at 1:07 PM, Jo Rhett wrote:

*boggle* Um, so your configuration management system is not part of your change management implementation? That's what you just said, and it makes no sense.

Jo,

Not to speak for David but in general - the point is that they are different components of an interlocking whole.

In the cases you are discussing (conflict between multiple groups working on related systems) you need to implement better change control or CI.  While Puppet works quite well with those technologies, we don't yet provide tooling around git/svn/choose your tool VCS, nor do we provide the workflow itself.

In terms of conflicting changes, you really need code review, CI, or preferably both.  That's how large organizations handle scale.  Trying to force the tool to solve development problems isn't going to work.

Look at how development teams solve the same problems.  They don't do it by refusing to build a new daily snapshot of parts of the software.

-- 

Eric Shamow

Professional Services

http://puppetlabs.com/

(c)631.871.6441

[Jo Rhett]

On Monday, June 18, 2012 at 1:07 PM, Jo Rhett wrote:

*boggle* Um, so your configuration management system is not part of your change management implementation? That's what you just said, and it makes no sense.

On Jun 18, 2012, at 1:10 PM, Eric Shamow wrote:

Not to speak for David but in general - the point is that they are different components of an interlocking whole.

Of course they are.

In the cases you are discussing (conflict between multiple groups working on related systems) you need to implement better change control or CI.  While Puppet works quite well with those technologies, we don't yet provide tooling around git/svn/choose your tool VCS, nor do we provide the workflow itself.

Of course not.  My response was to people who literally, specifically told me to edit the policy but not apply it until the specified time.  Like "dude, stop puppet on that host and run it by hand later".  Works great with 5 systems, not so much with 500 and different teams who want puppet running for their own work.

In terms of conflicting changes, you really need code review, CI, or preferably both.  That's how large organizations handle scale.  Trying to force the tool to solve development problems isn't going to work. Look at how development teams solve the same problems.  They don't do it by refusing to build a new daily snapshot of parts of the software.

You are singing to the choir.  You missed the point I was responding to originally, which was the suggestion to stop puppet on the existing hosts so I could deploy the policy to the new hosts without affecting the service, then restarting puppet on those hosts at the appropriate time.  Which is *NOT* applicable to any reasonable workflow.

I find it really odd that people are coming down on me about having good change management, in response to my comment that no reasonable change management system would perform the steps suggested.  Totally, completely, beating up the choir.

[Wolf Noble]

… Now that I'm excessively caffeinated (I'm not actually sure if that's better, or worse, than my previous state, but)…

On Jun 18, 2012, at 12:47 PM, Jo Rhett wrote:

> On Jun 18, 2012, at 12:55 AM, Felix Frank wrote:
>> this thread is starting to confuse me, I am no longer sure what you're
>> suggesting, precisely.
>>
>> a) Make it possible to nullify notifications under certain circumstances.
>> b) Make it possible to ignore file owner/mode for files that exist already.
>>
>> While (b) is rather tasteless to me (as is the whole "replace"
>> parameter), it is certainly well in line of what's possible today, so I
>> wouldn't object too much.
>> (a) is a nightmare I hope you're not invested in.
>
> Well, a in the service of b -- but as a general point, I think that every notify/subscribe should be tune-able as to which things changing will cause the action to take place.

Not to continue this thread longer than it needs to go, but wouldn't your suggested paradigm permit you to bite yourself in the following scenario:
- change the ownership or mode of a file to the point that the required application could no longer access the file
- exclude this change from notifying or triggering the application that the permissions or ownership of its' config file have changed.
This change will go unnoticed until:
o Some random point in time in the future wherein the service "should" restart according to the method you propose.
o Some part of the application needs to re-read it's configuration file
o The server reboots

Suddenly things don't work. You don't have a smoking gun for the culprit change as that "clean" deployment happened [hours,days,weeks] ago with some other "unrelated" change by some other team that this service was set to ignore.

That really seems, to me at least, like a huge bag of pain to drag around waiting to pull out simply because it's tuesday.
… I never could get the hang of tuesdays.

Just my $.02, but if a file's ownership shouldn't change, and it belongs to a specific module, and there becomes a reason to change that ownership, without impacting existing modules, does it make sense to create a different module, and manage the dissimilar needs via that route?

That would at least let you know you're attempting to utilize two incompatible resources before doing so





________________________________

This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you.

[Jo Rhett]

On Jun 18, 2012, at 1:57 PM, Wolf Noble wrote:

Well, a in the service of b -- but as a general point, I think that every notify/subscribe should be tune-able as to which things changing will cause the action to take place.

Not to continue this thread longer than it needs to go, but wouldn't your suggested paradigm permit you to bite yourself in the following scenario:
 - change the ownership or mode of a file to the point that the required application could no longer access the file
 - exclude this change from notifying or triggering the application that the permissions or ownership of its' config file have changed.
 This change will go unnoticed until:
    o Some random point in time in the future wherein the service "should" restart according to the method you propose.
    o Some part of the application needs to re-read it's configuration file
    o The server reboots

Suddenly things don't work. You don't have a smoking gun for the culprit change as that "clean" deployment happened [hours,days,weeks] ago with some other "unrelated" change by some other team that this service was set to ignore.

I do believe I can shoot myself in the foot a dozen different ways that puppet does allow me to do:

   * break the configuration in the change

   * fail to restart the service

   * break some other dependancy

…etc

The short version is this is nowhere close to the easiest way to bag the service or host. I can do it dozens of ways with puppet today.  It's my job to write the policy well, and test it well, and test all its dependencies.  Puppet can't save me from myself.

What would be really nice is if I can, writing my policy carefully, achieve more granularity, more control. Saying that I shouldn't have finer-grained control because I could bag the service makes no sense, unless this was opening some new vector in which to do so.  It isn't.

Just my $.02, but if a file's ownership shouldn't change,  and it belongs to a specific module, and there becomes a reason to change that ownership, without impacting existing modules, does it make sense to create a different module, and manage the dissimilar needs via that route?

Same software, same management functions, same configs… just a different permissions change on new installations. Should I really duplicate the entire module, and manage all changes in both places?  And forever try to manage which host should be in which generation?

[Eric Shamow]

On Monday, June 18, 2012 at 4:04 PM, Jo Rhett wrote:

Same software, same management functions, same configs… just a different permissions change on new installations. Should I really duplicate the entire module, and manage all changes in both places?  And forever try to manage which host should be in which generation?

No - if it's that small and simple, the data bout which host is in which should be in your source of truth, CMDB, etc - and Puppet should read that data and determine which attribute or set of attributes (or resources) is applied based on that.

You can do this today with hiera and conditionals.

[Wolf Noble]

On Jun 18, 2012, at 6:04 PM, Jo Rhett wrote:

> On Jun 18, 2012, at 1:57 PM, Wolf Noble wrote:
>>> Well, a in the service of b -- but as a general point, I think that every notify/subscribe should be tune-able as to which things changing will cause the action to take place.
>>
>> Not to continue this thread longer than it needs to go, but wouldn't your suggested paradigm permit you to bite yourself in the following scenario:
>> - change the ownership or mode of a file to the point that the required application could no longer access the file
>> - exclude this change from notifying or triggering the application that the permissions or ownership of its' config file have changed.
>> This change will go unnoticed until:
>> o Some random point in time in the future wherein the service "should" restart according to the method you propose.
>> o Some part of the application needs to re-read it's configuration file
>> o The server reboots
>> Suddenly things don't work. You don't have a smoking gun for the culprit change as that "clean" deployment happened [hours,days,weeks] ago with some other "unrelated" change by some other team that this service was set to ignore.
>
> I do believe I can shoot myself in the foot a dozen different ways that puppet does allow me to do:
> * break the configuration in the change
> * fail to restart the service
> * break some other dependancy
> …etc
>
> The short version is this is nowhere close to the easiest way to bag the service or host. I can do it dozens of ways with puppet today. It's my job to write the policy well, and test it well, and test all its dependencies. Puppet can't save me from myself.
> What would be really nice is if I can, writing my policy carefully, achieve more granularity, more control. Saying that I shouldn't have finer-grained control because I could bag the service makes no sense, unless this was opening some new vector in which to do so. It isn't.

No, it's not the easiest way to break your environment. but it is a direct line to future obfuscated breakage, red herrings, and new and exciting ways to waste lots of engineers' time trying to suss out what in the the last N changes broke $package.

Not taking that into account will arguably lead one to making bad design choices. Aren't we supposed to be lazy and try to NOT shoot ourselves in the foot unexpectedly?

>> Just my $.02, but if a file's ownership shouldn't change, and it belongs to a specific module, and there becomes a reason to change that ownership, without impacting existing modules, does it make sense to create a different module, and manage the dissimilar needs via that route?
>
> Same software, same management functions, same configs… just a different permissions change on new installations. Should I really duplicate the entire module, and manage all changes in both places? And forever try to manage which host should be in which generation?

There's many ways of doing this… A case statement tied to a version number, or some other fact will get you this..
Aren't you pretty clearly stating that this old generation IS different than the next generation? How is puppet supposed to KNOW the difference between the two?

I've yet to see a satisfactory implementation of 'do what I mean, not what I say'.. but then again, I think that's why we're driving the computers and not the other way around…
oof. My laptop's out of battery… have to go plug it in…Hey… Wait a minute..

[Jo Rhett]

On Jun 18, 2012, at 4:41 PM, Wolf Noble wrote:

No, it's not the easiest way to break your environment. but it is a direct line to future obfuscated breakage, red herrings, and new and exciting ways to waste lots of engineers' time trying to suss out what in the the last N changes broke $package.

Not taking that into account will arguably lead one to making bad design choices.  Aren't we supposed to be lazy and try to NOT shoot ourselves in the foot unexpectedly?

First of all, do you know this environment better than I do?  Are you in a position to tell us that this risk is worse than another? I can assure you that the risk of using a completely different configuration manager/ecosystem side by side with puppet is much risker than using the fine-grained control to do exactly what we know and have tested to work properly through an extensive QA process.

I am amazed that people are very interested in telling me that I should implement an external system to replace puppet, rather than allow fine-grained control of triggers.  This is simply amazing.  Sure, it's much better to run two different configuration management systems interlaced with each other.  Nothing could go wrong with that, right? *headdesk*

Same software, same management functions, same configs… just a different permissions change on new installations. Should I really duplicate the entire module, and manage all changes in both places?  And forever try to manage which host should be in which generation?

There's many ways of doing this…  A case statement tied to a version number, or some other fact will get you this..
Aren't you pretty clearly stating that this old generation IS different than the next generation? How is puppet supposed to KNOW the difference between the two?

It isn't. That's the point.  At the puppet level there is absolute no difference.  We simply want new installations to have the new permissions. Old installations are going to be upgraded by hand, outside of puppet. We desire a period of overlap, where new installations can be set up correctly with the new permissions WITHOUT having the older installations fall over.

During this overlap period, any change to the installations will be applied to both old and new.

Having "replace => false" not apply to mode, owner and group would meet our needs -- but the general-purpose fix could apply to a lot more situations.

I've yet to see a satisfactory implementation of 'do what I mean, not what I say'.. but then again, I think that's why we're driving the computers and not the other way around…

This has nothing to do with "do what I mean".  I am being very, very specific about what I say.  I want to be more specific than puppet allows me, and people are fighting this idea all over the place.

[Shawn]

------Original Message------
From: Felix Frank
Sender: puppet...@googlegroups.com
To: puppet...@googlegroups.com
ReplyTo: puppet...@googlegroups.com
Subject: Re: [Puppet Users] can we avoid notify/subscribe firing on a mode change?
Sent: Jun 14, 2012 7:18 AM

On 06/14/2012 12:39 PM, Jo Rhett wrote:
>> 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.
>
> How so? The variable would allow the user to be explicit. As it stands
> now, I suspect most people would be surprised.

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 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.

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?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Sent via BlackBerry

[Jo Rhett]

Right, sure.  Instead of 18 lines of puppet policy that do exactly what I need, I should instead go create an infrastructure based around a barely documentation and SLOW part of puppet.  Because who wants finer granularity for your controls, when you could implement a huge infrastructure instead?

I take it you are a bit too young to have watched companies go out and implement Active Directory to solve a minor technical problem, aren't you?  There is no value in implementing an infrastructure with its own requirements for redundancy and its own dependancies to solve something you can code in an hour.

On Jun 18, 2012, at 4:27 PM, Eric Shamow wrote:

No - if it's that small and simple, the data bout which host is in which should be in your source of truth, CMDB, etc - and Puppet should read that data and determine which attribute or set of attributes (or resources) is applied based on that.

You can do this today with hiera and conditionals.

-- 

Eric Shamow

Professional Services

http://puppetlabs.com/

(c)631.871.6441

 

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Shawn]

Brutal you are.
-yoda

Sent via BlackBerry

---

From: Jo Rhett <jrh...@netconsonance.com>

Sender: puppet...@googlegroups.com

Date: Mon, 18 Jun 2012 17:07:21 -0700

To: <puppet...@googlegroups.com>

ReplyTo: puppet...@googlegroups.com

Subject: Re: [Puppet Users] can we avoid notify/subscribe firing on a mode change?

[Denmat]

Okay back to the original problem. It's become a bit hard to follow.

Without code change to puppet you're stumped. But without knowing your systems a combination of package based deployments and excluding mode or owner maybe will get you by?

But with puppet code change, would a way of doing what you are proposing be something like this:

file { title:

  owner => name,

  mode => 0755,

  content => content,

  notify.=> service[name],

  notify_on => ['owner', 'content'],

}

Now I don't know how easy that is to code into puppet, but I think that would sound like a useful feature to me.

Regards,

Den

[Eric Shamow]

Jo,

Let's not make this personal.  You don't know how old I am or what infrastructures I've managed.

You don't need to use Hiera.  You can use any data lookup tool you like to do the same thing.

What you are seeing is not an official stance of any kind, it's a spontaneous community reaction.  People aren't agreeing with you, which means you aren't arguing effectively.

Instead of making the case that someone else should do this, I recommend that you code up a solution and issue a pull request.  If the code looks valuable it can then be managed like any other feature or code request in Puppet.  

Clearly the community is not crying out for the solution as you've enunciated it.  Maybe you've enunciated it poorly.  In that case, write something to fix it and some demo usage.  Code wins arguments.

-Eric

-- 

Eric Shamow

Professional Services

http://puppetlabs.com/

(c)631.871.6441

[Felix Frank]

On 06/19/2012 04:48 AM, Eric Shamow wrote:
> Jo,
>
> Let's not make this personal. You don't know how old I am or what
> infrastructures I've managed.
>
> You don't need to use Hiera. You can use any data lookup tool you like
> to do the same thing.
>
> What you are seeing is not an official stance of any kind, it's a
> spontaneous community reaction. People aren't agreeing with you, which
> means you aren't arguing effectively.
>
> Instead of making the case that someone else should do this, I recommend
> that you code up a solution and issue a pull request. If the code looks
> valuable it can then be managed like any other feature or code request
> in Puppet.
>
> Clearly the community is not crying out for the solution as you've
> enunciated it. Maybe you've enunciated it poorly. In that case, write
> something to fix it and some demo usage. Code wins arguments.

Aptly put.

Please stop accusing us of being ignorant of your problems (we are, so
yes, we are going to discuss this from a lot more academical position
than you are). I also find the notion that the suggestion to submit a
patch was an implied "eff off" mildly offensive.

I will argue the design principle of the very "replace" parameter and
this whole business all day long, but if there's code, and there is
someone needing and using the code (and most importantly, a puppetlabs
maintainer who will merge it)...well, there it is then.

[Jo Rhett]

Yep, pretty much exactly what I proposed in https://projects.puppetlabs.com/issues/14998

That said, someone offline made a fair argument for it not being another directive, but perhaps an attribute of the notify or subscribe directive. I would totally support that idea.

On Jun 18, 2012, at 5:26 PM, Denmat wrote:

Okay back to the original problem. It's become a bit hard to follow.

Without code change to puppet you're stumped. But without knowing your systems a combination of package based deployments and excluding mode or owner maybe will get you by?

But with puppet code change, would a way of doing what you are proposing be something like this:

file { title:

  owner => name,

  mode => 0755,

  content => content,

  notify.=> service[name],

  notify_on => ['owner', 'content'],

}

Now I don't know how easy that is to code into puppet, but I think that would sound like a useful feature to me.

Regards,

Den

[Jo Rhett]

On Jun 18, 2012, at 7:48 PM, Eric Shamow wrote:

You don't need to use Hiera.  You can use any data lookup tool you like to do the same thing.

You are suggesting to create an external data reference for something which should be 100% expressed within the puppet policies.  There is no other need for external data lookup (related to this software, this unit build, etc) so having to build an infrastructure and new data source to express this idea simply doesn't make much sense.

Instead of making the case that someone else should do this, I recommend that you code up a solution and issue a pull request.  If the code looks valuable it can then be managed like any other feature or code request in Puppet.  

Given that most of the work I've submitted to date hasn't even been reviewed nevermind prioritized, I think you can understand why I avoid writing code before there is someone interested in having it.  Over the years I've learned to pay attention to this, and my effort based on that.

Code wins arguments.

I so totally wish that were true, but I've spent far too many years in the linux / *bsd / postgres / etc communities to be that naive ;-)