Hello, I am facing a strange behaviour with exported resources overriding in 0.25.5 (CentOS). I am using nagios with exported resources. In my base class, I define a hostgroup by default for all nodes. In an apache vhost define, I override this hostgroup to a value common to all webservers. This works. But in another class, I use apache vhost define but I want to override another time the hostgroup to set it to another value. This does not work, the hostgroup for the host is set to the one for apache vhosts. Is there a way to tell that the last resource override should happen after the apache vhost define is applied ? Here is what it looks like : class nagios { @@nagios_host { $fqdn: ensure => present, alias => $hostname, address => $ipaddress, use => "linux-server", check_command => "check-host-alive", max_check_attempts => 3, hostgroups => "linux-servers", contact_groups => "admins", } } define apache::vhost ([...]){ [···] Nagios_host<| title == $fqdn|> { hostgroups => "webservers", } } class specialized::host { include apache apache::vhost {"$fqdn": [...] } Nagios_host <| title == $fqdn|> { hostgroups => "cihosts", contact_groups => "ciadmins", require => File["/etc/nagios"], } } node "myhost" { include nagios include specialized::host } Note, the contact_groups override works well. Cheers, Julien Garet -- 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 Wed, May 11, 2011 at 12:17 AM, Julien Garet <julien.garet@inria.fr>wrote:> Hello, > I am facing a strange behaviour with exported resources overriding in > 0.25.5 (CentOS). I am using nagios with exported resources. In my base > class, I define a hostgroup by default for all nodes. In an apache vhost > define, I override this hostgroup to a value common to all webservers. This > works. > But in another class, I use apache vhost define but I want to override > another time the hostgroup to set it to another value. This does not work, > the hostgroup for the host is set to the one for apache vhosts. > > Is there a way to tell that the last resource override should happen after > the apache vhost define is applied ? >Unfortunately there isn''t. The feature you''re using to override resources is actually a bit of an unintended consequence of another feature added to Puppet in 0.25.5. In Puppet 2.7, the order these resources will be evaluated in will be guaranteed to be deterministic, so this will help with testing and staging into pre-production, but currently the best practice is to not override the same parameter using the collection syntax. Hope this helps, -- Jeff McCune Puppet Labs @0xEFF -- 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 May 11, 4:27 pm, Jeff McCune <j...@puppetlabs.com> wrote:> On Wed, May 11, 2011 at 12:17 AM, Julien Garet <julien.ga...@inria.fr>wrote: > > > Hello, > > I am facing a strange behaviour with exported resources overriding in > > 0.25.5 (CentOS). I am using nagios with exported resources. In my base > > class, I define a hostgroup by default for all nodes. In an apache vhost > > define, I override this hostgroup to a value common to all webservers. This > > works. > > But in another class, I use apache vhost define but I want to override > > another time the hostgroup to set it to another value. This does not work, > > the hostgroup for the host is set to the one for apache vhosts. > > > Is there a way to tell that the last resource override should happen after > > the apache vhost define is applied ? > > Unfortunately there isn''t. The feature you''re using to override resources > is actually a bit of an unintended consequence of another feature added to > Puppet in 0.25.5.I consider that unfortunate only insomuch as it makes the OP''s life more difficult. In general, Puppet does not like it when you make contradictory declarations about a node, and I am happy to have it that way. Even when 2.7 makes the result of evaluation of such a manifest deterministic, *relying* on that evaluation order to resolve conflicts will still be a poor idea. What I consider unfortunate here is that Puppet does not raise an error when an attempt is made to perform conflicting overrides.> In Puppet 2.7, the order these resources will be evaluated in will be > guaranteed to be deterministic, so this will help with testing and staging > into pre-production, but currently the best practice is to not override the > same parameter using the collection syntax.And that will remain the best practice for the foreseeable future, as far as I am concerned. Speaking of deterministic evaluation, just how stable is it going to be? That is, it''s one thing for ordering to be consistent for a particular set of manifests, but what will happen when the manifests are modified? How will ordering be affected by manifest changes? John -- 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 May 12, 6:10 am, jcbollinger <John.Bollin...@stJude.org> wrote:> Speaking of deterministic evaluation, just how stable is it going to > be? That is, it''s one thing for ordering to be consistent for a > particular set of manifests, but what will happen when the manifests > are modified? How will ordering be affected by manifest changes? >You can read more about the design here, but basically: in an edited manifest, any two resources that HAVEN''T been changed (and which don''t depend on things that have been changed) will have the same order relative to each other. -- 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 May 12, 11:32 am, Nick Fagerlund <nick.fagerl...@puppetlabs.com> wrote:> You can read more about the design here...Wow, self, way to not post that link. http://projects.puppetlabs.com/issues/6911 -- 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 May 12, 1:32 pm, Nick Fagerlund <nick.fagerl...@puppetlabs.com> wrote:> On May 12, 11:32 am, Nick Fagerlund <nick.fagerl...@puppetlabs.com> > wrote: > > > You can read more about the design here... > > Wow, self, way to not post that link. > > http://projects.puppetlabs.com/issues/6911Thanks, Nick. What I take from that is that resources that do not otherwise have a relative order defined (directly or indirectly, explicitly or implicitly) will be ordered by an unpredictable but deterministic and consistent function of their titles. Does that about sum it up? John -- 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.