I am testing this on a RHOSO environment with octavia where `amphoraImageContainerImage` was set to `registry-proxy.engineering.redhat.com/rh-osbs/rhoso18-octavia-amphora-image:18.0.1-2` when the controlplane was initially configured. The amphora images had been properly created.

TEST 1

Then, I removed from glance the amphora images:

sh-5.1$ openstack image delete octavia-amphora-fips-18.0-20240904.1.x86_64 octavia-amphora-vert-fips-18.0-20240904.1.x86_64

On one tmux pane I run: 

watch -d oc wait -n openstack --timeout=180s --for=condition=OctaviaAmphoraImagesReady octavia.octavia.openstack.org/octavia

On another tmux pane I edit the controlplane CR with `oc edit` and set :

amphoraImageContainerImage: ""

On another tmux pane I was monitoring this:

[zuul@controller-0 ~]$ watch -d 'oc get oscp controlplane; echo; oc -n openstack get pods | grep -v Completed | grep octavia'

And I observed:

1. controlplane state changed from "Setup complete" to "Octavia in progress" for a few seconds and finally to "Setup complete" again.
2. No extra octavia pod was spawned
3. OctaviaAmphoraImagesReady condition is True during all this process

This seems ok to me because no images needed to be uploaded for this octavia config change.

TEST 2

I edit the controlplane CR with `oc edit` and set :

amphoraImageContainerImage: quay.io/gthiemonge/octavia-amphora-image

I observed:

1. The controlplane status changes to "Octavia in progress" for some seconds and back to "Setup complete" soon.
2. An "octavia-image-upload" pod starts running and uploads an "octavia-amphora-x64-haproxy-centos-9-stream" to glance. That pod disappears once the image status is set to "active"
3. During the whole process, the  OctaviaAmphoraImagesReady condition remains True.

IMO, point 3 from TEST 2 is wrong and that conddition should be set to False when a change in the value of amphoraImageContainerImage is detected (and the process to upload an amphora image to glance starts) and it should be false until the amphora image is set to "active"