Re: [linuxtools-dev] [Docker Tooling] launch "default" docker machine "a

[Tim Orling <ticotimo@xxxxxxxxx>]

Yes. Exactly what I meant. I suspect the environment variables will also change with the new Docker that is in beta testing. I have not had time to test it yet.

IMHO, on startup we should check if Docker is running and if so connect to either the "default" machine or one which is defined in Preferences or Properties (persistent storage of some kind) or as Roland mentioned, configurable through an extension point. If Docker isn't running, we should throw up a dialog that asks the user if we should try to launch it. If not found we could even <cough> try to install it with vagrant or point them to the Docker website.

In our case, we are hosting cross-toolchains in containers, so as soon as the C/C++ perspective is active (or our specific plugin) we would want the docker machine in question to be connected. As invisible to the user as possible :)

I am happy to try to contribute to the code base.

Cheers.

--Tim (Intel)

On Thu, Jun 30, 2016 at 7:17 AM, Roland Grunberg <rgrunber@xxxxxxxxxx> wrote:

> Hello Tim,
>
> If you have the DOCKER_HOST, DOCKER_TLS_VERIFY and DOCKER_CERT_PATH
> environment variables set in your shell, they should be detected by the
> connection wizard, which will then avoid the need to detect any active
> Docker Machine.

I think Tim wants an approach that automatically adds the connections
for the users at startup, or perhaps when the Eclipse Docker Tooling
perspective is launched. Basically, the user shouldn't have to enter
the information for their connections, or click anything, if our tooling
is aware of how to find them.

I think this would be very possible as long as it's a type of connection
that we "know about". So we could easily check/add
"unix:///var/run/docker.sock", "tcp:///127.0.0.1:2375", connections set
through env variables (that persist into new shells), any active/inactive
Docker Machine connection, and hopefully soon we'll support ADB/CDK
connections also.

The first step I'd like to see taken in this direction is an extension
point to allow contributing connection types, rather than us always
hard-coding common ones. This way users could also write very simple
plugins to define the info of their docker daemon connections, and as
long as that plugin is present at runtime, the tooling would be able to
load it.

Cheers,
--
Roland Grunberg

_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev