Hello, I found out that a puppetmaster I manage is currently not using the thin_storeconfigs option and suggested to the other admins that we use this in order to reduce puppet run times a little. Is it recommended to purge the [mysql] database once the option is enabled on the puppetmaster? p.s. on another note: I can''t grasp the advantage of not using thin_storeconfigs. Since we''ll be parsing the manifests on every change anyway, having all info replicated into a database doesn''t seem to bring us anything. Is there any use case where not using this option would make sense? -- Gabriel Filion -- 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 May 21, 2011, at 4:10 PM, Gabriel Filion wrote:> Hello, > > I found out that a puppetmaster I manage is currently not using the > thin_storeconfigs option and suggested to the other admins that we use > this in order to reduce puppet run times a little. > > Is it recommended to purge the [mysql] database once the option is > enabled on the puppetmaster? > > > p.s. on another note: I can''t grasp the advantage of not using > thin_storeconfigs. Since we''ll be parsing the manifests on every change > anyway, having all info replicated into a database doesn''t seem to bring > us anything. Is there any use case where not using this option would > make sense?In theory, you might have an app that you wrote that uses data that''s in the "full" storeconfigs. In practice, I assume you''d know if you wrote such an app. -- 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 Sun, May 22, 2011 at 2:10 AM, Gabriel Filion <lelutin@gmail.com> wrote:> Hello, > > I found out that a puppetmaster I manage is currently not using the > thin_storeconfigs option and suggested to the other admins that we use > this in order to reduce puppet run times a little. > > Is it recommended to purge the [mysql] database once the option is > enabled on the puppetmaster? > > > p.s. on another note: I can''t grasp the advantage of not using > thin_storeconfigs. Since we''ll be parsing the manifests on every change > anyway, having all info replicated into a database doesn''t seem to bring > us anything. Is there any use case where not using this option would > make sense? > > Applications such as Foreman [1] can utilize your existing store configsdata.... but in foreman case it can import it in alternative ways as well... Ohad [1] - http://theforeman.org> -- > Gabriel Filion > > -- > 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.
On 22/05/11 01:10, Gabriel Filion wrote:> Hello, > > I found out that a puppetmaster I manage is currently not using the > thin_storeconfigs option and suggested to the other admins that we use > this in order to reduce puppet run times a little.Thin storeconfigs won''t reduce your puppet agent run time, only the master compilation time.> Is it recommended to purge the [mysql] database once the option is > enabled on the puppetmaster?I don''t think so. The next run with thin_storeconfigs should get rid of all the extraneous data.> p.s. on another note: I can''t grasp the advantage of not using > thin_storeconfigs. Since we''ll be parsing the manifests on every change > anyway, having all info replicated into a database doesn''t seem to bring > us anything. Is there any use case where not using this option would > make sense?Having all the data in the database can help write inventory applications. If you don''t have such application, thin storeconfig is way better. On another hand, if you don''t use exported resources/collection, you really don''t care about storeconfigs at all and you should disable it altogether. -- Brice Figureau My Blog: http://www.masterzen.fr/ -- 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 11-05-22 05:22 AM, Brice Figureau wrote:> On 22/05/11 01:10, Gabriel Filion wrote: >> Hello, >> >> I found out that a puppetmaster I manage is currently not using the >> thin_storeconfigs option and suggested to the other admins that we use >> this in order to reduce puppet run times a little. > > Thin storeconfigs won''t reduce your puppet agent run time, only the > master compilation time.thanks for the precision. still there''s a little gain in comparison. I would probably gain more performance in upgrading from 0.25.5 to 2.6.x, but that will come later since it requires more effort.>> Is it recommended to purge the [mysql] database once the option is >> enabled on the puppetmaster? > > I don''t think so. The next run with thin_storeconfigs should get rid of > all the extraneous data.great, that''s good to know.>> p.s. on another note: I can''t grasp the advantage of not using >> thin_storeconfigs. Since we''ll be parsing the manifests on every change >> anyway, having all info replicated into a database doesn''t seem to bring >> us anything. Is there any use case where not using this option would >> make sense? > > Having all the data in the database can help write inventory > applications. If you don''t have such application, thin storeconfig is > way better. On another hand, if you don''t use exported > resources/collection, you really don''t care about storeconfigs at all > and you should disable it altogether.thanks to everyone for details on this subject. since we currently don''t use the extra info (and don''t plan to use it in the near future), but do use exported resources (nagios configs, ssh keys), using storeconfigs with thin_storeconfigs will fit just great. -- Gabriel Filion -- 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.
So if Nagios configs are the only thing you use stored configs for, thin stored configs will work just fine? If so, I forsee a switch in our future. :) Also, since you mentioned it... how difficult is it to upgrade from 0.25 to 2.6 / 2.7? I''ve been curious to upgrade but for the most part everything''s been working fine so I''ve been holding off. Will I need to rewrite parts of my config? (I''m not doing much fancy, mostly user/service/package/file management with a side of Nagios.) -- Nathan Clemons http://www.livemocha.com The worlds largest online language learning community On Wed, May 25, 2011 at 10:16 AM, Gabriel Filion <lelutin@gmail.com> wrote:> On 11-05-22 05:22 AM, Brice Figureau wrote: > > On 22/05/11 01:10, Gabriel Filion wrote: > >> Hello, > >> > >> I found out that a puppetmaster I manage is currently not using the > >> thin_storeconfigs option and suggested to the other admins that we use > >> this in order to reduce puppet run times a little. > > > > Thin storeconfigs won''t reduce your puppet agent run time, only the > > master compilation time. > > thanks for the precision. still there''s a little gain in comparison. I > would probably gain more performance in upgrading from 0.25.5 to 2.6.x, > but that will come later since it requires more effort. > > >> Is it recommended to purge the [mysql] database once the option is > >> enabled on the puppetmaster? > > > > I don''t think so. The next run with thin_storeconfigs should get rid of > > all the extraneous data. > > great, that''s good to know. > > >> p.s. on another note: I can''t grasp the advantage of not using > >> thin_storeconfigs. Since we''ll be parsing the manifests on every change > >> anyway, having all info replicated into a database doesn''t seem to bring > >> us anything. Is there any use case where not using this option would > >> make sense? > > > > Having all the data in the database can help write inventory > > applications. If you don''t have such application, thin storeconfig is > > way better. On another hand, if you don''t use exported > > resources/collection, you really don''t care about storeconfigs at all > > and you should disable it altogether. > > thanks to everyone for details on this subject. since we currently don''t > use the extra info (and don''t plan to use it in the near future), but do > use exported resources (nagios configs, ssh keys), using storeconfigs > with thin_storeconfigs will fit just great. > > -- > Gabriel Filion > > -- > 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.
On Wed, May 25, 2011 at 10:23 AM, Nathan Clemons <nathan@livemocha.com>wrote:> So if Nagios configs are the only thing you use stored configs for, thin > stored configs will work just fine? > > If so, I forsee a switch in our future. :) > > Also, since you mentioned it... how difficult is it to upgrade from 0.25 to > 2.6 / 2.7? I''ve been curious to upgrade but for the most part everything''s > been working fine so I''ve been holding off. Will I need to rewrite parts of > my config? (I''m not doing much fancy, mostly user/service/package/file > management with a side of Nagios.) >You shouldn''t have to rewrite anything to go from 0.25 to 2.6.x. -- 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 11-05-25 01:28 PM, Nigel Kersten wrote:> On Wed, May 25, 2011 at 10:23 AM, Nathan Clemons <nathan@livemocha.com > <mailto:nathan@livemocha.com>> wrote: > > So if Nagios configs are the only thing you use stored configs for, > thin stored configs will work just fine? > > If so, I forsee a switch in our future. :) > > Also, since you mentioned it... how difficult is it to upgrade from > 0.25 to 2.6 / 2.7? I''ve been curious to upgrade but for the most > part everything''s been working fine so I''ve been holding off. Will I > need to rewrite parts of my config? (I''m not doing much fancy, > mostly user/service/package/file management with a side of Nagios.) > > > You shouldn''t have to rewrite anything to go from 0.25 to 2.6.x.Like Nigel said, if you don''t use too much fancy features combined with funky inheritance, you shouldn''t have much problems upgrading. You could try things out first to see how things go and to be able to make corrections to your manifests if needed. Set up a new puppet master with 2.6/2.7, copy your modules and manifests to that new server and setup a few virtual servers to use different setups from your nodes. This testing phase will be the longest, but it''s always better to be safe than sorry ;) After that, upgrade your puppet master, wait a couple of days just to see if it holds up well. Finally upgrade your clients. -- Gabriel Filion -- 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 May 25, 2011, at 10:23 AM, Nathan Clemons wrote:> So if Nagios configs are the only thing you use stored configs for, thin stored configs will work just fine? > > If so, I forsee a switch in our future. :) > > Also, since you mentioned it... how difficult is it to upgrade from 0.25 to 2.6 / 2.7? I''ve been curious to upgrade but for the most part everything''s been working fine so I''ve been holding off. Will I need to rewrite parts of my config? (I''m not doing much fancy, mostly user/service/package/file management with a side of Nagios.)I''d avoid any version of puppet that ends in a "0" like the plague if you want stability. Other than that, I haven''t run into almost any problems upgrading except that, in my experience, each time you upgrade the major version, puppet seems to use up 20% more RAM. (compounding) It also seems to get faster and use less disk IO each time I upgrade the major version. For more speed improvements, take a look at "recurse => remote" in "File". -- 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, May 25, 2011 at 11:52 AM, Patrick <kc7zzv@gmail.com> wrote:> > I''d avoid any version of puppet that ends in a "0" like the plague if you > want stability.The project has been steadily improving in this regard, but it''s definitely been a problem. I have great hopes for 2.7.0 though, and the more people that test out our RCs (hint! hint!) the better it''s going to be. http://www.puppetlabs.com/downloads/puppet/puppet-2.7.0rc3.tar.gz http://www.puppetlabs.com/downloads/puppet/puppet-2.7.0rc3.tar.gz.asc -- Nigel Kersten Product, Puppet Labs @nigelkersten -- 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.
Peter Meier
2011-May-27 16:25 UTC
testing new puppet versions - was Re: [Puppet Users] enabling of ''thin_storeconfigs''
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi>> I''d avoid any version of puppet that ends in a "0" like the plague if you >> want stability. > > > The project has been steadily improving in this regard, but it''s definitely > been a problem. > > I have great hopes for 2.7.0 though, and the more people that test out our > RCs (hint! hint!) the better it''s going to be.Awesome would be some kind of script with which I could test the new release. Something with puppet cucumber, that people could run and that would simply try to compile all the catalogs for their hosts and maybe also comparing the catalogs to the ones of the currently installed version. Also it could record compile time etc. so we wouldn''t fall into another regression as we did with 2.6.0 I know more or less how I could do that with puppet-cucumber and R.I.''s catalog-diff but I lack a bit the time to setup that. But I would certainly download a tarball and run the script that I only need to point to my puppet.conf and send the feedback on that. I think this could be in general useful for future releases. Yeah I know, I''m just throwing in ideas that don''t contain actual code... Sorry. ~pete -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3f0GsACgkQbwltcAfKi3/bNACeOw2bAr+oYL3VGoWZSLJWCpni bl4AoIx0j7pTlabE4jAkGUEX8hpbxOv0 =2EUf -----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.
Nigel Kersten
2011-May-27 16:49 UTC
Re: [Puppet-dev] testing new puppet versions - was Re: [Puppet Users] enabling of ''thin_storeconfigs''
On Fri, May 27, 2011 at 9:25 AM, Peter Meier <peter.meier@immerda.ch> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi > > >> I''d avoid any version of puppet that ends in a "0" like the plague if > you > >> want stability. > > > > > > The project has been steadily improving in this regard, but it''s > definitely > > been a problem. > > > > I have great hopes for 2.7.0 though, and the more people that test out > our > > RCs (hint! hint!) the better it''s going to be. > > Awesome would be some kind of script with which I could test the new > release. Something with puppet cucumber, that people could run and that > would simply try to compile all the catalogs for their hosts and maybe > also comparing the catalogs to the ones of the currently installed version. >As far as just testing new versions, the envpuppet script makes this really easy. https://github.com/puppetlabs/puppet/blob/2.7.x/ext/envpuppet You can simply checkout the git repo, and run it "live" out of the repo. I know we''ve had a few people work on catalog compilation and comparison, I''ll let them speak here. Also it could record compile time etc. so we wouldn''t fall into another> regression as we did with 2.6.0 >As a note here, we''re working on standardized performance testing with a baseline of manifests so we know when we''re introducing performance regressions.> > I know more or less how I could do that with puppet-cucumber and R.I.''s > catalog-diff but I lack a bit the time to setup that. But I would > certainly download a tarball and run the script that I only need to > point to my puppet.conf and send the feedback on that. > > I think this could be in general useful for future releases. > > Yeah I know, I''m just throwing in ideas that don''t contain actual > code... Sorry. >Ideas are awesome too :)> > ~pete > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk3f0GsACgkQbwltcAfKi3/bNACeOw2bAr+oYL3VGoWZSLJWCpni > bl4AoIx0j7pTlabE4jAkGUEX8hpbxOv0 > =2EUf > -----END PGP SIGNATURE----- > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to puppet-dev@googlegroups.com. > To unsubscribe from this group, send email to > puppet-dev+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > >-- Nigel Kersten Product, Puppet Labs @nigelkersten -- 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.