Consider deprecating in favor of upstream's images

[tianon]

Upstream maintains their own set of images at https://hub.docker.com/r/percona/, and we should seriously consider deprecating this one (similar to ownCloud; docker-library/docs#1251) in favor of theirs. 👍

[tianon]

@EvgeniyPatlan @vadimtk sorry for the cold-ping, but I'd love to have your opinions on this if you're willing to share (or willing to redirect this to someone who can opine on this better), since you appear to be maintaining https://github.com/percona/percona-docker 🙏 ❤️

(Alternatively, we'd love to work with y'all to have you take over this image officially, but it's totally understandable if that's not something that's interesting to Percona ATM. ❤️)

[vadimtk]

I am fine if upsteam uses our images, but it is out of our hands.
My preference would be to have more descriptive names though, like percona-server, percona-xtradb-cluster, percona-server-mongodb, as we have multiple products starting with percona-

[tianon]

@vadimtk you mean if we use your images for https://hub.docker.com/_/percona/? We're discussing either deprecating that image entirely (like https://hub.docker.com/_/owncloud/, for example) or having you folks be more involved, but it sounds like your preference would be for deprecation?

(Thanks so much for engaging in discussion with us! ❤️)

[vadimtk]

@tianon , no we do not want to deprecate that! my preference would be to redirect that to https://hub.docker.com/_/percona-server/ and use our images.
If that is not possible, than we can use our images for https://hub.docker.com/_/percona/

[tianon]

Unfortunately, Docker Hub doesn't support redirection like that, so our best bet is likely to be consuming your Dockerfile directly from https://github.com/percona/percona-docker, which is going to involve updating https://github.com/docker-library/official-images/blob/master/library/percona and reviewing the actual source bits to see what the delta is. Taking a cursory look over the contents of the entrypoint script in the percona-server, it would need at least some minor initial changes just to be compatible with the guidelines/requirements in https://github.com/docker-library/official-images#readme.

Is that work you folks are willing to take on in order to take over this image properly? How can we help to support that work?

There are also likely some docs updates we'll need to make over at https://github.com/docker-library/docs/tree/master/percona (where to file issues, who the image maintainer is, potentially any usage changes, etc).

[vadimtk]

@tianon let us look into that.

[tianon]

Hey @vadimtk, any update? 🙏 ❤️

[vadimtk]

@tianon We are still looking into this, sorry been busy with our releases.

[delgod]

Hi @tianon,

Sorry for a very long response!
We (@percona) are interested in maintaining https://hub.docker.com/_/percona/ images.

Our current release procedure looks like this:

• automatically build a docker image to perconalab/percona-server Docker Hub repo
• run automatic and manual testing on the image
• during the product release, we run docker tag perconalab/percona-server:version percona/percona-server:version and docker push percona/percona-server:version

So the best case for us would be to have docker push percona:version rights.
In such a case, we can deliver a QA verified/tested image.
Is it possible to get docker push percona:version rights?

Another thing: we have a lot of products and worry that end users may not fully understand what product is hidden under the general percona name.
Is it possible to get official Docker Hub images for percona-server, percona-xtradb-cluster, pmm-server, percona-server-mongodb?

Anyway, we are fully open to collaboration and can make any needed changes to
https://github.com/percona/percona-docker repository.
Just let me know what is required, and I will prepare PR.

[tianon]

Is it possible to get docker push percona:version rights?

Unfortunately, no -- see https://github.com/docker-library/official-images#readme for information about the top-level images. All of those (and all changes to them) are peer-reviewed via that repository. It would be possible to get more repos there, but it might also make sense to simply place those as tags of this existing percona image, especially if the way they are run / parameters to them is similar? For example, percona:server-5.7.x, percona:server-mongodb-5.7.x, etc.

That readme I've linked above also outlines the requirements the image is expected to meet in order to qualify for the program (see especially https://github.com/docker-library/official-images#review-guidelines and the following contents).

It's likely also worth comparing the functionality of this repository's docker-entrypoint.sh script to the functionality of the scripts you've got for those upstream images to ensure that usage is roughly equivalent -- there might be a few bits where the usage differs, but I don't think it'll be too drastic. The entrypoint script here in this repository is probably also a good example for how to make sure the image follows the larger official-images guidelines, at least for the runtime aspects.

[delgod]

Hi @tianon,

Thanks for the clarification, we are ok to have one single repo for many products.

So, if I understood correctly the next step is to read guidelines carefully and prepare PR to https://github.com/docker-library/docs/tree/master/percona repo.
We can train with percona:8.0.12.alpha release.
It is public available alpha release, and I can make changes into 8.0-alpha images more freely.
When all Docker Hub recommendations satisfied and PR ready for a merge (approved from your side) I can ask our QA run all needed tests on the modified image.
If everything OK from QA side - we can merge PR.
If the process works fine from both sides - we can start to rework 5.x images.
What do you think?

[jelovac]

Hi all,

Just wondering will this move affect current docker-library/percona users? How do you plan to publish the reworked images, are they going to be published under a new tag?

Best regards,
Vladimir

[delgod]

Hi @jelovac,

I think the following tags will be replaced - percona:latest, percona:5 percona:5.7 percona:5.6, percona:5.5.
I believe tags with exact version (like percona:5.5.61-stretch) shouldn't be changed or removed.

[delgod]

Hi @tianon,

could you please review?

1. additional mysql image tests add additional env variables tests for mysql official-images#4944
2. use upstream images will all needed changes - use upstream percona images official-images#4977

[glensc]

the two images entrypoint are different. shouldn't be just replaced. last time i looked percona images lacked initdb.d support.

[delgod]

Hi @glensc,

please check the current version of entrypoint - https://github.com/percona/percona-docker/blob/master/percona-server.57/ps-entry.sh
if you expect any kind of regression, please show me which functionality doesn't exist in https://github.com/percona/percona-docker repository.

[glensc]

@delgod as i guessed, my information is not current :)

however, i have questions:

what about user/group id? library/percona uses fixed uid/gid based on top level image (which results uid=999, gid=999 at this moment):

percona/5.7/Dockerfile

Lines 4 to 5 in 0f4b22a

	# add our user and group first to make sure their IDs get assigned consistently, regardless of whatever dependencies get added
	RUN groupadd -r mysql && useradd -r -g mysql mysql

but percona hardcodes 1001:1001:

• https://github.com/percona/percona-docker/blob/f176d725d49b6c241263ea796eddb58f17e415f2/percona-server.57/Dockerfile#L5

and i don't see any ocurrence of chown/chmod to mitigate migration pain:

• https://github.com/percona/percona-docker/blob/f176d725d49b6c241263ea796eddb58f17e415f2/percona-server.57/ps-entry.sh

i found PR in library/mysql repo:

• Allow arbitrary --user values mysql#161

---

second question is about files being owned by root group:

but later uses 1001:0, which is super odd:

• https://github.com/percona/percona-docker/blob/f176d725d49b6c241263ea796eddb58f17e415f2/percona-server.57/Dockerfile#L33

i.e the extra writable to root group behavior

[delgod]

Hi @glensc,

thanks for the report, I have added compatibility logic in this PR -
percona/percona-docker#51
is it enough?

about root group, the answer is simple - in OpenShift you get random EUID, you cannot predict EUID.
So simples workaround, provide write permission for root group, in such case mysqld always have enough permissions for write.

[yosifkit]

This is done now: docker-library/official-images#4977 🎉