Support for Customizing the HAProxy Feature Version

[kinjelom]

Now an HAProxy feature version properties.ha_proxy.haproxy_feature_version can be specified by the major.minor version number, one of several HAProxy packages included in this release:

• haproxy-2.8 - support EOL: 2028-Q2 (LTS)
• haproxy-2.9 - support EOL: 2025-Q1 (STS)
• haproxy-3.0 - support EOL: 2029-Q2 (LTS)

LTS - Long Term Support
STS - Short Term Support

Note: This release will be tested only with the default HAProxy feature version (now: 2.8). Use other feature versions with raw configurations at your own risk.

HAProxy 3.0 Major changes

[peanball]

@kinjelom please excuse the delay. First of all, thank you for creating this PR.

We are discussing this PR and have a few more questions / comments.

Could you expand a little more on the motivation for delivering multiple HAProxy versions in the same boshrelease? What is the specific use case where this helps you?

Based on the motivation, some of the comments below may still change.

With the state of our understanding, we have the following comments:

• "Use [other versions] at your own risk" is not acceptable in our opinion. All contained versions should be tested via acceptance tests. This can of course be done with some changes to the acceptance test setup.
  • But beware: this will extend the runtime of the PR and release acceptance tests. While the docker bosh setup takes ca. 12-15 minutes, the remaining 15-20 minutes are on deploying and running HAProxy acceptance tests. Those times would be multiplied by the delivered versions.
• We have auto bumpers in place for various things, including HAProxy. We would need some strategy of how to decide, which versions will be included. Example: Some defined base version (e.g. 2.8) and N subsequent versions.
  • Hard-coding version numbers is an absolute no-go. The auto bumper would need to be adapted.
  • -dev versions of HAProxy could also be included if the motivation is testing scenarios.

[kinjelom]

@peanball Wrapping haproxy in boshrelease has many advantages, but it often limits configuration flexibility. By using raw-config, we give up some convenience but gain complete configuration freedom.

Currently, we mainly use haproxy-boshrelease with raw-config.
This approach shifts the testing burden onto the boshrelease user.
Therefore, the user needs an easy method to verify if their raw-config will work with the next major version of haproxy.
Additionally, once they have verified that everything works, I see no obstacles to using that specific version of haproxy with that specific config.

I don't see a problem with the raw-config user being able to freely choose the haproxy major version. However, supporting a new major version of haproxy with the traditional boshrelease config requires significantly more work.

I am starting to wonder whether combining the boshrelease approach with traditional config and raw-config is a good idea. Wouldn't it be better to create a separate boshrelease that supports only raw-config?...

[peanball]

There are also some open questions that would also need to be resolved (listed at the bottom). Your take on those questions would be very welcome as well.

We have the following suggestions on how to integrate this change better with our release strategy.

1. Adding multiple packages for different versions is something that, e.g. the Postgres boshrelease already does, in a similar way. So conceptually this whole PR is fine overall and makes sense.
2. We have lots of common things (hatop, PCRE, socat, ...) that should ideally not be repeated in each HAProxy version package. We should instead move those to a separate package. The respective HAPRoxy version jobs can then also depend on this common package.
   You started something similar already with the packaging-tools.sh file.
3. The acceptance test execution setup will need to be adapted to run the acceptance tests with each of the HAProxy versions. Ideally this should be done as parallel as possible.
   Currently, the setup is as follows: Deploy n haproxy deployments (n = ginkgo parallel execution concurrency, currently ends up being n = 7). Run the tests in parallel, distributed on the various HAProxy deployments.
   For multiple HAProxy releases we'd need 3 x n HAProxy deployments, if we support 3 HAProxy versions.
4. The different version should be handled by the auto bump-dependencies.py script as well, instead of a fixed list of versions. This ensures that newer version are automatically pulled in and don't require manual checking.

Open questions:

• How do we pick, which versions are provided in the release?
  • Should LTS versions remain until they're out of service / support?
  • How many versions do we support concurrently?
  • Do we want to have the current dev release included for testing?
• What do we do with tests that are targeting a feature in a newer HAProxy version that is not supported by an older version? (Potentially tagging of tests in Ginkgo)
• What should the versioning scheme look like?
  • e.g. haproxy-boshrelease v15.0.0+2.8.10+2.9.3+3.0.3 The main idea for exposing the HAProxy version number in the boshrelease version was to quickly see, which HAProxy version is deployed exactly.

Again, it would be very interesting for us to get your take and opinion on these questions -- or at least the ones that are relevant to you and your daily work.

[peanball]

please note that we have an auto-bumper in place for updating versions in ci/scripts/autobump-dependencies.py.

This script can bump the versions in specific packages and takes care of uploading blobs, etc. already.

[peanball]

we could add a package that is called haproxy-common, which would install all those helpers and provide PCRE, etc. for compilation.

The respective specific haproxy version would then only reference the haproxy blob itself, and we could reduce the amount of duplicated code as the setup of commonly available things could be done in the haproxy-common component.

[peanball]

The auto bumper relies on the value in the comment. Please don't remove it.

[peanball]

As noted before, we should instead set up the auto-bumper for the 3 packages, respectively pinned to their correct HAProxy version.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within 15 days.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within 15 days.