Paul Richardson
Paul Richardson
Thanks @joelanford. That is really interesting. Am looking into your suggestions and will keep an eye on how this progresses.
So, the changes should not be committed. 1. The changes are transient to the kustomization config files 2. A user is able to make use of these files without using...
Can this be closed as asked and answered?
@tadayosi Would appreciate your views on this please.
The reason lies in the use of OLM (or not upstream). Upstream, the tests install the operator without OLM and therefore adds the correct operatorID (the test uses "[camel-k-kamelet](https://github.com/apache/camel-k/blob/main/e2e/global/common/kamelet_test.go#L36)"). So...
> I don't think so. For upstream global e2e testing, `KamelInstallWithOperatorID()` also omits the operator ID so the IntegrationPlatform should be always `camel-k`: https://github.com/apache/camel-k/blob/main/e2e/support/test_support.go#L246 This is my bad explanation. From...
> OLM has a feature where the operator controller can stamp out a `OperatorCondition` object to tell OLM to not update it right now (even if update policy is set...
Having tested the use of the upgradeable `operationcondition`, I've found that this does not function in the way I thought it would. When `7.10.2` of our operator is installed, I...
Asked and answered so closing.
This is where the olm upgrade tests starts the upgrade -> https://github.com/apache/camel-k/blob/main/e2e/namespace/upgrade/olm_upgrade_test.go#L120