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.

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