Execution order of classes

[Markus "Shorty" Uckelmann]

Hi all,

I'm stuck in the hell of class dependencies and hope that someone here
can help me.

Puppet-Version is 2.7.21
It's the Debian Squeeze package from the Puppetlabs Repo.

I want one class to manage everything database related. So I call it in
"site.pp" like this:

node client1 {
class { 'database': }
}

It's parameterized and uses default values. The class "database"
declares(executes) other classes.

Now to my problem. I have a "sub"-class "database::packages" which must
be executed before every other stuff inside the database class. Here is
the code:

1 class database {
2 class { 'database::packages': } ->
3 # setup data dirs
4 class { 'database::directories':
5 # require => Class['database::packages'],
6 }
7 # Class['database::packages'] -> Class['database::directories']
8 }

I tried three different things. None of them worked. First one is the
chaining arrow in line 2. The next two tries I left commented out. In
line 5 I tried to require the "packages" class inside the "directories"
class declaration. And last in line 7 I tried the chaining again.

Whenever I run this code on a client, the "directories" class gets
executed first and fails, because it needs a specific user which is
setup in the "packages" class.

BTW: I also tried to put the code from line 7 inside the "sub"-classes.

Thanks for any help.

Cheers, Shorty

[Markus Uckelmann]

Cheers, Markus

[Markus "Shorty" Uckelmann]

Am 24.05.2013 11:35, schrieb Markus Uckelmann:
> Hi all,

Sorry for the double post.

[jcbollinger]

As judged how?

 

and fails, because it needs a specific user which is
setup in the "packages" class.

 
All of the methods you tried for declaring the needed relationship are valid and appear correct.  I conclude that you have diagnosed the problem incorrectly.

To be sure, you do have an order-of-application issue, but I don't think it's the relative order of these classes themselves that is the problem.  It is more likely a containment issue within one or more of those classes' implementations.  I suggest you read the documentation on that area (http://docs.puppetlabs.com/puppet/3/reference/lang_containment.html) for information on that problem and and least one possible solution.


John

[Markus "Shorty" Uckelmann]

Am 24.05.2013 16:20, schrieb jcbollinger:

>> Whenever I run this code on a client, the "directories" class gets
>> executed first
>
> As judged how?

Running "puppet apply --test" in a Client, destroying the client(it's a
Vagrant instance) and doing it again... ;)

> All of the methods you tried for declaring the needed relationship are
> valid and appear correct. I conclude that you have diagnosed the
> problem incorrectly.

How should I have diagnosed this? Would have the debug switch helped?

> those classes' implementations. I suggest you read the documentation on
> that area
> (http://docs.puppetlabs.com/puppet/3/reference/lang_containment.html)
> for information on that problem and and least one possible solution.

That did the trick. Now my code looks like this:

class database ( $serverpackage = 'mariadb' ) {
class { 'database::packages':
serverpackage => $serverpackage,
}
# setup data dirs(should change my.cnf and restart mysql!)
class { 'database::directories':

require => Class['database::packages'],
}

anchor {'db_first':} -> Class['database::packages'] -> anchor {'db_last':}

[...]
}

After a handful of testruns it seems to work. I had read the
documentation you mentioned and didn't make the connection. My mistake.

Thanks for your help John.

BTW: I joined the related bug report ;)

Cheers, Shorty

[jcbollinger]

I'm glad you got it working.

In response to your question, when I said you had diagnosed the problem incorrectly, I meant you had come to an incorrect conclusion, not necessarily that you had done anything inherently wrong.  However, the --debug switch is definitely your friend when you are trying to figure out Puppet problems.  If you had enabled it on the agent then you might have seen resources from the several classes being applied in an intermingled fashion (instead of first all belonging to one class, then all belonging to another, etc.), which would have been a clearer sign of a containment problem.


Best,

John