I'm with Trevor here. A Face to interact with environments and query for state would be really helpful to debug such issues or force a refresh.
On Monday, 28 April 2014 20:55:02 UTC+2, Trevor Vaughan wrote: > > "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]<javascript:> > > wrote: > >> On Mon, Apr 28, 2014 at 4:51 AM, Brice Figureau < >> [email protected] <javascript:>> 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] <javascript:>. >>> 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] <javascript:> >> 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] <javascript:>. >> 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] <javascript:> > > -- 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/0501feb5-05a4-464b-b3d5-171d579f6f32%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
