Yeah, I don't think anyone would give access to the production rabbitmq directly.
We use Yagi [1] to pipe it to AtomHopper [2] for downstream consumption/sanitizing. -S [1] https://github.com/rackerlabs/yagi [2] http://atomhopper.org/ ________________________________ From: Duncan Thomas <duncan.tho...@gmail.com> Sent: Wednesday, April 8, 2015 2:03 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] how to send messages (and events) to our users >From a security point, it certainly scares the hell out of me On 7 April 2015 at 08:45, Chris Friesen <chris.frie...@windriver.com<mailto:chris.frie...@windriver.com>> wrote: On 04/06/2015 10:08 PM, Angus Salkeld wrote: On Tue, Apr 7, 2015 at 1:53 PM, Chris Friesen <chris.frie...@windriver.com<mailto:chris.frie...@windriver.com> <mailto:chris.frie...@windriver.com<mailto:chris.frie...@windriver.com>>> wrote: On 04/06/2015 08:55 PM, Angus Salkeld wrote: Hi all For quite some time we (Heat team) have wanted to be able to send messages to our users (by user I do not mean the Operator, but the User that is interacting with the client). What do I mean by "user messages", and how do they differ from our current log messages and notifications? - Our current logs are for the operator and have information that the user should not have (ip addresses, hostnames, configuration options, other tenant info etc..) - Our notifications (that Ceilometer uses) *could* be used, but I am not sure if it quite fits. (they seem a bit heavy weight for a log message and aimed at higher level events) <snip> What are some options we could investigate: 1. remote syslog 2. Zaqar 3. Other options: Please chip in with suggestions/links! What about a per-user notification topic using the existing notification backend? Wouldn't that require the Operator to provide the end user with access to the message bus? Seems scary to me. AMQP supports access controls, so is it really all that scary? Maybe set up a virtual host per user if we want to be paranoid? (Just throwing it out there as an option since we're already using it...) Chris __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev