Bug 1885415 - Review Request: haproxy18 - HAProxy reverse proxy for high availability environments
Summary: Review Request: haproxy18 - HAProxy reverse proxy for high availability envir...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: Package Review
Version: epel7
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-05 21:01 UTC by Robert Scheck
Modified: 2020-11-14 00:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-14 00:40:37 UTC
Type: Bug


Attachments (Terms of Use)
Diff between current HAProxy from RHEL 8 and this package (6.87 KB, text/plain)
2020-10-05 21:06 UTC, Robert Scheck
no flags Details
Diff between current HAProxy from RHEL 8 and this package (6.02 KB, text/plain)
2020-10-25 00:55 UTC, Robert Scheck
no flags Details

Description Robert Scheck 2020-10-05 21:01:29 UTC
Spec URL: http://labs.linuxnetz.de/bugzilla/haproxy18.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/haproxy18-1.8.23-1.el7.src.rpm
Description: HAProxy is a TCP/HTTP reverse proxy which is particularly suited for high availability environments. Indeed, it can:
 - route HTTP requests depending on statically assigned cookies
 - spread load among several servers while assuring server persistence
   through the use of HTTP cookies
 - switch to backup servers in the event a main one fails
 - accept connections to special ports dedicated to service monitoring
 - stop accepting connections without breaking existing ones
 - add, modify, and delete HTTP headers in both directions
 - block requests matching particular patterns
 - report detailed status to authenticated users from a URI
   intercepted from the application
Fedora Account System Username: robert


This package is intended only for EPEL 7 to provide some kind of forward compatibility for admins depending on TLSv1.3 at RHEL 7. RHEL 7 is only shipping the old openssl-1.0.2k-19.el7.x86_64 (and it won't change that as stated in bug #1416715). So this is haproxy-1.8.23-5.el8 from RHEL 8 modified to be installable along with the regular package, but linked against openssl11-libs from EPEL 7 for TLSv1.3 support. The package itself was as less modified as possible to make the differences hopefully easily reviewable.

Comment 1 Robert Scheck 2020-10-05 21:06:35 UTC
Created attachment 1719178 [details]
Diff between current HAProxy from RHEL 8 and this package

Comment 2 Carl George 🤠 2020-10-24 02:29:29 UTC
As we were discussing on IRC, this package doesn't need a formal review.  It falls under bullet point two here [0] of multiple versions of the same package.

That said, there are a few things that need to be corrected.

1. The package should to be named haproxy1.8 to comply with the naming guidelines [1].  Please close the current fedscm repo request [2] and re-do it as haproxy1.8 (still with the `--exception` flag).

2. The /var/lib/haproxy directory already exists in the RHEL haproxy package.  Sharing the state directory could disturb the base package, which is not allowed by EPEL policy [3].

3. I understand what you're trying to do with the syspaths subpackage, but similar to the previous item, this is not allowed by policy, as the files would conflict with the RHEL haproxy package.


[0] https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
[2] https://pagure.io/releng/fedora-scm-requests/issue/29940
[3] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy

Comment 3 Robert Scheck 2020-10-24 11:50:48 UTC
(In reply to Carl George 🤠 from comment #2)
> 1. The package should to be named haproxy1.8 to comply with the naming
> guidelines [1].  Please close the current fedscm repo request [2] and re-do
> it as haproxy1.8 (still with the `--exception` flag).

Did I overlook something? It says "All other packages derived from it MUST include the base name suffixed by either: [bullet point] The package version, which SHOULD include the periods present in the original version. [...]" - not MUST, thus "haproxy18" should be sufficient.

> 2. The /var/lib/haproxy directory already exists in the RHEL haproxy
> package.  Sharing the state directory could disturb the base package, which
> is not allowed by EPEL policy [3].

I have explicitly ensured in the default configuration of haproxy18, that there is no file conflict or overlap within the state directory at al. Further on, I even actually tested whether both packages can coexist during run-time without disturbing each other. Note that the official SCL rh-haproxy18-haproxy-1.8.24-2.el7 does exactly the same here (because they all share the haproxy user/group and its home directory, while changing the home directory of the haproxy user actually would disturb the base package).

> 3. I understand what you're trying to do with the syspaths subpackage, but
> similar to the previous item, this is not allowed by policy, as the files
> would conflict with the RHEL haproxy package.

Even this is a completely optional subpackage, the admin needs to explicitly install? If that remains the only blocker, I will drop the subpackage then.

Comment 4 Carl George 🤠 2020-10-24 23:07:19 UTC
> Did I overlook something? It says "All other packages derived from it MUST include the base name suffixed by either: [bullet point] The package version, which SHOULD include the periods present in the original version. [...]" - not MUST, thus "haproxy18" should be sufficient.

What is the justification for not following the guideline?  Most packages that do not follow this were created before the guideline existed.  New packages going forward need to follow it unless there is a good reason not to.  On a related note, once the package name is changed to haproxy1.8, the path suffixes should probably be 1.8 instead of 18 as well for consistency.

> I have explicitly ensured in the default configuration of haproxy18, that there is no file conflict or overlap within the state directory at al. Further on, I even actually tested whether both packages can coexist during run-time without disturbing each other. Note that the official SCL rh-haproxy18-haproxy-1.8.24-2.el7 does exactly the same here (because they all share the haproxy user/group and its home directory, while changing the home directory of the haproxy user actually would disturb the base package).

rh-haproxy18-haproxy uses /var/opt/rh/rh-haproxy18/lib/haproxy.  It also owns the /var/lib/haproxy directory as the home directory of the shared haproxy user, but it explicitly doesn't use it.  If you want to follow the SCL package's example, you need to use a different state directory as well.  If the /var/lib/haproxy directory in your package is empty and unused, then it would meet EPEL guidelines in my opinion.  Just using a different path for the stats socket is not sufficient, because that assumes that haproxy will never write anything else to that directory.  That may be true, but we should play it safe and not make assumptions.

> Even this is a completely optional subpackage, the admin needs to explicitly install? If that remains the only blocker, I will drop the subpackage then.

Every package in EPEL is optional, and EPEL packages are not allowed to have file conflicts with RHEL packages.


P.S. There is no need to use the needinfo flag, I'm cc'ed on the bug already.  All you accomplished by that is sending me two email notifications instead of one.  You should also be aware that until the flag is cleared, bugzilla will continue to email me every few days.  We all get too much email as it is, so please respect people's inboxes and only use the needinfo flag sparingly, such as when someone is non-responsive for several weeks.

Comment 5 Robert Scheck 2020-10-25 00:54:11 UTC
(In reply to Carl George 🤠 from comment #4)
> What is the justification for not following the guideline?  Most packages
> that do not follow this were created before the guideline existed.  New
> packages going forward need to follow it unless there is a good reason not
> to.  On a related note, once the package name is changed to haproxy1.8, the
> path suffixes should probably be 1.8 instead of 18 as well for consistency.

I would like to see the haproxy18 package as a strong and direct competitor to Red Hat's rh-haproxy18 package, not only due to the main feature difference (TLSv1.3), but also by its quite similar package name. And especially for RHEL 7, administrators are used to versioned packages without a dot, be it python36, mozjs17, mozjs24, mozjs52, rh-gitXX, rh-mariadbXXX, rh-perlXXX, rh-phpXX or rh-postgresqlXX to just name a few quite common ones. Being also an administrator myself, I find it kind of confusing to mix different naming schemes that late on RHEL 7, also once it comes to file and directory path names (note that we are not talking here about e.g. yet another Python library that is automagically added as dependency during installation where the file and directory path names do not really matter, because it's hidden by the programming language, but about a software where administrators, also hopefully migrating from rh-haproxy18, actually need to type these path names or to migrate configurations). This package is not targetting RHEL 8 or similar, where I would agree about a new naming scheme, but the older RHEL 7, where I would like to keep and continue exactly the naming and spirit for the last < 4 years until EOL, that de-facto existed in the > 6 years before. I understand that you might not treat this as a strong justification, but for me as a packager, it's the actual freedom that I see by "should" rather "must" in the guidelines.

> rh-haproxy18-haproxy uses /var/opt/rh/rh-haproxy18/lib/haproxy.  It also
> owns the /var/lib/haproxy directory as the home directory of the shared
> haproxy user, but it explicitly doesn't use it.  If you want to follow the
> SCL package's example, you need to use a different state directory as well. 
> If the /var/lib/haproxy directory in your package is empty and unused, then
> it would meet EPEL guidelines in my opinion.  Just using a different path
> for the stats socket is not sufficient, because that assumes that haproxy
> will never write anything else to that directory.  That may be true, but we
> should play it safe and not make assumptions.

Playing safe is indeed a valid argument (even I did various checks), so I've changed the path.


Spec URL: http://labs.linuxnetz.de/bugzilla/haproxy18.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/haproxy18-1.8.23-2.el7.src.rpm

Comment 6 Robert Scheck 2020-10-25 00:55:37 UTC
Created attachment 1724010 [details]
Diff between current HAProxy from RHEL 8 and this package

Comment 7 Neal Gompa 2020-10-26 12:09:57 UTC
Robert, please change the version suffix to the accurate version string. In general, we are trying to stop having packages named with versions lacking the separators because it's confusing to most people and causes other issues for third parties. That's why Python has finally stopped doing this, and LLVM stopped doing this a long time ago.

Comment 8 Robert Scheck 2020-10-26 12:28:49 UTC
Neal, I explained above why I would like to use the freedom from 'should', and I've doubts that the old EPEL 7 branch is the right candidate to enforce a (currently) non-mandatory guideline that strongly like it happens in this RHBZ. I agree for more recent branches like EPEL 8, but not for EPEL 7.

Comment 9 Carl George 🤠 2020-10-28 22:36:34 UTC
> This package is not targetting RHEL 8 or similar, where I would agree about a new naming scheme, but the older RHEL 7, where I would like to keep and continue exactly the naming and spirit for the last < 4 years until EOL, that de-facto existed in the > 6 years before.

This is a really good point.  You've convinced me.  Feel free to proceed with importing to the haproxy18 repo that has already been requested.

> Diff between current HAProxy from RHEL 8 and this package

One small suggested tweak, rather than mucking with the regparm_opts variable, just delete USE_LUA=1 from the make command a few lines later.

Comment 10 Fedora Update System 2020-10-29 01:44:25 UTC
FEDORA-EPEL-2020-0d6230d04e has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0d6230d04e

Comment 11 Fedora Update System 2020-10-30 01:37:56 UTC
FEDORA-EPEL-2020-0d6230d04e has been pushed to the Fedora EPEL 7 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0d6230d04e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Fedora Update System 2020-11-14 00:40:37 UTC
FEDORA-EPEL-2020-0d6230d04e has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.