I am Ayushi, I recently graduated from University of Waterloo in Computer Engineering and I am planning to pursue my Masters in Computer Engineering in September. I have experience in Swift and distributed systems through my past internships and academic courses.
I was looking into the project of a native client for interacting with etcd servers using gRPC APIs. The client aims to integrate etcd into their Swift applications seamlessly, leveraging Swift's concurrency and async/await.
The Swift-etcd client will tackle these areas:
Authentication: Support variety of authentication mechanisms e.g. TLS certificates and auth tokens. Targeting v3 auth in etcd-client, and supporting TTL for v3 auth.
Q1: What sort of auth tokens should it support? According to etcd docs, simple and JWT tokens can be used, with JWT designed for production use cases.
Q2: If there are multiple tokens (simple, JWT), would multiple environments need to be supported? E.g. dev/prod environments.
Q3: Should an external host be supported, e.g. api.example.com?
K,V Operations: The etcd-client should support get, put, delete, operations.
Q1: Should flags be supported, e.g. get --from-key foo?
Q2: Should multiple operations be supported in a delete? E.g. del foo1 foo2?
Q3: Should historical changes of keys be considered to support revisions? E.g. etcdctl put foo bar; etcdctl put foo bar2
Watch operations: The etcd-client will monitor for changes on a specific key / range of keys, and update the user when the watch operation is complete.
Q1: Should the progress command be supported to return watch progress?
Lease operations: The client will support lease operations with a default / specified TTL, and will allow users to revoke and keep-alive the existing lease operation.
The etcd-client supports many more operations, and these are a small subset of those operations. Are there more operations that would need to be added for the swift-etcd-client to make it production ready? Are there any considerations I have not taken into account?
@FranzBusch Looking forward to connect and all the Swift community!
Thanks for voicing interest in the project. Let me try to answer some of the questions that you have:
You are right that etcd uses two different kinds of token but this fact should be mostly irrelevant for a client since clients should treat the token as an opaque string and just send it with every gRPC call.
None of this applies to the client. The client should take a configuration that either enables or disables authentication. If authentication is enabled then it should also take a username: String and password: String.
etcd talks in key ranges and bot the RangeRequest and the DeleteRangeRequest take a key and range_end. We should expose this in our Swift client's APIs. Users can then query or delete multiple keys.
I don't think that is something that our Swift API needs to consider.
We should make this a stretch goal of the project. The progress command is used to periodically receive responses with no events to allow clients to detect if a watcher has been disconnected.
For now the project is just focused on providing support for the listed operations. However, if we have more time we can look into supporting all of the Auth, Cluster and Maintenance APIs.
Thank you for providing clarity on several aspects of the project. Your responses address most of the concerns and questions. I will start drafting my proposal now, are there any specifics swift is looking for in the proposal? Also, is it possible to share the draft with you once its done so I can get some feedback?
Thanks again for all the answers.
@ayushi2103, just in case Franz would not respond before the submission deadlines - as I know is traveling right now - feel free to add myself as well and I can provide hints.
And make sure to not miss the actual submission :)