So, we talked about this today and came up with a tenative first plan:
* We are going to open 2 ports on our proxy01/10 (the ones in phx2).
* We are going to have haproxy forward in connections on those to the
rabbitmq cluster.
* One of them ( 5671 ) the normal rabbitmq port, will be used for
re
On Thu, 28 Feb 2019 at 16:04, Jeremy Cline wrote:
>
> On 2/27/19 2:10 PM, Clement Verna wrote:
> > On Wed, 27 Feb 2019 at 18:27, Aurelien Bompard
> > wrote:
> >>
> >> I'm assuming you're considering the solution where we have a single
> >> broker and we make it publicly accessible (option 1).
> >
On 2/27/19 2:10 PM, Clement Verna wrote:
On Wed, 27 Feb 2019 at 18:27, Aurelien Bompard
wrote:
I'm assuming you're considering the solution where we have a single
broker and we make it publicly accessible (option 1).
how easy would it be to turn off the possibility for external
publisher to
On Thu, 28 Feb 2019 at 11:26, Aurelien Bompard
wrote:
>
> > my overall feeling is that the
> > risk of DoS should be one of the factor we take into account to make
> > the decision but we should also consider how easy is it to use, how
> > easy is it to maintain, how much effort is it to setup.
>
> my overall feeling is that the
> risk of DoS should be one of the factor we take into account to make
> the decision but we should also consider how easy is it to use, how
> easy is it to maintain, how much effort is it to setup.
I agree, and since both burdens (daily maintenance and dealing wit
On Wed, 27 Feb 2019 at 18:27, Aurelien Bompard
wrote:
>
> I'm assuming you're considering the solution where we have a single
> broker and we make it publicly accessible (option 1).
>
> > how easy would it be to turn off the possibility for external
> > publisher to flood the broker ?
>
> External
I'm assuming you're considering the solution where we have a single
broker and we make it publicly accessible (option 1).
> how easy would it be to turn off the possibility for external
> publisher to flood the broker ?
External clients won't publish anything, they'll be read-only (with a
few exc
On Wed, 27 Feb 2019 at 07:57, Clement Verna 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 wit
On Wed, 27 Feb 2019 at 13:32, Stephen John Smoogen wrote:
>
> On Wed, 27 Feb 2019 at 05:17, Clement Verna wrote:
> >
> > On Wed, 27 Feb 2019 at 10:57, Aurelien Bompard
> > wrote:
> > >
> > > Hey y'all,
> > >
> > > Fedora Messaging, the replacement for fedmsg, is using AMQP and thus a
> > > messa
On Wed, 27 Feb 2019 at 05:17, Clement Verna wrote:
>
> On Wed, 27 Feb 2019 at 10:57, Aurelien Bompard
> wrote:
> >
> > 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 on
On Wed, 27 Feb 2019 at 10:57, Aurelien Bompard
wrote:
>
> 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 fo
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 outsi
12 matches
Mail list logo
