"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 <[email protected]> wrote: > On Mon, Apr 28, 2014 at 4:51 AM, Brice Figureau < > [email protected]> 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 [email protected]. >> 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 > [email protected] > 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 [email protected]. > 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 [email protected] -- 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 [email protected]. 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.
