Ok, not sure how much I can help, but I'll try. First, fair warning: This is a messy part of the code that we're trying to get into shape, but it's got more rough spots than other parts.
Ok, you're clearly having trouble with the difference between compile time and run time. Basically anything involving Puppet::Type has to be at run time (that is, on the client, when the compile is completely done). Thus, it looks like everything here is happening at run time, and none of it is at parse time. Thus, you should be able to control any order issues through relationships. It *looks* like you should be able to do what you want through a combination of autorequire and generate. Use 'autorequire' so that dependencies are set up for you as automatically as possible. For any actual creation of resources, use a generate method. It looks like the 'create_default_build' method should be called from that, but note that 'generate' should return resources, not directly add them to the catalog (see transaction.rb for how it's used; the generate_additional_resources method). I think there are a couple of examples shipped with Puppet, although probably a bit simplistic, or too complicated, as in file.rb's eval_generate method. Note that 'generate' is called recursively. I *think* 'finish' is called in graph order, so this should all just work. I'm not sure about where you should be calling purge_unknown_fragments, though. Maybe in the provider's prefetch method? On Aug 21, 2012, at 11:46 AM, Trevor Vaughan <[email protected]> wrote: > Sure thing! > > You can find an example of what I'm doing here: goo.gl/1HiZm > > This works just fine. > > However, if we have a resource that we're creating in the finish > define that another resource in a manifest relies on, *sometimes* that > requirement fails. > > So, if we created a file resource in 'create_default_build' '/tmp/foo' > for example then, in a manifest, had a require => File['/tmp/foo'] > statement, then this statement would work occasionally. > > In that light it feels like a parse order issue but I have no idea > where or why or how to stick something in 'initialize' that says that > this object should be coming later in the parse tree. > > Let me know if that's not enough and I can hack together a full example. > > Trevor > > > > > On Tue, Aug 21, 2012 at 12:56 PM, Luke Kanies <[email protected]> wrote: >> On Aug 20, 2012, at 5:21 PM, Trevor Vaughan <[email protected]> wrote: >> >>> So, I'm stumbling through some sort of strange code and want to know >>> where I'm going wrong. >>> >>> We've been updating our concat module on Github and are now >>> auto-generating the concat_build from the 'finish' portion of the >>> concat_fragment type if it doesn't already exist. >>> >>> This *seems* reasonable, but I'm starting to see potential situations >>> where I've been experimenting with different techniques for doing this >>> and have found the following: >>> >>> 1) When auto-spawning a resource in the 'initialize' define, you don't >>> have any guarantee as to which one will be hit first, the one in the >>> manifest or the one spawned from the resource since the code isn't >>> fully compiled at that time. >>> 2) When auto-spawning a resource in the 'finish' define, you have the >>> guarantee that the catalog has been fully compiled but, occasionally, >>> when I try to set a require to that object, it fails stating that the >>> object is not defined. >>> >>> I'm assuming that #2 is happening because the containing object has >>> not yet completed its journey through the compiler but I'm curious if >>> there is a way that I can tell the catalog that the auto-generated >>> object (that will be optionally spawned in the 'finish' define) exists >>> without completely breaking things. >>> >>> Any suggestions or assistance would be appreciated. >> >> Can you post some code? I'm not quite sure what you mean, and as you know, >> this is complicated stuff. >> >> -- >> Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199 >> >> -- >> 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. >> > > > > -- > 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 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. > -- Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199 -- 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.
