Add Heat container image definitions by slagle · Pull Request #76 · openstack-k8s-operators/s2i-openstack-containers

slagle · 2026-08-13T20:16:11Z

Add Heat container image definitions

Use a single heat-api image for heat-api and heat-api-cfn and contains
httpd, mod_ssl, python3-mod_wsgi. heat-engine is a separate image.

The images build Heat from source upstream config files (api-paste.ini,
environment.d, templates), and the distgit heat-dist.conf.

Note that python3-cryptography is pinned to 43.0.0-4.el10, which matches
the major version in upper-constraints.txt.

Jira: OSPRH-34691
Jira: OSPRH-34692
Jira: OSPRH-34693
Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com
Signed-off-by: James Slagle jslagle@redhat.com

yazug

couple of nits but looks good to me nothing blocking it from my point of view.

rabi

Few questions as well,

Consolidating to one image means the three RELATED_IMAGE_HEAT_* references all have to point at the same pullspec, and needs changes in heat-operator/openstack-operator, right?

Since all three services would then share one image digest, any rebuild of that image would roll all three (api, api-cfn, engine) together, even for a fix that only affects one role (e.g. an httpd CVE bouncing number of heat-engine pods). Has this been taken into consideration?

amoralej · 2026-08-14T06:55:27Z

Thanks for consolidating into a single one, that's great.

New container name is openstack-heat which didn't exist in tcib. @yazug is that a problem? I think you mentioned to reuse an existing name when possible.

amoralej · 2026-08-14T11:01:53Z

Few questions as well,

Consolidating to one image means the three RELATED_IMAGE_HEAT_* references all have to point at the same pullspec, and needs changes in heat-operator/openstack-operator, right?

Yes, the three RELATED_IMAGE_HEAT... should point to the same container image so the three values in OpenStackVersion would point to the same image.

I don't know the details of heat-operator but i wouldn't expect this to require any change on it (we are doing the same in watcher-operator).

About changes in openstack-operator to get default values, I'd say just setting the default values (https://github.com/search?q=repo%3Aopenstack-k8s-operators%2Fopenstack-operator+RELATED_IMAGE_HEAT_&type=code) . Given that this is different than tcib, we will need some mapping for transition for the mapping of container names to OpenStackVersion fields for CI which is what we just starting adding in https://github.com/openstack-k8s-operators/s2i-openstack-containers/blob/main/containers/image-mappings.yaml

I may be missing something but from the impact in operators itself, i think consolidation should be easy to manage. @stuggi , any opinion on this?

Since all three services would then share one image digest, any rebuild of that image would roll all three (api, api-cfn, engine) together, even for a fix that only affects one role (e.g. an httpd CVE bouncing number of heat-engine pods). Has this been taken into consideration?

Yes. I think it has been considered but it's probably good to wide the discussion and make sure all impact is considered. @yazug may give the opinion of reldel on that and give additional details about how the actual process works. Some considerations to keep in mind.

I'd say (@yazug please confirm) that in most cases the entire bundle of containers is rebuild and delivered as a whole, at least for periodic releases (both bug releases and FR ones). I'm not sure if in CVEs there are partial releases.
The impact of pods restarting on each service can be different and can be a factor. While in some cases restarting pods with new versions may be inocuous, short and fast in other reducing pod restarts may be a relevant factor to reduce and may be a factor to decide what / if to consolidate.
Think also the opposite case, rebuilds of bugs or CVEs that affect all is faster :) .
anything i may missing ...

From the s2i-openstack-operators itself, reducing the number of images will help managing the content from different aspects so it's a fair goal but you are right that there may be other considerations.

Do you think it'd be good to have some wider discussion and / or document these considerations somewhere?

slagle · 2026-08-14T14:30:26Z

From the s2i-openstack-operators itself, reducing the number of images will help managing the content from different aspects so it's a fair goal but you are right that there may be other considerations.

The additional surface area is httpd, mod_ssl, python3-mod_wsgi, since those are now included in the image that's used by heat-engine. If those deps do need to get updated frequently, we're talking about a lot of container restarts anyway across all the APIs. Adding in heat-engine to that list doesn't seem like it would make much difference. heat-engine restarts also shouldn't cause any disruption to any user stacks that might be in progress.

That seems worth it for managing 1 less container image.

amoralej · 2026-08-14T15:58:45Z

Thanks for consolidating into a single one, that's great.

New container name is openstack-heat which didn't exist in tcib. @yazug is that a problem? I think you mentioned to reuse an existing name when possible.

Confirmed by @yazug we need the name for the new common container to be an existing one in tcib, heat-api, heat-base, heat-api-cfn or heat-engine.

rabi · 2026-08-17T03:36:34Z

since those are now included in the image that's used by heat-engine

I don't see any reason we continue including those in heat-engine.

Adding in heat-engine to that list doesn't seem like it would make much difference. heat-engine restarts also shouldn't cause any disruption to any user stacks that might be in progress.

Well, heat-engine waits for in-progess stacks to complete or timeout before killing the engines. I don't think it's correct to assume that restarting heat-engines unnecessarily won't be an overhead.

we need the name for the new common container to be an existing one in tcib, heat-api, heat-base, heat-api-cfn or heat-engine.

I don't think we should name the common image any of the above as it would be misleading/confusing. I would prefer we split them into 2 images heat-api (includes heat-api-cfn) and heat-engine.

rabi · 2026-08-17T04:08:15Z

I don't know the details of heat-operator but i wouldn't expect this to require any change on it

Are we planning to keep the three RELATED_IMAGE_HEAT_* env vars (one per service) now that all three run the same image? If so, we've to guarantee they stay pinned to the same digest and don't diverge over time. Should we collapse to a single reference instead?

amoralej · 2026-08-17T09:52:18Z

I don't know the details of heat-operator but i wouldn't expect this to require any change on it

Are we planning to keep the three RELATED_IMAGE_HEAT_* env vars (one per service) now that all three run the same image? If so, we've to guarantee they stay pinned to the same digest and don't diverge over time. Should we collapse to a single reference instead?

That's TBD at this point. I thin keeping RELATED_IMAGE_HEAT_* on sync is doable, but we may also have a single env variable and consume the same to populate defaults for multiple openstackversion fields. We just need to manage the transition so that it's tied to moving all the CI jobs to new s2i master ones and make sure it's properly managed in the e2e process.

elfiesmelfie · 2026-08-17T11:29:50Z

+# Install wheels temporarily so entry points are available for config generation
+RUN pip3 install --no-cache-dir --prefix=/usr \
+      -c /tmp/build-constraints.txt \
+      --find-links=/wheels/deps \
+      --find-links=/wheels/pkgs \
+      /wheels/pkgs/*.whl


You don't run the config generator, so this can also be removed, since the installation is only being done here for config generator.

Suggested change

# Install wheels temporarily so entry points are available for config generation

RUN pip3 install --no-cache-dir --prefix=/usr \

-c /tmp/build-constraints.txt \

--find-links=/wheels/deps \

--find-links=/wheels/pkgs \

/wheels/pkgs/*.whl

elfiesmelfie · 2026-08-17T11:32:28Z

+COPY --from=build /configfiles/etc/heat/heat.conf /etc/heat/heat.conf
+COPY --from=build /configfiles/etc/heat/api-paste.ini /etc/heat/api-paste.ini
+COPY --from=build /configfiles/etc/heat/environment.d/default.yaml /etc/heat/environment.d/default.yaml
+COPY --from=build /configfiles/etc/heat/templates/AWS_CloudWatch_Alarm.yaml /etc/heat/templates/AWS_CloudWatch_Alarm.yaml
+COPY --from=build /configfiles/etc/heat/templates/AWS_RDS_DBInstance.yaml /etc/heat/templates/AWS_RDS_DBInstance.yaml


The configfiles dir used to be populated by the config generator, which is not being run.
Remove these lines

Suggested change

COPY --from=build /configfiles/etc/heat/heat.conf /etc/heat/heat.conf

COPY --from=build /configfiles/etc/heat/api-paste.ini /etc/heat/api-paste.ini

COPY --from=build /configfiles/etc/heat/environment.d/default.yaml /etc/heat/environment.d/default.yaml

COPY --from=build /configfiles/etc/heat/templates/AWS_CloudWatch_Alarm.yaml /etc/heat/templates/AWS_CloudWatch_Alarm.yaml

COPY --from=build /configfiles/etc/heat/templates/AWS_RDS_DBInstance.yaml /etc/heat/templates/AWS_RDS_DBInstance.yaml

Some of these files (all but heat.conf I think) are not generated via config generator but copied from the upstream repo but it was removed together with the config generator one i think. See:

https://github.com/openstack-k8s-operators/s2i-openstack-containers/compare/d139011c3d6918cb017b24510a67d6418d69ab18..4b7f44bd08d9f1d4145bcce72b2fc42536b59d4b#diff-985200677c64c1f53e3f7f779f2896ea14a067b9ce342cacb90a3835dfbe89dbL73-L76

Those lines need to be restored.

elfiesmelfie · 2026-08-17T11:55:47Z

+RUN chmod 640 /etc/heat/heat.conf /etc/heat/api-paste.ini && \
+    chown -R heat:heat /etc/heat /usr/share/heat


Suggested change

RUN chmod 640 /etc/heat/heat.conf /etc/heat/api-paste.ini && \

chown -R heat:heat /etc/heat /usr/share/heat

RUN chown -R heat:heat /etc/heat /usr/share/heat

We may need to keep the chmod 640 for the config files other than heat.conf.

Agreed. Unfortunately, I cannot edit my suggestion at this time; github is having some technical issues

diff --git containers/heat/heat/Containerfile containers/heat/heat/Containerfile index 58ce632..11d90d4 100644 --- containers/heat/heat/Containerfile +++ containers/heat/heat/Containerfile @@ -57,12 +57,10 @@ RUN for src_dir in /src/*/ /src/overrides/*/; do \ fi; \ done > /source-built-packages.txt -# Install wheels temporarily so entry points are available for config generation -RUN pip3 install --no-cache-dir --prefix=/usr \ - -c /tmp/build-constraints.txt \ - --find-links=/wheels/deps \ - --find-links=/wheels/pkgs \ - /wheels/pkgs/*.whl +RUN cp -a ${SERVICE_SRC}/etc/heat/api-paste.ini /configfiles/etc/heat/ && \ + cp -a ${SERVICE_SRC}/etc/heat/environment.d/default.yaml /configfiles/etc/heat/environment.d/ && \ + cp -a ${SERVICE_SRC}/etc/heat/templates/AWS_CloudWatch_Alarm.yaml /configfiles/etc/heat/templates/ && \ + cp -a ${SERVICE_SRC}/etc/heat/templates/AWS_RDS_DBInstance.yaml /configfiles/etc/heat/templates/ # --- Runtime stage --- FROM ${BASE_IMAGE} @@ -93,7 +91,6 @@ RUN mkdir -p /etc/heat /var/log/heat /var/lib/heat /usr/share/heat && \ chown -R heat:heat /etc/heat /var/log/heat /var/lib/heat /usr/share/heat # Install config files — each file listed explicitly -COPY --from=build /configfiles/etc/heat/heat.conf /etc/heat/heat.conf COPY --from=build /configfiles/etc/heat/api-paste.ini /etc/heat/api-paste.ini COPY --from=build /configfiles/etc/heat/environment.d/default.yaml /etc/heat/environment.d/default.yaml COPY --from=build /configfiles/etc/heat/templates/AWS_CloudWatch_Alarm.yaml /etc/heat/templates/AWS_CloudWatch_Alarm.yaml @@ -101,7 +98,7 @@ COPY --from=build /configfiles/etc/heat/templates/AWS_RDS_DBInstance.yaml /etc/h COPY common/config/usr/share/heat/heat-dist.conf /usr/share/heat/heat-dist.conf # Set config file permissions -RUN chmod 640 /etc/heat/heat.conf /etc/heat/api-paste.ini && \ +RUN chmod 640 /etc/heat/api-paste.ini && \ chown -R heat:heat /etc/heat /usr/share/heat # Apache httpd setup for WSGI

And you also need to create the /configfiles/etc/heat/environment.d and /configfiles/etc/heat/templates firs in the build layers

You can probably move these COPY lines into the runtime stage instead. I don't think they need to be moved between layers

These COPY commands are already in the runtime stage. Or do you mean the initial cp commands for these files, just do that in runtime?

I experienced a dumb moment about these, and confused two sets of config files: the ones from the openstack repo and the ones from the s2i repo.

Please ignore the suggestion to remove the COPY commands from the build stage

slagle · 2026-08-17T22:07:37Z

I believe I have addressed all the comments, and got it building again.

slagle · 2026-08-17T22:10:09Z

I don't think we should name the common image any of the above as it would be misleading/confusing. I would prefer we split them into 2 images heat-api (includes heat-api-cfn) and heat-engine.

@rabi
I'm not opposed to going back to that. Especially since for some reason we can't rename any containers for 19, so heat-engine would need to use an image named "heat-api" if we keep the all in one image.

I'll let you make the call, let me know which you prefer.

rabi · 2026-08-18T06:17:51Z

I don't think we should name the common image any of the above as it would be misleading/confusing. I would prefer we split them into 2 images heat-api (includes heat-api-cfn) and heat-engine.

@rabi I'm not opposed to going back to that. Especially since for some reason we can't rename any containers for 19, so heat-engine would need to use an image named "heat-api" if we keep the all in one image.

I'll let you make the call, let me know which you prefer.

IMO, we should go back, keeping in mind the number of limitations we've with this atm.

We can't name the container image heat or heat-all
We need to change operators to use single RELATED_IMG env var as it seems multiple env vars can't use the same image as per reldel

We can change back to single image later if other services like nova, cinder etc follow the single image pattern.

slagle · 2026-08-18T16:27:14Z

I don't think we should name the common image any of the above as it would be misleading/confusing. I would prefer we split them into 2 images heat-api (includes heat-api-cfn) and heat-engine.

@rabi I'm not opposed to going back to that. Especially since for some reason we can't rename any containers for 19, so heat-engine would need to use an image named "heat-api" if we keep the all in one image.
I'll let you make the call, let me know which you prefer.

IMO, we should go back, keeping in mind the number of limitations we've with this atm.
* We can't name the container image heat or heat-all

* We need to change operators to use single RELATED_IMG env var as it seems multiple env vars can't use the same image as per reldel
We can change back to single image later if other services like nova, cinder etc follow the single image pattern.

I've separated it back out into heat-api and heat-engine. I think we would just need to drop the env var for heat-api-cfn in openstack-operator and it can use the heat-api env var instead.

rabi · 2026-08-19T03:58:11Z

+    chown -R heat:heat /etc/heat /var/log/heat /var/lib/heat /usr/share/heat
+
+# Install config files — each file listed explicitly
+COPY --from=build /configfiles/etc/heat/api-paste.ini /etc/heat/api-paste.ini


We don't need this in heat-engine container.

Removed (and other refs)

rabi · 2026-08-19T03:58:30Z

+COPY common/config/usr/share/heat/heat-dist.conf /usr/share/heat/heat-dist.conf
+
+# Set config file permissions
+RUN chmod 640 /etc/heat/api-paste.ini && \


rabi · 2026-08-19T03:59:51Z

+
+# Install config files — each file listed explicitly
+COPY --from=build /configfiles/etc/heat/api-paste.ini /etc/heat/api-paste.ini
+COPY --from=build /configfiles/etc/heat/environment.d/default.yaml /etc/heat/environment.d/default.yaml


We don't need these env files heat-api anyway.

Removed, and also removed from the build phase

rabi · 2026-08-19T04:16:10Z

+# Install config files — each file listed explicitly
+COPY --from=build /configfiles/etc/heat/api-paste.ini /etc/heat/api-paste.ini
+COPY --from=build /configfiles/etc/heat/environment.d/default.yaml /etc/heat/environment.d/default.yaml
+COPY --from=build /configfiles/etc/heat/templates/AWS_CloudWatch_Alarm.yaml /etc/heat/templates/AWS_CloudWatch_Alarm.yaml


Actually we can get rid these templates as they're history. cloud-watch api has been dropped since long.

Removed (and other refs)

rabi · 2026-08-19T04:45:35Z

@@ -0,0 +1,12 @@
+[DEFAULT]


I think we can drop this file completely.

This comes from the previous rpm packaging. Do we no longer need these settings? Most of them are different from the default values.

They don't matter. In 17.1 we used to run heat-engine with /usr/bin/heat-engine --config-file /usr/share/heat/heat-dist.conf --config-file /etc/heat/heat.conf but in 18 it's /usr/bin/python3 /usr/bin/heat-engine --config-file /etc/heat/heat.conf.d

https://github.com/openstack-k8s-operators/heat-operator/blob/main/internal/heatengine/deployment.go#L94-L97

coderabbitai · 2026-08-19T13:31:59Z

Important

🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: b797b828-1364-4d02-b87a-00f1b305b0ca

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

rebtoor · 2026-08-19T15:10:13Z

/lgtm

amoralej

This looks fine to me.

heat-dist.conf may be adjusted as follow-up if desired.

rebtoor · 2026-08-19T15:21:55Z

/approve

openshift-ci · 2026-08-19T15:22:01Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rebtoor

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [rebtoor]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

elfiesmelfie

Please include an update to containers/image-mappings.yaml

elfiesmelfie · 2026-08-19T16:29:14Z

Have a look at the comment on #15 (comment)

You could do the same here in heat, with a heat/bindeps and heat//bindeps (and for the other {python,}*deps files), to reduce the maintenance effort. There is a reference implementation in cinder.

This can be done in a follow up IMHO

Ok, I did that for bindeps and builddeps

elfiesmelfie · 2026-08-19T16:31:27Z

+# --- Runtime stage ---
+FROM ${BASE_IMAGE}
+
+LABEL summary="OpenStack Heat engine" \


Update the description if this is used for multiple heat services now

Use a single heat-api image for heat-api and heat-api-cfn and contains httpd, mod_ssl, python3-mod_wsgi. heat-engine is a separate image. The images build Heat from source upstream config files (api-paste.ini, environment.d, templates), and the distgit heat-dist.conf. Note that python3-cryptography is pinned to 43.0.0-4.el10, which matches the major version in upper-constraints.txt. Jira: OSPRH-34691 Jira: OSPRH-34692 Jira: OSPRH-34693 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: James Slagle <jslagle@redhat.com>

slagle force-pushed the heat branch from 6ce15c9 to 1c25f13 Compare August 13, 2026 20:22

yazug reviewed Aug 13, 2026

View reviewed changes

Comment thread containers/heat/heat-api/bindeps.txt Outdated

Comment thread containers/heat/heat/pythonbuilddeps.txt

Comment thread containers/heat/heat/Containerfile Outdated

slagle force-pushed the heat branch from 1c25f13 to d139011 Compare August 13, 2026 20:51

yazug approved these changes Aug 13, 2026

View reviewed changes

openshift-ci Bot assigned yazug Aug 13, 2026

openshift-ci Bot added the lgtm label Aug 13, 2026

rabi reviewed Aug 14, 2026

View reviewed changes

Comment thread containers/heat/requirements.lock.master Outdated

Comment thread containers/heat/builddeps.txt

Comment thread containers/heat/rpms.in.yaml Outdated

slagle force-pushed the heat branch from d139011 to 4b7f44b Compare August 14, 2026 14:24

openshift-ci Bot removed the lgtm label Aug 14, 2026

slagle force-pushed the heat branch from 4b7f44b to 6ec40e8 Compare August 14, 2026 14:25

elfiesmelfie requested changes Aug 17, 2026

View reviewed changes

openshift-ci Bot assigned elfiesmelfie Aug 17, 2026

slagle force-pushed the heat branch 7 times, most recently from f77aa64 to 77899b5 Compare August 17, 2026 20:46

slagle force-pushed the heat branch from 77899b5 to 7638a4f Compare August 18, 2026 16:25

slagle force-pushed the heat branch from 7638a4f to 4378d4f Compare August 18, 2026 18:57

elfiesmelfie mentioned this pull request Aug 18, 2026

TEST Use s2i images infrawatch/feature-verification-tests#424

Open

rabi reviewed Aug 19, 2026

View reviewed changes

slagle force-pushed the heat branch from 4378d4f to 041f0b5 Compare August 19, 2026 13:31

slagle force-pushed the heat branch from 041f0b5 to 6946c47 Compare August 19, 2026 13:39

openshift-ci Bot assigned rebtoor Aug 19, 2026

openshift-ci Bot added the lgtm label Aug 19, 2026

rebtoor requested review from amoralej and elfiesmelfie August 19, 2026 15:10

amoralej approved these changes Aug 19, 2026

View reviewed changes

openshift-ci Bot assigned amoralej Aug 19, 2026

openshift-ci Bot added the approved label Aug 19, 2026

elfiesmelfie requested changes Aug 19, 2026

View reviewed changes

openshift-ci Bot removed the lgtm label Aug 19, 2026

slagle force-pushed the heat branch from 6946c47 to 32d5883 Compare August 19, 2026 16:54

slagle force-pushed the heat branch from 32d5883 to 913a6ff Compare August 19, 2026 17:00

elfiesmelfie approved these changes Aug 19, 2026

View reviewed changes

openshift-ci Bot added the lgtm label Aug 19, 2026

openshift-merge-bot Bot merged commit fd2bb69 into openstack-k8s-operators:main Aug 19, 2026
6 of 7 checks passed

slagle mentioned this pull request Aug 20, 2026

Heat S2I: Consolidate CFN API into API image openstack-k8s-operators/openstack-operator#2043

Draft

		RUN chmod 640 /etc/heat/heat.conf /etc/heat/api-paste.ini && \
		chown -R heat:heat /etc/heat /usr/share/heat

	RUN chmod 640 /etc/heat/heat.conf /etc/heat/api-paste.ini && \
	chown -R heat:heat /etc/heat /usr/share/heat
	RUN chown -R heat:heat /etc/heat /usr/share/heat

Uh oh!

Conversation

slagle commented Aug 13, 2026 • edited by openshift-ci Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yazug left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rabi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

amoralej commented Aug 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

amoralej commented Aug 14, 2026

Uh oh!

slagle commented Aug 14, 2026

Uh oh!

amoralej commented Aug 14, 2026

Uh oh!

rabi commented Aug 17, 2026

Uh oh!

rabi commented Aug 17, 2026

Uh oh!

amoralej commented Aug 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slagle commented Aug 17, 2026

Uh oh!

slagle commented Aug 17, 2026

Uh oh!

rabi commented Aug 18, 2026

Uh oh!

slagle commented Aug 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slagle commented Aug 13, 2026 •

edited by openshift-ci Bot

Loading

amoralej commented Aug 14, 2026 •

edited

Loading

coderabbitai Bot commented Aug 19, 2026 •

edited

Loading