search

docker / machine

Machine management for a container-centric world
https://docs.docker.com/machine/
Apache License 2.0
6.62k stars 1.97k forks source link

0.5.0rc3 upgrade doesn't use most logical/recent b2d ISO #2098

Open pvnovarese opened 8 years ago

pvnovarese commented 8 years ago

I had docker toolbox 1.9 rc1 installed on my machine, and I used the included docker-machine to create some hosts. This went as expected and the hosts were created using the b2d 1.9 rc1 ISO.

I then upgraded toolbox to 1.9 rc2 (which upgraded b2d to 1.9 rc2 and machine to 0.5.0 rc3). When I try upgrading the same host, docker-machine doesn't use the 1.9 rc2 ISO that ships with toolbox, and instead goes and downloads 1.8.3 ISO and "upgrades" my machine to that.

pvn@dewgong /Users/pvn> file .docker/machine/cache/boot2docker.iso .docker/machine/cache/boot2docker.iso: ISO 9660 CD-ROM filesystem data 'Boot2Docker-v1.9.0-rc2 ' (bootable)

pvn@dewgong /Users/pvn> eval "$(docker-machine env test3)" pvn@dewgong /Users/pvn> docker version Client: Version: 1.9.0-rc2 API version: 1.21 Go version: go1.4.3 Git commit: 60d36f7 Built: Fri Oct 23 00:20:59 UTC 2015 OS/Arch: darwin/amd64

Server: Version: 1.9.0-rc1 API version: 1.21 Go version: go1.4.3 Git commit: 9291a0e Built: Wed Oct 14 03:29:07 UTC 2015 OS/Arch: linux/amd64

pvn@dewgong /Users/pvn> docker-machine upgrade test3 Stopping machine to do the upgrade... Upgrading machine test3... Downloading https://github.com/boot2docker/boot2docker/releases/download/v1.8.3/boot2docker.iso to /Users/pvn/.docker/machine/cache/boot2docker.iso... Starting machine back up...

pvn@dewgong /Users/pvn> docker version Client: Version: 1.9.0-rc2 API version: 1.21 Go version: go1.4.3 Git commit: 60d36f7 Built: Fri Oct 23 00:20:59 UTC 2015 OS/Arch: darwin/amd64 Error response from daemon: client is newer than server (client API version: 1.21, server API version: 1.20)

pvn@dewgong /Users/pvn> docker-machine -v docker-machine version 0.5.0-rc3 (a1e610b)

pvn@dewgong /Users/pvn> file .docker/machine/cache/boot2docker.iso .docker/machine/cache/boot2docker.iso: ISO 9660 CD-ROM filesystem data 'Boot2Docker-v1.8.3 ' (bootable)

pvnovarese commented 8 years ago

This is particularly weird because "docker-machine create" doesn't have any problem using the 1.9.0-rc2 ISO. It seems that at the very least both operations should have consistent behavior here.

nathanleclaire commented 8 years ago

@tianon Do you think it would make sense to start doing the boot2docker RCs at boot2docker/boot2docker and adding some kind of --release-candidate flag to docker-machine upgrade to allow upgrading to a release candidate?

oxypwn commented 8 years ago

How about making sure that boot2docker rc is available, documented and compatible with *-boot2docker-url? That way we can create a machine with the rc directly.

tianon commented 8 years ago

They've been announced in the same places Docker is; they're currently at https://github.com/tianon/boot2docker-legacy/releases and are usable with "boot2docker-url" CLI flag.

I'm not opposed to uploading them to boot2docker/boot2docker, assuming that we've had sufficient releases of docker-machine that filter out pre-release uploads so that we can be reasonably assured that folks with older releases aren't getting the RCs by mistake. That filtering code's only been in one major release (0.4) so far, right?

nathanleclaire commented 8 years ago

I'm not sure such filtering code exists at all for us today, so I'm not wanting to rush into anything. Just considering the options at hand. Personally I'm pretty OK with being able to create brand new VMs with the RC ISOs, but the expectations around upgrade seem to confuse some users.

tianon commented 8 years ago

Ah, that filtering code was introduced with the b2d-ng code, and then subsequently reverted also. So currently, if I upload any RCs to boot2docker/boot2docker, regardless of that "pre-release" flag, they'll be upgraded to on docker-machine upgrade, which IMO is surprising behavior and is why I haven't done so. I'm definitely 100% +1 to getting that filtering code in place and letting it bake for one or two major Machine releases before we switch to uploading RCs to the main repo.

nathanleclaire commented 8 years ago

Yeah, cool, I think that's what I'd like to do as well.

pvnovarese commented 8 years ago

I'm not sure what other users expect, but my personal expectation is that at a given point in time, if I "docker-machine create" a new machine or if I "docker-machine upgrade" an existing one, both of those operations conclude by leaving me with a machine with the same version of engine installed.

Also, even if you guys decide that the default upgrade behavior is to never use release candidate ISOs without some explicit --use-release-candidate flag (or similar), that's fine, but "upgrading" 1.9rc2 to 1.8.3 shouldn't happen without some sort of "are you sure you want to do this?" step.

tiborvass commented 8 years ago

@nathanleclaire @tianon I have a similar issue: docker-machine upgrade uses whatever --boot2docker-url was given at create time, and I can't override it. So for the RC, I used file:///... and when I want to upgrade to 1.9.0 it still looks for my file:///... one when I'd like it to fetch the latest.

Do you want me to open a new issue?