On Wed, Aug 26, 2009 at 10:44 AM, S H <[email protected]> wrote:

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

Did that help at all? Is there additional information I can get for you?

-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