Thanks John, Unfortunately, the internals are above my current understanding as well. But, yes, your ideas and explanation make sense and I had hit that site before.
I'm not exactly sure what my class variable belongs to but I do know that I couldn't figure out another sane way of sharing state between all of the instances. Still crossing my fingers that something better comes along. I could fall back to doing what datacat does and spawning another resource just for the purpose of building this one, but that doesn't really seem better. Thanks, Trevor On Mon, Jun 2, 2014 at 2:56 PM, John Bollinger <[email protected]> wrote: > > > On Monday, June 2, 2014 11:04:01 AM UTC-5, Trevor Vaughan wrote: >> >> Just checking in. Does anyone else have any ideas on this one? >> >> I've tried everything obvious that I could think of and I'm coming up >> blank. >> >> > > I found some possibly-relevant information here: > http://makandracards.com/makandra/14229-the-many-gotchas-of-ruby-class-variables. > One of the details that strikes me as more important is that a reference to > a class variable is bound at parse time, based on the lexical scope in > which it appears (my paraphrase). In particular, the class_eval and > instance_eval functions do not, the article claims, affect the scope with > respect to which the variable is interpreted, and its appearance within the > block passed to one of those functions is what triggers the warning, or at > least one thing that can trigger it. (Note also the author's summary: > "TLDR: Ruby class variables (@@foo) are dangerous in many ways. You > should avoid them at all cost.") I think that means your class variable > may not belong to the class to which you think it does. > > Since the whole point here is to have a data repository that multiple > provider instances can share, can you not open a Puppet class whose > instances are accessible and have appropriate duration, and add one as an > instance variable? I had at one point suggested that the perhaps > Puppet::Transaction should offer such a capability, and indeed, tying the > data to a single transaction would problems with data being held over from > run to run in daemon mode. It sounds good to me, anyway, but I'm afraid > the implementation details are beyond my current knowledge of Puppet > internals. > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/2dbe06ee-9867-4da4-a6c8-71e92d61c94d%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/2dbe06ee-9867-4da4-a6c8-71e92d61c94d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUoym42ZQpF-MqjZLQR1yLOpf-9%3DefLzTMW_wcN8JGgww%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
