FAQ
If you setup a schedule such that packages are only installed certain hours of the day, well, that part works. They won't install until that time. However, if you have a policy that depends on the package being installed, if it is NOT installed due to the schedule, it satisfies the Require and everything else happens. I'm going to call this misfeature: "No package? No Problem! ":(

Example: with this example, if you apply the policy after 8pm (if you are using UTC like we are, that's noon PST) then it will actually install the configuration files and attempt to start the service. This is clearly a bug. Given some multi-application interactions, this could cause a major service outage. (I didn't find this with snmp but instead with some inhouse system components. I replicated it with this config before reporting it)

I observed this on 2.7.19 but checking the sources it appears likely to be a problem with 3.0 as well.

site.pp:
# Schedule in the early part of the working day (not peak)
schedule { 'early-day':
range => '17 - 20',
period => daily,
periodmatch => number,
}
Package {
schedule => 'early-day',
}
node default {
class { snmpd: }
}

class snmpd {
package { 'net-snmp':
ensure => present,
alias => 'snmpd',
}
package { 'net-snmp-perl':
ensure => present,
require => Package['net-snmp'],
}
file { "/etc/sysconfig/snmpd":
owner => root,
group => root,
mode => 0755,
source => 'puppet:///modules/snmpd/snmpd.sysconfig',
require => Package['net-snmp'],
notify => Service['snmpd'],
}
file { '/etc/snmp/snmpd.conf':
ensure => file,
owner => root,
group => root,
mode => 0755,
content => template('snmpd/snmpd.conf'),
require => Package['net-snmp'],
notify => Service['snmpd'],
}
service { 'snmpd':
ensure => running,
enable => true,
require => Package['net-snmp','net-snmp-perl'],
}
}

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

  • Jo Rhett at Nov 8, 2012 at 10:47 pm
    Note that a workaround is to override the schedule for each package that is depended on this way, but that prevents application of "ensure => latest". Which brings up a really good point. What if I want to install software at any hour, but only update the same software during certain hours? The current Package resource doesn't seem capable of this, especially since There Can Be Only One :(
    On Nov 8, 2012, at 2:42 PM, Jo Rhett wrote:
    If you setup a schedule such that packages are only installed certain hours of the day, well, that part works. They won't install until that time. However, if you have a policy that depends on the package being installed, if it is NOT installed due to the schedule, it satisfies the Require and everything else happens. I'm going to call this misfeature: "No package? No Problem! ":(

    Example: with this example, if you apply the policy after 8pm (if you are using UTC like we are, that's noon PST) then it will actually install the configuration files and attempt to start the service. This is clearly a bug. Given some multi-application interactions, this could cause a major service outage. (I didn't find this with snmp but instead with some inhouse system components. I replicated it with this config before reporting it)

    I observed this on 2.7.19 but checking the sources it appears likely to be a problem with 3.0 as well.

    site.pp:
    # Schedule in the early part of the working day (not peak)
    schedule { 'early-day':
    range => '17 - 20',
    period => daily,
    periodmatch => number,
    }
    Package {
    schedule => 'early-day',
    }
    node default {
    class { snmpd: }
    }

    class snmpd {
    package { 'net-snmp':
    ensure => present,
    alias => 'snmpd',
    }
    package { 'net-snmp-perl':
    ensure => present,
    require => Package['net-snmp'],
    }
    file { "/etc/sysconfig/snmpd":
    owner => root,
    group => root,
    mode => 0755,
    source => 'puppet:///modules/snmpd/snmpd.sysconfig',
    require => Package['net-snmp'],
    notify => Service['snmpd'],
    }
    file { '/etc/snmp/snmpd.conf':
    ensure => file,
    owner => root,
    group => root,
    mode => 0755,
    content => template('snmpd/snmpd.conf'),
    require => Package['net-snmp'],
    notify => Service['snmpd'],
    }
    service { 'snmpd':
    ensure => running,
    enable => true,
    require => Package['net-snmp','net-snmp-perl'],
    }
    }

    --
    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
    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 Nov 8, 2012 at 10:51 pm
    This is now https://projects.puppetlabs.com/issues/17507
    On Nov 8, 2012, at 2:42 PM, Jo Rhett wrote:
    If you setup a schedule such that packages are only installed certain hours of the day, well, that part works. They won't install until that time. However, if you have a policy that depends on the package being installed, if it is NOT installed due to the schedule, it satisfies the Require and everything else happens. I'm going to call this misfeature: "No package? No Problem! ":(

    Example: with this example, if you apply the policy after 8pm (if you are using UTC like we are, that's noon PST) then it will actually install the configuration files and attempt to start the service. This is clearly a bug. Given some multi-application interactions, this could cause a major service outage. (I didn't find this with snmp but instead with some inhouse system components. I replicated it with this config before reporting it)

    I observed this on 2.7.19 but checking the sources it appears likely to be a problem with 3.0 as well.

    site.pp:
    # Schedule in the early part of the working day (not peak)
    schedule { 'early-day':
    range => '17 - 20',
    period => daily,
    periodmatch => number,
    }
    Package {
    schedule => 'early-day',
    }
    node default {
    class { snmpd: }
    }

    class snmpd {
    package { 'net-snmp':
    ensure => present,
    alias => 'snmpd',
    }
    package { 'net-snmp-perl':
    ensure => present,
    require => Package['net-snmp'],
    }
    file { "/etc/sysconfig/snmpd":
    owner => root,
    group => root,
    mode => 0755,
    source => 'puppet:///modules/snmpd/snmpd.sysconfig',
    require => Package['net-snmp'],
    notify => Service['snmpd'],
    }
    file { '/etc/snmp/snmpd.conf':
    ensure => file,
    owner => root,
    group => root,
    mode => 0755,
    content => template('snmpd/snmpd.conf'),
    require => Package['net-snmp'],
    notify => Service['snmpd'],
    }
    service { 'snmpd':
    ensure => running,
    enable => true,
    require => Package['net-snmp','net-snmp-perl'],
    }
    }

    --
    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
    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.
  • R.I.Pienaar at Nov 8, 2012 at 10:55 pm

    ----- Original Message -----
    From: "Jo Rhett" <jrhett@netconsonance.com>
    To: puppet-users@googlegroups.com
    Sent: Thursday, November 8, 2012 10:50:54 PM
    Subject: Re: [Puppet Users] MAJOR BUG: package requirements are ignored when schedules are used.

    This is now https://projects.puppetlabs.com/issues/17507
    also see http://projects.puppetlabs.com/issues/5286 I think the
    hard part here is figuring out what is right behaviour

    --
    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 Nov 8, 2012 at 11:21 pm

    On Nov 8, 2012, at 2:55 PM, R.I.Pienaar wrote:
    also see http://projects.puppetlabs.com/issues/5286 I think the
    hard part here is figuring out what is right behaviour

    I don't think either situation is hard to determine what the expected behavior should be. I updated 5286 with some thoughts.

    For package installs, either one of the following behaviors is correct/intuitive. I prefer the first one:

    1. Check if the package is installed. If it is installed and has a schedule, don't check the version for update or removal. If it isn't installed and should be, install it outside of the schedule.

    *OR*

    2. Do not run things which fail dependency on a package which is not installed.

    But running a bunch of commands and trying to start services when their dependancies are not installed is madness, and likely to really hurt someone in the wrong situations.

    --
    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 Nov 9, 2012 at 4:17 pm

    On Thursday, November 8, 2012 5:21:51 PM UTC-6, Jo wrote:
    On Nov 8, 2012, at 2:55 PM, R.I.Pienaar wrote:
    also see http://projects.puppetlabs.com/issues/5286 I think the
    hard part here is figuring out what is right behaviour
    Consider also issue http://projects.puppetlabs.com/issues/5876<http://projects.puppetlabs.com/issues/5286>,
    which is related.

    I don't think either situation is hard to determine what the expected
    behavior should be. I updated 5286 with some thoughts.


    Me, too.



    For package installs, either one of the following behaviors is
    correct/intuitive. I prefer the first one:

    1. Check if the package is installed. If it is installed and has a
    schedule, don't check the version for update or removal. If it isn't
    installed and should be, install it outside of the schedule.

    *OR*

    2. Do not run things which fail dependency on a package which is not
    installed.

    Although it would produce more favorable behavior for the particular
    manifests at issue here, I can't agree with option (1). The question
    should be about whether Puppet applies the Package resource, not about the
    details of what is involved in applying it under one set of circumstances
    vs. another.

    I more or less agree with (2), but I would couch it in different terms:

    2'. Do not attempt to apply a resource that has a 'require' relationship
    (or equivalent) with a resource that is not successfully applied, and
    2'a. Do not consider resources to have been successfully applied when they
    are excluded from application by a schedule.

    The first is a Puppet invariant, so the second is the key.


    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/-/FyX3f4Ciz_gJ.
    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
postedNov 8, '12 at 10:42p
activeNov 9, '12 at 4:17p
posts6
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase