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

Unable to reference an existing Jenkins CR in a different namespace #922

Closed
valenca opened this issue Oct 27, 2023 · 6 comments
Closed

Unable to reference an existing Jenkins CR in a different namespace #922

valenca opened this issue Oct 27, 2023 · 6 comments
Labels
bug Something isn't working good first issue Good for newcomers stale

Comments

@valenca
Copy link

valenca commented Oct 27, 2023

Describe the bug
When setting the jenkins.enabled configuration to false (i.e. telling the operator to look at an existing Jenkins CR, as opposed to creating a new one from the values), we can no longer set the namespace, as it will read the operator's metadata to compute the Jenkins namespace.

To Reproduce
Create a Jenkins CR in namespace "jenkins"
Install the jenkins operator in the namespace operators, with jenkins.enabled = false and jenkins.namespace = jenkins. It will not be able to find the Jenkins CR in the jenkins ns, and will idle waiting for one in the operator namespace.

Additional information
It was introduced by this commit, specifically:
1b6e944

Kubernetes version:
Jenkins Operator version:
0.8.0

Workaround:
Since we are deploying the operator with kustomize, we can do a post-render step to change the WATCH_NAMESPACE operator env var:

  postRenderers:
  - kustomize:
      patchesStrategicMerge:
        - kind: Deployment
          apiVersion: apps/v1
          metadata:
            name: jenkins-jenkins-operator
          spec:
            template:
              spec:
                containers:
                  - name: jenkins-operator
                    env:
                      - name: WATCH_NAMESPACE
                        $patch: delete
        - kind: Deployment
          apiVersion: apps/v1
          metadata:
            name: jenkins-jenkins-operator
          spec:
            template:
              spec:
                containers:
                  - name: jenkins-operator
                    env:
                      - name: WATCH_NAMESPACE
                        value: jenkins

It's always possible to change the deployment directly, but as far as we tried, it wasn't possible to do it within the values.yaml file.

@valenca valenca added the bug Something isn't working label Oct 27, 2023
@brokenpip3 brokenpip3 added the good first issue Good for newcomers label Oct 27, 2023
@brokenpip3
Copy link
Collaborator

brokenpip3 commented Oct 27, 2023

yeah make sense, should be an easy helm chart fix, do you want to try to make a PR?

@brokenpip3
Copy link
Collaborator

(this commit 1b6e944 is necessary for the kubectl apply manifest installation option that we have)

@valenca
Copy link
Author

valenca commented Oct 27, 2023

I'd be happy to help, I'm just not sure of all the ramifications. I assume that just removing the {{- if .Values.jenkins.enabled }} will have ill effects on some cases, like the kubectl apply manifest you mention.

What would be the approach here? Add a new parameter to the operator CRD that reads from there instead?

@brokenpip3
Copy link
Collaborator

brokenpip3 commented Oct 27, 2023

No I think that this should be resolved at helm chart level only, something like adding a watched-namespace key here:

and adding the proper if logic in the operator deployment, wdyt?

@valenca
Copy link
Author

valenca commented Oct 27, 2023

Ah right. I don't know why I mentioned the CRD, I meant exactly that, the operator object in the values. I'll see what I can do.

@valenca
Copy link
Author

valenca commented Oct 27, 2023

#923 Here we go. I'm not entirely sure if I can manage any test implementation nor if the PR text is as expected. It's been a while since I contributed to open source :P

@github-actions github-actions bot added the stale label Dec 27, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 7, 2024
@brokenpip3 brokenpip3 removed the stale label Jan 7, 2024
@brokenpip3 brokenpip3 reopened this Jan 7, 2024
@github-actions github-actions bot added the stale label Mar 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers stale
Projects
None yet
Development

No branches or pull requests

2 participants