Ability to Override httpCustomErrorCodePages in ClusterDeployment about hive HOT 7 CLOSED

@MuneebAijaz Sure, we would be happy to work with you on this. It should be pretty straightforward:

• Add the field to the ClusterIngress struct in clusterdeployment_types.go
• Run make update vendor to regenerate CRDs and the vendored copy of the API
• Add the code in remoteingresscontroller.go that parlays the new field into the IngressController object
• Add unit tests to remoteinrgess_controller_test.go to verify ⬆️
• Test in a real cluster to make sure it does what you want.

from hive.

Hive does not create syncsets for anything by default; this is clearly coming from somewhere else. You may be able to figure out where by looking at managed fields:

oc get sss $name -o yaml --show-managed-fields

Also noteworthy is that the clustersync controller will apply syncsets in ascending alpha name order; so you may be able to work around this by naming your patch z-default-ingress-controller-patch or similar.

from hive.

The above mentioned SyncSet is created by Hive itself. That causes our patch to be overwritten.
We are providing custom TLS certificates for the spoke and that therefore creates ClusterIngress SyncSet.
Even if we change the name with z-default-ingress-controller-patch on every reconcile it will try to change the same resource two times causing the ingress pod roll-out to happen twice

from hive.

Okay, I found the code that creates the SyncSet when CD.Spec.Ingress is specified.

Also let me correct/clarify my statement about ordering: We apply in alpha order, but we apply all SyncSets first; then all SelectorSyncSets. So the rename wouldn't have made a different in your case -- your SSS would have been applied last anyway.

causing the ingress pod rollout to happen twice

While not ideal, does this actually cause a problem? I ask because...

I can see where we would be able to add HttpErrorCodePages to our Ingress API and get it funneled through to the IngressController. I've opened HIVE-2040 to put that on our radar. However, our belt is pretty tight for feature work at the moment, so it may be a while before we can get to it.

Out of curiosity, how are you consuming/installing hive? From OperatorHub? Via ACM or MCE? Directly from the repo?

from hive.

While not ideal, does this actually cause a problem? I ask because...

SyncSet applies hives default values,

httpErrorCodePages:
        name: ''

Our SelectorSyncSet applies custom values,

  httpErrorCodePages:
       name: saap-error-pages

So both of these conflict with each other on every reconcile, which constantly make our pod and configmap recreate.

Out of curiosity, how are you consuming/installing hive? From OperatorHub? Via ACM or MCE? Directly from the repo?

Via ACM

from hive.

Thanks for the responses. Are you able to (create a Jira account and) follow the card? We don't track issues in GH so I'd like to close this one.

from hive.

Hi, @2uasimojo , I would like to work on this. Are you accepting community PRs for hive?

from hive.