etcd: `ls` command is missing in etcdctl v3

@Sartner ETCDCTL_API=3 ./etcdctl get / --prefix --keys-only

On environment:

• macOS v10.13.1 (High Sierra)
• etcd v3.2.10 (install via brew install etcd)

The command get / --prefix will return an empty response. Instead you can do the following:

ETCDCTL_API=3 etcdctl get "" --prefix --keys-only | sed '/^\s*$/d'

^ using the empty quote will returns all keys then pipe it to removes empty lines.

ETCDCTL_API=3 etcdctl --endpoints=http://localhost:2379 get / --prefix --keys-only

@gmcquillan ls was not removed; it was never supported in v3 in the first place. Use the v2 backend or the v2 emulation layer if you want a directory hierarchy.

I recognize that the underlying serialization and replication of data in etcd3 has very different semantics than it did with etcd2, however people still conceive of data as a hierarchical tree.

Removing the commands to explore that hierarchy from the core of command-line client seems like a mistake to me.

There’s an additional 40 characters needed for one of the most common operations an administrator could possibly have in etcd – and it’s not obvious without a google search how to list keys as you might’ve done before.

Is there a reason to make the UX for this much, much harder to use? Is querying partial keys (i.e. using ls) really that unsafe?

@heyitsanthony Thanks for responding. Those are two good choices.

I’m just concerned that in v4, or v5, or v6 those kinds of feature bridges won’t be available.

I want to communicate that, like the original author of this issue and the 30 people who’ve found it and thumbs-up’ed the answer, this change (between v2 and v3) kinda violates our expectations about the UX. If it were my project, I’d want to know.

Thanks.

You can use ETCDCTL_API=3 ./etcdctl get z --prefix to achieve similar goal. There is no directory in v3, thus no ls.

For listing all keys etcdctl --endpoints=http://localhost:2379 get --prefix --keys-only / doesn’t work on linux anymore. But etcdctl --endpoints=http://localhost:2379 get --prefix --keys-only '' does.

I want to know how many third party resources created in kubernetes

You should use k8s tool set to do it, not etcdctl. etcd3 does not understand any path structure. we do not plan to add that feature in core etcd either.

@xiang90 Hi, I would like to get all keys by rest api, can you do me a favor?thx

For listing all keys etcdctl --endpoints=http://localhost:2379 get --prefix --keys-only / doesn’t work on linux anymore. But etcdctl --endpoints=http://localhost:2379 get --prefix --keys-only '' does.

Would it be worth adding a section in the docs https://etcd.io/docs/current/dev-guide/interacting_v3/ that briefly explains how to list all keys i.e. run the above command?

I’ve seen seriously hierarchical systems built on etcdv2; like DNS systems. So +1 for supporting hierarchies again.

because it’d be very expensive to support with the v3 data model and having special support for it would reduce performance for applications that don’t need it.

@heyitsanthony - How about hiding it behind a compiler flag? - We’re in the Go world here, so it’s possible without any efficiency drop.

(just don’t know if the etcd people want to maintain two paradigms; it’s like having InnoDB and TokuDB in the MySQL world. Abstracting out the engines into those two then letting the communities split could be a long-term maintenance option…)