ok, sorry for the misunderstanding, Tim. I now see what you meant and I like Roland's idea of using extensions to auto-detect connection upon initialization. I would add that it should be an option in the Docker tooling preferences (enabled by default).
I see that Roland already opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=497101 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=497101> to track this RFE. Best regards, Xavier > On 30 Jun 2016, at 18:03, Tim Orling <ticot...@gmail.com> wrote: > > 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 > <mailto: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 > <http://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 <mailto: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 > <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
_______________________________________________ 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
