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?...