-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libkv should have a way to watch a directory that doesn't exist yet. #16
Comments
I'm not sure this is a good pattern to watch over a directory that does not exist yet. The client code should make sure that the directory exists before watching it (or creating it if it does not exist). We have this problem in Swarm where we don't verify that the key exists before trying to watch it for the discovery (so we'll fix it in Swarm directly). A good way would be to do something like: if !store.Exists(key) {
store.Put(key, []byte(""))
}
store.Watch(key) I'm not entirely sure that this is the responsibility of |
@abronan It's fine with me that the client needs to ensure the directory exists before watching it. However, etcd makes a distinction between directories (which cannot have values) and other keys. I believe that in etcd, if you |
@spikecurtis You have a point! We can adopt either your solution or the go-client has this method: Thoughts? |
@abronan I don't really like the idea of a Clearly, a well designed application should have a key structure that is unambiguous about which are and are not directories. However, it's easy to mess this up. Watches being "helpful" and overwriting existing keys (possibly throwing out any data on them) could be really difficult to debug. |
@spikecurtis I see how this could turn bad even though the key structure is something that should be well thought out in the client code so if you do a We have the choice of either:
This is a choice and I'm probably slightly leaning towards the It's just a matter of smoothing the experience on the three existing stores (and probably more in the future) so it's going to be nearly impossible to have an optimal solution for each store. We will need to make compromises for some backends unfortunately. We can probably open a separate issue and talk about which model makes more sense for |
@abronan if you want to open a separate issue, can you cc me on it? For the record, I think Zookeeper works like Consul inasmuch as it doesn't distinguish between directories and "files". I.e. znodes can store values even if they are not a leaf in the tree. I'm not sure we can offer a totally consistent API. If we follow what you call the Consul model, then
will succeed on Consul, but the second call will fail on etcd. Likewise
will succeed on Consul, but will fail on etcd. There will be similar inconsistencies if we follow the etcd model of explicitly creating directories, since etcd will fail later attempts to Basically, what I'm saying is that either way we go, application designers are going to have an inconsistent experience. Etcd is going to fail requests that would succeed in Consul. So, designers that want their applications to work with any backend are going to have to design the keyspace with etcd-style constraints, i.e. that you can only store data at leaves in your tree. |
@spikecurtis Sure! So far in swarm we only create values on Leaf keys/nodes (so we don't encounter the issue you mentioned). This is kind of a mix between This is mentioned nowhere so we need to spin up a generic documentation explaining what to expect from the library. In your example, There are still room for improvement though as this is hard to abstract backend K/V stores with such different ways to handle keys/directories/values 😄 (PS: would you mind opening a separate issue with your example? I think this is a perfect example of what we need to take care of/improve in libkv) |
For anyone following this thread, @spikecurtis raised #20 to cover the example above (as requested by @abronan) |
Return the modified key on WatchTree call for etcd v3
We need a way to watch a directory that doesn't exist yet.
Basically, either all the backends need to handle watching directories that don't exist, or we need a way to create directories so the watcher can create, then watch. I'm guessing the latter is going to be easier.
/cc @mavenugo this problem is blocking libnetwork functioning correctly with etcd backend
The text was updated successfully, but these errors were encountered: