So.. I''ve been fighting with trying to get puppet to include/execute module in a certain order for several weeks now. I kind of have something hacked together, but it scares me a bit since I don''t know exactly what is happening. I don''t suppose there''s still an easy way to do this....? 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.
First post didn''t appear on the list (gee, like that doesn''t happen all the time....) So.. I''ve been fighting with trying to get puppet to include/execute module in a certain order for several weeks now. I kind of have something hacked together, but it scares me a bit since I don''t know exactly what is happening. I don''t suppose there''s still an easy way to do this....? 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.
On Thu, Nov 26, 2009 at 7:45 PM, Douglas Garstang <doug.garstang@gmail.com> wrote:> First post didn''t appear on the list (gee, like that doesn''t happen > all the time....)But it did, this is the second post from you on the topic. -- 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Douglas Garstang wrote:> First post didn''t appear on the list (gee, like that doesn''t happen > all the time....)It did appear - and it''s never happened to me. I would suggest perhaps looking to your end for issues?> So.. I''ve been fighting with trying to get puppet to include/execute > module in a certain order for several weeks now. I kind of have > something hacked together, but it scares me a bit since I don''t know > exactly what is happening.Can you elaborate on what you want to do and/or perhaps some the module/manifests you''ve developed? Regards James Turnbull - -- Author of: * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLDz+7AAoJECFa/lDkFHAyjFkIAIpkz4cZ9nIvf7bmyYd7y4WZ k89taq/h9lCjsf+wsTpFygrbYZ5hS9TfPg+GA7zb/b9FAQP4w21ShkfDbAJF0h+S DjZ4hg2nu8vhvsRyHUz4cYa1m8aQqTTllaOqP7fO1byakaOIES5GXsdlHu3vErtZ Klgs39b0mRA/nAopDldhjdtk7Uwup6lrslLYZPvW1fzgkdvIyRXq6XFetG6spAY5 zn4x0QQA1CIRhxg7dOCvPP6IVoWf+69hTTiSfaOYpAz2FZqKNRzPHaAqLYCbHyX3 gWr5Tw74vtfie1PrSk76nOcnCxbGN/6L02zsDXRzIanXww2pyPfvBWkkBLsKLNw=6x8y -----END PGP SIGNATURE----- -- 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.
Douglas, Douglas Garstang wrote:> First post didn''t appear on the list (gee, like that doesn''t happen > all the time....)Google Groups doesn''t send emails back to the original sender. If you want to check if an email has hit the list, check the web interface at http://groups.google.com/group/puppet-users. cYa, Avi -- 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.
Avi Miller wrote:> Google Groups doesn''t send emails back to the original sender. If > you want to check if an email has hit the list, check the web > interface at http://groups.google.com/group/puppet-users.Actually, I believe Google Groups does send them. AFAIK, the lovely ''feature'' of not getting list mail you sent is a Gmail one, not Google Groups. At least, I''ve always gotten my own list posts (and I hope that doesn''t change). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Marriage is like a bank account. You put it in, you take it out, you lose interest. -- Prof. Irwin Corey
Douglas Garstang wrote:> First post didn''t appear on the list (gee, like that doesn''t happen > all the time....) > > So.. I''ve been fighting with trying to get puppet to include/execute > module in a certain order for several weeks now. I kind of have > something hacked together, but it scares me a bit since I don''t know > exactly what is happening. > > I don''t suppose there''s still an easy way to do this....?I have as one of the very fist things in my site.pp a list of imports of modules. That way at least the init.pp of each of the listed modules is activated. This is from before autoloading though, so in a newer installation I would consider most modules that need an import as (slightly) broken. Regards, DavidS -- 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 Nov 26, 2009, at 10:14 PM, Todd Zullinger wrote:> Avi Miller wrote: >> Google Groups doesn''t send emails back to the original sender. If >> you want to check if an email has hit the list, check the web >> interface at http://groups.google.com/group/puppet-users. > > Actually, I believe Google Groups does send them. AFAIK, the lovely > ''feature'' of not getting list mail you sent is a Gmail one, not Google > Groups.I can confirm this. I also get my own posts. One more reason not to use Gmail, I guess. :) On a related [OT] note: Anyone know if you can use Groups, Calendar, Reader, etc. but not have a Gmail account? My friends discover my Gmail address somehow and send mail to it, but I never check it. -- Rob McBroom <http://www.skurfer.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.
Rob McBroom wrote:> On Nov 26, 2009, at 10:14 PM, Todd Zullinger wrote: > >> Avi Miller wrote: >>> Google Groups doesn''t send emails back to the original sender. If >>> you want to check if an email has hit the list, check the web >>> interface at http://groups.google.com/group/puppet-users. >> Actually, I believe Google Groups does send them. AFAIK, the >> lovely ''feature'' of not getting list mail you sent is a Gmail one, >> not Google Groups. > > I can confirm this. I also get my own posts. One more reason not to > use Gmail, I guess. :)me too> On a related [OT] note: Anyone know if you can use Groups, Calendar, > Reader, etc. but not have a Gmail account? My friends discover my > Gmail address somehow and send mail to it, but I never check it.yes, there is a way (convoluted but existing) I recently removed my gmail account from my google account. IIRC it is buried in the gmail settings somewhere. Regards, DavidS -- 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 27.11.2009 17:51, David Schmitt wrote:> Rob McBroom wrote: > >> On Nov 26, 2009, at 10:14 PM, Todd Zullinger wrote: >> >> >>> Avi Miller wrote: >>> >>>> Google Groups doesn''t send emails back to the original sender. If >>>> you want to check if an email has hit the list, check the web >>>> interface at http://groups.google.com/group/puppet-users. >>>> >>> Actually, I believe Google Groups does send them. AFAIK, the >>> lovely ''feature'' of not getting list mail you sent is a Gmail one, >>> not Google Groups. >>> >> I can confirm this. I also get my own posts. One more reason not to >> use Gmail, I guess. :) >> > me too > > >> On a related [OT] note: Anyone know if you can use Groups, Calendar, >> Reader, etc. but not have a Gmail account? My friends discover my >> Gmail address somehow and send mail to it, but I never check it. >> > > yes, there is a way (convoluted but existing) I recently removed my > gmail account from my google account. IIRC it is buried in the gmail > settings somewhere. >You may also forward your e-mails to your real e-mail address.> > Regards, DavidS > > -- > > 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. > > >Silviu -- 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, Nov 26, 2009 at 11:59 PM, David Schmitt <david@dasz.at> wrote:> Douglas Garstang wrote: >> First post didn''t appear on the list (gee, like that doesn''t happen >> all the time....) >> >> So.. I''ve been fighting with trying to get puppet to include/execute >> module in a certain order for several weeks now. I kind of have >> something hacked together, but it scares me a bit since I don''t know >> exactly what is happening. >> >> I don''t suppose there''s still an easy way to do this....? > > I have as one of the very fist things in my site.pp a list of imports of > modules. That way at least the init.pp of each of the listed modules is > activated. > > This is from before autoloading though, so in a newer installation I > would consider most modules that need an import as (slightly) broken.Not quite sure I follow David. You explicitly import specific modules in site.pp? This is what I have currently... import "definitions/*.pp" import "modules/*.pp" import "nodes/*.pp" Are you saying that by putting specific module imports before these lines that they will get executed first? Is this actually documented somewhere? 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.
On Thu, Nov 26, 2009 at 6:55 PM, James Turnbull <james@lovedthanlost.net> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Douglas Garstang wrote: >> First post didn''t appear on the list (gee, like that doesn''t happen >> all the time....) > > It did appear - and it''s never happened to me. I would suggest perhaps > looking to your end for issues?They usually do appear... sometimes not however.> >> So.. I''ve been fighting with trying to get puppet to include/execute >> module in a certain order for several weeks now. I kind of have >> something hacked together, but it scares me a bit since I don''t know >> exactly what is happening. > > Can you elaborate on what you want to do and/or perhaps some the > module/manifests you''ve developed?I really can''t remember anymore. Someone on this list seemed quite certain that modules where executed in the order they were imported, which turned out to be wrong. At the moment I have a few modules tagged as ''bootstrap''. The initial puppet.conf on the client has ''tags=bootstrap'' in it, so that when puppet runs for the first time, it only applies those modules. There''s also a puppet module which over writes the puppet.conf and removes the tags=bootstrap line so that the next time it runs, it grabs everything else. This approach isn''t perfect though. I''d really like to be able to execute the modules within the bootstrap phase within a specific order, so that, say, ntp gets done first followed by LDAP, and so on. If LDAP is half implemented, and puppet tries to add a user through another module, for example, the useradd command just locks up. Within the bootstrapped modules currently I have a horrible mess of unmaintainable requires => statements, that are just going to get harder to maintain as times goes on. I''m afraid to touch it now, for fear of what will break. And, this fear of touching stuff applies to everything else too. I''m using puppet to deploy the RPM"s for our software and manage the config files. Obviously things have to get done in a certain order, and the complexity of all the dependancies is simply NUTS. I''m afraid to touch it, for fear of what it will break. 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.
Douglas Garstang wrote:> On Thu, Nov 26, 2009 at 11:59 PM, David Schmitt <david@dasz.at> wrote: >> Douglas Garstang wrote: >>> First post didn''t appear on the list (gee, like that doesn''t happen >>> all the time....) >>> >>> So.. I''ve been fighting with trying to get puppet to include/execute >>> module in a certain order for several weeks now. I kind of have >>> something hacked together, but it scares me a bit since I don''t know >>> exactly what is happening. >>> >>> I don''t suppose there''s still an easy way to do this....? >> I have as one of the very fist things in my site.pp a list of imports of >> modules. That way at least the init.pp of each of the listed modules is >> activated. >> >> This is from before autoloading though, so in a newer installation I >> would consider most modules that need an import as (slightly) broken. > > Not quite sure I follow David. > > You explicitly import specific modules in site.pp? This is what I have > currently... > > import "definitions/*.pp" > import "modules/*.pp" > import "nodes/*.pp" > > Are you saying that by putting specific module imports before these > lines that they will get executed first? Is this actually documented > somewhere?Uhhh, importing, parsing and application on the client are different issues. Since I''m not sure (anymore) what you are referring to, I''ll define those actions explicitly for this discussion: * parsing: the process of translating the manifests and modules on disk into the catalog, which is sent to the client. * importing: while parsing, the execution of the import() method adds more modules and manifests to be parsed. * application: after the catalog is downloaded by the client, the contents of the catalog are applied to the system. Depending on which action you really meant, the question has different answers: * parsing: manifests and modules are parsed in top-down order. Methods, variables, classes, defines and resources earlier in a file are parsed (and thus evaluated) before those later in the file. * importing: since import is a function, it is evaluated at that point in the parsing process when it is encountered in the manifest. At this point the referenced files are parsed and their content added to the catalog (as far as they are applicable). * application: application order is totally dependent on the require/before/notify/subscribe meta-parameters as specified in the catalog. Parse-order has no influence here. For my recommended way of using modules that are not safe for autoloading, please see lines 13-17 in http://github.com/puppet-modules/puppet-manifests/blob/master/manifests/site.pp Regards, DavidS -- 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 Mon, Nov 30, 2009 at 12:12 AM, David Schmitt <david@dasz.at> wrote:> Douglas Garstang wrote: >> On Thu, Nov 26, 2009 at 11:59 PM, David Schmitt <david@dasz.at> wrote: >>> Douglas Garstang wrote: >>>> First post didn''t appear on the list (gee, like that doesn''t happen >>>> all the time....) >>>> >>>> So.. I''ve been fighting with trying to get puppet to include/execute >>>> module in a certain order for several weeks now. I kind of have >>>> something hacked together, but it scares me a bit since I don''t know >>>> exactly what is happening. >>>> >>>> I don''t suppose there''s still an easy way to do this....? >>> I have as one of the very fist things in my site.pp a list of imports of >>> modules. That way at least the init.pp of each of the listed modules is >>> activated. >>> >>> This is from before autoloading though, so in a newer installation I >>> would consider most modules that need an import as (slightly) broken. >> >> Not quite sure I follow David. >> >> You explicitly import specific modules in site.pp? This is what I have >> currently... >> >> import "definitions/*.pp" >> import "modules/*.pp" >> import "nodes/*.pp" >> >> Are you saying that by putting specific module imports before these >> lines that they will get executed first? Is this actually documented >> somewhere? > > Uhhh, importing, parsing and application on the client are different > issues. Since I''m not sure (anymore) what you are referring to, I''ll > define those actions explicitly for this discussion: > > * parsing: the process of translating the manifests and modules on > disk into the catalog, which is sent to the client. > > * importing: while parsing, the execution of the import() method > adds more modules and manifests to be parsed. > > * application: after the catalog is downloaded by the client, the > contents of the catalog are applied to the system. > > > Depending on which action you really meant, the question has different > answers: > > * parsing: manifests and modules are parsed in top-down order. > Methods, variables, classes, defines and resources earlier in a file are > parsed (and thus evaluated) before those later in the file. > > * importing: since import is a function, it is evaluated at that > point in the parsing process when it is encountered in the manifest. At > this point the referenced files are parsed and their content added to > the catalog (as far as they are applicable). > > * application: application order is totally dependent on the > require/before/notify/subscribe meta-parameters as specified in the > catalog. Parse-order has no influence here.Thanks, but i don''t think you answered my question. Lets dumb it down. How can I ENSURE that EVERYTHING from module A is implemented before ANYTHING from module B? 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.
On Mon, Nov 30, 2009 at 1:21 PM, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Mon, Nov 30, 2009 at 12:12 AM, David Schmitt <david@dasz.at> wrote: >> Douglas Garstang wrote: >>> On Thu, Nov 26, 2009 at 11:59 PM, David Schmitt <david@dasz.at> wrote: >>>> Douglas Garstang wrote: >>>>> First post didn''t appear on the list (gee, like that doesn''t happen >>>>> all the time....) >>>>> >>>>> So.. I''ve been fighting with trying to get puppet to include/execute >>>>> module in a certain order for several weeks now. I kind of have >>>>> something hacked together, but it scares me a bit since I don''t know >>>>> exactly what is happening. >>>>> >>>>> I don''t suppose there''s still an easy way to do this....? >>>> I have as one of the very fist things in my site.pp a list of imports of >>>> modules. That way at least the init.pp of each of the listed modules is >>>> activated. >>>> >>>> This is from before autoloading though, so in a newer installation I >>>> would consider most modules that need an import as (slightly) broken. >>> >>> Not quite sure I follow David. >>> >>> You explicitly import specific modules in site.pp? This is what I have >>> currently... >>> >>> import "definitions/*.pp" >>> import "modules/*.pp" >>> import "nodes/*.pp" >>> >>> Are you saying that by putting specific module imports before these >>> lines that they will get executed first? Is this actually documented >>> somewhere? >> >> Uhhh, importing, parsing and application on the client are different >> issues. Since I''m not sure (anymore) what you are referring to, I''ll >> define those actions explicitly for this discussion: >> >> * parsing: the process of translating the manifests and modules on >> disk into the catalog, which is sent to the client. >> >> * importing: while parsing, the execution of the import() method >> adds more modules and manifests to be parsed. >> >> * application: after the catalog is downloaded by the client, the >> contents of the catalog are applied to the system. >> >> >> Depending on which action you really meant, the question has different >> answers: >> >> * parsing: manifests and modules are parsed in top-down order. >> Methods, variables, classes, defines and resources earlier in a file are >> parsed (and thus evaluated) before those later in the file. >> >> * importing: since import is a function, it is evaluated at that >> point in the parsing process when it is encountered in the manifest. At >> this point the referenced files are parsed and their content added to >> the catalog (as far as they are applicable). >> >> * application: application order is totally dependent on the >> require/before/notify/subscribe meta-parameters as specified in the >> catalog. Parse-order has no influence here. > > Thanks, but i don''t think you answered my question. > > Lets dumb it down. How can I ENSURE that EVERYTHING from module A is > implemented before ANYTHING from module B?in 0.25, use the require function in module A to require the class in module B. http://reductivelabs.com/trac/puppet/wiki/FunctionReference#require in 0.24.x this is a bit more frustrating, and you need to require the resources in module A to require the class in module B. -- nigel -- 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.
you can use the function: require CLASS from any class starting in 25.1. This will ensure that every resource in the current class requires every resource in the provided CLASS. On Mon, Nov 30, 2009 at 3:21 PM, Douglas Garstang <doug.garstang@gmail.com>wrote:> On Mon, Nov 30, 2009 at 12:12 AM, David Schmitt <david@dasz.at> wrote: > > Douglas Garstang wrote: > >> On Thu, Nov 26, 2009 at 11:59 PM, David Schmitt <david@dasz.at> wrote: > >>> Douglas Garstang wrote: > >>>> First post didn''t appear on the list (gee, like that doesn''t happen > >>>> all the time....) > >>>> > >>>> So.. I''ve been fighting with trying to get puppet to include/execute > >>>> module in a certain order for several weeks now. I kind of have > >>>> something hacked together, but it scares me a bit since I don''t know > >>>> exactly what is happening. > >>>> > >>>> I don''t suppose there''s still an easy way to do this....? > >>> I have as one of the very fist things in my site.pp a list of imports > of > >>> modules. That way at least the init.pp of each of the listed modules is > >>> activated. > >>> > >>> This is from before autoloading though, so in a newer installation I > >>> would consider most modules that need an import as (slightly) broken. > >> > >> Not quite sure I follow David. > >> > >> You explicitly import specific modules in site.pp? This is what I have > >> currently... > >> > >> import "definitions/*.pp" > >> import "modules/*.pp" > >> import "nodes/*.pp" > >> > >> Are you saying that by putting specific module imports before these > >> lines that they will get executed first? Is this actually documented > >> somewhere? > > > > Uhhh, importing, parsing and application on the client are different > > issues. Since I''m not sure (anymore) what you are referring to, I''ll > > define those actions explicitly for this discussion: > > > > * parsing: the process of translating the manifests and modules on > > disk into the catalog, which is sent to the client. > > > > * importing: while parsing, the execution of the import() method > > adds more modules and manifests to be parsed. > > > > * application: after the catalog is downloaded by the client, the > > contents of the catalog are applied to the system. > > > > > > Depending on which action you really meant, the question has different > > answers: > > > > * parsing: manifests and modules are parsed in top-down order. > > Methods, variables, classes, defines and resources earlier in a file are > > parsed (and thus evaluated) before those later in the file. > > > > * importing: since import is a function, it is evaluated at that > > point in the parsing process when it is encountered in the manifest. At > > this point the referenced files are parsed and their content added to > > the catalog (as far as they are applicable). > > > > * application: application order is totally dependent on the > > require/before/notify/subscribe meta-parameters as specified in the > > catalog. Parse-order has no influence here. > > Thanks, but i don''t think you answered my question. > > Lets dumb it down. How can I ENSURE that EVERYTHING from module A is > implemented before ANYTHING from module B? > > 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > >-- 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.
> Lets dumb it down. How can I ENSURE that EVERYTHING from module A is > implemented before ANYTHING from module B?That''s roughly like asking: How can I ensure that no code from jar file A depends on jar file B? It''s really up to the individual classes inside the jar files to behave the way you want. I''d like to make a proposal around module metadata, so that you could declare things like: - this module depends on others - this module works for this list of $operatingsystems - this module uses this sysadmin strategy J. -- Julian Simpson Software Build and Deployment http://www.build-doctor.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.
If I understand correctly - inside class b, you say: require a (ie class a) right? - is that just for 25.x? -Roy Julian Simpson wrote:>> Lets dumb it down. How can I ENSURE that EVERYTHING from module A is >> implemented before ANYTHING from module B? >> > > That''s roughly like asking: > > How can I ensure that no code from jar file A depends on jar file B? > > It''s really up to the individual classes inside the jar files to > behave the way you want. I''d like to make a proposal around module > metadata, so that you could declare things like: > > - this module depends on others > - this module works for this list of $operatingsystems > - this module uses this sysadmin strategy > > J. > >-- 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 Mon, Nov 30, 2009 at 2:04 PM, Dan Bode <dan@reductivelabs.com> wrote:> you can use the function: > > require CLASS > > from any class starting in 25.1. > > This will ensure that every resource in the current class requires every > resource in the provided CLASS.I wasn''t able to get 0.25 to work. After spending a few weeks in abject frustration, unable to get the ssl keys to work, i was forced to give up and go back to 0.24. 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,> > require CLASS > > > > from any class starting in 25.1. > > > > This will ensure that every resource in the current class requires > every resource in the provided CLASS. > > I wasn''t able to get 0.25 to work. After spending a few weeks in > abject frustration, unable to get the ssl keys to work, i was forced > to give up and go back to 0.24.modules are just convenient locations for files, templates and classes, there isnt a concept of ''do everything in this module'' you need to create wrapper classes, for example: class php { include php::install include php::config } class php::xml { package{"php-xml": ensure => present, require => Class["php"] } } include php include php::xml The require function will make this easier as mentioned but on 0.24 this is your best bet -- 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.
I think what Doug is trying to ask is, how the hell do we make sure that resources get applied in a predictable order? On Nov 30, 2009, at 4:05 PM, R.I.Pienaar wrote:> hello, > >>> require CLASS >>> >>> from any class starting in 25.1. >>> >>> This will ensure that every resource in the current class requires >> every resource in the provided CLASS. >> >> I wasn''t able to get 0.25 to work. After spending a few weeks in >> abject frustration, unable to get the ssl keys to work, i was forced >> to give up and go back to 0.24. > > modules are just convenient locations for files, templates and classes, there isnt a concept of ''do everything in this module'' you need to create wrapper classes, for example: > > class php { > include php::install > include php::config > } > > class php::xml { > package{"php-xml": > ensure => present, > require => Class["php"] > } > } > > > include php > include php::xml > > The require function will make this easier as mentioned but on 0.24 this is your best bet > > -- > 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. > >-- 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.
----- "Michael T. Halligan" <michael@halligan.org> wrote:> I think what Doug is trying to ask is, how the hell do we make sure > that resources get applied in a predictable order?And the answer below is the only viable way. And the bigger answer is, mostly it doesn''t matter and many people *think* order is important when it''s mostly not in practice, for legit cases below is the only option.> > > On Nov 30, 2009, at 4:05 PM, R.I.Pienaar wrote: > > > hello, > > > >>> require CLASS > >>> > >>> from any class starting in 25.1. > >>> > >>> This will ensure that every resource in the current class > requires > >> every resource in the provided CLASS. > >> > >> I wasn''t able to get 0.25 to work. After spending a few weeks in > >> abject frustration, unable to get the ssl keys to work, i was > forced > >> to give up and go back to 0.24. > > > > modules are just convenient locations for files, templates and > classes, there isnt a concept of ''do everything in this module'' you > need to create wrapper classes, for example: > > > > class php { > > include php::install > > include php::config > > } > > > > class php::xml { > > package{"php-xml": > > ensure => present, > > require => Class["php"] > > } > > } > > > > > > include php > > include php::xml > > > > The require function will make this easier as mentioned but on 0.24 > this is your best bet > > > > -- > > 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. > > > > > > -- > > 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.-- 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.
Michael T. Halligan writes: > I think what Doug is trying to ask is, how the hell do we make sure > that resources get applied in a predictable order? Use "require" or "before". That''s why they''re in Puppet. -- 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,> Someone on this list seemed quite certain that modules where executed > in the order they were imported, which turned out to be wrong. > > At the moment I have a few modules tagged as ''bootstrap''. The initial > puppet.conf on the client has ''tags=bootstrap'' in it, so that when > puppet runs for the first time, it only applies those modules. > There''s also a puppet module which over writes the puppet.conf and removes > the tags=bootstrap line so that the next time it runs, it grabs > everything else. > > This approach isn''t perfect though. I''d really like to be able to > execute the modules within the bootstrap phase within a specific > order, so that, say, ntp gets done first followed by LDAP, and so on. > If LDAP is half implemented, and puppet tries to add a user through > another module, for example, the useradd command just locks up. > Within the bootstrapped modules currently I have a horrible mess of > unmaintainable requires => statements, that are just going to get > harder to maintain as times goes on. I''m afraid to touch it now, for > fear of what will break.If you use the method I highlighted earlier with wrapper classes this becomes trivial class bootstrap { tag "bootstrap" include ldap include yum::repos } class puppet::config { tag "bootstrap" file{"/etc/puppet/puppet.conf": require => Class["bootstrap"] . . } } now you can keep things simple, you can still just run the bootstrap tag and the bonus is all the stuff in the ''bootstrap'' class will be 100% by the time your config file goes out. Inside the bootstrap class there are very fewer things that are truly order dependent, if you really need yum before ldap then just do a single require there. You have very few require => lines and ordering is predictable for the few things where it matters, later on ordering is less important. Take a hypothetical ''monitoring should be done after apache is installed'' - it really doesnt matter that much if say apache is setup after your monitoring since at the end of the run both will be there anyway. Installing apache does not fail if monitoring isnt there, it just seems better in your mind if they happen in a given order. -- 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.
Michael, and Doug, On reading this thread it looks like there''s a lot of frustration going on. There''s a few questions that need answering. I''ll list them below: 1) "how... do we make sure that resources get applied in a predictable order" (profanity elided) 2) Why does puppet manage dependencies the way it does? 3) How can I keep dependencies manageable? The answer to #1 is simple, and has been repeated. Use require/subscribe and/or before/notify. The answer to #2 is more complicated, and has been hashed over before on the list, but I''ll comment that some people just don''t like the dependency model in puppet. There are other tools out there that use a different model - personally I prefer Puppet''s way. #3 can be answered "the same as you would in object-oriented development" - develop good abstractions and minimize your crossing of abstraction boundaries. It sounds like Doug''s manifests don''t follow these guidelines, as he says "Within the bootstrapped modules currently I have a horrible mess of unmaintainable requires => statements, that are just going to get harder to maintain as times goes on. I''m afraid to touch it now, for fear of what will break." Refactoring is in order. Let me know if I can clarify any of this. --Paul Lathrop On Mon, Nov 30, 2009 at 4:08 PM, Michael T. Halligan <michael@halligan.org> wrote:> I think what Doug is trying to ask is, how the hell do we make sure that resources get applied in a predictable order? > > > On Nov 30, 2009, at 4:05 PM, R.I.Pienaar wrote: > >> hello, >> >>>> require CLASS >>>> >>>> from any class starting in 25.1. >>>> >>>> This will ensure that every resource in the current class requires >>> every resource in the provided CLASS. >>> >>> I wasn''t able to get 0.25 to work. After spending a few weeks in >>> abject frustration, unable to get the ssl keys to work, i was forced >>> to give up and go back to 0.24. >> >> modules are just convenient locations for files, templates and classes, there isnt a concept of ''do everything in this module'' you need to create wrapper classes, for example: >> >> class php { >> include php::install >> include php::config >> } >> >> class php::xml { >> package{"php-xml": >> ensure => present, >> require => Class["php"] >> } >> } >> >> >> include php >> include php::xml >> >> The require function will make this easier as mentioned but on 0.24 this is your best bet >> >> -- >> 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. >> >> > > -- > > 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. > > >-- 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.
Paul Lathrop writes: > 2) Why does puppet manage dependencies the way it does? > 3) How can I keep dependencies manageable? > > The answer to #2 is more complicated, and has been hashed over before > on the list, but I''ll comment that some people just don''t like the > dependency model in puppet. There are other tools out there that use > a different model - personally I prefer Puppet''s way. Ultimately I think Puppet''s way makes the most sense -- when you need to enforce dependencies they''re explicitly documented in the manifests, not implicitly dependent to something like declaration order. It helps you to remember them if you move a resource from one place to another. > #3 can be answered "the same as you > would in object-oriented development" - develop good abstractions and > minimize your crossing of abstraction boundaries. It sounds like > Doug''s manifests don''t follow these guidelines, as he says "Within the > bootstrapped modules currently I have a horrible mess of > unmaintainable requires => statements, that are just going to get > harder to maintain as times goes on. I''m afraid to touch it now, for > fear of what will break." Refactoring is in order. There are cases where you have a lot of dependencies and ordering requirements and this tends to provoke a reaction of "dependency management is HAAARRRD". But those are the cases where it''s also the most important. If you want to create something maintainable under those circumstances, you''re going to have to work out the proper dependency relationships sooner or later. Unfortunately I don''t know of any configuration management tool that figures out dependencies for you; the best you can hope for right now is to have one that lets you express them clearly. -- 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 Mon, Nov 30, 2009 at 4:58 PM, Steven VanDevender <stevev@uoregon.edu> wrote:> Paul Lathrop writes: > > 2) Why does puppet manage dependencies the way it does? > > 3) How can I keep dependencies manageable? > > > > The answer to #2 is more complicated, and has been hashed over before > > on the list, but I''ll comment that some people just don''t like the > > dependency model in puppet. There are other tools out there that use > > a different model - personally I prefer Puppet''s way. > > Ultimately I think Puppet''s way makes the most sense -- when you need to > enforce dependencies they''re explicitly documented in the manifests, not > implicitly dependent to something like declaration order. It helps you > to remember them if you move a resource from one place to another. > > > #3 can be answered "the same as you > > would in object-oriented development" - develop good abstractions and > > minimize your crossing of abstraction boundaries. It sounds like > > Doug''s manifests don''t follow these guidelines, as he says "Within the > > bootstrapped modules currently I have a horrible mess of > > unmaintainable requires => statements, that are just going to get > > harder to maintain as times goes on. I''m afraid to touch it now, for > > fear of what will break." Refactoring is in order. > > There are cases where you have a lot of dependencies and ordering > requirements and this tends to provoke a reaction of "dependency > management is HAAARRRD". But those are the cases where it''s also the > most important. If you want to create something maintainable under > those circumstances, you''re going to have to work out the proper > dependency relationships sooner or later. Unfortunately I don''t know of > any configuration management tool that figures out dependencies for you; > the best you can hope for right now is to have one that lets you express > them clearly.A conclusion I''ve come to is that inter-class requires are almost always better done by requiring the entire class rather than individual resources outside the current class. So intra-class dependencies are for specific resource order within the class, and inter-class dependencies all live at the class level. This may be obvious, but we slowly had requires creep up that were not done this way, and it causes no end of hell for debugging. -- nigel -- 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.