I appreciate you taking the time to review my post and give such a thorough
answer.
Thank you,
Johnathan
On Friday, March 9, 2018 at 9:52:19 AM UTC-5, jcbollinger wrote:
>
>
>
> On Thursday, March 8, 2018 at 4:53:27 PM UTC-6, Johnathan Komara wrote:
>
>
>> 'profile::a' should be applied to every server and 'profile::b' is only
>> being applied to a few servers. My understanding of resource chaining is
>> that I can alter the order in which the classes are ran. I need "b" to run
>> first so that I can key off of "defined(File['/etc/test/txt']).
>>
>
>
> No, you don't, and you shouldn't. You should not use the defined()
> function at all, in fact, because it produces evaluation-order
> dependencies, which is exactly what you are dealing with. You will find
> considerable discussion of this topic in the archives of this group,
> including several previous assertions on my part that defined() is evil.
>
> Additionally, you are conflating two different orderings: order of
> manifest *evaluation* on the master and order of catalog *application* on
> the target node. Resource relationships, whether established via the chain
> operators or via the appropriate resource metaparameters,affect only the
> latter, whereas defined(), being evaluated during catalog building, is
> affected only by the former.
>
>
>>
>> I have tried multiple approaches and I cannot get this to work.
>>
>
>
> I'm not at all surprised, since even if you are determined to use
> defined() despite my advice, you're trying to use the wrong tool for the
> job of getting the evaluation order you need to make it work. Evaluation
> order depends primarily on the contents and lexical order of your
> manifests. It is extremely difficult to predict, and if you have caching
> enabled in the relevant environment then you're pretty much toast.
>
>
>
>> The only way that it works is if I explicitly include 'profile::b' before
>> 'profile::a' in base.
>>
>> class profile::base {
>> include 'modules'
>> include '::profile::b'
>> include '::profile::a'
>> }
>>
>> Or if I remove 'profile::a' from base and include them both in the role.
>>
>> class role::test_server inherits ::role {
>> include '::profile::b'
>> include '::profile::a'
>> }
>>
>>
> As I said, the contents and lexical order of your manifests. But even
> that may not be reliable. Classes can be included multiple times, from
> multiple locations, and if you have another location where you include
> ::profile::a before or without including ::profile::b, then your result
> will depend which declaration of ::profile::a is evaluated first.
>
>
>>
>> I have alternatives. I can set values in hiera to key off of or push out
>> custom facts.
>>
>
>
> And that is what you indeed should do instead. There might be room for an
> accompanying refactoring of your manifest set to go along with it and make
> things smoother, but you'll need to determine that for yourself.
>
> Moreover, you might not need to add anything in the first place. You
> already have logic some place to determine whether to assign
> role::test_server to your nodes. It seems that's the same thing you want
> to rely on here.
>
>
>
>> Custom facts will not be there on the first run which is probably ok. I
>> think we would run into a few issues here and there but I could make it
>> work.
>>
>
>
> Custom facts could work too, but it is best for the target configuration
> of your nodes to be determined by their identities and invariant
> characteristics, based on centrally-maintained manifests and data.
>
>
>
>> Everything I have read says that chaining the resource should enforce the
>> order but I am obviously missing something. Can someone see what I am doing
>> wrong or explain why this will not work?
>>
>
>
> In addition to what I've already said, the fact that you're using class
> inheritance has bad code smell, and in practice it contributes to your
> problem.
>
> Class inheritance is an ancient feature of the language that was
> originally intended to provide for overriding the parameters of resources
> declared by the parent class. It still works for that, but Puppet has
> other mechanisms for that purpose, and for avoiding the need for overrides
> in the first place, and nowadays those are stylistically preferred. Class
> inheritance also has the side effect of causing the parent class to be
> evaluated before the child class, which is what makes the params class
> pattern work, and that pattern is the only widely accepted use for class
> inheritance in modern Puppet.
>
> In OO-speak, prefer composition over inheritance. Very much more so in
> Puppet DSL -- which looks a lot more like an OO language than it really is
> -- than in general-purpose OO programming languages, such Java or C++.
>
>
> John
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" 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-users/b80ef1bd-86aa-4687-9823-c446594d2550%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
