[hoffmaen]

https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0061-haproxy-awslc.md

Some implementation details:

• One release only, which contains packages for all SSL variants, with and without the HAProxy source code patch
• All packages are compiled once, which increases total deploy time by ~ 1-2 minutes
• Two new bosh properties determine the package to use at deploy-time:
  ** config.ssl_variant (default: openssl, options: openssl, awslc, awslc-fips)
  ** config.include_haproxy_patches (default: false, options: true, false)

Thus this change is not breaking default behavior, as it keeps using OpenSSL by default.

Details on integration tests:

• One execution of integration tests takes in average 35 minutes (unchanged)
• Integration tests can not run in parallel due to low hardware capacity on concourse (see Minimize concurrently opened containers #974)
• Integration tests should also be executed with AWS-LC and AWS-LC FIPS builds in some cases. They run sequentially, so their execution takes ~40 additional minutes each.
• The integration tests verify that the correct TLS library is used.
  ** Before creating a new release, acceptance tests for openssl, awslc and aws-lc have to pass
  ** On Pull-Requests, the label run-ci-awslc must be set when the integration tests for AWS-LC and AWS-LC FIPS should be executed. By having this optional we save time and resources, when the change does not relate to the AWS-LC branch.

[b1tamara]

Is there any need of specific script to build dev release if bosh create-release --force --timestamp-version produces the same?

[hoffmaen]

That's really arguable with the single release now!
What this script now additionally does is proper release naming including the haproxy and awslc versions, and uploading to bosh, but we could decide to drop it entirely.

[b1tamara]

Reviewed packages and src folders. Both look good to me. I would add a dependency graph to have a clear overview of all dependencies between the haproxy job and libraries in packages.

[b1tamara]

Very minor note regarding the output of the single test. It will be like:

Runs the HAProxy binary for the configured SSL variant
    By Reading the SSL library from the running HAProxy binary (haproxy -vv)
    By Expecting AWS-LC FIPS

The first message could be shortened to "Tests the configured SSL variant" to avoid very long test case messages :) But as I mentioned above, very minor note, and it is your choice if you want to change it.

[b1tamara]

Reviewed acceptance_tests folder. It looks good, too.

[b1tamara]

As of now if the ssl variant is an invalid value:

[NOTICE]   (16) : Loading success.
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Fri Oct 23 11:03:29 AM UTC 2026: ERROR: ha_proxy.ssl_variant='openss' is not a valid SSL variant (openssl, awslc, awslc-fips)
Fri Oct 23 11:04:02 AM UTC 2026: ERROR: ha_proxy.ssl_variant='openss' is not a valid SSL variant (openssl, awslc, awslc-fips)

I would check the value earlier (in the jobs/haproxy/templates/haproxy.config.erb similar to allowed option of disable_domain_fronting.
To prevent starting HAProxy due to a configuration issue.

[b1tamara]

Is it still true? I guess the release name will not continue the AWS-LS version after moving to a single release with multiple SSL libs.

[hoffmaen]

Yes it is. Because now, besides HAProxy, the AWS-LC version is the main pillar that denotes the release. I would like to keep it so that it's clear which versions we use in a release. E.g. we might bump AWS-LC but keep HAProxy version, and this bump was not obvious without this change.