Page MenuHomePhabricator

Downgrade docker-compose.yml version
Open, Needs TriagePublic

Description

The current docker-compose.yml declares a version 3.7; this is not compatible with the version of docker-compose (1.21.0) shipped by the latest release of Ubuntu (19.10 Eoan Ermine), which only supports up to version 3.6. (The compose file reference doesn’t tell you this – it only lists the required Docker Engine release, for some reason – but you can compare the release notes of docker-compose 1.21.2 and 1.22.0.) Would it be possible to downgrade the version so Ubuntu users can use the file? At a glance, none of the additional parameters in Version 3.7 appear to be used in MediaWiki’s docker-compose.yml.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 24 2020, 5:45 PM

I'm not sure about this. My initial reaction would be, that's fine, and maybe even use a version compatible with the LTS (whatever version Ubuntu 19.04 installs via apt get). But Docker's documentation tells you to install docker-compose via curl, or pip, or to run as a container and not to install via your package manager. So maybe adding clarification in DEVELOPERS.md about where to install and what minimum version to use would be a decent alternative?

brennen added a subscriber: brennen.Mar 4 2020, 7:05 PM
daniel added a subscriber: daniel.Mar 9 2020, 5:15 PM

I make life easier for new developers, it seems best to use a version that is likely already installed on their system. Unless we need some feature that's not available until a later version.

Reedy added a subscriber: Reedy.Mar 9 2020, 5:17 PM

I make life easier for new developers, it seems best to use a version that is likely already installed on their system. Unless we need some feature that's not available until a later version.

"I'm still using some older LTS... It's supported by my distro, why can't I use the version here?"

As is the usual argument with this sort of thing. There has to be a line somewhere, like you say, for a specific feature. We shouldn't be unnecessarily restrictive unless we have a reason to do so

daniel added a comment.Mar 9 2020, 6:11 PM

"I'm still using some older LTS... It's supported by my distro, why can't I use the version here?"

Well, this is a development environment. It's reasonable to expect develoepers to update more frequently than just LTS. I'm, running Ubuntu 19.10, and it doesn't work for me.

As is the usual argument with this sort of thing. There has to be a line somewhere, like you say, for a specific feature. We shouldn't be unnecessarily restrictive unless we have a reason to do so

Using an old version is restrictive to developers relying on new features. Using a new version is restrictive (or coercive?) for users trying to run it. I'd say be accommodating to users (that is, php devs), as long as it's not terribly restrictive to maintainers of the image.

Change 579922 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/core@master] [docker] Add recommendation to install docker-compose binary

https://gerrit.wikimedia.org/r/579922

I make life easier for new developers, it seems best to use a version that is likely already installed on their system. Unless we need some feature that's not available until a later version.

"I'm still using some older LTS... It's supported by my distro, why can't I use the version here?"

Well, this is the latest release of Ubuntu and not some older LTS version. Do we want to drop support of the latest stable release of ubuntu as it would be "too old?

Well, this is the latest release of Ubuntu and not some older LTS version. Do we want to drop support of the latest stable release of ubuntu as it would be "too old?

When we started in on local-charts, we set an explicit goal of supporting the current Ubuntu LTS and Debian Stable. We didn't, however, do that by way of using distribution-official packages, since that would have been impossible.

My take is that a similar practice is ok here. We should make sure the tooling will run on baseline installs (and the stable releases are a good proxy for that), but we shouldn't necessarily shackle ourselves to distro-official package sources.

Which is to say: I'm cool with downgrading the version if it expands the number of people who can just use apt-get without penalizing us on features/bugs, but maybe we shouldn't treat the version that's installable from the package repos as the hard limit on what operating systems we support?

If Docker's documentation told you to install docker-compose via apt-get I would be totally sympathetic to the idea that we should pin at the latest Ubuntu LTS version. But instead they say:

On Linux systems, first install the Docker for your OS as described on the Get Docker page, then come back here for instructions on installing Compose on Linux systems.

And those instructions offer: 1) download the binary via curl and place in your $PATH, 2) install via pip (with or without virtualenv), 3) run as a container

So if you are installing docker-compose via apt-get, that is unsupported to begin with -- personally I don't think we should be trying to accommodate that workflow. That said, if the majority of folks disagree with this assessment, then let's downgrade the version.

Change 579922 merged by jenkins-bot:
[mediawiki/core@master] [docker] Add recommendation to install docker-compose binary

https://gerrit.wikimedia.org/r/579922

We could also consider:

  • bundling docker-compose?
  • running docker-compose in a docker-container? (although doing this as part of a dev environment prototype gave me a headache last time)

We could also consider:

  • bundling docker-compose?

I'm not sure I understand; do you mean bundling it with mw? If so I would be kind of hesitant to do that.

  • running docker-compose in a docker-container? (although doing this as part of a dev environment prototype gave me a headache last time)

I've tried this before and think I had a similar headache to yours, let's not please :) plus it's quite slow that way, there's a lot of overhead involved.