Remove Kubernetes UIDs and use Name instead

[silvin-lubecki]

As Kubernetes names are unique, we should only display them and avoid Kubernetes UIDs which are also unique but not commonly used in Kubernetes world (only for debug purpose I presume).

This impacts two commands:

• docker stack ps
• docker stack services

Docker stack ps

$ DOCKER_ORCHESTRATOR=kubernetes docker stack ps mystack
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
85d44891-5da mystack_db-664ccb47c8-tczq7 dockerdemos/lab-db docker-for-desktop Running Running 2 minutes ago
85d768f1-5da mystack_web-cb4868b76-qs5pp dockerdemos/lab-web docker-for-desktop Running Running 2 minutes ago *:0->80/tcp
8c6da80e-5da mystack_words-6954ccfd5b-6kph5 dockerdemos/lab-words docker-for-desktop Running Running 2 minutes ago
85e5c1c6-5da mystack_words-6954ccfd5b-dtc5l dockerdemos/lab-words docker-for-desktop Running Running 2 minutes ago
85e41d2e-5da mystack_words-6954ccfd5b-ph9m2 dockerdemos/lab-words docker-for-desktop Running Running 2 minutes ago
8ac68c76-5da mystack_words-6954ccfd5b-rbj2c dockerdemos/lab-words docker-for-desktop Running Running 2 minutes ago
85f0343f-5da mystack_words-6954ccfd5b-z6vrb dockerdemos/lab-words docker-for-desktop Running Running 2 minutes ago

Here we have the node name column, which can be replaced by the Kubernetes Node UID using the --no-resolve flag (btw we have to resolve the UID, which can be counter-intuitive regarding the flag name... see code here)

$ DOCKER_ORCHESTRATOR=kubernetes docker stack ps mystack --no-resolve
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
85d44891-5da mystack_db-664ccb47c8-tczq7 dockerdemos/lab-db d0e2dcd7-4474-11e8-b8ab-025000000001 Running Running 15 minutes ago
85d768f1-5da mystack_web-cb4868b76-qs5pp dockerdemos/lab-web d0e2dcd7-4474-11e8-b8ab-025000000001 Running Running 15 minutes ago *:0->80/tcp
8c6da80e-5da mystack_words-6954ccfd5b-6kph5 dockerdemos/lab-words d0e2dcd7-4474-11e8-b8ab-025000000001 Running Running 14 minutes ago
85e5c1c6-5da mystack_words-6954ccfd5b-dtc5l dockerdemos/lab-words d0e2dcd7-4474-11e8-b8ab-025000000001 Running Running 15 minutes ago
85e41d2e-5da mystack_words-6954ccfd5b-ph9m2 dockerdemos/lab-words d0e2dcd7-4474-11e8-b8ab-025000000001 Running Running 15 minutes ago
8ac68c76-5da mystack_words-6954ccfd5b-rbj2c dockerdemos/lab-words d0e2dcd7-4474-11e8-b8ab-025000000001 Running Running 14 minutes ago
85f0343f-5da mystack_words-6954ccfd5b-z6vrb dockerdemos/lab-words d0e2dcd7-4474-11e8-b8ab-025000000001 Running Running 15 minutes ago

Question 1: Do we keep the --no-resolve flag for backward compatibility with swarm scripts, but always output node name?

Question 2: About the ID column vs the Name column for Kubernetes. We output both of them in Kubernetes, but ID is kind of useless.

Question 3: Another thing is the task name is not the real Kubernetes Pod name. It is arbitrary prefixed be the stack name (here mystack_) to match Swarm UX. Do we keep this feature?

The output could be like the following:

$ DOCKER_ORCHESTRATOR=kubernetes docker stack ps mystack --no-resolve
NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
db-664ccb47c8-tczq7 dockerdemos/lab-db docker-for-desktop Running Running 15 minutes ago
web-cb4868b76-qs5pp dockerdemos/lab-web docker-for-desktop Running Running 15 minutes ago *:0->80/tcp
words-6954ccfd5b-6kph5 dockerdemos/lab-words docker-for-desktop Running Running 14 minutes ago
words-6954ccfd5b-dtc5l dockerdemos/lab-words docker-for-desktop Running Running 15 minutes ago
words-6954ccfd5b-ph9m2 dockerdemos/lab-words docker-for-desktop Running Running 15 minutes ago
words-6954ccfd5b-rbj2c dockerdemos/lab-words docker-for-desktop Running Running 14 minutes ago
words-6954ccfd5b-z6vrb dockerdemos/lab-words docker-for-desktop Running Running 15 minutes ago

Docker stack services

$ DOCKER_ORCHESTRATOR=kubernetes docker stack services mystack
ID NAME MODE REPLICAS IMAGE PORTS
85d43ffe-5da mystack_db replicated 1/1 dockerdemos/lab-db
85d9f971-5da mystack_web replicated 1/1 dockerdemos/lab-web *:80->80/tcp
d74ed7f1-47c mystack_words replicated 5/5 dockerdemos/lab-words

Question 4: Same as question 2 here, do we need to keep the ID column?

The output could be like the following:

$ DOCKER_ORCHESTRATOR=kubernetes docker stack services mystack
NAME MODE REPLICAS IMAGE PORTS
mystack_db replicated 1/1 dockerdemos/lab-db
mystack_web replicated 1/1 dockerdemos/lab-web *:80->80/tcp
mystack_words replicated 5/5 dockerdemos/lab-words

[chris-crone]

While users may only ever use object names in Kubernetes, UIDs might be useful for debugging. Names are unique across space while UIDs are unique across space and time (see: ref). It appears that there can be races caused by this.

Q1: In Swarm we literally do a DNS resolve of the hostname of the node. For Kubernetes we're not really resolving the name or UID as they're in the node metadata. I'm OK with keeping the flag for backwards compatibility.

Q2: As stated before, the IDs may be useful for debugging even if they're not useful for manipulating objects.

Q3: I'm not sure if we can interact with tasks by name in Swarm. If we can then we should try to match this behaviour for Kubernetes. If not, this is cosmetic so matching Swarm is OK.

Q4: This is tricky. A Swarm service maps to a Kubernetes Deployment/StatefulSet/... (for the containers) plus one or more Kubernetes Services (Headless/NodePort/LoadBalancer) for networking. Here we're only showing the Kubernetes Headless service UID. I don't know what we could do better here.

@wsong WDYT?

[wsong]

Debugging info is fine, but I think that docker stack ps should optimize for showing info that's useful for the customer. In the case of Swarm, we need to show IDs because they're the only unique identifier, but in Kube, the UIDs are just spam 99% of the time.

[thaJeztah]

For containers, both ID and Name are unique as well, so I don't see the situation that different

I wonder though how many people would use the --no-resolve in general, so if it's a big issue

[wsong]

Name isn't actually unique for containers, though, because if you're using UCP, you can have two containers with the same name on different nodes.

[thediveo]

Over time, two different containers might have the same name, yet two different IDs, so it is crucial to detect that the same name references different container instances over time.