Hi all,
I''m a bit struggeling with puppet evaluation order.
I have module foo and module bar.
The nodes, will usually have foo and in some cases foo and bar modules.
i want to define a default root password for module foo, but a different
password for bar.
now as other modules are using the root user definitions, I''ve created
it as
a virtual resource somewhere else.
What I''ve done so far is:
*module foo::users*
realize( User["root"] )
User ["root"] {password => ''$...''}
@notify { "Setting Root Password to foo":
tag => foo_root_password,
require => User["root"]
}
*module bar::users*
realize( User["root"]
Notify <| tag == foo_root_password |>
if defined(Class["foo::users"]) {
notice("Using foo root password")
} else {
User ["root"] {password =>
''$...''}
}
this works 50% of times....
What am I doing wrong?
Thanks,
Ohad
--~--~---------~--~----~------------~-------~--~----~
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-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
Ohad Levy wrote:> Hi all, > > I''m a bit struggeling with puppet evaluation order. > > I have module foo and module bar. > The nodes, will usually have foo and in some cases foo and bar modules. > > i want to define a default root password for module foo, but a > different password for bar. > > now as other modules are using the root user definitions, I''ve created > it as a virtual resource somewhere else. > What I''ve done so far is: > *_module foo::users_* > realize( User["root"] ) > User ["root"] {password => ''$...''} > @notify { "Setting Root Password to foo": > tag => foo_root_password, > require => User["root"] > } > > _*module bar::users*_ > > realize( User["root"] > > Notify <| tag == foo_root_password |> > if defined(Class["foo::users"]) { > notice("Using foo root password") > } else { > User ["root"] {password => ''$...''} > } >Show us your real manifests! --debug output, too. Regards, AJ --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Jun 17, 2008, at 10:20 PM, Ohad Levy wrote:> Hi all, > > I''m a bit struggeling with puppet evaluation order. > > I have module foo and module bar. > The nodes, will usually have foo and in some cases foo and bar > modules. > > i want to define a default root password for module foo, but a > different password for bar. > > now as other modules are using the root user definitions, I''ve > created it as a virtual resource somewhere else. > What I''ve done so far is: > module foo::users > realize( User["root"] ) > User ["root"] {password => ''$...''} > @notify { "Setting Root Password to foo": > tag => foo_root_password, > require => User["root"] > } > > module bar::users > realize( User["root"] > > Notify <| tag == foo_root_password |> > if defined(Class["foo::users"]) { > notice("Using foo root password") > } else { > User ["root"] {password => ''$...''} > } > > this works 50% of times.... > > What am I doing wrong? >How are the classes included? Seems like that would make the biggest difference. If bar::users is included first, it will win. -- A complex system that works is invariably found to have evolved from a simple system that works. -- John Gaule --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
OK, now it gets difficult. in my environment, I have some modules, which some of their classes inherits other classes (from other modules). when this happens, puppet reports something like : debug: Class ''foo::users'' already evaluated; not evaluating again it would be a nightmare to figure out which includes happens first, is it safe to assume that its based on the ordered showed in: classes.txt? is there any other approach I could take? it would be really hard to manipulate the order of includes between different modules in a really large environment. Thanks, Ohad On 6/18/08, Luke Kanies <luke@madstop.com> wrote:> > > On Jun 17, 2008, at 10:20 PM, Ohad Levy wrote: > > > Hi all, > > > > I''m a bit struggeling with puppet evaluation order. > > > > I have module foo and module bar. > > The nodes, will usually have foo and in some cases foo and bar > > modules. > > > > i want to define a default root password for module foo, but a > > different password for bar. > > > > now as other modules are using the root user definitions, I''ve > > created it as a virtual resource somewhere else. > > What I''ve done so far is: > > module foo::users > > realize( User["root"] ) > > User ["root"] {password => ''$...''} > > @notify { "Setting Root Password to foo": > > tag => foo_root_password, > > require => User["root"] > > } > > > > module bar::users > > realize( User["root"] > > > > Notify <| tag == foo_root_password |> > > if defined(Class["foo::users"]) { > > notice("Using foo root password") > > } else { > > User ["root"] {password => ''$...''} > > } > > > > this works 50% of times.... > > > > What am I doing wrong? > > > > How are the classes included? Seems like that would make the biggest > difference. If bar::users is included first, it will win. > > -- > A complex system that works is invariably found to have evolved from a > simple system that works. -- John Gaule > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > > >--~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
maybe I''m doing something fundmentlly wrong with modules, here is an example of how I use it our environment. this is the output of external_nodes: --- classes: - host-puppetmaster - blr its important to mention that differnt admins have different permissions to edit different modules. here is the output of classes.txt: blr - included from external_nodes common::timezone-base - included by blr class common::config-timezone-blr - included by common::timezone-base bangalore::common - included by blr class common::users - inherited by bangalore::users (!) bangalore::users - included by bangalore::common host-base - inherited by host-puppetmaster (!) ssh::common - included by host-base . . . . . . host-puppetmaster - - included from external_nodes puppetmaster::puppetmaster - included from host-puppetmaster . . puppetmaster::ssh - included from host-puppetmaster and inherits common:ssh (!) . .. ... any feedback? Thanks, Ohad On 6/18/08, Ohad Levy <ohadlevy@gmail.com> wrote:> > OK, now it gets difficult. > > in my environment, I have some modules, which some of their classes > inherits other classes (from other modules). > when this happens, puppet reports something like : > debug: Class ''foo::users'' already evaluated; not evaluating again > > it would be a nightmare to figure out which includes happens first, is it > safe to assume that its based on the ordered showed in: classes.txt? > > is there any other approach I could take? it would be really hard to > manipulate the order of includes between different modules in a really large > environment. > > Thanks, > Ohad > > On 6/18/08, Luke Kanies <luke@madstop.com> wrote: >> >> >> On Jun 17, 2008, at 10:20 PM, Ohad Levy wrote: >> >> > Hi all, >> > >> > I''m a bit struggeling with puppet evaluation order. >> > >> > I have module foo and module bar. >> > The nodes, will usually have foo and in some cases foo and bar >> > modules. >> > >> > i want to define a default root password for module foo, but a >> > different password for bar. >> > >> > now as other modules are using the root user definitions, I''ve >> > created it as a virtual resource somewhere else. >> > What I''ve done so far is: >> > module foo::users >> > realize( User["root"] ) >> > User ["root"] {password => ''$...''} >> > @notify { "Setting Root Password to foo": >> > tag => foo_root_password, >> > require => User["root"] >> > } >> > >> > module bar::users >> > realize( User["root"] >> > >> > Notify <| tag == foo_root_password |> >> > if defined(Class["foo::users"]) { >> > notice("Using foo root password") >> > } else { >> > User ["root"] {password => ''$...''} >> > } >> > >> > this works 50% of times.... >> > >> > What am I doing wrong? >> > >> >> How are the classes included? Seems like that would make the biggest >> difference. If bar::users is included first, it will win. >> >> -- >> A complex system that works is invariably found to have evolved from a >> simple system that works. -- John Gaule >> --------------------------------------------------------------------- >> Luke Kanies | http://reductivelabs.com | http://madstop.com >> >> >> >> >> >--~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Jun 18, 2008 at 2:07 AM, Ohad Levy <ohadlevy@gmail.com> wrote:> maybe I''m doing something fundmentlly wrong with modules, here is an example > of how I use it our environment. > > this is the output of external_nodes: > > --- > classes: > - host-puppetmaster > - blr > > its important to mention that differnt admins have different permissions to > edit different modules. > > here is the output of classes.txt: > > blr - included from external_nodes > common::timezone-base - included by blr class > common::config-timezone-blr - included by common::timezone-base > bangalore::common - included by blr class > common::users - inherited by bangalore::users (!) > bangalore::users - included by bangalore::common > host-base - inherited by host-puppetmaster (!) > ssh::common - included by host-base > . > . > . > . > . > . > host-puppetmaster - - included from external_nodes > puppetmaster::puppetmaster - included from host-puppetmaster > . > . > puppetmaster::ssh - included from host-puppetmaster and inherits common:ssh > (!) > . > .. > ... > > > any feedback? > > Thanks, > Ohad >As has already been asked show us the real manifests and the --debug output. That is the only way to really give you good help. Second point there is _no_ set order in which resources are applied. That is what the require, notify, before and subscribe are for. Evan --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Jun 18, 2008, at 1:15 AM, Ohad Levy wrote:> OK, now it gets difficult. > > in my environment, I have some modules, which some of their classes > inherits other classes (from other modules). > when this happens, puppet reports something like : > debug: Class ''foo::users'' already evaluated; not evaluating again > > it would be a nightmare to figure out which includes happens first, > is it safe to assume that its based on the ordered showed in: > classes.txt? > > is there any other approach I could take? it would be really hard to > manipulate the order of includes between different modules in a > really large environment.In general, this difficulty is indicative that some other design should be used. I don''t know what the "right" option is, but something like a single class with a case statement, or finding a way to use conflicting subclasses, or maybe have one subclass actually subclass the other, so that if classB is included it always wins out over classA. -- Man is the only animal that can remain on friendly terms with the victims he intends to eat until he eats them. -- Samuel Butler (1835-1902) --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Jun 17, 2008 at 11:15 PM, Ohad Levy <ohadlevy@gmail.com> wrote:> OK, now it gets difficult. > > in my environment, I have some modules, which some of their classes > inherits other classes (from other modules). > when this happens, puppet reports something like : > debug: Class ''foo::users'' already evaluated; not evaluating again > > it would be a nightmare to figure out which includes happens first, is it > safe to assume that its based on the ordered showed in: classes.txt?No -- Puppet puts the resources you define together in a directed graph and does a topological sort. The end result is that there are likely multiple valid solutions for your manifest, which means you can''t rely on the order.> is there any other approach I could take? it would be really hard to > manipulate the order of includes between different modules in a really large > environment.We have similar problems, honestly. The practices which have served us best: 1) Every module "includes" all the other modules it requires, all the time, at the top of each class. 2) We use Class["foo"] as a require, often at the resource that we expect to be applied first within a class. For example, if we''re doing an LDAP Authentication recipe, we might have Class[''pam''] as a require on the package install. Best of luck, Ohad. Adam -- HJK Solutions - We Launch Startups - http://www.hjksolutions.com Adam Jacob, Senior Partner T: (206) 508-4759 E: adam@hjksolutions.com --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Jun 18, 2008 at 10:00 PM, Evan Hisey <ehisey@gmail.com> wrote:> > As has already been asked show us the real manifests and the --debug > output. That is the only way to really give you good help. Second > point there is _no_ set order in which resources are applied. That is > what the require, notify, before and subscribe are for. >For one, it would be a bit hard to put my real manifests, as we have more than 5000 lines :) Secondly, Maybe I didn''t explain myself correctly, you are right that the order of resource executing is done by require, before notify etc, however, and please correct my if I''m wrong here, try to put an if defined statement in your manifest, it will return true only if the class is really defined and it had evaluated already, that means, that if the puppetmaster reads the manifest with the if defined statement before it reads the class/resource you are trying to check against, it will return false. Ohad --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Well.. the main reason of trying to have this design is access control. I have the need to support many different locations, each of them needs some "freedom" but on the other hand, most of them needs to be as much possible the same. My ideal solution, is to create a module per location, where they have the rights to do what ever they want in that module, and if there is a real need, they could inherit something and change it (for normal configuration files we have a similar structure with multiple file sources). For example, each location wants a different root password. another reason to do it this way, is that its very easy to maintain globally, the person who is responsible for the "global" module (e.g. the common module) does not need to deal with every site exception list ( imagine you have 100 sites each one with his own needs... it would be hell to manage from the "HQ" point of view). What I dont understand is when the puppetmaster decides to not evaluate a class: debug: Class ''foo::users'' already evaluated; not evaluating again because the behavior that i see is that if i inherit the foo:users from another class, the inherited modifications that I do are completely ignored, and this seems wrong. but, it does work in some cases, I didn''t check, but it might be a different mongrel process each time (could it be that each PM returns diffrent config tree??) is there a way to force it to re-evaluate again? thanks a lot, Ohad On Wed, Jun 18, 2008 at 11:04 PM, Luke Kanies <luke@madstop.com> wrote:> > On Jun 18, 2008, at 1:15 AM, Ohad Levy wrote: > > > OK, now it gets difficult. > > > > in my environment, I have some modules, which some of their classes > > inherits other classes (from other modules). > > when this happens, puppet reports something like : > > debug: Class ''foo::users'' already evaluated; not evaluating again > > > > it would be a nightmare to figure out which includes happens first, > > is it safe to assume that its based on the ordered showed in: > > classes.txt? > > > > is there any other approach I could take? it would be really hard to > > manipulate the order of includes between different modules in a > > really large environment. > > > In general, this difficulty is indicative that some other design > should be used. > > I don''t know what the "right" option is, but something like a single > class with a case statement, or finding a way to use conflicting > subclasses, or maybe have one subclass actually subclass the other, so > that if classB is included it always wins out over classA. > > -- > Man is the only animal that can remain on friendly terms with the > victims he intends to eat until he eats them. > -- Samuel Butler (1835-1902) > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > > >--~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Adam,> > > We have similar problems, honestly. The practices which have served us > best: > > 1) Every module "includes" all the other modules it requires, all the > time, at the top of each class.I kinda do the same, but how do you handle inherited object modification? I cant get it work properly (e.g. works most of the times, but not all times, especially not on the first run)> > 2) We use Class["foo"] as a require, often at the resource that we > expect to be applied first within a class. For example, if we''re > doing an LDAP Authentication recipe, we might have Class[''pam''] as a > require on the package install. >That goes without saying...> > Best of luck, Ohad. > > AdamThanks :) --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Jun 18, 2008, at 8:01 PM, Ohad Levy wrote:> Well.. the main reason of trying to have this design is access > control. > > I have the need to support many different locations, each of them > needs some "freedom" but on the other hand, most of them needs to be > as much possible the same. > > My ideal solution, is to create a module per location, where they > have the rights to do what ever they want in that module, and if > there is a real need, they could inherit something and change it > (for normal configuration files we have a similar structure with > multiple file sources). > For example, each location wants a different root password.This kind of thing is where the external node tools can help; you can build a parameter inheritance model that makes it easy to acquire cross-cutting attributes (i.e., the root password is chosen based on location but set in some basic configuration class, so it''s cross- cutting).> > another reason to do it this way, is that its very easy to maintain > globally, the person who is responsible for the "global" module > (e.g. the common module) does not need to deal with every site > exception list ( imagine you have 100 sites each one with his own > needs... it would be hell to manage from the "HQ" point of view). > > > What I dont understand is when the puppetmaster decides to not > evaluate a class: > debug: Class ''foo::users'' already evaluated; not evaluating again > > because the behavior that i see is that if i inherit the foo:users > from another class, the inherited modifications that I do are > completely ignored, and this seems wrong. > but, it does work in some cases, I didn''t check, but it might be a > different mongrel process each time (could it be that each PM > returns diffrent config tree??) > > is there a way to force it to re-evaluate again?Classes are singletons, so no matter how many times you do ''include'', they can only get evaluated once. If you attempted to evaluate them again, you''d get duplicate resources for every resource in the class. I don''t really understand what you mean when you say the inherited modifications are ignored. Can you explain, preferably with code? -- The Chico, California, City Council enacted a ban on nuclear weapons, setting a $500 fine for anyone detonating one within city limits. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, Jun 19, 2008 at 9:26 AM, Luke Kanies <luke@madstop.com> wrote:> > This kind of thing is where the external node tools can help; you can > build a parameter inheritance model that makes it easy to acquire > cross-cutting attributes (i.e., the root password is chosen based on > location but set in some basic configuration class, so it''s cross- > cutting). >Thanks - thats the right direction!> > What I dont understand is when the puppetmaster decides to not > > evaluate a class: > > debug: Class ''foo::users'' already evaluated; not evaluating again > > > > because the behavior that i see is that if i inherit the foo:users > > from another class, the inherited modifications that I do are > > completely ignored, and this seems wrong. > > but, it does work in some cases, I didn''t check, but it might be a > > different mongrel process each time (could it be that each PM > > returns diffrent config tree??) > > > > is there a way to force it to re-evaluate again? > > > Classes are singletons, so no matter how many times you do ''include'', > they can only get evaluated once. If you attempted to evaluate them > again, you''d get duplicate resources for every resource in the class. > > I don''t really understand what you mean when you say the inherited > modifications are ignored. Can you explain, preferably with code? >Sorry, my bad, it seems that i was ignoring class variable scope, which is not being inherited... Thanks. Ohad --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---