Yeah, that method should probably be moved into the framework, rather than be 
hung off of Puppet::Type.


On Aug 24, 2012, at 10:10 AM, Trevor Vaughan <[email protected]> wrote:

> That's what I am thinking, but I took a look at 'finish' and it seems
> to be where the code is called to check the dependencies. Shouldn't
> this be a function of the catalog, not the type?
> 
> So:
> 
> 1) Compile catalog
> 2) Run 'finish' in the types (very useful to have)
> 3) catalog.check_deps (or something)
> 
> Trevor
> 
> On Fri, Aug 24, 2012 at 11:55 AM, Luke Kanies <[email protected]> wrote:
>> I think 'finish' is only called when all of the resources are created and 
>> added to the catalog, but 'initialize' is called to actually create each 
>> resource.
>> 
>> On Aug 23, 2012, at 9:57 AM, Trevor Vaughan <[email protected]> wrote:
>> 
>>> This is what's confusing me most certainly.
>>> 
>>> If I add a statement in the 'initialize' define that lists a count of
>>> the items in the catalog, it increases *every time*.
>>> 
>>> However, in the 'finish' define, it is static.
>>> 
>>> Why doesn't it know about the entire catalog, and why does catalog
>>> injection not work consistently in both places?
>>> 
>>> I think you answered enough of my question for me to muddle through
>>> though. I'll take a look at generate.
>>> 
>>> Thanks,
>>> 
>>> Trevor
>>> 
>>> On Tue, Aug 21, 2012 at 7:55 PM, Luke Kanies <[email protected]> wrote:
>>>> 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.
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> 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.
>> 
> 
> 
> 
> -- 
> 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.

Reply via email to