Hi,
I posted first draft of the change here:
https://issues.apache.org/jira/browse/KAFKA-1809
Its missing a lot of the feedback from Jun (IPv6, upgrade path, could
use more tests probably).
However, it has most of the structure that I had in mind.
So, comments are more than welcome :)
Gwen
On
I don't think it necessarily has to be. I was thinking about that while I
was typing it out, and I realized that as well. With a special broker port,
my biggest concern is making sure that nothing other than a broker uses it
(and so cannot bypass security controls like authentication and
authorizat
Todd,
Does that imply the intra-broker protocol is always plaintext?
Thanks,
Jun
On Tue, Dec 2, 2014 at 3:31 PM, Todd Palino wrote:
> Thanks. Just to add more detail as to why I think it's a good idea to be
> able to segregate traffic like that...
>
> One reason would just be to separate out
1. What would the format of advertised listener looks like? If we have two
hosts separated by a colon, it may make parsing IP v6 harder.
3.1 Currently, the only public api that exposes requests/responses is the
SimpleConsumer. Since most people probably use the high level consumer,
breaking the ap
Thanks. Just to add more detail as to why I think it's a good idea to be
able to segregate traffic like that...
One reason would just be to separate out the intra-cluster communication to
a separate port. This can allow you to run it over a different interface
(for example, you could have dedicate
The good news is that I'm not using a map to represent protocol list.
The bad news is that as mentioned in the wiki: producers, consumers
and broker configuration specify "security protocol", so we'll know
which host/port pair to use for communication. This implicitly assumes
there will be only on
Gwen - just my reading of what we could expect from what you had described
so far. Without having gone into implementation details, there didn't seem
to be anything that would block the ability to run two ports with the same
protocol configuration, at least from the way you proposed to represent it
Hey Todd,
You say "lose the ability" - you mean this ability actually exist now?
Or is this something you hope the new patch will support?
Gwen
On Tue, Dec 2, 2014 at 2:08 PM, Todd Palino wrote:
> Leaving aside the rest of this, on #1, while I consider being able to
> advertise the ports a good
Thanks you so much for your help here Jun!
Highlighting the specific protocols is very useful.
See some detailed comments below.
On Tue, Dec 2, 2014 at 1:58 PM, Jun Rao wrote:
> Hi, Gwen,
>
> Thanks for writing up the wiki. Some comments below.
>
> 1. To make it more general, should we support a
Leaving aside the rest of this, on #1, while I consider being able to
advertise the ports a good idea, I don't want to lose the ability for
maintaining multiple ports with the same protocol. For example, being able
to have 2 plaintext ports, one that only brokers communicate over, and one
that gene
Hi, Gwen,
Thanks for writing up the wiki. Some comments below.
1. To make it more general, should we support a binding and an advertised
host for each protocol (e.g. plaintext, ssl, etc)? We will also need to
figure out how to specify the wildcard binding host.
2. Broker format change in ZK
The
+1 to doing this, can you sub ticket in the security ticket when you create
the JIRA for this (unless you did it already and I missed it). I made one
comment in regards to the JSON returned on the confluence otherwise this
matches what we already agreed and discussed and like how it is breaking it
Hi Everyone,
One of the pre-requisites we have for supporting multiple security
protocols (SSL, Kerberos) is to support them on separate ports.
This is done in KAFKA-1684 (The SSL Patch), but that patch addresses
several different issues - Multiple ports, enriching the channels, SSL
implementatio
13 matches
Mail list logo
