Puppet users - Jun 2012 - 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?

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.



-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- Original Message -----
> From: "Jo Rhett" <jrhett@netconsonance.com>
> To: puppet-users@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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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/-/4itkAcJeJgMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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


-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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 <jrhett@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Friday, June 15, 2012 2:35:47 AM UTC-5, David Schmitt
wrote:
>
> 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. 
>
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

-- 
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/-/xz6y7-MD8T8J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jun 14, 2012 at 11:20 AM, jcbollinger
<John.Bollinger@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,

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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/-/IaSh6KEzhxsJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, Jun 15, 2012 at 2:41 PM, Jo Rhett <jrhett@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.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.

On Fri, Jun 15, 2012 at 5:36 PM, Jo Rhett <jrhett@netconsonance.com>
wrote:
> 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.
>
> --
> 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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, Jun 15, 2012 at 8:36 PM, Jo Rhett <jrhett@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,

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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?

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.

--  

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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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


________________________________

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.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

------Original Message------
From: Felix Frank
Sender: puppet-users@googlegroups.com
To: puppet-users@googlegroups.com
ReplyTo: puppet-users@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.


Sent via BlackBerry

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Brutal you are. 
-yoda
Sent via BlackBerry

-----Original Message-----
From: Jo Rhett <jrhett@netconsonance.com>
Sender: puppet-users@googlegroups.com
Date: Mon, 18 Jun 2012 17:07:21 
To: <puppet-users@googlegroups.com>
Reply-To: puppet-users@googlegroups.com
Subject: Re: [Puppet Users] can we avoid notify/subscribe firing on a mode
change?

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-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
-- 
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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




On 19/06/2012, at 10:11, "Shawn" <taaj.shawn@gmail.com> wrote:
> Brutal you are. 
> -yoda
> Sent via BlackBerry
> From: Jo Rhett <jrhett@netconsonance.com>
> Sender: puppet-users@googlegroups.com
> Date: Mon, 18 Jun 2012 17:07:21 -0700
> To: <puppet-users@googlegroups.com>
> ReplyTo: puppet-users@googlegroups.com
> Subject: Re: [Puppet Users] can we avoid notify/subscribe firing on a mode
change?
> 
> 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-users@googlegroups.com.
>> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
>> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
> 
> -- 
> 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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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


On Monday, June 18, 2012 at 5:07 PM, Jo Rhett wrote:
> 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-users@googlegroups.com
(mailto:puppet-users@googlegroups.com).
> > To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
(mailto:puppet-users+unsubscribe@googlegroups.com).
> > For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
> 
> -- 
> 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
(mailto:puppet-users@googlegroups.com).
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
(mailto:puppet-users+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.