Open mcbenjemaa opened 2 years ago
+1
Another use case:
If someone uses the PR generator & Git generator against the same Kustomize overlay, they may wish to patch
the PR generator's Deployment name so that the PR container can be deployed alongside the normal container and otherwise use the same Service, ServiceAccount, etc.
Currently you can do this by passing nameSuffix
to the PR generator. But then, you duplicate all the other resources too. Including the Service, ServiceAccount, etc.
Another use case is to use kustomize to change ingress host which is currently not possible without a patch (https://github.com/kubernetes-sigs/kustomize/issues/347). For example:
$ cat ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test
spec:
rules:
- host: test.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: test
port:
name: http
$ cat kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ingress.yaml
patches:
- target:
kind: Ingress
name: test
patch: |
- op: replace
path: /spec/rules/0/host
value: new-host.example.com
$ kustomize build
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test
spec:
rules:
- host: new-host.example.com
http:
paths:
- backend:
service:
name: test
port:
name: http
path: /
pathType: Prefix
Note: Ingress host test.example.com
was replaced with new-host.example.com
.
Similar usecase to @r0bj, I would like to add annotations to existing objects.
Adding a field to ApplicationSourceHelm so that kustomize users get the benifet of using it to apply patches.
I think I'd wanna do this at the top level so you can apply patches to more than just Helm sources.
I could imagine something like this, basically borrowing patches
from Kustomize:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: myapps
spec:
generators:
- pullRequest:
github:
owner: myorg
repo: myrepository
template:
spec:
patches:
- target:
kind: Ingress
patch: |-
- op: replace
path: /spec/rules/0/host
value: '{{branch}}.example.com'
PoC of that ^ https://github.com/argoproj/argo-cd/pull/14648
And a similar feature at the ApplicationSet instead of the Application level: https://github.com/argoproj/argo-cd/pull/14893
Fixed by the #14648 and #14893 ?
@joebowbeer not exactly, I misspoke in my comment above saying #14646 was a PoC of my proposed spec. I think OP wants the patches to be able to apply to any source type, not just kustomize. Similar request here: https://github.com/argoproj/argo-cd/issues/16352
This feature would help a lot!
+1 will be happy to see patch in provider
Would love to see the patches
field on an Application
pointing to a Helm chart for its source.
Summary
What change you think needs making.
A new patching approach for arogcd Application with kustomize.
Motivation
Please give examples of your use case, e.g. when would you use this.
Managing many platforms that essentially use almost the same applications is somehow cumbersome with apps of apps pattern or via a helm chart. (We want to avoid DRY as mush as possible!) Using kustomize to build a common base for all platforms is really better and consistent. All our members should know the Application manifests very well, and thus can apply patches more easily.
Proposal
How do you think this should be implemented?
Adding a field to
ApplicationSourceHelm
so that kustomize users get the benifet of using it to apply patches.Check my demo repo: https://github.com/mcbenjemaa/argocd-apps