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

Search Discussions

  • R.I.Pienaar at Jun 13, 2012 at 8:50 am

    ----- 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.
  • Jo Rhett at Jun 13, 2012 at 8:58 am

    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.
  • Felix Frank at Jun 14, 2012 at 7:22 am
    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.
  • Jo Rhett at Jun 14, 2012 at 10:39 am

    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.
  • Felix Frank at Jun 14, 2012 at 11: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.
  • Jo Rhett at Jun 14, 2012 at 1:13 pm

    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.
  • Felix Frank at Jun 14, 2012 at 1:29 pm
    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.
  • Jo Rhett at Jun 14, 2012 at 1:44 pm

    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.
  • Felix Frank at Jun 14, 2012 at 2:09 pm

    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.
  • David Schmitt at Jun 14, 2012 at 3:52 pm

    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.
  • Jo Rhett at Jun 14, 2012 at 7:29 pm

    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.
  • Brian Gallew at Jun 14, 2012 at 10:29 pm
    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 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.
  • David Schmitt at Jun 15, 2012 at 7:35 am

    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.
  • Jcbollinger at Jun 15, 2012 at 2:16 pm

    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.
  • Jo Rhett at Jun 15, 2012 at 6:36 pm

    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.
  • Jcbollinger at Jun 15, 2012 at 9:40 pm

    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.
  • Jo Rhett at Jun 16, 2012 at 12:18 am
    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.
  • Jo Rhett at Jun 15, 2012 at 6:26 pm

    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.
  • Jcbollinger at Jun 15, 2012 at 10:13 pm

    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.
  • Jo Rhett at Jun 16, 2012 at 12:22 am

    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.
  • David Schmitt at Jun 18, 2012 at 9:09 am

    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.
  • Jo Rhett at Jun 18, 2012 at 8:07 pm

    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.
  • Eric Shamow at Jun 18, 2012 at 8:10 pm

    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.
  • Jo Rhett at Jun 18, 2012 at 8:25 pm

    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.
  • Jcbollinger at Jun 14, 2012 at 3:20 pm

    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.
  • Ashley Penney at Jun 15, 2012 at 5:00 pm

    On Thu, Jun 14, 2012 at 11:20 AM, jcbollinger 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.
  • Jo Rhett at Jun 15, 2012 at 6:41 pm

    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.
  • Ashley Penney at Jun 15, 2012 at 10:25 pm

    On Fri, Jun 15, 2012 at 2:41 PM, Jo Rhett 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.
  • Jo Rhett at Jun 16, 2012 at 12:36 am

    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.
  • Brian Gallew at Jun 16, 2012 at 3:21 am
    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 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.
  • Jo Rhett at Jun 18, 2012 at 5:40 pm

    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.
  • Ashley Penney at Jun 16, 2012 at 1:39 pm
    On Fri, Jun 15, 2012 at 8:36 PM, Jo Rhett 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.
  • Felix Frank at Jun 18, 2012 at 7:55 am
    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.
  • Jo Rhett at Jun 18, 2012 at 5:47 pm

    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.
  • Wolf Noble at Jun 18, 2012 at 8:57 pm
    … 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.
  • Jo Rhett at Jun 18, 2012 at 11:05 pm

    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.
  • Eric Shamow at Jun 18, 2012 at 11:27 pm

    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.
  • Jo Rhett at Jun 19, 2012 at 12:07 am
    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.
  • Shawn at Jun 19, 2012 at 12:11 am
    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.
  • Denmat at Jun 19, 2012 at 12:26 am
    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" 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 Rhett at Jun 19, 2012 at 9:52 pm
    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.
  • Eric Shamow at Jun 19, 2012 at 2:48 am
    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.
  • Felix Frank at Jun 19, 2012 at 9:14 am

    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.
  • Jo Rhett at Jun 19, 2012 at 11:10 pm

    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.
  • Wolf Noble at Jun 18, 2012 at 11:41 pm

    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.
  • Jo Rhett at Jun 19, 2012 at 12:04 am

    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.
  • Shawn at Jun 19, 2012 at 12:04 am

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJun 13, '12 at 8:33a
activeJun 19, '12 at 11:10p
posts48
users11
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase