Puppet users - Nov 2012 - MAJOR BUG: package requirements are ignored when schedules are used.

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.

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.

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.

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

>> This is now https://projects.puppetlabs.com/issues/17507
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.

On Thursday, November 8, 2012 5:21:51 PM UTC-6, Jo
wrote:
>
> >> This is now https://projects.puppetlabs.com/issues/17507 
>
> 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.