[jira] Commented: (ZOOKEEPER-991) QuoromPeer.OBSERVER_ID
[
https://issues.apache.org/jira/browse/ZOOKEEPER-991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994848#comment-12994848
]
Vishal K commented on ZOOKEEPER-991:
Please see https://issues.apache.org/jira/browse/ZOOKEEPER-933
> QuoromPeer.OBSERVER_ID
> --
>
> Key: ZOOKEEPER-991
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-991
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum
>Affects Versions: 3.3.2
> Environment: Windows
>Reporter: Sandeep Maheshwari
> Fix For: 3.3.3
>
>
> I don't understand why do we even need this code at first place.
> if (remoteSid == QuorumPeer.OBSERVER_ID) {
>/*
> * Choose identifier at random. We need a value to identify
> * the connection.
> */
>remoteSid = observerCounter--;
>initializeMessageQueue(remoteSid);
>LOG.info("Setting arbitrary identifier to observer: " +
> remoteSid);
>}
> Even if remove above code from public Long readRemoteServerID(Socket sock)
> {} function the FLE will work correctly. Because when any other
> peer(PARTICIPANT) receive a notification from the observer, that peer won't
> consider his(observer) vote because of this check
> if(!self.getVotingView().containsKey(response.sid))
> Hence there is no need of that code. Also bcoz to above code there is a
> possibility of creating redundant threads (SendWorker-ReceiveWorker) bcoz
> when same participant try to initiate connection with same peer we are doing
> (sid = observerCounter--;). So the same observer getting different sid and
> hence corresponding thread would be crated which will be of no use.
> Please let me know if i am correct.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ZOOKEEPER-781) provide a generalized "connection strategy" for ZooKeeper clients
[ https://issues.apache.org/jira/browse/ZOOKEEPER-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michi Mutsuzaki updated ZOOKEEPER-781: -- Attachment: ZOOKEEPER-781.patch > provide a generalized "connection strategy" for ZooKeeper clients > - > > Key: ZOOKEEPER-781 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-781 > Project: ZooKeeper > Issue Type: New Feature > Components: c client, java client >Reporter: Patrick Hunt >Assignee: Qian Ye > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-781.patch, ZOOKEEPER-781.patch, > ZOOKEEPER-781.patch > > > A connection strategy allows control over the way that ZooKeeper clients (we > would implement this for both c and java apis) connect to a serving ensemble. > Today we have two strategies, randomized round robin (default) and ordered > round robin, both of which are hard coded into the client implementation. We > would generalize this interface and allow users to create their own. > See this page for more detail: > http://wiki.apache.org/hadoop/ZooKeeper/ConnectionStrategy -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ZOOKEEPER-896) Improve C client to support dynamic authentication schemes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994911#comment-12994911 ] Michi Mutsuzaki commented on ZOOKEEPER-896: --- I'll try making the change for Java client. --Michi > Improve C client to support dynamic authentication schemes > -- > > Key: ZOOKEEPER-896 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-896 > Project: ZooKeeper > Issue Type: Improvement > Components: c client >Affects Versions: 3.3.2 >Reporter: Botond Hejj >Assignee: Botond Hejj > Fix For: 3.4.0 > > Attachments: NIOServerCnxn.patch, ZOOKEEPER-896.patch, > ZOOKEEPER-896.patch, ZOOKEEPER-896.patch > > > When we started exploring zookeeper for our requirements we found the > authentication mechanism is not flexible enough. > We want to use kerberos for authentication but using the current API we ran > into a few problems. The idea is that we get a kerberos token on the client > side and than send that token to the server with a kerberos scheme. A server > side authentication plugin can use that token to authenticate the client and > also use the token for authorization. > We ran into two problems with this approach: > 1. A different kerberos token is needed for each different server that client > can connect to since kerberos uses mutual authentication. That means when the > client acquires this kerberos token it has to know which server it connects > to and generate the token according to that. The client currently can't > generate a token for a specific server. The token stored in the auth_info is > used for all the servers. > 2. The kerberos token might have an expiry time so if the client loses the > connection to the server and than it tries to reconnect it should acquire a > new token. That is not possible currently since the token is stored in > auth_info and reused for every connection. > The problem can be solved if we allow the client to register a callback for > authentication instead a static token. This can be a callback with an > argument which passes the current host string. The zookeeper client code > could call this callback before it sends the authentication info to the > server to get a fresh server specific token. > This would solve our problem with the kerberos authentication and also could > be used for other more dynamic authentication schemes. > The solution could be generalization also for the java client as well. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ZOOKEEPER-850) Switch from log4j to slf4j
[ https://issues.apache.org/jira/browse/ZOOKEEPER-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994910#comment-12994910 ] Michi Mutsuzaki commented on ZOOKEEPER-850: --- Hi Olaf, The patch doesn't apply any more. Could you update the patch if you have time? If not, I'll take care of it. Thanks! --Michi > Switch from log4j to slf4j > -- > > Key: ZOOKEEPER-850 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-850 > Project: ZooKeeper > Issue Type: Improvement > Components: java client >Affects Versions: 3.3.1 >Reporter: Olaf Krische >Assignee: Olaf Krische > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-3.3.1-log4j-slf4j-20101031.patch.bz2, > ZOOKEEPER-3.4.0-log4j-slf4j-20101102.patch.bz2, ZOOKEEPER-850.patch, > ZOOKEEPER-850.patch, ZOOKEEPER-850.patch > > > Hello, > i would like to see slf4j integrated into the zookeeper instead of relying > explicitly on log4j. > slf4j is an abstract logging framework. There are adapters from slf4j to many > logger implementations, one of them is log4j. > The decision which log engine to use i dont like to make so early. > This would help me to embed zookeeper in my own applications (which use a > different logger implemenation, but slf4j is the basis) > What do you think? > (as i can see, those slf4j request flood all other projects on apache as well > :-) > Maybe for 3.4 or 4.0? > I can offer a patchset, i have experience in such an migration already. :-) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ZOOKEEPER-781) provide a generalized "connection strategy" for ZooKeeper clients
[ https://issues.apache.org/jira/browse/ZOOKEEPER-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994923#comment-12994923 ] Hadoop QA commented on ZOOKEEPER-781: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12471092/ZOOKEEPER-781.patch against trunk revision 1069169. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 18 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/131//testReport/ Findbugs warnings: https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/131//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/131//console This message is automatically generated. > provide a generalized "connection strategy" for ZooKeeper clients > - > > Key: ZOOKEEPER-781 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-781 > Project: ZooKeeper > Issue Type: New Feature > Components: c client, java client >Reporter: Patrick Hunt >Assignee: Qian Ye > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-781.patch, ZOOKEEPER-781.patch, > ZOOKEEPER-781.patch > > > A connection strategy allows control over the way that ZooKeeper clients (we > would implement this for both c and java apis) connect to a serving ensemble. > Today we have two strategies, randomized round robin (default) and ordered > round robin, both of which are hard coded into the client implementation. We > would generalize this interface and allow users to create their own. > See this page for more detail: > http://wiki.apache.org/hadoop/ZooKeeper/ConnectionStrategy -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ZOOKEEPER-781) provide a generalized "connection strategy" for ZooKeeper clients
[ https://issues.apache.org/jira/browse/ZOOKEEPER-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994926#comment-12994926 ] Michi Mutsuzaki commented on ZOOKEEPER-781: --- It looks like a compilation error in C client. Qian, could you take a look? Thanks! --Michi /PreCommit-ZOOKEEPER-Build/trunk/src/c/generated -DUSE_STATIC_LIB -DZKSERVER_CMD="\"/grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh\"" -DZOO_IPV6_ENABLED -g -O2 -MT zktest_st-TestClient.o -MD -MP -MF .deps/zktest_st-TestClient.Tpo -c -o zktest_st-TestClient.o `test -f 'tests/TestClient.cc' || echo '/grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/'`tests/TestClient.cc [exec] [exec] /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/include/zookeeper.h: In member function 'zhandle_t* Zookeeper_simpleSystem::createClient(const char*, watchctx_t*)': [exec] [exec] /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/include/zookeeper.h:353: error: too many arguments to function 'zhandle_t* zookeeper_init(const char*, void (*)(zhandle_t*, int, int, const char*, void*), int, const clientid_t*, void*, int (*)(int, int*, sockaddr_storage*), int (*)(int, int*, sockaddr_storage*), int)' [exec] [exec] /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/TestClient.cc:234: error: at this point in file [exec] [exec] /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/include/zookeeper.h: In member function 'zhandle_t* Zookeeper_simpleSystem::createchClient(watchctx_t*, const char*)': [exec] [exec] /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/include/zookeeper.h:353: error: too many arguments to function 'zhandle_t* zookeeper_init(const char*, void (*)(zhandle_t*, int, int, const char*, void*), int, const clientid_t*, void*, int (*)(int, int*, sockaddr_storage*), int (*)(int, int*, sockaddr_storage*), int)' [exec] [exec] /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/TestClient.cc:241: error: at this point in file [exec] [exec] make[1]: Leaving directory `/grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build/test/test-cppunit' [exec] [exec] make[1]: *** [zktest_st-TestClient.o] Error 1 [exec] [exec] make: *** [check-am] Error 2 [exec] > provide a generalized "connection strategy" for ZooKeeper clients > - > > Key: ZOOKEEPER-781 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-781 > Project: ZooKeeper > Issue Type: New Feature > Components: c client, java client >Reporter: Patrick Hunt >Assignee: Qian Ye > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-781.patch, ZOOKEEPER-781.patch, > ZOOKEEPER-781.patch > > > A connection strategy allows control over the way that ZooKeeper clients (we > would implement this for both c and java apis) connect to a serving ensemble. > Today we have two strategies, randomized round robin (default) and ordered > round robin, both of which are hard coded into the client implementation. We > would generalize this interface and allow users to create their own. > See this page for more detail: > http://wiki.apache.org/hadoop/ZooKeeper/ConnectionStrategy -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ZOOKEEPER-938) support Kerberos Authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eugene Koontz updated ZOOKEEPER-938: Attachment: ZOOKEEPER-938.patch this version of the patch adds support for: requireClientAuthScheme=(scheme) in zoo.cfg, which will disconnect clients if they do not first authenticate with the given scheme. For example, requireClientAuthScheme=sasl will disconnect clients if they do not first authenticate using SASL. > support Kerberos Authentication > --- > > Key: ZOOKEEPER-938 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-938 > Project: ZooKeeper > Issue Type: New Feature > Components: java client, server >Reporter: Eugene Koontz >Assignee: Eugene Koontz > Fix For: 3.4.0 > > Attachments: NIOServerCnxn.patch, ZOOKEEPER-938.patch, > ZOOKEEPER-938.patch, jaas.conf, sasl.patch > > > Support Keberos authentication of clients. > The following usage would let an admin use Kerberos authentication to assign > ACLs to authenticated clients. > 1. Admin logs into zookeeper (not necessarily through Kerberos however). > 2. Admin decides that a new node called '/mynode' should be owned by the user > 'zkclient' and have full permissions on this. > 3. Admin does: zk> create /mynode content kerb:zkcli...@foofers.org:x:cdrwa > (note: for now, the dummy ':x' is a placeholder for the password, and is > required by the zk command parser. The user's actual password is not stored > within Zookeeper; simply put 'x' there.) > 4. User 'zkclient' logins to kerberos using the command line utility 'kinit'. > 5. User connects to zookeeper server using a Kerberos-enabled version of > zkClient (ZookeeperMain). > 6. Behind the scenes, the client and server exchange authentication > information. User is now authenticated as 'zkclient'. > 7. User accesses /mynode with permissions 'cdrwa'. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ZOOKEEPER-938) support Kerberos Authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995116#comment-12995116 ] Hadoop QA commented on ZOOKEEPER-938: - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12471140/ZOOKEEPER-938.patch against trunk revision 1069169. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 11 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/132//testReport/ Findbugs warnings: https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/132//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/132//console This message is automatically generated. > support Kerberos Authentication > --- > > Key: ZOOKEEPER-938 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-938 > Project: ZooKeeper > Issue Type: New Feature > Components: java client, server >Reporter: Eugene Koontz >Assignee: Eugene Koontz > Fix For: 3.4.0 > > Attachments: NIOServerCnxn.patch, ZOOKEEPER-938.patch, > ZOOKEEPER-938.patch, jaas.conf, sasl.patch > > > Support Keberos authentication of clients. > The following usage would let an admin use Kerberos authentication to assign > ACLs to authenticated clients. > 1. Admin logs into zookeeper (not necessarily through Kerberos however). > 2. Admin decides that a new node called '/mynode' should be owned by the user > 'zkclient' and have full permissions on this. > 3. Admin does: zk> create /mynode content kerb:zkcli...@foofers.org:x:cdrwa > (note: for now, the dummy ':x' is a placeholder for the password, and is > required by the zk command parser. The user's actual password is not stored > within Zookeeper; simply put 'x' there.) > 4. User 'zkclient' logins to kerberos using the command line utility 'kinit'. > 5. User connects to zookeeper server using a Kerberos-enabled version of > zkClient (ZookeeperMain). > 6. Behind the scenes, the client and server exchange authentication > information. User is now authenticated as 'zkclient'. > 7. User accesses /mynode with permissions 'cdrwa'. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[DISCUSS] Move BookKeeper and Hedwig to the incubator
I wanted to initiate this discussion (not a vote) so that we can work out interest levels and all be on the same page. These are our current contribs: bookkeeper/ fatjar/ hedwig/ huebrowser/ loggraph/ monitoring/ rest/ zkfuse/ zkperl/ zkpython/ zktreeutil/ zooinspector/ While most of these are relatively closely tied to ZK, in particular BK and Hedwig are projects that are not directly related to ZK. Rather they are users of the service, similar to say HBase. >From bk/hedwig perspective: I personally think that both of these projects would benefit by moving to the incubator. They could build their own distinct communities and could govern their own development. Their own releases should not be directly tied to ZK releases. As these projects gain momentum (bk is already being looked at by Hadoop and others) this will be even more of an issue. >From zk perspective: While we could also make these subprojects of ZK I don't think that's the right way to go. We (zk pmc) shouldn't be governing these communities, that's what the incubator is for. The incubator may seem daunting given the list of issues that need to be resolved and the oversite provided, but I can tell you from personal experience (whirr) that this is not as big a deal as it seems. I would be willing to be a mentor for both of these projects if they were to move to incubator. >From apache perspective: apache created the incubator specifically for the reasons I'm citing and want to see new, distinct projects move through that process, eventually to become a TLP. Also, how does our (ZK) community recognize the contributions of those primarily working on BK/Hedwig. Do we make them ZK committers? We could, but committership on ZK is supposed to be reserved for those making contributions to ZK itself (the code and community). Given that BK/Hedwig are distinct codebases/users/community this doesn't really fit and complicates some of the governance issues. Please do give this some thought and respond with your insights. Regards, Patrick
