etcd3 equivalent of in-order keys

[Jesse Millan]

etcd-dev,

 I understand that the v3 API did away with directories.

My question is, what would be an equivalent way to simulate in-order keys? Would it just be to create regular keys and retrieve them as a range sorted by CREATE?

-Jesse

[Brandon Philips]

In-order by name? All keys in v3 are a sorted range.

--
You received this message because you are subscribed to the Google Groups "etcd-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to etcd-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jesse Millan]

I am trying to simulate v2 feature of creating 'in-order keys' in a directory as described here in v3.

From link:

Using POST on a directory, you can create keys with key names that are created in-order. This can be used in a variety of useful patterns, like implementing queues of keys which need to be processed in strict order. An example use case would be ensuring clients get fair access to a mutex....

[Brandon Philips]

Right, see the priority queue recipe: https://github.com/coreos/etcd/blob/2724c3946eb2f3def5ed38a127be982b62c81779/contrib/recipes/priority_queue.go#L38

[Jesse Millan]

Thanks for the link Brandon.

To unsubscribe from this group and stop receiving emails from it, send an email to etcd-dev+unsubscribe@googlegroups.com.

[Dmitry Kakurin]

Enqueue uses NewSequentialKV that does a retry loop on the client in case of key collision.

Was it also the case in v2 API? Or was the server assigning monotonically-increasing numbers and guaranteeing key uniqueness with a single client call?

I.e. was it always a client-only feature with no server support?

Thank you, Dmitry.

[anthony...@coreos.com]

The v2 API supports a monotonic counter with the CreateInOrder client call.

[Dmitry Kakurin]

Is this a slight regression in capabilities then going from v2 to v3 API?

Or is there a way to propagate KV data from Compare to Then section of a Transaction?

[anthony...@coreos.com]

There hasn't been a pressing need to add server-side monotonic increment in v3; the v3 API was never supposed to be a 100% reimplementation of v2.

In most cases similar functionality can be achieved by sorting by modification revision. The priority queue implementation is a rare exception.

[Dmitry Kakurin]

To be clear: I'm not criticizing, just clarifying :-). I can stick with v2 API, so it's no problem.

My scenario similar (but not the same) as Leader Election as described by this ZooKeeper recipe: https://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection

And it uses server-assigned monotonically-increasing numbers.

Thanks, Dmitry.

[anthony...@coreos.com]

That feature is not necessary for retry-free leader election in v3; it can be done cheaply with sorted create revisions (which are also server-assigned monotonically increasing numbers). It's implemented in https://github.com/coreos/etcd/blob/master/clientv3/concurrency/election.go

I suspect the Zookeeper recipe uses SEQUENTIAL since that can use one GetChildren request to find the leader; inspecting the znode Czxids / create revisions would need a Stat request for every key in addition to the initial GetChildren listing. The v3 API is more efficient in this respect since it can fetch the key with the lowest create revision for a prefix by issuing a single RPC.