fix: remove conflicting tls proxy secret generator. #567
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The issue resolved by this Pull Request:
Resolves https://issues.redhat.com/browse/RHOAIENG-2798
Description of your changes:
This solves a race condition that existed because of a workaround we've implemented. KFP exposes a service that is backed by the apiserver pod. In Data Science Pipelines, we want this service name to be dynamic --
ds-pipeline-{ DSPA NAME }}
. In KFP v2, the running pipeline pods call back to the apiserver via its service, and they rely on the hardcoded service name ofml-pipeline
(kubeflow/pipelines#9689). To temporarily work around this hardcoding, we're exposing both services -- our dynamically-named one and the hardcodedml-pipeline
one. (Both services point to the same apiserver pod.)We use the OpenShift service ca operator to generate certs which we mount into the oauth proxy sidecar for the apiserver. This cert generation is triggered by an annotation on the service. When we created the yaml for the hardcoded
ml-pipeline
duplicate service, we mistakenly duplicated the annotation as well. This caused a race condition where sometimes the OpenShift service ca operator would see theml-pipeline
service first, causing our dynamically-named service to be in error state (message:secret dspa-master/ds-pipelines-proxy-tls-{dspa-name} does not have corresponding service UID
). The workaroundml-pipeline
service doesn't need the annotation, so we just remove it here.see https://issues.redhat.com/browse/RHOAIENG-2798 for more details
Testing instructions
ds-pipelines-proxy-tls-sample
ensure the owner of this secret is the service namedds-pipeline-<dspa_name>
ml-pipeline
service is utilized by actual pipeline executions (due to hardcoded names in upstream kfp) so run one or two to confirm these remain unaffected, they should run to completion successfully (assuming no user code errors)Checklist