Upgrade doesn't work for machines where --virtualbox-boot2docker-url was used in create

[dave-tucker]

To recreate:

$ docker-machine create -d virtualbox --virtualbox-boot2docker-url=https://github.com/boot2docker/boot2docker/releases/download/v1.8.3/boot2docker.iso 183

$ docker-machine upgrade 183
Stopping machine to do the upgrade...
Upgrading machine 183...
Downloading boot2docker.iso from https://github.com/boot2docker/boot2docker/releases/download/v1.8.3/boot2docker.iso...
Starting machine back up...

$ docker-machine ssh 183 docker -v
Docker version 1.8.3, build f4bf5c7

I'd expect that machine to be upgraded to the latest version of Docker

[dave-tucker]

/cc @tiborvass per #2098 (comment)

[dmp42]

cc @nathanleclaire

[nathanleclaire]

It's difficult to say what the right behavior should be, since there are certainly users who would expect a custom-used ISO to never be overwritten.

[dave-tucker]

I would recommend two distinct behaviours

docker-machine update

• Gets the latest version of the ISO at the URL specified during creation
• This is useful for folks using custom ISOs

docker-machine upgrade

• Get the latest boot2docker ISO and upgrades the machine
• Perhaps we allow for a version to be specified, if present, upgrade to that one
• Also, we could allow pre-release versions, and if enabled, upgrade to the latest release candidate

There are open issues for the last 2 points of upgrade I think...

[tiborvass]

I don't like having both update and upgrade.

Tibor Vass

On Thu, Nov 5, 2015 at 8:22 PM, Dave Tucker notifications@github.com
wrote:

I would recommend two distinct behaviours

docker-machine update

• Gets the latest version of the ISO at the provided URL
• This is useful for folks using custom ISOs

docker-machine upgrade

• Get the latest boot2docker ISO and upgrades the machine
• Perhaps we allow for a version to be specified, if present, upgrade
  to that one
• Also, we could allow pre-release versions, and if enabled, upgrade
  to the latest release candidate

—
Reply to this email directly or view it on GitHub
#2195 (comment).

[dave-tucker]

I guess I was trying to say, instead of having one command doing 2 things for 2 different users, it might make sense to split the command in two.
update could be renamed recreate or create --recreate or similar if that makes it more palletable

Without splitting the behaviours, the other approach I can think of would be as follows:

• add some logic that looks at the b2d iso and see's if it's from the b2d repo
• if yes, then get the latest release and upgrade
• if no, just fetch the latest version of the ISO

I get bad vibes from just thinking about baking assumptions like that (only upgrade ISOs from b2d repo) in to code.

Especially as the "upgrade" logic could be useful if users were able to change the GitHub repo via a flag. For example, If I'm developing a boot2docker style ISO (e.g https://github.com/docker/boot2docker), it would be useful to me to have users specify that they want this at create time and to re-use the upgrade checking logic.

docker-machine create -d virtualbox --virtualbox-boot2docker-repo docker/boot2docker debian
# When a new release is pushed
docker-machine upgrade debian

[pdalpra]

Unfortunately, this will hit hard in the near future, as the b2d for Docker 1.9.1 is broken and many people had to use a 1.9.0 ISO or custom images...

WDYT of a -f flag to force upgrading to the latest official Boot2Docker image ?
Which would basically boil down to overwrite the "Boot2DockerURL" and reset it to an empty string, as it is when no custom URL is provided.

[fmonniot]

I encountered this problem while trying to update to docker 1.10.
I understand that defining a new behavior (wether it's a -f flag or new commands) is hard, but in the meantime maybe docker-machine could just display a simple message indicating no upgrade have been performed because of the --virtualbox-boot2docker-url usage ? At least people will not wonder why nothing happened even if the command successfully ran.

[nathanleclaire]

I understand that defining a new behavior (wether it's a -f flag or new commands) is hard, but in the meantime maybe docker-machine could just display a simple message indicating no upgrade have been performed because of the --virtualbox-boot2docker-url usage ? At least people will not wonder why nothing happened even if the command successfully ran.

Sounds good, a new issue / PR for this would help us to track the feature request if you're willing.

[pdalpra]

@nathanleclaire provided a PR for this @ #3019