I just read over the PR that you linked to. It looks like an interesting idea, but I have to wonder about it a little bit. This proposal isn't to add automated metrics to the puppet master to keep track of things like compile stats, file request stats, etc. It is more of a manual mechanism for the sysadmin to mark a master on- or off-line. If I'm understanding that correctly, then I'm kinda wondering about the utility given that you can (if you are using the master in passenger, which if you are using load balancers you probably are) just setup an apache Location (or similar) that will serve the status file. At that point it removes that from the masters responsibility, which for this kind of switch seems like the right thing.
On Thu, Aug 22, 2013 at 5:36 PM, Dustin J. Mitchell <dus...@v.igoro.us>wrote: > I thought I'd kick off discussion of this ARM, > https://github.com/puppetlabs/armatures/pull/60/files > (I started discussion in the pull req, but this is probably a better > place for it) > > First, the summary is about the implementation - it should probably > start with the goal: "load balancers should be able to poll masters > for their status, to support removal of malfunctioning masters from > the pool" or the like. The summary's the first (and sometimes only) > place people will look, so you have to hook them in early. Then you > can go on to discuss implementation. > > I think this is my concern. I didn't see anything in the arm about the system tracking itself for the status. It looked like it is entirely up to the operator to mark the status. I think that getting a monitoring system into puppet is absolutely necessary and the best way of doing that is if it tracks what is happening. Part of doing this, I think, is going to require some clear definitions of what it means for the puppet master to be "working". Maybe some examples of situations where the master stopped working by some definition would be a good place to start, then we can figure out how the master might have been able to signal that it has reach that "non-working" state. > Let me know if I've mischaracterized the intent. > > Second, as someone who had never heard of the status indirection, the > description is confusing as to what exists and what doesn't. It might > be nice to split that up into "current functionality" and "proposed > functionality". > > Perhaps include an example of both -- for me: > dmitchell@releng-puppet2 ~ $ curl -k > https://puppet:8140/production/status/no_key > Forbidden request: > releng-puppet2.srv.releng.scl3.mozilla.com(10.26.48.50) access to > /status/no_key [find] at :115 > > I think you're also suggesting additional keys beyond `is_alive`. > Again, an example might make that clearer. > > Finally, on a technical basis, I'm not clear on how command-line > switches would translate into changes of state for a running master. > Is that through another operation on the REST endpoint? > > I think this sounds like a great idea. Will you be able to implement > it, once the ARM is ironed out? > > Dustin > > -- > 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 post to this group, send email to puppet-dev@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-dev. > For more options, visit https://groups.google.com/groups/opt_out. > -- Andrew Parker a...@puppetlabs.com Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2013, August 22-23 in San Francisco - * http://bit.ly/pupconf13* **Register now and take advantage of the Final Countdown discount - save 15%!* -- 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 post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
