Re-Doing Connection to HZN CLI

[JMAR059]

Based on last week's meeting, Jeff Lu showed us the Auto-Dock, which he uses to run HZN commands from his main computer. Given the ease of this, and @Demopans 's research indicating difficulty to have a SSH connection between a Docker container and an Open Horizon Management Hub, as discussed we will move forward with trying to use it instead of the previous idea.

Moving forward, we must decide exactly how this will be implemented. Based on the Auto-Dock description, it runs off an install script that is curled and ran from a terminal. This in turn, makes a Docker Container which is able to be called to run HZN commands. We can use this installation process that is already made and simply figure out how to call those docker containers ourselves to interact with our extension. Discussed in the meeting, there are two ways to implement:

1. Have the client install Auto-Dock locally themselves. This will ensure installation (free us of that trouble) and be useful for those who have already installed it. Then, we simply just have to learn how to interact with these containers from our Docker Extension to relay information and do commands. Auto-Dock should have some info on how these containers work with each other, and Docker guides should help us replicate that through the extension instead.

2. Learn how the Auto-Dock client installation works, then package that with our extension. This makes the process harder, but may be a better all-in-one package for our client. The inner-workings would have to better understood, but maybe it helps the extension run and call HZN commands better. Until the first method is tried, this should be avoided, but kept in mind in case it solves an issue.

This hopefully achieves something similar to this diagram:

[Docker Desktop] ---------> [Docker Containers] --------> [Edge Node Agent] ---------------> [Open Horizon "Exchange"]

Info gets displayed back to the extension

Post any new findings below, and check out the Auto-Dock repo: https://github.com/playground/auto-dock

[Demopans]

Go with (2). We'll be tackling the same problem with (1) since the problem is more or less a consequence of how Docker functions by default (having a VM access host resources practically arbitrarily is the dream for remote code execution)