[
https://issues.apache.org/jira/browse/KAFKA-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077832#comment-14077832
]
Joe Stein commented on KAFKA-1477:
----------------------------------
Hi Jun, maybe what we (myself, Ivan and the other developers working @ BDOSS)
should do then is keep this patch up to date (from a rebase / fix perspective)
so folks that are using it already (as there are some folks doing that) and
folks that can't use Kafka with out it (there are folks in that camp too) and
continue to keep it updated so they still get the benefits coming in 0.8.2 (and
moving onwards until/if it gets upstream). It requires some more work on our
part and on theirs but that is the trade off we would have to accept. Then we
can add to the design doc as you suggest and take changes that come up from
there and work them back into the patch (or create a new one) as appropriate
and release it as the team can agree for the community needs.
Another option to the dangling patch approach (which I have seen be an issue in
projects) is a security branch. This approach I have seen be problematic from
a community perspective especially with voting and releasing. I am not sure if
it was the project team members that caused this or the approach they took or
something else, unsure. I would be cautious with going the branch route and I
don't know dunno if it would be better but maybe? I also don't know if there
were enough other pmc members that would vote for a branch release (regardless
of what it was) and then also if they wold vote these changes in a branch
release or what folks think of this in general. Having something available
from an Apache perspective release perspective has certain
usefulness/requirements within organizations that you can't get any other way.
>From my perspective I want to-do what is going to be best for the community
>and the project. Personally I am happy to spend my time and commit BDOSS
>resources to apply the patch when we need to for our use or our clients need
>for it... I can't speak for others though,
Per the port - there may be use case(s) that you need to have both the secure
and non secure ports on so maybe what we do is make it configurable so you can
turn off the none secure port along with enabling a secure port. I know having
only a secure and authenticated port on is a use case.
> add authentication layer and initial JKS x509 implementation for brokers,
> producers and consumer for network communication
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-1477
> URL: https://issues.apache.org/jira/browse/KAFKA-1477
> Project: Kafka
> Issue Type: New Feature
> Reporter: Joe Stein
> Assignee: Ivan Lyutov
> Fix For: 0.8.2
>
> Attachments: KAFKA-1477-binary.patch, KAFKA-1477.patch,
> KAFKA-1477_2014-06-02_16:59:40.patch, KAFKA-1477_2014-06-02_17:24:26.patch,
> KAFKA-1477_2014-06-03_13:46:17.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
