[jira] [Comment Edited] (KAFKA-1477) add authentication layer and initial JKS x509 implementation for brokers, producers and consumer for network communication

["Joe Stein (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077832#comment-14077832 ] 

Joe Stein edited comment on KAFKA-1477 at 7/29/14 7:50 PM:
-----------------------------------------------------------

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 release perspective has certain usefulness 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 port on at the same time.  Maybe what we do is make it configurable so you can turn off the none secure port along with enabling a secure port or even enable both.  I know having only the secure and authenticated port on is a use case.


was (Author: joestein):
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)