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 <rgrun...@redhat.com> 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@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev >
_______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
