Request for taking over DOI maintainership

[dkorunic]

Dear team, we (HAProxy Technologies) would like to ask if it is possible to transfer/take over HAProxy DOI maintainership to us. We would also like to know of the exact steps that are required to do this on both sides.

We are currently maintaining haproxytech/haproxy-* images which unnecessarily create a fork in the community, instead of unifying our efforts with the community and Docker. We also have a number of improvements planned:

1. Add a HAProxy variant with s6-overlay and Dataplaneapi enabled by default for the future K8s Gateway API project as well as some other incoming community-related projects (instead of running dataplaneapi as a program within HAProxy),
2. Add a HAProxy variant with AWS-LC OpenSSL replacement instead of problematic OpenSSL 3.x,
3. Add more distribution variants, like we have in haproxytech/haproxy-* images.
4. Further streamline and automate new HAProxy release builds

We have obtained "Verified Publisher" status and plan to collaborate with Docker community even better in the future.

[tianon]

👋 welcome! ❤️

I'd probably recommend starting at https://github.com/docker-library/official-images#maintainership or even higher at https://github.com/docker-library/official-images#contributing-to-the-standard-library, so you can get an idea of what you're signing up for. 😄

After you've gone through that, maybe you'll have a better idea of whether you'd like to start right off the bat with directly transferring this repository or whether you'd like to ease into it by co-maintaining for a little while or something (we're honestly open to however you'd like to roll this, but we do want you to be coming into it with "eyes wide open" so to speak). 👍

(I'm happy to answer questions or provide more detail if there's something that isn't clear!)

Add a HAProxy variant with s6-overlay

In the interest of being completely transparent here, unfortunately something like s6-overlay is not going to be acceptable within the official images program. See https://github.com/docker-library/official-images#init, but the short version is that separate related programs should run in separate containers (although they can be maintained under haproxy:xxx if they are tightly related).

Add a HAProxy variant with AWS-LC OpenSSL replacement instead of problematic OpenSSL 3.x,

We've had some prior discussion on that in #182 and #237, with the conclusion that it wasn't clear whether there was a single "upstream-recommended" answer to the problem, so we have avoided making a particular decision on your behalf. 😅

It would be entirely reasonable for the "default" variants to switch to an alternative implementation, if that's what you would prefer (it doesn't have to be an alternative variant from our perspective, if that makes sense - it certainly can be, though!).

Add more distribution variants

I'd be curious to know the use case of doing so? We typically discourage this sort of (all predominantly glibc-based) base OS diversity within a single image because for most users it's not functionally all that different or useful (and usually just makes choosing an appropriate base more difficult), and instead encourage maintainers to focus on the "upstream-preferred" base distribution, especially since Docker makes distribution differences matter quite a bit less -- are there concrete functional differences/advantages to users choosing one of these over the other besides their own personal preferences?

[dkorunic]

👋 welcome! ❤️

Thank you for the warm and rather detailed response! I (and the rest of the team of course) appreciate it.

I'd probably recommend starting at https://github.com/docker-library/official-images#maintainership or even higher at https://github.com/docker-library/official-images#contributing-to-the-standard-library, so you can get an idea of what you're signing up for. 😄

Will do.

After you've gone through that, maybe you'll have a better idea of whether you'd like to start right off the bat with directly transferring this repository or whether you'd like to ease into it by co-maintaining for a little while or something (we're honestly open to however you'd like to roll this, but we do want you to be coming into it with "eyes wide open" so to speak). 👍

I think that co-maintaining is totally fine for now, if that works with you and the team of course.

(I'm happy to answer questions or provide more detail if there's something that isn't clear!)

If there is any chat or other communication place that you'd like to have us to have better/faster communication, let me know -- but e-mail is fine as well.

Add a HAProxy variant with s6-overlay

In the interest of being completely transparent here, unfortunately something like s6-overlay is not going to be acceptable within the official images program. See https://github.com/docker-library/official-images#init, but the short version is that separate related programs should run in separate containers (although they can be maintained under haproxy:xxx if they are tightly related).

I understand, if those are the rules then there is not much we can do about it in DOI, but we will certainly do this in our haproxytech images due to the fact we are going into the direction of having a full API for our HAProxy images. Since HAProxy and Dataplaneapi are separate processes and it's implied that Dataplaneapi has to be able to connect to master socket, has to be able to send signals, has to be able to even restart HAProxy and all of that in the unprivileged mode, we have been typically doing this for our customers by introducing s6-overlay in our images and we were hoping to give this to our community users as well. Single image with all the features is the "vision" we are having, but again we understand there are rules that DOI has to adhere by.

Add a HAProxy variant with AWS-LC OpenSSL replacement instead of problematic OpenSSL 3.x,

We've had some prior discussion on that in #182 and #237, with the conclusion that it wasn't clear whether there was a single "upstream-recommended" answer to the problem, so we have avoided making a particular decision on your behalf. 😅

It is rather complex topic which we're actively working on, not only just as a quick-fix, but as a long-term decision in regards to features, LTS releases and obviously due to being able to pass FIPS compliance as well. AWS-LC indeed looks quite promising in many regards.

It would be entirely reasonable for the "default" variants to switch to an alternative implementation, if that's what you would prefer (it doesn't have to be an alternative variant from our perspective, if that makes sense - it certainly can be, though!).

Great to hear, thank you!

Add more distribution variants

I'd be curious to know the use case of doing so? We typically discourage this sort of (all predominantly glibc-based) base OS diversity within a single image because for most users it's not functionally all that different or useful (and usually just makes choosing an appropriate base more difficult), and instead encourage maintainers to focus on the "upstream-preferred" base distribution, especially since Docker makes distribution differences matter quite a bit less -- are there concrete functional differences/advantages to users choosing one of these over the other besides their own personal preferences?

Surprisingly, we had many users and customers (for the enterprise variants) that were asking all of those and even more (we get asked to provide UBI9 variant frequently) for a variety of reasons, which I admit are not necessarily always something we would personally go with. For now our haproxytech/haproxy-debian has 10M downloads but roughy 5k per week, haproxytech-haproxy-alpine has 5M downloads but roughly 21k per week and haproxytech/haproxy-ubuntu has 1M downloads, but surprisingly has roughly 8k downloads per week, more than our Debian variant so I guess there is some increased activity there.

It's not really comparable to haproxy DOI image, but we can merge some efforts and we can continue working on some DOI-incompatible features in our own images as agreed above.

[yosifkit]

Welcome and thanks for your responses!

Just in case you haven't seen what the current DOI build process looks like, "An image's source changed in Git, now what?" is a great walkthrough that we just updated.

If you'd like to chat, we are both in the Docker Community slack (http://dockr.ly/comm-slack) though our time zones might not line up well.

Since you want to start with co-maintaining, you should have an invite to give you access to merge and close PRs and issues here in docker-library/haproxy💪. Are there other members of your team that we should add?