operate-first / argocd-apps Goto Github PK

We now have a situation where one argocd app is deploying manifests for 2 different environments (infra/cnv), but both these environments may want to consume from the same base, which could yield conflicting application names (hence CR names), this is obviously a conflict that cannot occur. This is an inherent flaw with the design of using base/overlays for this purpose, so we may want to re-consider that format for this repo. Thoughts?

Namespace: opf-monitoring
Destination cluster: in-cluster
Project: operate-first

Hi

from PR #148 we changed the path with the manifests to apply , but if I look in ArgoCD our app still points to the old manifests path

is there some step we are missing?

I think these docs here are a bit confusing, and not clear. We should also note that if you're adding only to a specific environment you'll need to include the full manifest and provide examples. (Related)

The example Grafanadatasource in operate-first/apps was not synced by ArgoCD

The tekton pipelinerun and taskrun are to be excluded from the argocd resources. As these contents are generated dynamically, these resources would explode tekton based application on argocd deployment.

- apiGroups:
  - "tekton.dev"
  kinds:
  - "PipelineRun"
  - "TaskRun"
  clusters:
  - "*"

See for example: https://argocd-server-argocd.apps.cnv.massopen.cloud/applications/prod-thoth-solver?operation=false

• Add any supplementary documentation to aid with the process.
• Also add the process for gaining access to ArgoCD projects

Should point to this path: https://github.com/operate-first/odh/tree/master/kfdef/jupyterhub

Namespace: opf-jupyterhub
Destination cluster: in-cluster
Project: operate-first

Let's sync ArgoCD via ArgoCD to avoid manual deployments of it.

These workshops use ephemeral clusters, and once the workshop is done they are brought down and we will clean up these cluster secrets. We should consider how to properly clean these workshops up from ArgoCD, a good example are all the user# apps currently existing in live state.

Instructions on how to make a PR like the one here

I don't see any real benefit to having argocd-apps be its own separate repo. It's also annoying making 2 prs everytime a new app is added. WDYT about moving this repo's contents to root folder of apps in an argocd-apps folder?

Context: Currently the ArgoCD setup does fully work in MOC settings only. The Applications are deployable to all the downstreams, yet they are required to be deployed to projects which don't exist in these downstream deployments.

#36 (comment)

Outcome:
Ensure that any app can be successfully deployed to other downstreams without any ops related blocker

The application is erroring out as the resource WorkflowTemplate is not allowed.
May be it has to be included in https://gitlab.com/open-infrastructure-labs/moc-cnv-sandbox/-/blob/master/manifests/argocd/overlays/prod/projects/thoth.yaml

I wonder, can we move the app of apps to the argocd-apps repo? So adding a cluster would be only PRs against 2 repos, instead of 3?

Originally posted by @tumido in operate-first/apps#419 (comment)

Right now it's not that straightforward to add a new cluster to ArgoCD. 3 PRs are minimal. If we can remove once step, it would be a huge improvement.

after Harshad fixed my proken #37 by merging #41 the app is not being deployed. and I cant see it at https://argocd-server-argocd.apps.cnv.massopen.cloud/applications

any hints?

/kind bug
/label sig/devops
Related-To: #34

the third link on https://github.com/operate-first/argocd-apps/blob/main/docs/onboard_team_to_argocd.md is outdated... ;)

/kind bug

This should be created here

All the apps here

Notable larger apps: cluster-resources and kfdefs

As an Application Owner/Project-specific DevOps,
I want to get access to ArgoCD Web UI
so that I can see the status of my deployments

ssia

/kind feature
/label sig/devops
/priority important-soon
/assign @harshad16
/assign @goern