On Jul 22, 2008, at 3:54 AM, Peter Meier wrote:

>
> Hi
>
>> Hrm, in reading more closely, I now see that your code will only ever
>> initialize the @updates hash, it will never replace it.  Once  
>> @updates
>> is created, the content becomes static, which is obviously a problem.
>
> ok, yeah I now see this as a problem as well. I didn't think/see that
> the provider never gets invalidated. Or is there a function for this?

There's no class-level flushing, ATM, only instance-level.  This could  
be considered a shortcoming in the API.
[..]

> a more general question to understand how providers are instantiated:
>
> puppet will run prefetch once as a global initalizer, but every  
> package
> will get it's own instance of the package provider?

Prefetching, in essentially all of the cases right now, is the process  
of creating a *new* provider instance, already loaded with the current  
state, and replacing each resource's provider with this preloaded  
provider.

This ended up being about 100x easier than reassigning the values on  
existing providers.

> actually I have some problem to understand of what kind will be
> package.provider in your example? an instance of the yum provider, or
> any other selected provider? maybe someone could point me to some
> documentation about that or explain it a bit in detail? thanks!

Each resource instance gets an instance of the related provider, so in  
your case each package gets an instance of the Yum provider.

>
>> The downside of it is that you'll then have to change the 'latest'
>> method so that, if no value is already present (e.g., in the
>> @property_hash), it will need to know how to retrieve the value
>> itself.
>>
>> I don't know if the yumhelper.rb can be run for individual
>> packages.  (Note that this state would only ever happen outside of a
>> normal transaction, such as when you're running 'ralsh package  
>> <foo>'.)
>
> looking at the fact that running yum itself is very expensive, I don't
> think it is a good idea to run the yumhelper for every package.

Sorry, I wasn't thorough enough in my explanation.  There could be  
cases where prefetching didn't happen (not in the current  
architecture, but in a custom application, for instance) -- in those  
cases, you might want the ability to create a package, retrieve the  
state of just that one package, and then change something.  E.g., if I  
wanted to use ralsh to modify a package, it doesn't make sense to  
prefetch the whole system.

>
> however I have another idea:
>
> currently I check if @updates is undef, how about setting @updates in
> every prefetch to nil and then checking if @updates is nil? the  
> problem
> is that you seem not to able to undef variables (only constants) in
> ruby. or have this changed?

Clearing the hash is sufficient; you don't need to undef it.

But again, I think the right solution is to modify the prefetch method  
to add the 'latest' value to the prefetched data before the new  
provider instance is created.  That makes it cleaner, you have no  
cached data, and the instances aren't doing callbacks to their classes.

>
> ok anyway this won't change the fact that we still have the hackish
> thing with the yumhelper. But I currently don't see a more performant
> solution, regarding yum's overbloated behaviour. In my opinion calling
> yumhelper or even yum for every package is simply too slow and just  
> will
> use a lot of resources.


Clearly; I hope you never thought I was recommending that.

-- 
There are three social classes in America: upper middle class, middle
class, and lower middle class. --Judith Martin
---------------------------------------------------------------------
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