"OTOH, for a new user who is just starting to try things out, having it watch a single file (probably the environment directory) isn't going to be obvious. How are they do know that after editing a manifest they also need to go and touch a directory. So, while the directory watching could give a mechanism for triggering a cache invalidation for deployment scenarios, I don't think it is something that will help new users."
This is why I wanted a puppet face to do it. puppet env refresh 'foobar' or the like Also: puppet env check -> Return the list of environments that are 'dirty' Trevor On Mon, Apr 28, 2014 at 1:54 PM, Andy Parker <a...@puppetlabs.com> wrote: > On Mon, Apr 28, 2014 at 4:51 AM, Brice Figureau < > brice-pup...@daysofwonder.com> wrote: > >> On Wed, 2014-04-23 at 03:19 +0200, Henrik Lindberg wrote: >> > On 2014-22-04 8:06, Thomas Hallgren wrote: >> > > Would a MANUAL strategy make sense? I.e. instead of rebooting the >> > > master, just tell it to clear the cache (perhaps per environment). >> > > >> > > - thomas >> > > >> > Circling back to this. Andy pointed out later that the best way to do >> > this is to get the web environment to do a graceful restart by either >> > sending apache or unicorn (depending on what is used) a HUP. >> >> That should work for Apache or Nginx. >> >> But what about the new users running a master on webrick? >> >> > I think setting the default timeout value to something short should handle > these use cases. We are thinking of setting the default to around 15 > seconds should be fine. In fact this is the default for the current system > to rescan the files. > > >> Those are the users that we want to protect against: >> * stale cache and endless issues to understand why the master doesn't >> pick up the manifests changes >> * bad performance if there's no caching at all. People are prompt to >> make opinions (especially when something doesn't work at first). >> >> > Absolutely. These are exactly the concerns that I've had as we went over > how to handle the cache invalidation. > > >> But maybe, we just don't care about webrick (I don't remember if the >> webrick support will abandoned or not or is it already)? >> >> > It is still around, but I don't consider it anything more than a quick and > dirty way to stand up a master for testing and development (either on > puppet or of puppet manifests). I would love to get rid of it, but there > isn't a simple option to take its place right now. > > >> > The problem with doing the manual cache invalidation is knowing which >> > running instance of the master to talk to, and it would either need an >> > IPC mechanism, or that all instances watch the same file - and then we >> > are back at the complex behavior we want to avoid... >> >> Well, having at most a dozen processes watching one given file shouldn't >> be as harmfull than having a dozen processes watching a ton of manifest >> files... >> >> > OTOH, for a new user who is just starting to try things out, having it > watch a single file (probably the environment directory) isn't going to be > obvious. How are they do know that after editing a manifest they also need > to go and touch a directory. So, while the directory watching could give a > mechanism for triggering a cache invalidation for deployment scenarios, I > don't think it is something that will help new users. > > >> -- >> Brice Figureau >> My Blog: http://www.masterzen.fr/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to puppet-dev+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/1398685885.26219.32.camel%40arsenic.daysofwonder.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Andrew Parker > a...@puppetlabs.com > Freenode: zaphod42 > Twitter: @aparker42 > Software Developer > > *Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September > 22-24 in San Francisco* > *Register by May 30th to take advantage of the Early Adopter discount > <http://links.puppetlabs.com/puppetconf-early-adopter> **—**save $349!* > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CANhgQXszc%2BdN8Qj0QXVzBc%3D8WrAoL0KTwoSv2%3DEyxXKLWdQaXA%40mail.gmail.com<https://groups.google.com/d/msgid/puppet-dev/CANhgQXszc%2BdN8Qj0QXVzBc%3D8WrAoL0KTwoSv2%3DEyxXKLWdQaXA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWFqzKmTQK5OCsndaDborvSgE806UfOG1DHFQ9FEhWaeQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
