<br><br><div class="gmail_quote">On Wed, Jun 29, 2011 at 6:25 PM, Jason J. W. Williams <span dir="ltr"><<a href="mailto:jasonjwwilliams@gmail.com">jasonjwwilliams@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>We've looked at doing passive queue declares to get queue depths for alerting, reporting and auto-scaling of our consumers. Unfortunately passive queue declares appear to require configure access. I can see why queue.declare requires this but passive commands perhaps should have a different bit setting?</div>
</blockquote><div><br></div></div><div>We've moved to monitoring this with custom checks to the web API.</div></div></blockquote><div><br></div><div>Same here, our main use case is auto-scaling with our consumer code, i.e. app looks to see how many messages are pending and if thresholds are met, will kick off new threads if allowed.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>That's actually something I've been wanting to bring up on the list. Currently, we give Nagios it's own user with admin access so it can use the REST API. We also have a provisioning user that is used to create (via the REST API) the various users our apps need in the individual Chef recipes (we wrote a Chef "library" to abstract out the API). It would be nice to have a "read only" admin type that doesn't allow that type of admin to create/change permissions, because it looks like outside of being able to change permissions that standard RMQ permissions apply to the API.</div>
</blockquote><div><br></div><div>Read-only admin or more granular ACL controls with R/W bits for each setting� either would satisfy my needs.</div><div><br></div><div>Gavin</div></div>