Thanks Dustin for your suggestions. I think you have the basic understanding of the intent. Today I have the load balancers looking at the status REST call to determine if the master is capable of servicing agents. The advantage of looking at the REST call vs. looking only at if the TCP connection connects is that the REST call will allow the LB to detect if the service is actually responding.
I think your idea of getting some examples and more suggested responses is a good idea. Thank you for that. I did push on this a bit as Eric thought it might be good to have it for the Armature meeting at PuppetConf, so I probably released it a bit sooner than I should have. I will go back to revise and get more information into ARM-15. I have already started some preliminary code changes for this ARM, but there is going to be some thought work on the actual implementation. On Wednesday, Eric hit me with the question about how to make this work under Rack. Previously I have been only thinking about a single thread and a multi threaded environment with access to a shared data segment. Rack adds a new twist to the problem and need to think about the best way handle this. Thanks. -- Gerard On Thursday, August 22, 2013 5:36:55 PM UTC-7, Dustin J. Mitchell 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. > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
