Originally this was investigated as a part of the artemiscloud issue#17 where a logged error was noted if the credentials secret was pre-existing on startup of the operator. This would occur in the case where a broker deployment was previously created in the namespace and then the operator had to restart for some reason.

After investigating more fully it appears that at the point in time when the error is logged the operator stays in the creatingk8sresources state and does not move to it's regular processing state 'containerrunning' even though there are broker pods running. As a result updates are not processed correctly at this point in time.

I began work on it on a branch however that work is incomplete at the moment.

As indicated in the affects versions I suspect this behaviour was introduced in the 7.6.0 broker product release where new functionality was introduced to handle upgrades and the overall startup flow was updated.