This issue is supposed to provide some clarity on how the rapiDAST team will migrate to another gitops repo.
This migration should look similar to the aggregate changes of these two prs: the infra changes, and operator deployment. The following is a list of the files introduced in the PR and how these kubernetes resources map to changes in Gitops:
ignore other changes in that cluster-scope/overlays/prod/moc/smaug/kustomization.yaml file, they are just alphabetically sorting the bundles already deployed to the cluster
the CatalogSource for the rapidast operator (file)
the OperatorGroup for the rapdiast namespace in which the operator will be deployed (file)
the Subscription to the rapidast operator using above CatalogSource and OperatorGroup (file)
Modifications to the kustomization overlay that deploys those 3 resources to the Smaug cluster (file)
Our argocd cluster-resources-smaug application watches the Smaug kustomization overlay (operate-first/apps/cluster-scope/overlays/prod/moc/smaug/kustomization.yaml). It builds and deploys everything in this file, as well as what it builds from the MOC common overlay (operate-first/apps/cluster-scope/overlays/prod/moc/common/kustomization.yaml), because it is referenced from the kustomization overlay. Between these two overlays that get built, all the changes in git from those 2 PRs get picked up by our Argocd Applications and deployed to the openshift cluster.
Gregory-Pereira
commented
1 year ago
This issue is supposed to provide some clarity on how the rapiDAST team will migrate to another gitops repo.
This migration should look similar to the aggregate changes of these two prs: the infra changes, and operator deployment. The following is a list of the files introduced in the PR and how these kubernetes resources map to changes in Gitops:
The first PR:
psse-research grouprapidast namespacewith amediumResourceQuota and a project admin rolebinding for that ns (namespace file)project admin rolebindingfor the namespace (applies rbac for group to ns)cluster-scope/overlays/prod/moc/smaug/kustomization.yamlfile, they are just alphabetically sorting the bundles already deployed to the clusterThe second PR:
CatalogSourcefor the rapidast operator (file)OperatorGroupfor the rapdiast namespace in which the operator will be deployed (file)Subscriptionto the rapidast operator using aboveCatalogSourceandOperatorGroup(file)Our argocd
cluster-resources-smaugapplication watches the Smaug kustomization overlay (operate-first/apps/cluster-scope/overlays/prod/moc/smaug/kustomization.yaml). It builds and deploys everything in this file, as well as what it builds from the MOC common overlay (operate-first/apps/cluster-scope/overlays/prod/moc/common/kustomization.yaml), because it is referenced from the kustomization overlay. Between these two overlays that get built, all the changes in git from those 2 PRs get picked up by our Argocd Applications and deployed to the openshift cluster.