Hey y'all, Fedora Messaging, the replacement for fedmsg, is using AMQP and thus a message broker. The current clusters we have deployed in staging and prod are only accessible from inside our infrastructure. There are two needs for an externally accessible broker: - the CentOS folks, who are outside of our infrastructure, would like to send messages - people from the community would like to subscribe to messages and do things based on them We have several options to make that happen. 1. Use our existing cluster and expose it to the world The advantage is we don't maintain another cluster, but the downside is in the case of a DoS attack we're directly affected. With RabbitMQ 3.7 there are some limits[0] you can set on vhosts (max connections and max queues), but we're not yet on 3.7. [0] https://www.rabbitmq.com/vhosts.html#limits 2. Use a separate cluster and copy messages over We could deploy a separate cluster that would get a copy of all messages, and would be more limited in resources. It truly isolates infrastructure, so it's better protected against DoS, but it's more work for sysadmins. In both cases, there are several paths we can take as regards to authentication. A: make a single readonly account for everybody in the community to use, and a few read-write accounts (with X509 certs) for people who need to publish, ie CentOS CI. If we choose a separate broker we can copy those messages back to the main cluster. The issue here is that everybody in the community will be using the same account, so it's harder to shut down bad actors. It would also be theoretically possible for someone to consume from somebody else's queue (unless people make sure they use UUIDs in queues, I think we can enforce that but it way have side effects). However, it enables the same kind of usage that fedmsg provided before. B: require authentication with username & password but make it easy to get accounts. People could require accounts via tickets for example. It will make it much harder to abuse the service, and we could easily shut down bad actors. However it's an obviously heavier load on the people who will handle the tickets and create the accounts. My personal preference would be option 2A, so an external broker with an anonymous read-only account, but all combinations of options inflict different loads on the sysadmin (on deployment and in the longer term), so I think it's really up to them. What do you guys think? Thanks Aurélien _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
