Please don't upgrade docker without asking first

[rfay]

Please don't auto-upgrade Docker Desktop. Or give us an option to disable upgrades like this. It's fine to prepare the new patch. It's fine to simplify the process. But don't just install without giving us some recourse.

Despite the most heroic efforts of the Docker team, a new release may have new bugs. In software we deal with this all the time. All of us face it, and to move forward there has to be some risk.

However, if there's no way to stop auto-upgrades, there's no easy way to go back to the working version.

So Docker Desktop for Mac 3.0.2 has problems that completely break ddev and some other tools, see docker/for-mac#5157. So fine, we need to roll back to 3.0.1 right?

Unfortunately, with the current auto-upgrade approach introduced in 3.0.0, If you install 3.0.1 it will immediately prepare to install 3.0.2. Then when you reboot or restart docker, voila, you have 3.0.2 again, which doesn't work. And there seems to be no way to stop this cycle.

For those with this pain right now: I think installing Docker Desktop 2.5.0.1 is the only solution.

[kinoute]

I 100% agree. 3.0.2 completely broke my volumes, I rollbacked to 3.0.1 which was self-updated again to 3.0.2... Please ask the user to update or make it optional in the settings.

[ebriney]

Sorry about it, we rushed a bit the last update and introduce a severe bug.
I'll try to fix it today and if I cannot, rollback last grpcfuse patches.
On next updates we will do some canary updates.
But the whole goal of auto-upgrading is to avoid the spread versions, it's a mess to investigate when you have reports from 1 year old version, that's the main reason why we choose to do that.
Just for you to understand:

[ThomasNegeli]

@ebriney
We appreciate your hard work in maintaining the software.
I totally agree that the spread of versions is a real problem.
The problem for a developer is, that on one day your local setup might work, and you reboot your machine the other day, and your setup is broken without any hint.
A comparison with a browser version, as @stephen-turner did in docker/for-mac#5119 (comment), is not a practical usecase for a system backing your development workflow.
So please let us choose when we update the client, and don't do the decision for us.

[mehigh]

Blocking outgoing network connections to desktop.docker.com can keep you on on the functional 3.0.1 by not allowing the auto-upgrade to 'find' the broken 3.0.2 version, this can be used as a temporary patch.
You'd need somethling like Little Snitch to achieve it, but at least you won't lose a Monday.

[ebriney]

You can also use 3.0.2 and switch back to osxfs

[mehigh]

Preferences -> Experimental Features -> Turn Off "Use gRPC FUSE for file sharing"

Thanks for the tip @ebriney

[CedricAlb]

Disabling use of gRPC FUSE was not sufficient to fix my ddev environment (composer commands was freezing, web container unable to stop), I had to revert Docker Desktop to v2.5.0.1

[rfay]

@CedricAlb I hope you'll test with the build in docker/for-mac#5157 (comment) - it would be really important to know if it solves your specific problem.

[CedricAlb]

@rfay I just installed this build for testing but no success...
Composer is still freezing here :

my-project-web:/var/www/html$ composer info -vvv
Reading ./composer.json
Loading config file ./composer.json
Checked CA file /etc/ssl/certs/ca-certificates.crt: valid
Executing command (/var/www/html): git branch -a --no-color --no-abbrev -v

And I still have this error when I try to stop any project :

ddev stop
Stopping ddev-my-project-web ...  
Stopping ddev-my-project-dba ... done
Stopping ddev-my-project-db  ... error
 
ERROR: for ddev-my-project-web  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70) 
An HTTP request took too long to complete. Retry with --verbose to obtain debug information. 
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60). 
Failed to pause containers for my-project: Failed to run docker-compose [-f /Users/me/Develop/my-project/.ddev/.ddev-docker-compose-full.yaml stop], err='exit status 1', stdout='', stderr='Stopping ddev-my-project-web ... 
Stopping ddev-my-project-dba ... done
Stopping ddev-my-project-db  ... error

ERROR: for ddev-my-project-web  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)
An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).' 
Removing container: ddev-my-project-web 

Should I create an issue with these details in the ddev github page ?

[rfay]

@CedricAlb this conversation should be in the other issue (#5157) or in DDEV-Local issue queue. If you can tell us how to recreate the issue - full instructions, preferably with a simple example, it can likely get fixed. This doesn't look like any of the reported issues in docker/for-mac#5157, so it may be something new, or of course, something else. I think the best thing would be a new issue either in this issue queue or the ddev issue queue.

[jonesiscoding]

A reasonable compromise to prevent version spread while allowing people some control over when and how updates install would be to allow the feature to be turned off, but either require the update or disable the software after a reasonable period of time. The definition of "reasonable period" of time might be the subject of some debate, of course.

[rfay]

As users we need to be able to control when an upgrade happens. We understand the need of you maintainers to limit the exposure to a thousand versions, but we really do have to know:

• What version might be installed (currently "Update and restart" doesn't give any suggestion of this)
• When an upgrade will happen. We don't want an upgrade to an unknown version just because macOS or Windows decided to reboot.
• What is in the proposed version and why. Apparently the release notes are not automated, as version 3.0.3 was released today and it does not show in the release notes.

We understand your need to control the number of versions out there, but I think you can understand our need for control of when new versions get installed. Thanks!

[Nuru]

Automatic updating is not an acceptable solution to your version spread problem. This tool simply cannot be used if it is subject to failure at any moment. Forcing auto-updates on unwilling developers will backfire on you. They will either roll back to v2.5.0.1 and stay there until you change your mind, or install Little Snitch to block your automatic upgrades (which will also block your telemetry feed). I almost placed an order for Little Snitch yesterday, but decided to wait a week or two for you to change your minds about this.

You can address version spread by disabling the ability to upload diagnostics from non-current versions, closing issues opened with old versions, and other ways to simply say "we only support the current version, and if you are not on the current version, we are not going to talk to you". Maybe that sounds harsh, but what you are actually doing by forcing version updates on people is even harsher. Not only are you saying "we are not going to talk to you", you are saying "we are not even going to let you run old versions".

Keep the auto-update feature. Allow people to turn it off. Allow people to select which version (of some reasonable number of past versions) to run so they can be secure in the ability to roll back if they have problems with the new version.

[Nuru]

Sorry about it, we rushed a bit the last update and introduce a severe bug.
But the whole goal of auto-upgrading is to avoid the spread versions, it's a mess to investigate when you have reports from 1 year old version, that's the main reason why we choose to do that.

@ebriney Another reason besides https://github.com/docker/for-mac/issues/5163#issuecomment-749283618 that automatic updates is not a solution to your problems is that with automatic updates, any bug that you release becomes an urgent production issue affecting all your users. You need the edge and stable channels and you want to be able to tell people to use an old version while you work on fixes for problems in the current version. The idea that somehow you will be able to do what no one else can do and guarantee you will only release bug free code is just fantasy. No one expects you to be perfect. What we all expect is that you will give us some ability to carry on when bugs make it into a release, and not break our big presentation because we had to reboot our laptop an hour before it.