Zookeeper 3.5.5

[bitchkat]

Zookeeper 3.4.14 has been released. We'd really appreciate an updated ZookeeperNetEx when you have time.

[shayhatsor]

Sorry for the delayed response. I hope I'll have more time soon to address upgrading. thanks

[bitchkat]

Thanks. FYI, Zookeeper 3.5.5 stable has officially been released. If you want to skip 3.4.14 and go directly to 3.5.5 I know that I wouldn't complain.

[shayhatsor]

Sorry (again) for the delayed response. I'll start to look at the code today/tomorrow. thanks @bitchkat !

[krojew]

@shayhatsor do you plan to skip ahead to 3.5.5?

[shayhatsor]

yes, finally 3.5 is stable!

[monodop]

Looking forward to a 3.5.5 release as it provides TTL nodes, which would be pretty useful for my current use case!

[ztzg]

Hi @shayhatsor,

I have recently implemented SASL support for the @ewhauser client, used by some of our applications: https://github.com/ewhauser/zookeeper/pull/38

Your project seems to be more active; it would be great to hear your plans regarding this implementation—for ZK 3.5 and beyond.

Are you currently using it in production? Do you know of other active users? Would you be interested patches adding new features, such as the one mentioned above? (If so, we might be able to contribute.)

Do you already have plans regarding the alignment with 3.5 and master? Are you going to merge the 3.5 branches as you did with the 3.4, or do you have something else in mind?

Some of your (abandoned) PRs moved the client to contrib in preparation to merging; should another attempt be made to give this client the "shape" of a contrib as part of the alignment? Or would that be difficult?

(It might be even better to drop everything which is not .NET, e.g., src/c, src/java, etc., and to shuffle the rest to look like a "normal" .NET project. Or is there a specific reason to keep those around?)

What do you think?

Cheers, -D

[bitchkat]

I have a product in production that is using zookeepernetex. I plan on moving the server to Zookeeper 3.5 soon since the ZK maintainers on the ZK email list have verified that 3.4 clients will work with 3.5 servers. They won't be able to use 3.5 features like ephemeral containers but I can live with that. There is also an interesting discussion going on in regards to a gRPC based client implementation that would make it vastly easier to create clients for other languages.

Unfortunately, I moved on to a different team and am not directly involved in any .Net development for the past 12 months so I haven't had the time to pitch in. Otherwise, I would have worked on upgrading ZookeeperNetEx to 3.5 and sent Shay a merge request. My port of Curator to .Net has also sat idle and unfinished as well.

[ztzg]

Hi @bitchkat,

I have a product in production that is using zookeepernetex.

Good to know!

I plan on moving the server to Zookeeper 3.5 soon since the ZK maintainers on the ZK email list have verified that 3.4 clients will work with 3.5 servers. They won't be able to use 3.5 features like ephemeral containers but I can live with that.

Right. At this point, updating clients should only be needed for accessing new features.

There is also an interesting discussion going on in regards to a gRPC based client implementation that would make it vastly easier to create clients for other languages.

Indeed. For the record, Jordan Zimmerman has written an initial plan here.

Note, however, that the result might become ZK 4.0, and not be backward compatible. (Not to mention that it is way too early to start speculating on a release date.)

Unfortunately, I moved on to a different team and am not directly involved in any .Net development for the past 12 months so I haven't had the time to pitch in. Otherwise, I would have worked on upgrading ZookeeperNetEx to 3.5 and sent Shay a merge request.

Also good to know! (I might be able to help, which is why I was asking about "strategies," if any have been formed.)

My port of Curator to .Net has also sat idle and unfinished as well.

Ah; I did not know about that (making a mental note).

Cheers, -D

[shayhatsor]

hi @ztzg ,

I have recently implemented SASL support for the @ewhauser client, used by some of our applications: ewhauser#38

As far as I know the @ewhauser project has been abandoned for years, and its implementation isn't async. I actually built this client for https://github.com/dotnet/orleans. I used to be very active in that project.

Your project seems to be more active; it would be great to hear your plans regarding this implementation—for ZK 3.5 and beyond.

It used to be a lot more active, the truth is that it has been a long time since i actually used this project on a daily basis. I'm actually not developing with .net at work for two years now. The funny thing is that I was just thinking about how to continue with this project.

Are you currently using it in production?

No. But I used to use it a lot, fixed many bugs along the way. Also made performance improvements.

Do you know of other active users?

Yes, Microsoft project Orleans and Gigya. I'm sure there're a lot of others.

Would you be interested patches adding new features, such as the one mentioned above? (If so, we might be able to contribute.)

It depends, if the code stays similar to the java code then yes. By that I mean that the reason I was able to keep up with the java versions was that i used their diff in order to see what was changed.

Do you already have plans regarding the alignment with 3.5 and master? Are you going to merge the 3.5 branches as you did with the 3.4, or do you have something else in mind?

About the branches, I'd probably just merge 3.5 with master. As I believe that my 3.4 client can't get any better.

Some of your (abandoned) PRs moved the client to contrib in preparation to merging; should another attempt be made to give this client the "shape" of a contrib as part of the alignment? Or would that be difficult?

I'm not sure I follow. If you're talking about merging this code with the official Apache code, it'll be great to be added as a contrib project. But they didn't want to support a .net client, so I did it myself. I'm not sure much has changed since then.

(It might be even better to drop everything which is not .NET, e.g., src/c, src/java, etc., and to shuffle the rest to look like a "normal" .NET project. Or is there a specific reason to keep those around?)

I keep these around in order to make diffs when the official versions come out, and then figure out from there what's missing in the .net version.

What do you think?

I think that as far as a 3.4 client, as far as I know, there isn't anything out there that comes close to this client. About 3.5, it's hard to say definitively. I've made some minor steps towards that version, in the near future I'll see how much work is needed there and decide then.

Cheers, -D

Thanks for you interest !

[ztzg]

Hi @shayhatsor,

Thank you for your reply.

[…] I actually built this client for https://github.com/dotnet/orleans. I used to be very active in that project. […] Microsoft project Orleans and Gigya [are active users]. I'm sure there're a lot of others.

Interesting. Will check these out!

Would you be interested patches adding new features, such as the one mentioned above? (If so, we might be able to contribute.)

It depends, if the code stays similar to the java code then yes. By that I mean that the reason I was able to keep up with the java versions was that i used their diff in order to see what was changed.

I already had a look at the relevant area of the client code, and it is indeed strikingly similar to the Java side :) (I know, not too surprising given the initial automatic translation.)

So yes, I suppose the best would be to start by creating some kind of .NET equivalent to ZooKeeperSaslClient, adding it to ClientCnxn, and "translating" the authentication logic/"flow" used on the Java side. (ZooKeeperSaslClient itself would be markedly different, as .NET does not include an SASL implementation (AFAICT) and applications might want to plug their own.)

[…]

Some of your (abandoned) PRs moved the client to contrib in preparation to merging; should another attempt be made to give this client the "shape" of a contrib as part of the alignment? Or would that be difficult?

I'm not sure I follow. If you're talking about merging this code with the official Apache code, it'll be great to be added as a contrib project. But they didn't want to support a .net client, so I did it myself. I'm not sure much has changed since then.

The code in this repository is under src/dotnet/, but some of your ZooKeeper PRs moved it under src/contrib/ (which is under less stringent requirements) at the request of some project members. I thought that keeping/maintaining the 3.5+ version of the C# client under contrib in this repository, in a fresh fork of upstream master, might facilitate a later pull into ZK.

As for what has changed: .NET Standard and the cross-platform availability of .NET Core might make things easier.

(It might be even better to drop everything which is not .NET, e.g., src/c, src/java, etc., and to shuffle the rest to look like a "normal" .NET project. Or is there a specific reason to keep those around?)

I keep these around in order to make diffs when the official versions come out, and then figure out from there what's missing in the .net version.

I see. This would also "conflict" with my suggestion above. Nevermind.

[…]

Thanks for you interest !

Thank you for the clarifications!

Cheers, -D

[xqrzd]

I'm available to help out with SASL GSSAPI (Kerberos). I recently did it for a .NET client for Apache Kudu. AFAIK NegotiateStream is the only way to accomplish this without relying on pinvoke (eg. SSPI on Windows).

See AuthenticateSaslGssApiAsync for a general idea, https://github.com/xqrzd/kudu-client-net/blob/master/src/Knet.Kudu.Client/Negotiate/Negotiator.cs#L246

My implementation came from Npgsql, https://github.com/npgsql/npgsql/blob/dev/src/Npgsql/NpgsqlConnector.Auth.cs#L222

[shayhatsor]

@xqrzd, go for it :) if you have any questions while developing, contact me.

[bitchkat]

With zookeeper 3.6.0 being released today https://zookeeper.apache.org/doc/r3.6.0/releasenotes.html perhaps we should skip 3.5 for zookeepernetex and go directly to 3.6?

[Shani-Z]

Hi @shayhatsor, Do you plan to support Zookeeper SSL connection in new release?

[shayhatsor]

@Shani-Z, I have no plans of supporting SASL. I have actually took a long break from this project and just getting back to it. The last I heard, @xqrzd was planning to do just that.

[Jetski5822]

Hey @shayhatsor any news of getting a new release out?