On 6/18/19 8:35 AM, Aurelien Bompard wrote:
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.
Yes, this is correct. Also, I don't want to optimize for people who are
not configuring their application in Ansible. Those people should not do
that and when they have problems and outages, as harsh as it sounds, I
don't care. They should do it right.
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?
Yeah, so I think we can keep the namespacing just for sanity's sake, but
the problems we hit were things like not knowing you had to add some
extra Ansible steps to create your queue in the first place (and then
asking the obvious question of why you have to repeat yourself in the
config in Ansible and then separate roles), accidentally delegating the
creation of the queue (but not the user) to the production broker
instead of the staging broker, forgetting to set passive_declares =
true, and so on.
Each of these things required me to stop what I was doing, look at
someone's Ansible role, grok the situation, investigate the broker, etc.
It's wasting a ton of my time doing system admin work I don't need to
do, and it's not what I'm employed to do so I can only justify so much
of it.
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.
Indeed. It doesn't have to be publicly accessible (and, in fact, I'd
rather it wasn't). As it stands now I often proxy with ssh to get to it
and that's easy enough.
I don't have strong opinions on the implementation, I just don't want
people to have to struggle through what can be a very simple process
with powerful debugging and monitoring tools.
- Jeremy
_______________________________________________
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
