On Wed, Aug 26, 2009 at 1:20 AM, Luke Kanies <[email protected]> wrote:

>
> On Aug 25, 2009, at 4:00 PM, S H wrote:
>
> >
> >
> > On Tue, Aug 25, 2009 at 5:33 PM, Luke Kanies <[email protected]> wrote:
> >
> > On Aug 25, 2009, at 1:57 PM, S H wrote:
> >
> > > If this is the wrong list, please let me know. I'm emailing puppet-
> > > dev since this is firmly in the realm of Puppet code rather than
> > > typical manifest implementation.
> >
> > I think this is the right list.  At the least, I read this one far
> > more than -users, and I'm likely to be the only person who knows some
> > of this stuff, unfortunately.
> >
> > >
> > > I'm not sure if this is a bug or if I'm doing it wrong, so any help
> > > is appreciated. This issue exposed itself while I was working on my
> > > Bacula type/provider and I have confirmed that it is also a problem
> > > with Naginator.
> > >
> > > Using Naginator as the example, if I have a manifest like this:
> > >
> > >        nagios_host { "test1":
> > >                alias => "alias1",
> > >                address => "address1",
> > >        }
> > >
> > >        nagios_contactgroup { "test2":
> > >                target => "/etc/nagios/nagios_host.cfg",
> > >                alias => "alias2",
> > >        }
> > >
> > > Only one of the changes will go through at a time. If I add another
> > > nagios_host to the manifest, either both nagios_host configurations
> > > or the nagios_contactgroup configuration will go through.
> > >
> > > What I suspect is probably very different than the reality, but here
> > > it is anyway: provider instances for a given type share the @records
> > > value so modifications to one are reflected in all of them.Different
> > > types don't share @records values, so flushing leaves the last man
> > > standing.
> > >
> > > Obviously, I still haven't figured out the exact details. Can anyone
> > > shed any light on this?
> >
> > Um, that's pretty strange, and I don't really know what could be
> > causing it.  I've certainly never heard of anything like it.
> >
> > Each provider class should be completely independent, and there's no
> > way that flushing one should cause another not to get flushed.
> >
> > Are you saying that the changes don't get logged, or that they don't
> > happen?  If they don't even get logged, do you get anything
> > informative if you run with --verbose --evaltrace?
> >
> > They all get flushed and the changes get logged - the problem lies
> > in the way they're flushed.
> >
> > nagios_host and nagios_contactgroup have each prefetched the file
> > (if it exists) and modified their own @records variables to reflect
> > the changes as they deem necessary. Puppet then calls flush on each
> > of these - let's say nagios_host goes first.
> >
> > So nagios_host's to_file() method produces the string that
> > represents the file according to its internal representation, and
> > that string is written to the file. Then the same thing happens for
> > nagios_contactgroup, but since nagios_host changes didn't affect its
> > own representation of the string, the file is written out as it was
> > originally + nagios_contactgroup's changes.
> >
> > I'll get you the output tomorrow when I'm back at my workstation,
> > but it looks perfectly normal. I pieced this together by yaml-
> > dumping variables in various places until I had an idea of what was
> > happening.
>
> I'm... still confused.  I'll wait for your email with the outputs.
>

puppet# cat test.pp
nagios_host { "test1":
        alias => "alias1",
        address => "address1",
}

nagios_contactgroup { "test2":
        target => "/etc/nagios/nagios_host.cfg",
        alias => "alias2",
}

puppet# puppet  --trace --evaltrace --debug --verbose test.pp
puppet# rm /etc/nagios/nagios_host.cfg
puppet# touch /etc/nagios/nagios_host.cfg
puppet# puppet  --trace --evaltrace --debug --verbose test.pp
info: Loading fact fc_location
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31: command not
found:
debug: Creating default schedules
debug: Prefetching naginator resources for nagios_host
debug: Prefetching naginator resources for nagios_contactgroup
debug: //Nagios_host[test1]: Changing ensure
debug: //Nagios_host[test1]: 1 change(s)
notice: //Nagios_host[test1]/ensure: created
debug: Flushing nagios_host provider target /etc/nagios/nagios_host.cfg
debug: Failed to load library 'shadow' for feature 'libshadow'
debug: Finishing transaction 341800180 with 0 changes
debug: //Nagios_contactgroup[test2]: Changing ensure
debug: //Nagios_contactgroup[test2]: 1 change(s)
notice: //Nagios_contactgroup[test2]/ensure: created
debug: Flushing nagios_contactgroup provider target
/etc/nagios/nagios_host.cfg
info: Filebucket[/var/puppet/clientbucket]: Adding
/etc/nagios/nagios_host.cfg(901d65a4e8dacbf4e87ba544d5a86d9a)
debug: Finishing transaction 345760510 with 2 changes
puppet# cat /etc/nagios/nagios_host.cfg
# HEADER: This file was autogenerated at Wed Aug 26 10:24:24 -0400 2009
# HEADER: by puppet.  While it can still be managed manually, it
# HEADER: is definitely not recommended.
define contactgroup {
        contactgroup_name              test2
        alias                          alias2
}
puppet#



If I add a yaml-dump to parsedfile.rb's self.flush_target(target) method so
it looks like this:

def self.flush_target(target)
        backup_target(target)

        records = target_records(target).reject { |r|
            r[:ensure] == :absent
        }
        require 'yaml'
        puts YAML::dump(records)

    target_object(target).write(to_file(records))
end


We get:

puppet# puppet --trace --evaltrace --debug --verbose test.pp
info: Loading fact fc_location
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31: command not
found:
debug: Creating default schedules
debug: Prefetching naginator resources for nagios_host
debug: Prefetching naginator resources for nagios_contactgroup
debug: //Nagios_host[test1]: Changing ensure
debug: //Nagios_host[test1]: 1 change(s)
notice: //Nagios_host[test1]/ensure: created
debug: Flushing nagios_host provider target /etc/nagios/nagios_host.cfg
debug: Failed to load library 'shadow' for feature 'libshadow'
debug: Finishing transaction 341645600 with 0 changes
---
- !ruby/object:host
  ensure: :present
  on_disk: true
  parameters:
    address: address1
    host_name: test1
    alias: alias1
  target: /etc/nagios/nagios_host.cfg
debug: //Nagios_host[test2]: Changing ensure
debug: //Nagios_host[test2]: 1 change(s)
notice: //Nagios_host[test2]/ensure: created
debug: Flushing nagios_host provider target /etc/nagios/nagios_host.cfg
---
- !ruby/object:host
  ensure: :present
  on_disk: true
  parameters:
    address: address1
    host_name: test1
    alias: alias1
  target: /etc/nagios/nagios_host.cfg
- !ruby/object:host
  ensure: :present
  on_disk: true
  parameters:
    address: address2
    host_name: test2
    alias: alias2
  target: /etc/nagios/nagios_host.cfg
debug: //Nagios_contactgroup[test3]: Changing ensure
debug: //Nagios_contactgroup[test3]: 1 change(s)
notice: //Nagios_contactgroup[test3]/ensure: created
debug: Flushing nagios_contactgroup provider target
/etc/nagios/nagios_host.cfg
info: Filebucket[/var/puppet/clientbucket]: Adding
/etc/nagios/nagios_host.cfg(f81a6f0dd450b6617255a18c3787abfc)
---
- !ruby/object:contactgroup
  ensure: :present
  on_disk: true
  parameters:
    contactgroup_name: test3
    alias: alias3
  target: /etc/nagios/nagios_host.cfg
debug: Finishing transaction 345707210 with 3 changes
puppet#


So you can see that, while both nagios_host resources were flushed to the
file in the second step, only the contactgroup was flushed in the third
step. This overwrote the file that contained the two nagios hosts (which was
backed up to the filebucket right before).

Hopefully that makes things clearer.

-Shawn




>
> --
> Nonreciprocal Laws of Expectations:
>     Negative expectations yield negative results. Positive expectations
>     yield negative results.
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to