On Wed, 27 Feb 2019 at 07:57, Clement Verna <cverna@xxxxxxxxxxxxxxxxx> wrote: > > > I can say that there are quite a few people out there who look for > > someone uttering "hypothetical DoS" to prove to them one will exist. > > So now that you have done so.. we should assume we will have one and > > plan on how to deal with. > > I am all for assuming this will happen but I am also all for > considering what would be the impact and how we could mitigate it. For > example how easy would it be to turn off the possibility for external > publisher to flood the broker ? Could this be automated from a nagios > alert ? Can we configure the queues that are critical to have higher Usually monitoring is only going to see it way after it has started. It also may also be on the bus with the new monitoring consuming and deploying things there [because everyone loves buses.] There are > priority to the external ones ? If we have on public broker with > authentication can we easily kill the accounts that are flooding us ? > What are the consequences of the service been down ? What is an > acceptable down time 1 min, 1h , 1 day , 1 week, 1 month ? > These days.. people seem to think 1 minute downtime is way too long for anything we do. With the faster artifact creation, we are probably wanting to make sure we are 24x7x52 with large amounts of bus traffic. I think in analogies so here is how I am looking at it. We have cities of data and we have buses running through the city. One design has us having every bus go to every city in the world just in case there is a passenger which might want to get on. And if someone decides to send a million busses into our city there isn't anything we can do. The same with the other cities who we are asking to join our city transit system. [This may sound incredibly daft, but that has sort of happened in the past with early transit systems.. when anyone could put a train on the early train systems... people did.. Another time someone saw that the rules said a bus system was supposed to arrive at every stop so they had to send busses around places to even other towns which delayed things. Modern city congestion is mostly everyone having a car and dropping it on the road because hey eveyrone else is and no one is going to notice my car.] Smart transit designs assume that you want to control traffic for various reasons at certain points. It can be everything from security to capacity to latency. I would prefer to have a train system between us and CentOS and Brno and India versus finding out that we have timeouts somewhere because a service assumed local bus and the response from PHX2 to Pune was too long. Does that make sense? > I have the feeling that answering these questions would help in taking > an informed decision. > > > > > > Just my 0.02 $ since I have very little knowledge about RabbitMQ ;-) > > > > > > > > > > > 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 > > > _______________________________________________ > > > 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 > > > > > > > > -- > > Stephen J Smoogen. > > _______________________________________________ > > 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 > _______________________________________________ > 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 -- Stephen J Smoogen. _______________________________________________ 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
