KFLUXINFRA-554: Konflux Components for EaaS Clusters #3659
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: manish-jangra The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| apiVersion: kustomize.config.k8s.io/v1beta1 | ||
| kind: Kustomization | ||
| resources: | ||
| - environment.yaml |
There was a problem hiding this comment.
need to add this component to support local deployment from a fork in the future:
components:
- ../../k-components/inject-infra-deployments-repo-details
(maybe the path to the component is incorrect, try it before committing)
| apiVersion: kustomize.config.k8s.io/v1beta1 | ||
| kind: Kustomization | ||
| resources: | ||
| - ../../base/all-clusters |
There was a problem hiding this comment.
don't you need to include the new environment kustomization dir?
There was a problem hiding this comment.
changed approach a little bit, please check now
| @@ -0,0 +1,48 @@ | |||
| --- | |||
| apiVersion: argoproj.io/v1alpha1 | |||
There was a problem hiding this comment.
Why do you delete the monitoring components? do you plan to add them in a following pr?
There was a problem hiding this comment.
We're planning to set them up later (RHTAPWATCH-915).
manish-jangra
force-pushed
the
KFLUXINFRA-554
branch
from
2d21259
to
d74b465
Compare
There was a problem hiding this comment.
Before I comment on the PR, I need to make sure I understand the goal of the change.
Currently, prior to this change, we have the kflux-stg-ea01 cluster connected to konflux-public-staging ArgoCD instance. The all-application-sets in that ArgoCD instance already create some application for that cluster: https://argocd-server-konflux-public-staging.apps.appsres05ue1.pwhm.p1.openshiftapps.com/applications/konflux-public-staging/all-application-sets?view=tree&resource=
It created the applications that are common to all clusters.
This change is adding another overlay so is the plan to create a separate ArgoCD instance? if yes then we will need 3 flavors of the overlay, dev, staging and prod.
The other option is to deploy the eaas cluster from the same ArgoCD instance as kflux.
I need to understand the goal, i.e. if separate ArgoCD or same before commenting on the PR.
There was a problem hiding this comment.
IMO we should use our existing Argo instances. I don't see a reason to create new ArgoCD instances ATM.
There was a problem hiding this comment.
@gbenhaim I was thinking the same. Then we do not need a new ApplicationSet in a new overlay IIUC. All we need is to make sure that application that are deployed on all clusters are trimmed down to what we actually need on all cluster(all clusters is no longer host and member only, it includes EAAS).
The list of application we deploy to all cluster currently is this one:
- authentication
- backup
- cluster-secret-store
- disable-csvcopy-for-all-cluster
- external-secrets-operator
- kubesaw-common
- monitoring-workload-grafana
- monitoring-workload-logging
- monitoring-workload-prometheus
The only ones I see we do not need on EAAS are backup and kubesaw-common. All we have to do it to remove them from all-clusters and deploy them on member and host.
WDYT?
There was a problem hiding this comment.
What's the impact of omitting kubesaw-common? I suspect we may need it because the EaaS clusters will be configured with a SpaceProvisionerConfig and a new cluster role. Namespaces on the EaaS clusters will be provisioned using SpaceRequests in the appstudio tiers on the member clusters (see the ADR).
There was a problem hiding this comment.
for now kubesaw-common is needed where host and member toolchain operators are deployed so if we need to deploy one of those on the EAAS cluster, then it can stay in the applications common to all clusters
There was a problem hiding this comment.
@hugares thanks for the explanation. I think we should keep kubesaw-common here then.
There was a problem hiding this comment.
only backup was excluded, see #3675
| patch: |- | ||
| - op: replace | ||
| path: /spec/source/path | ||
| value: argo-cd-apps/overlays/environment |
There was a problem hiding this comment.
Using environment for the overlay name is likely to generate some confusion. It's an overloaded term when our other overlays are named after deployment environments (e.g. development, production-downstream). Maybe we should use eaas unless someone else has a better suggestion.
Also, should this name include a -downstream postfix in case we create an equivalent public overlay later?
There was a problem hiding this comment.
This change can be closed now, here is the replacement: #3675
|
PR needs rebase. 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-sigs/prow repository. |
This pull request will take care of deploying Konflux Components on EaaS Clusters. Not all Konflux components qualify to be deployed on EaaS Clusters.