Is it really this complicated? Follow my logic here...
In my scenario, it''s critical that my yum repositories get installed
by puppet to /etc/yum.repos.d first before anything else happens.
After this, the yum-priorities rpm must be installed with yum,
followed by ldap, since the installation of ldap MUST be complete and
the nscd service started before anything else gets done.
For this, I have a default package in the base node, like this:
node basenode_centos inherits basenode {
include yum
include ldap_client
include other_stuff
Package {
require => [
Yumrepo["Twofish-Core"],
Yumrepo["EPEL-Core"],
Yumrepo["DAG-Core"],
Yumrepo["CentOS-Base"],
Yumrepo["CentOS-Updates"],
Class["yum"],
Class["ldap_client"]
]
}
}
Now, the yum module will complain about module dependency looping, so
it''s a special case. It can''t automatically require all the
repositories it needs (for yum-prioritities), so the yum module has
this. I assume when you define a Package{} default at a lower level,
it overrides the upper level completely.
class yum {
Package {
require => Yumrepo["CentOS-Base"]
}
package {
yum:
ensure => installed;
centos-release:
ensure => installed;
yum-priorities:
ensure => installed;
}
}
My LDAP module has the same problem. Since it''s in the default
Package{}, it would also complain about module dependency looping, so
it has:
class ldap_client {
Package {
require => Class["yum"]
}
}
I''m still not sure that requiring a Class means that that class has to
be fully complete or not. The docs are vague on this. Anyway, but ldap
requiring the yum class, this means that the yum class (i hope) has to
be fully implemented before LDAP installs any packages.
Is it just me, or is this just plain way over complicated? I just know
that as soon a I touch something the whole damn thing is going to
break, and it will be a nightmare to debug. If we could include
modules in an order, and have them implemented in that order, it would
be SO much easier.
Doug.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
hello, ----- "Douglas Garstang" <doug.garstang@gmail.com> wrote:> Is it really this complicated? Follow my logic here... > > In my scenario, it''s critical that my yum repositories get installed > by puppet to /etc/yum.repos.d first before anything else happens. > After this, the yum-priorities rpm must be installed with yum, > followed by ldap, since the installation of ldap MUST be complete and > the nscd service started before anything else gets done. >Unfortunately this is pretty hard, there''s been many requests for a way to forceably hook something into the beginning of the process but so far there isnt a good way. There''s a ticket you can go and voice your support for the feature requests there. I''m thinking you can do what you want by being careful about how you compose your classes - quite hard if you''re just starting out though - but really if you need several different types of resource to execute before all other types of resources you''re going to be hard pressed to get this done without decoupling things. I have this problem too and took care of it this way: - create an environment that sets up JUST the stuff i need done first with putting down a cfg file to put the machine in the final environment as last step, call it bootstrap - this environment has only node default and nothing else. - arrange for kickstart to put down a cfg file that puts all machines into bootstrap So now you''ll run your node the first time, it will get yum repos setup, ldap installed and finally if both of those worked it will get a cfg file. With just these 3 tasks forcing the dependencies isn''t hard: Class[yum::config] - create your config files u need for yum Class[yum::repos] - include all your yum repo resources, requires yum::config Class[ldap::install] - installs the ldap package - requires yum::repos Class[ldap::config] - configures ldap, requires ldap::install Class["bootstrap"] - includes all the above File[/etc/puppet/puppet.conf] - requires Class["bootstrap"] Your default node would then just do: include bootstrap file{"/etc/puppet/puppet.conf": source => .... require => Class["boostrap"] } With this if any of the yum config, ldap config etc fails the puppet.conf wont be put down and your machine will stay in bootstrap, even if your requires are wrong after 2 or so runs it will sort itself out Future runs will get your normal manifests which should include yum repos, yum and ldap but then the ordering is less important since being first is only crucial the first time - subsequent times matter less. Other things you can do: - tag all your classes/resources with a tag and use the --tags option to run those, maybe easier than the environment - wrap your package calls in a define that has requires on the resources it creates, use that for all your package calls that way you do not need to specify require => on each one - create a small little bootstrap manifest that you put on the machine during kickstart, call this using the ''puppet'' executable and not via the master where the bulk of your manifests will come in You can read about classes dependencies here: http://www.devco.net/archives/2009/09/28/simple_puppet_module_structure.php and about using ''puppet'' rather than puppetd here http://www.devco.net/archives/2009/08/19/tips_and_tricks_for_puppet_debugging.php -- R.I.Pienaar --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
2009/10/25 R.I.Pienaar <rip@devco.net>:> > hello, > > ----- "Douglas Garstang" <doug.garstang@gmail.com> wrote: > >> Is it really this complicated? Follow my logic here... >> >> In my scenario, it''s critical that my yum repositories get installed >> by puppet to /etc/yum.repos.d first before anything else happens. >> After this, the yum-priorities rpm must be installed with yum, >> followed by ldap, since the installation of ldap MUST be complete and >> the nscd service started before anything else gets done. >> > > > Unfortunately this is pretty hard, there''s been many requests for a way to forceably hook something into the beginning of the process but so far there isnt a good way. There''s a ticket you can go and voice your support for the feature requests there. >The way i''ve gotten around this before is by tagging my classes, and then do an initial run with puppetd for things tagged with yum and ldap. Then you just run puppetd again, as the yum and ldap dependencies should be setup. Typically I did the yum/ldap tagged run inside a Kickstart, and the untagged run on reboot. HTH, Lindsay -- http://holmwood.id.au/~lindsay/ (me) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
----- "Lindsay Holmwood" <lindsay@holmwood.id.au> wrote:> > Unfortunately this is pretty hard, there''s been many requests for a > way to forceably hook something into the beginning of the process but > so far there isnt a good way. There''s a ticket you can go and voice > your support for the feature requests there. > > > > The way i''ve gotten around this before is by tagging my classes, and > then do an initial run with puppetd for things tagged with yum and > ldap. > > Then you just run puppetd again, as the yum and ldap dependencies > should be setup. > > Typically I did the yum/ldap tagged run inside a Kickstart, and the > untagged run on reboot.So exactly like i suggested later on in my mail? :) -- R.I.Pienaar --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
2009/10/25 R.I.Pienaar <rip@devco.net>:> > ----- "Lindsay Holmwood" <lindsay@holmwood.id.au> wrote: > >> >> The way i''ve gotten around this before is by tagging my classes, and >> then do an initial run with puppetd for things tagged with yum and >> ldap. >> > > So exactly like i suggested later on in my mail? :) >Yeah, sorry. I read it, but just chose a bad place to quote and jump off. :-) Lindsay -- http://holmwood.id.au/~lindsay/ (me) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---