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

Separating "tekton-pipelines" and "tekton-pipelines-resolvers" manifests. #5931

Open
michaelsatish opened this issue Dec 29, 2022 · 20 comments
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@michaelsatish
Copy link

Hi,

Creating this issue to request the separation of "tekton-pipelines" and "tekton-pipelines-resolvers" manifests with each release.

kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.43.0/release.yaml
kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.43.0/resolvers.yaml

I am using the Flux Kustomize controller to deploy Tekton Pipeline and running into kustomize namespace confliction.

Error: namespace transformation produces ID conflict

This does not work

apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: tekton-pipelines
spec:
  interval: 10m0s
  prune: true
  wait: true
  force: true
  path: ./infrastructure/tekton/pipelines
  sourceRef:
    kind: GitRepository
    name: flux-system
    namespace: flux-system

The directory ./infrastructure/tekton/pipelines has the pipeline release file.

  1. release.yaml
  2. kustomization.yaml

This works

apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: tekton-pipelines
spec:
  interval: 10m0s
  prune: true
  wait: true
  force: true
  path: ./infrastructure/tekton/pipelines
  sourceRef:
    kind: GitRepository
    name: flux-system
    namespace: flux-system
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: tekton-pipelines-resolvers
spec:
  interval: 10m0s
  prune: true
  wait: true
  force: true
  path: ./infrastructure/tekton/pipelines-resolvers
  sourceRef:
    kind: GitRepository
    name: flux-system
    namespace: flux-system

The directory ./infrastructure/tekton/pipelines has the pipeline release file and the directory ./infrastructure/tekton/pipelines-resolvers has the resolvers file.

@AlanGreene
Copy link
Member

This was originally the case but they were combined before release, see #5607 for previous discussion.
@abayer fyi

@michaelsatish
Copy link
Author

@abayer Is it possible to revert the decision to include the resolvers with the pipeline manifest and provide pipeline and resolvers separately with future releases?

Unfortunately I cannot use the Tekton operator as there is no support to provide images from a Private repo.

@vdemeester
Copy link
Member

@michaelsatish if the resolvers where to live in the same namespace as the rest of the pipeline payload (aka in tekton-pipelines), would it work ?

@michaelsatish
Copy link
Author

@vdemeester Thank you. That will work for me.

@vdemeester
Copy link
Member

@michaelsatish ok so the real problem is that we "ship" 2 namespaces in the same release.yaml 🤔

@michaelsatish
Copy link
Author

I think kustomize will not handle a manifest file having 2 kind of type namespace. See this kubernetes-sigs/kustomize#3156

@samip5
Copy link

samip5 commented Feb 18, 2023

Just hit this issue with Flux and kustomize cli.

error: accumulating resources: accumulation err='accumulating resources from 'pipelines': '/home/sky/Github/k8s-cluster/cluster/apps/ci/tekton/app/pipelines' must resolve to a file': recursed accumulation of path '/home/sky/Github/k8s-cluster/cluster/apps/ci/tekton/app/pipelines': namespace transformation produces ID conflict: [{"apiVersion":"v1","kind":"Namespace","metadata":{"annotations":{"internal.config.kubernetes.io/previousKinds":"Namespace","internal.config.kubernetes.io/previousNames":"tekton-pipelines","internal.config.kubernetes.io/previousNamespaces":"_non_namespaceable_"},"labels":{"app.kubernetes.io/instance":"default","app.kubernetes.io/part-of":"tekton-pipelines","pod-security.kubernetes.io/enforce":"restricted"},"name":"tekton-pipelines"}} {"apiVersion":"v1","kind":"Namespace","metadata":{"annotations":{"internal.config.kubernetes.io/previousKinds":"Namespace","internal.config.kubernetes.io/previousNames":"tekton-pipelines-resolvers","internal.config.kubernetes.io/previousNamespaces":"_non_namespaceable_"},"labels":{"app.kubernetes.io/component":"resolvers","app.kubernetes.io/instance":"default","app.kubernetes.io/part-of":"tekton-pipelines","pod-security.kubernetes.io/enforce":"restricted"},"name":"tekton-pipelines"}}]

@danmanners
Copy link

I'm running into this in my homelab as well with both ArgoCD. Having the single file breaks any GitOps tooling I've tested so far.

Genuine question: was #5607 QA tested with any GitOps tools like Flux or ArgoCD? This should/would have immediately failed.

@vdemeester
Copy link
Member

@michaelsatish @samip5 same question I asked @danmanners on #5607 (comment).

do you have an example of how one deploys Tekton Pipelines witsh Fluy or ArgoCD (aka the Application or other CRD used and the possible layout of a repo or something) ?

I want to understand how we can solve this, and if this is solvable independently of the release.yaml or not.

@michaelsatish
Copy link
Author

@vdemeester

Here is a simplified repo structure.

├── clusters
│   ├── dev
│   │   ├── infrastructure.yaml
├── infrastructure
│   ├── tekton
│   │   ├── pipelines
│   │   │   ├── release.yaml

The path ./infrastructure/tekton/pipelines has the release.yaml file.

The file ./clusters/dev/infrastructure.yaml has the flux CRD "kustomization". The flux source and kustomization controllers reconciles any changes in path ./infrastructure/tekton/pipelines

apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: tekton-pipelines
spec:
  interval: 10m0s
  prune: true
  wait: true
  force: true
  path: ./infrastructure/tekton/pipelines
  sourceRef:
    kind: GitRepository
    name: flux-system
    namespace: flux-system

Hope this helps.

@vdemeester
Copy link
Member

vdemeester commented Feb 21, 2023

@michaelsatish and infrastructure/tekton/pipelines can hold a kustomization.yaml or will it take any yaml from it ? 🤔
(I should read the documentation to be fair 🙃 )

@michaelsatish
Copy link
Author

@vdemeester My apologies I do have a kustomization.yaml, I was lazy. Having said that flux does auto create kustomization.yaml if it is missing.

https://fluxcd.io/flux/components/kustomize/kustomization/#generate-kustomizationyaml

If your repository contains plain Kubernetes manifests, the kustomization.yaml file is automatically generated for all the Kubernetes manifests in the directory tree specified in the spec.path field of the Flux Kustomization

@vdemeester
Copy link
Member

@michaelsatish ok thanks, it should help me 👼🏼 .

@jwitrick
Copy link

jwitrick commented Mar 2, 2023

Please either put the resolvers into the same namespace (I dont like using a bunch of different namespaces for the same tool anyway) or re-split the files.

@aw185176
Copy link

Please either put the resolvers into the same namespace (I dont like using a bunch of different namespaces for the same tool anyway) or re-split the files.

Echoing. Single manifest file + multiple Namespaces = break tons of existing workflows around Kustomize.

@tekton-robot
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

@tekton-robot tekton-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 9, 2023
@tekton-robot
Copy link
Collaborator

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

@tekton-robot tekton-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Sep 8, 2023
@tekton-robot
Copy link
Collaborator

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

@tekton-robot
Copy link
Collaborator

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@github-project-automation github-project-automation bot moved this from Todo to Done in Tekton Community Roadmap Oct 8, 2023
@vdemeester vdemeester reopened this Oct 9, 2023
@github-project-automation github-project-automation bot moved this from Done to In Progress in Tekton Community Roadmap Oct 9, 2023
@vdemeester
Copy link
Member

/lifecycle frozen

@tekton-robot tekton-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. labels Oct 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
Status: In Progress
Development

No branches or pull requests

8 participants