Automatically configure global build strategy #723
Conversation
nicolaferraro
force-pushed
the
703-global-operator
branch
2 times, most recently
from
e71e1f3
to
10f212c
Compare
nicolaferraro
changed the title
|
I've skipped warming phase when the operator is global and I'm not setting builder affinity with the operator. Builder and Publisher, instead are linked by affinity, because they need to share their RWO volume. Publisher can bind to operator or builder pod depending on the config (not sure if we still can use Tested in global configuration in openshift and minikube. |
|
I feel more and more that we must spend some time improving the integration tests, because we need to make sure that all deployment configuration work... |
|
Awesome work! I agree the combinatory of use cases may become unsustainable without integration tests! |
|
Should we update the OLM manifest now in preparation of the next release? I just fear we forget to add the cluster-wide permissions for that new installation mode. |
|
I'll do some tests with that. I was thinking we can add a SNAPSHOT CSV that we keep aligned with latest changes and change it to stable during release. |
I agree, that'd be the best approach. |
nicolaferraro
force-pushed
the
703-global-operator
branch
from
7f092e2
to
aa25cd7
Compare
|
No need to set cluster level permissions, OLM creates a clusterrole if you install it for all namespaces. Tested on OCP4 in both local and global mode ;) |
|
Will open another issue to refactor the different roles... |
Somehow, I hoped it would for a few seconds when I reviewed the PR, otherwise, that would have meant each operator had to define the majorant of all the required roles for all the install modes. So that is a good news. |
May be similar to #516. |
|
If this gets into master, I'll try to cut 0.3.4 today. |
Fix #703
This works on OpenShift. I'm checking Kubernetes.