Discussion: Have some docker-machine commands default to "default" VM?

[nathanleclaire]

In the original versions of Machine, commands like docker-machine start (without any arguments) would automatically run against the "active" machine. This was fine when Machine was directly embedded inside of Docker (a historical curiosity) but ultimately ended up being confusing and problematic so we removed it in favor of always specifying a target machine.

With the introduction of the Toolbox and deprecation of boot2docker one of the pieces of feedback we are getting is that users miss simplicity of commands running automatically against a"default" machine. Since it is likely that the majority of users will have only one machine, and we now have what is essentially a canonical default VM in default, I am wondering if we might want to just default most commands to be referencing default. The ambiguity would potentially be a lot less than the active tracking method, since there's no, "Wait, which host is active again?" conundrum.

e.g.:

$ docker-machine create -d virtualbox default
...
$ docker-machine stop
$ docker-machine start
$ docker-machine rm

One tricky angle on this is ssh. Without arguments it works fine, but it's impractical for CLI to know if something like docker-machine ssh ls means "run ls command on default machine" or "SSH into machine named ls". So, that would need some thought.

I don't really want to get into too much implicit behavior e.g. read the default host from a config file etc. because that's what we had before and it was damn confusing to debug when something went wonky. This might give us 80% of the way there without introducing too much difficult to follow behavior.

WDYT @ehazlett @tianon @hairyhenderson @bfirsh

[mhart]

Great, thanks for writing this up @nathanleclaire !

[tianon]

This sounds reasonable to me. For the ssh issue, could we utilize -- to disambiguate? ie, docker-machine ssh dev ls vs docker-machine ssh -- ls? (or is it even worth it vs just forcing users to explicitly state default if they want to run some other command?)

[hairyhenderson]

+1 - this could be implemented super-simply by simply using $DOCKER_MACHINE_NAME when no machine name is present.

Without arguments it works fine, but it's impractical for CLI to know if something like docker-machine ssh ls means "run ls command on default machine" or "SSH into machine named ls". So, that would need some thought.

Maybe naive, but couldn't we always assume the first argument is a machine name, except when there's no machine with that name, assume the active one instead?

It's true that if there's a machine named ls that makes things complicated, but honestly -- who has a machine named ls? 😉

Besides, in that (unusual) case I think it's reasonable to just let ssh error out if the command isn't found.

could we utilize -- to disambiguate? ie, docker-machine ssh dev ls vs docker-machine ssh -- ls? (or is it even worth it vs just forcing users to explicitly state default if they want to run some other command?)

-- is already necessary if you want to provide flags to the command being run, so it might be reasonable.

But the simplest to implement may well be to just force users to provide the machine name to run commands.

[bfirsh]

+1 😻

[nathanleclaire]

Yeah, I'm erring towards making the name always necessary to specifying if running an appended command, since that will lead to the most predictable behavior in general. This is really meant more as a shorthand than anything to get too clever.

[jeanlaurent]

The real usage gain is for people working with only 1 docker local instance, and this enhancement will really lower the learning curve of docker. docker-machine is now among the first command you end up using when discovering docker.

Pragmatically could we allow this for a subset of commands where there is always a predictable behavior. And explicitly don't allow it on command where it's the behavior is difficult to grasp (for instance create sshand scp).

[nathanleclaire]

Yes @jeanlaurent -- since one person using Docker with one VM is by far the most common Machine use case, this feature is intended to support that.

How would everyone feel about having docker-machine create default to mean something like docker-machine create -d virtualbox --virtualbox-memory 2048 default? It would be a predictable shorthand and I think could really help cut down on typing and/or annoyance at having to recreate VMs.

[dgageot]

+1

[ruippeixotog]

+1

[hairyhenderson]

How would everyone feel about having docker-machine create default to mean something like docker-machine create -d virtualbox --virtualbox-memory 2048 default?

I'm actually -1 on this. It would break the principle of least surprise. Almost every docker, docker-machine, and docker-compose command requires some form of flag or name to specify what you're intending to do. If I type docker run, for example, I don't get the hello-world image started up. Instead, I get a helpful usage message. Right now, docker-machine create gives a helpful usage message, and it would be surprising if it didn't...

Can I suggest 2 things instead:

• alter the virtualbox driver's virtualbox-memory flag to default to 2048 (1024 is just too small these days)
• make virtualbox the default driver

With this, the new user's experience looks like:

$ docker-machine create
...A useful help message telling the user they need to specify a name, suggest `default` as a good default...
$ docker-machine create default
...A useful log message telling the user that they've chosen to use the default driver, which is `virtualbox`...

This is still super simple for new users to get started with, and as a bonus it teaches them the concept of their newly-created machine having a name.

When I help new users get started with Docker Machine, usually they start with the Docker Toolbox, and end up with a machine named default, but they have no idea this is the case because it all happened under the covers. When they inevitably need to start running various docker-machine commands in their console (often in Windows, which is already a less-than-ideal experience), they're super-confused about what the default bit in the command even means.

[nathanleclaire]

I think it's a good consideration @hairyhenderson. I'm a bit on the fence about automatically setting default as the argument but changing the default driver to virtualbox seems like a no-brainer.

[nathanleclaire]

To play devil's advocate, I'd say the "modern" programmer is likely to be fairly accustomed to being able to create and use VMs without having to specify a name, whether it's through vagrant up or boot2docker init.

[hairyhenderson]

Sure, but vagrant up only works if you have a Vagrantfile in the cwd. If we ever get to machine declaration (as in #773), then this would make perfect sense.

And, the boot2docker CLI only ever worked with a local VM, and usually only a single one. Docker Machine has always been about managing local and remote machines, and a multiplicity of them.

If we're after the dead-simple lowest-barrier-to-entry-possible scenario, then we could add some interactivity, such as:

$ docker-machine create
Creating a new machine! If you don't want this, Ctrl+C and run "docker-machine create --help"
Enter your machine's name here, or hit <enter> to name it "default": ⏎

Sweet. Give me a minute while I create your new virtualbox-based docker machine named "default"!
...
$

[elmariofredo]

I think that we should first focus on commands users will use the most, in my opinion these are

$ docker-machine stop
$ docker-machine start
$ docker-machine restart
$ docker-machine ip

after installation basic user don't have to deal with pretty much anything else. For sake of beginner user comfort it's reasonable change to command line UX.

I'm not that fan of default machine name for create and rm, this is supposed to be executed by bit advance user and he should know what machine is he creating or deleting. Also it's not that common task.

For ssh with let's say I have machine named env and want to run env command the is command following docker-machine ssh env env which is wrong from UX perspective anyway, I would disallow run command without -- delimiter to make it absolutely clear. I don't see much of usefulness of different notation of running command with and without arguments. Then we could have default machine set as default as suggested by @tianon, so for simple login to default machine one could use docker-machine ssh and for command docker-machine ssh -- env. But this is bringing breaking change, so I would move it to separate feature request.

[hairyhenderson]

@elmariofredo - yep - I'm in favour of defaulting to $DOCKER_MACHINE_NAME for stop, start, restart, and ip.

I agree about ssh. TBH, if you're "doing it right", you shouldn't ever need to SSH in to your Docker machine. The ssh command is useful for stuff like troubleshooting, but it's not much to ask to just get the user to add the machine name!

[leon]

I've been using docker-machine for a while now and I feel the eval "$(docker-machine env myvm)" is a pain.

I understand that it's good to understand that docker-machine operates against the machine currently set in the env variables.

But couldn't we simplify this a bit.

I usually have one vm for every project I'm working on and name them after the project.

we have the

docker-machine active

to tell us which vm is active, why not let us set the active vm with it also

docker-machine active myvm

that way if I open up a new tab at most I would have to run the command above.
now I find myself first running docker env myvm to then copy and paste the eval script, since it's a bother typing it.

It would be even better if docker-machine could have auto complete so that you only would have to type the first letter of the vm and press tab.

[kudos]

@leon that's a different problem to what's being discussed here. I would suggest looking into autoenv or something similar, or open a new issue about eval'ing the env being a pain.