My fear here is that someone will manually create something and we have
to redeploy for some reason. They will be broken untll they manually
remember to do what they did again. :(
It's not manual at all actually, the queues that should be declared are in the app's configuration file, which is in ansible. The change that Jeremy proposes is to let the apps (the AMQP clients) create the queues instead of the ansible role.
In case of redeploy, on startup the app will recreate the queues and it should work.
My concern, though, is that the broker will end up with queues resulting from previous mistakes or typos and that we'll have to remove once in a while to avoid polluting the UI.
Also, there's one thing I'm not sure I'm getting right, Jeremy. Do you plan on giving users access to configure on any queues? ( ".*" ) Or just on a queue matching their username? In the former there's a security risk to allow a user to delete other user's queues, and in the latter I don't understand how it relieves pain from the end user, since they have to get their queue name right anyway. But I wasn't in your discussions with Adam so I'm not sure what we're trying to simplify here. Is it about removing the necessity to call the rabbit/queue Ansible role?
Could we add a suoders that would let people run these commands as the
monitoring user on one of the machines? But then I guess we would have
to give shell access, but I like that much better than guest/guest.
Thats sure to be abused.
Would it be sufficient to only allow monitoring access from within our infrastructure network?
Would need to run any of these changes by our security officer too.
Absolutely.
A.
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
