Look into tree tooltip API

[bwateratmsft]

There's a newish tree tooltip API supporting markdown that looks interesting: https://code.visualstudio.com/updates/v1_52#_markdown-tree-tooltip-api

We should see if there are some interesting ways we could use this API.

[bwateratmsft]

Some ideas for containers:

• Container name, ID
• Container status & uptime
• Image name, ID
• Ports
• Networks
• Volumes (Better management of Volumes #2054 / Feature Request: View of which Volumes are being accessed by running containers #2538)

[ucheNkadiCode]

Ideas for the Panes

Not in order of importance. I looked through each of the inspect documents and picked out which attributes I thought might be important

I'm open to discussing if Name for each of these artifacts would be redundant or would be good to have since the tooltip may cover the name 🤷🏽‍♂️

Containers:

• Container Name (ID in parenthesis)
• Container status: (stopped, running, paused maybe icon)
• Image Name (ID in parens)
• Ports (figure out how to list multiple)
• Environment Variables (can be set from image or programmatically)
• Volumes (Better management of Volumes #2054 / Feature Request: View of which Volumes are being accessed by running containers #2538) (hostPath or Named Volume : pathToContainerFolder) ( name if it's a named volume, path if its a bind mount)
  • Open in folder link (for bind mounts only)
• Networks (likely just one, but need case for if more than)
• (Probably not due to size): Labels (especially if group by label becomes a thing)

Files in Containers

• Permissions
• File Size

(any way at all to create markdown copy and paste button? or hover to make it easy to copy container ID for container)

Images:

• Image Name, (ID in parens)
• Image size (converted GB if greater than 1024 MB)
• Exposed Ports
• Environment variable
• Labels (Find a way to list multiple)
• List of associated containers (probably not)
• Last Created (probably not)

Registries: (probably not)

(when hovering over registry image):

• Full registry path
• Associated App Services (if applicable)
• Associated Container Instances (if applicable)
• Possibly the other fields for Images (listed above)

Networks:

• Network name
• Containers associated with Network
• Options that may be important such as docker.network.bridge.name (Probably not)
• Config? Would subnet and gateway be important to know? eg 172.XX.X.X (Probably not)
• Labels (probably not)

Volumes:

• Volume name
• List of containers accessing this Volume (needs more investigation)
• Options that may be important (Probably not) (didn't see any good examples)
• Labels (probably not)
• Date/Time Created (avoid times/creation not important)

Contexts:

Personally, I didn't see any information that looked super important, but if it is...

• Endpoints
  • docker.host
  • kubernetes.host (probably not)

[bwateratmsft]

Depends on microsoft/vscode-azuretools#835.

[ucheNkadiCode]

Example of a Container Tool Tip:

Name: beautiful_galois (5460373f9bec)
Status: Running (maybe a green play button icon)
Image Name: pythonsamplevscodedjangotutorial:latest (4e7e6992dac5)
Ports: 0.0.0.0:8000->8000/tcp
Environment: (table format required)

Key	Value	Source
SA_USERNAME	sa	Image
SA_PASSWORD	Admin123	Image
ACCEPT_EULA	Y	Runtime

Volumes: (table format required)

Type	Name/Source	Destination
Named Volume:	pythonVolume
Bind Mount:	/Users/vsCode/project/bin	/var/app

(The source folder for bind mounts should be openable with a click)
Networks: bridge <-- if one network. Otherwise,

Name
default
bridge

Labels: (probably will not be displayed due to size) - Could we just show the first 5?

Key	Value	Source
App_Name	pythonDjango	Image
Permission_Level	Admin	Runtime

Thoughts? This is likely entirely too big. But I was thinking that a table format made the most sense for the 1-n attributes. Any and all table header names can be adjusted as well. Just a starting point

[stuartthomson]

I wonder if it would be possible to make this customisable via a template, similar to the attach and logs commands? I have some custom container labels that I always want to check and I tend just to inspect via the extension and ctrl+f the output - having this in the tooltip would be brilliant.

I'd be up for prototyping something like that if it was possible.

[bwateratmsft]

We're starting some work on that right now, with Handlebars templates being used. I'd certainly be interested in what you want to see in the tooltips; it's pretty likely things we'd all want.

In the interest of performance, I have hardcoded the Handlebars template strings, but it certainly would be possible to make them customizable somehow (files or settings or something).

[stuartthomson]

I'd be interested in everything that the current tree item knows honestly. The only thing that seems potentially tricky is the case with specific labels. How should the template render if that label isn't present? Would be cool if the template could have conditions on it, if a certain label is present render differently than if it's absent.

[bwateratmsft]

We definitely can't show everything, but we're hoping in general to show a curated subset of what you'd see as an inspection result. Also, nice and neat and markdown-y.

[stuartthomson]

Apologies, I only meant that if users can define templates I'd be interested in having access to all of the tree item's data.

Also I was making the assumption that this would be done without another API call, so it could only be a subset of the inspect data anyway.

[bwateratmsft]

Ah, I understand what you mean. It's not set in stone yet but my thought was to do an inspect, and feed the entire inspection result to Handlebars as the context. Should open up a lot of possibilities.

I've also done some stuff to expand upon what comes from inspection. For instance, network inspect has a list of containers using the network, but volumes has nothing like that (and desperately needs it). So, in our translation layer, I fetched a list of containers using the volume, and tack them on to the inspect result in roughly the same shape as what is provided by network inspect.

[stuartthomson]

Having the entire inspection contents available to the template could definitely open up some exciting possibilities. I'm interested in what the performance is like from that, having to inspect the container then render into a template seems potentially slow.

[bwateratmsft]

Same, especially in remote scenarios it could be slow. The first tooltip is also gonna be a bit extra slow; we lazy-load a lot of larger dependencies, Handlebars included. I'll definitely come up with some perf data when I open my PR.

[ucheNkadiCode]

Suggestions:

• Show all of the sections regardless of emptiness - "None"
• Named Volume: instead of Volume
• Docker Host Endpoint in contexts
• Add associated containers in Images
• Adding None for any default sections that have no Ports, Associated Containers etc
• Reducing the size of the headers to Three ### and subsequent sections to Four ####
• (Hopefully) Reducing the space between headers

[bwateratmsft]

This is now released in Docker extension version 1.10.0.