[Puppet Users] defined function notparse order dependant

If the relevant code were just sitting there naked in your site manifest, I
think you'd probably see a fairly simple parse-order dependency -- I think
it's the fact that they're in defined types that's shifting things around.
Actually, one of the core team surprised me the other week by telling me
that defined types are somehow late-binding when creating their resources,
in a way that classes aren't; I can't remember why they thought it had been
implemented that way, though.

The point is, this is EXACTLY why we say to not use `defined()` like that,
is because it can cause havoc for downstream users like you. I'm afraid
you're going to have to fork b::b and go in and muck with its
implementation if you want any certainty around this behavior.

The difference between 'a' and 'b::b' was that 'a' didn't have a file
declaration, it had a resource declaration that had a file declaration. So
if I created a new resource that wrapped 'b::b' then I got a straight
forward parse-order dependency.

I tend to use defined because it allows you to under gird something without
that something actually knowing who you are. In this case the plugin was
git. I was using the repo resource to checkout some code. It was
declaring the folder that was going to be checked out. Defined works nice
because when you read it, you understand what they are trying to do, even
if puppet has a hard time producing that result. Alternatives I have read
involve defining a class and including it. But that requires git to know
about said class, also it doesn't work for resources which applies in this
case. The other alternative I have read about is something like
virtualized resources? You manifest them at each point. I have not really
seen any good documentation on what it is, how it works, what it requires.
The code I have seen does not make it clear to the user what is taking
pace, it just doesn't read well.

If you declare things something like this psuedo code:
A
C
F1
B
D
F2

When people read it they are going to more commonly expect the order to go
A
C
F1
B
D
F2

Not
A
B
C
D
F1
F2


In git they set recurse to true. Compound that with a resource default up
the declaration stack and you have puppet spending a long time uselessly
changing the ownership and permission on a ton a files when they get
checked out. I find the dynamic scope of resource defaults to be more of a
surprise and a burden then a useful tool.

Anyway I am resolved, thanks for the help.

A bit of a thread hijack, but I really agree about the dynamic scope for
resource defaults being just as (if not even more) annoying and
unpredictable than the dynamic scoping for variables was.

This is not a characteristic to manipulate, but rather a strong reason to
avoid defined() altogether. I cannot say this more strongly: DO NOT USE IT.



The *declaration* of resource A[$somevar] is surely parsed before the
declaration of B::B[$somevar], but that's not at all the same thing as the
body of defined type 'a' being parsed before the body of defined type
'b::b'. It's pretty much irrelevant why the parse order you see happens --
Puppet guarantees parse order only within each manifest file, so manifests
that depend on parse order across multiple files are flawed. Even if you
found a magic formulation that achieved the order you want on a given
version of Puppet, there is no guarantee that it would continue to work
even in the next maintenance release.

As I say here from time to time, your manifests should not attempt to query
Puppet about what has already been declared. There are a number of
techniques by which that is possible, but generally they can be described
as using "data-driven" approaches to manifest and manifest-set design. As
an over-simplified example, you could set a boolean node variable
$i_will_use_a, and then change the condition in b::b like so

define b::b (...) {
if ! $i_will_use_a {
file { $name:
...
}
}
...
}

There are a host of other ways to do essentially the same thing.


John

I appreciate the reply but I think the thrust of my point is getting missed.

Any other solution is far more cryptic, some reader coming and reading the
code will not understand the code nearly as well.

The fact that puppet has a dimension (parse order) that is so convoluted
that its behavior cannot be understood is not a virtue. It is a very bad
thing.