Hello, I was wondering if it''s possible to experiment with different PuppetDB setups, and see how different setups perform when hooked on a different database, run on different hardware, or some other configuration is changed. It would be good to know whether a certain change is going to be beneficial, or not, without having to point the production masters to an experimental setup. Is there any way I could simulate some load, similar to the traffic on the live setup? Or better yet, to duplicate/clone/mirror the live traffic somehow (even with another tool), without interfering with the live communication between the production PuppetDB and the masters? Suggestions are welcome! :) Thanks, ak0ska -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
So the closest and best thing I have now is this: https://github.com/kbarber/dark-loader-proxy But its very alpha and probably full of bugs. The principle is simple, it sits in front of your main traffic like a normal proxy, and forwards traffic to both a master PuppetDB, and a ''dark'' set of PuppetDB instances. Now as far as responses, it only cares about the responses from the ''master'' PuppetDB ignoring any dark instances responses (basically it drops them). But it could be adapted to compare responses for example. It adds overhead because the downstream multi-plexed requests are not threaded, read the README.md file for more details. I would like to find the time to make this more performant and able to be used in a production like environment but for now this is only recommended in test, or for short periods of time in production. ken. On Thu, Oct 24, 2013 at 1:56 PM, ak0ska <akos.hencz@gmail.com> wrote:> Hello, > > I was wondering if it''s possible to experiment with different PuppetDB > setups, and see how different setups perform when hooked on a different > database, run on different hardware, or some other configuration is changed. > It would be good to know whether a certain change is going to be beneficial, > or not, without having to point the production masters to an experimental > setup. Is there any way I could simulate some load, similar to the traffic > on the live setup? Or better yet, to duplicate/clone/mirror the live traffic > somehow (even with another tool), without interfering with the live > communication between the production PuppetDB and the masters? > > Suggestions are welcome! :) > Thanks, > ak0ska > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscribe@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users. > For more options, visit https://groups.google.com/groups/opt_out.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
I would LOVE it if this (or some other tool) would be capable of sending puppetdb pushes to a back-of-house / reporting puppetdb instance asynchronously... this seems like a nifty feature.. course, being able to list multiple puppetdb instances in /etc/puppet/puppetdb.conf might be just as nice for this too. On Thu, Oct 24, 2013 at 10:11 AM, Ken Barber <ken@puppetlabs.com> wrote:> So the closest and best thing I have now is this: > > https://github.com/kbarber/dark-loader-proxy > > But its very alpha and probably full of bugs. The principle is simple, > it sits in front of your main traffic like a normal proxy, and > forwards traffic to both a master PuppetDB, and a ''dark'' set of > PuppetDB instances. > > Now as far as responses, it only cares about the responses from the > ''master'' PuppetDB ignoring any dark instances responses (basically it > drops them). But it could be adapted to compare responses for example. > > It adds overhead because the downstream multi-plexed requests are not > threaded, read the README.md file for more details. I would like to > find the time to make this more performant and able to be used in a > production like environment but for now this is only recommended in > test, or for short periods of time in production. > > ken. > > On Thu, Oct 24, 2013 at 1:56 PM, ak0ska <akos.hencz@gmail.com> wrote: > > Hello, > > > > I was wondering if it''s possible to experiment with different PuppetDB > > setups, and see how different setups perform when hooked on a different > > database, run on different hardware, or some other configuration is > changed. > > It would be good to know whether a certain change is going to be > beneficial, > > or not, without having to point the production masters to an experimental > > setup. Is there any way I could simulate some load, similar to the > traffic > > on the live setup? Or better yet, to duplicate/clone/mirror the live > traffic > > somehow (even with another tool), without interfering with the live > > communication between the production PuppetDB and the masters? > > > > Suggestions are welcome! :) > > Thanks, > > ak0ska > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to puppet-users+unsubscribe@googlegroups.com. > > To post to this group, send email to puppet-users@googlegroups.com. > > Visit this group at http://groups.google.com/group/puppet-users. > > For more options, visit https://groups.google.com/groups/opt_out. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscribe@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users. > For more options, visit https://groups.google.com/groups/opt_out. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Looks great! Gonna give it a try, thank you! :) Created a ticket: http://projects.puppetlabs.com/issues/22975 On Thursday, October 24, 2013 5:11:40 PM UTC+2, Ken Barber wrote:> > So the closest and best thing I have now is this: > > https://github.com/kbarber/dark-loader-proxy > > But its very alpha and probably full of bugs. The principle is simple, > it sits in front of your main traffic like a normal proxy, and > forwards traffic to both a master PuppetDB, and a ''dark'' set of > PuppetDB instances. > > Now as far as responses, it only cares about the responses from the > ''master'' PuppetDB ignoring any dark instances responses (basically it > drops them). But it could be adapted to compare responses for example. > > It adds overhead because the downstream multi-plexed requests are not > threaded, read the README.md file for more details. I would like to > find the time to make this more performant and able to be used in a > production like environment but for now this is only recommended in > test, or for short periods of time in production. > > ken. > > On Thu, Oct 24, 2013 at 1:56 PM, ak0ska <akos....@gmail.com <javascript:>> > wrote: > > Hello, > > > > I was wondering if it''s possible to experiment with different PuppetDB > > setups, and see how different setups perform when hooked on a different > > database, run on different hardware, or some other configuration is > changed. > > It would be good to know whether a certain change is going to be > beneficial, > > or not, without having to point the production masters to an > experimental > > setup. Is there any way I could simulate some load, similar to the > traffic > > on the live setup? Or better yet, to duplicate/clone/mirror the live > traffic > > somehow (even with another tool), without interfering with the live > > communication between the production PuppetDB and the masters? > > > > Suggestions are welcome! :) > > Thanks, > > ak0ska > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Puppet Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to puppet-users...@googlegroups.com <javascript:>. > > To post to this group, send email to puppet...@googlegroups.com<javascript:>. > > > Visit this group at http://groups.google.com/group/puppet-users. > > For more options, visit https://groups.google.com/groups/opt_out. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.