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

dave-tucker commented 8 years ago

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 commented 8 years ago

/cc @tiborvass per https://github.com/docker/machine/issues/2098#issuecomment-154126476

dmp42 commented 8 years ago

cc @nathanleclaire

nathanleclaire commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 https://github.com/docker/machine/issues/2195#issuecomment-154255163.

dave-tucker commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@nathanleclaire provided a PR for this @ #3019

docker / machine

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