On Apr 15, 2:32 am, ikkaro <isaak.gonza...@gmail.com> wrote:
> The problem it's that when I run the class with stages it fails with a
> dependency cicle.
Which is? The --debug output showing the cycle and all the
autorequires would be helpful here.
> The class apt_official it set the Debian repos and doesn't "require"
> or "include any other class, it doesn't have dependencies.
>
> The class lsb-release install the packages lsb_release, this it's
> because I use the facter variable $lsbdistcodename to distinguish
> between Debian versions only in the class root_user_private_servers.
That's not going to do what you want, dependency issues
notwithstanding. Nodes posts all their facts to the server before
their manifest is compiled, so causing the lsb_release package to be
installed early in a Puppet run will not make the $lsbdistcodename
fact available later in the same run. Run stages partition a run into
stages, not into separate runs; there is no re-posting of facts
between stages.
> The idea it's to setup the Debian repositories first, then install the
> lsb_release package and the run all the others manifests.
Run stages can, in principle, give you that ordering. For what it's
worth, I personally would use only one preliminary stage, with
ordinary resource dependencies establishing the application order of
the resources in that stage. That wouldn't make any difference in
your dependency cycle, though.
> stage {"first": before=>Stage["second"]}
> stage {"second": before=>Stage["main"]}
>
> class { "compulsory_main1": stage=> first}
> class compulsory_main1
> {
> include apt_official
>
> }
>
> class { "compulsory_main2": stage=> second}
> class compulsory_main2
> {
> include lsb_release
>
> }
That's a strange way to do it. Why are you not doing this:
class { "apt-official": stage => first }
class { "lsb_release": stage => second }
? I suspect that the way you showed above puts only the wrapper
classes into the specified stages, not the wrapped ones. That could
impact your dependencies. Why do you need wrapper classes?
> class testA
> {
> include root_user_private_servers
>
> }
>
> I've also tried this one:
> class testA inherits compulsory_main2 {....}
Class inheritance is not the answer to this problem. Use it ONLY to
override resource properties, and override resource properties only
when you have no better alternative.
> this one
>
> class testA {
> include compulsory_main1
> include compulsory_main2
> include root_user_private_servers
> }
>
> and this one
>
> class testA {
> require compulsory_main1
> require compulsory_main2
> include root_user_private_servers
> }
The relative order of include and/or require statements is not a
reliable method to influence ordering, and it certainly does not
affect explicit dependencies, so this is also the wrong direction.
We can probably help you work out the dependency problem if you give
us more information. Again, however, this approach is not going to
get you where you want to be. As an alternative, you could use
conditional logic to get what you want across two Puppet runs, and
even to get the second one to commence soon after the first finishes.
Good luck,
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
