Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Allow usage of unique Kubernetes namespace annotation for Argo Workflows #6

Open
1 task done
zgastley opened this issue Jul 8, 2024 · 1 comment
Open
1 task done
Labels
enhancement New feature or request

Comments

@zgastley
Copy link

zgastley commented Jul 8, 2024

Have you searched for this feature request?

  • I searched but did not find similar requests

Problem Statement

Currently, the Argo Workflows plugin will utilize the backstage resources backstage.io/kubernetes-namespace annotation if present. This presents an issue with the Backstage Kubernetes plugin if the two do not share the same namespace target.

To be more specific, my organization uses shared namespaces for certain workflows - ie, all docker build steps for building and pushing an image to our artifact repo runs in the build-workflows namespace. However, the k8s resources are within a namespace named after the application itself.

Since the plugin will default to the default namespace if this annotation is omitted, we have to include it. But, once we include it, the k8s plugin will try to use the namespace for item look-up. This means essentially only one of these two things can configured correctly if they do not use the same namespace.

Possible Solution

if we simply add a new annotation config named something like argo-workflows.cnoe.io/argo-workflows-namespacethe plugins can stop sharing. I have started looking at the code on my local to see if this is as straightforward as it feels. I do not mind submitting a PR myself.

Alternatives Considered

No response

@zgastley zgastley added the enhancement New feature or request label Jul 8, 2024
@nimakaviani
Copy link
Contributor

thanks @zgastley for the suggestion. this sounds good to me. We can keep the other annotation too but add a new one for when conflicts arise. should be a fairly easy PR. looking forward to your contribution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants