nephio-controllers: remove dependency on Gitea

nephio-project / nephio

Nephio is a Kubernetes-based automation platform for deploying and managing highly distributed, interconnected workloads such as 5G Network Functions, and the underlying infrastructure on which those workloads depend.

Apache License 2.0

103 stars 53 forks source link

nephio-controllers: remove dependency on Gitea #357

Closed johnbelamaric closed 11 months ago

johnbelamaric commented 1 year ago

/sig automation

debeaueric commented 1 year ago

Important to avoid deploying Gitea while we can use existing GitLab or GitHub. Porch is working fine with GitLab and GitHub.

vjayaramrh commented 1 year ago

Using the link at https://github.com/nephio-project/test-infra/blob/main/e2e/provision/playbooks/cluster.yml as a starting point to understand the sandbox install flow and gitea install flow(cc: @rravindran123 ). Other useful and relevant links to understand flow are at i)https://github.com/nephio-project/test-infra/blob/main/e2e/provision/playbooks/roles/bootstrap/README.md ii)https://github.com/nephio-project/test-infra/blob/main/e2e/provision/playbooks/roles/install/README.md

vjayaramrh commented 12 months ago

As a next step, Investigate and Understand why the nephio-controller and token-controller deployment are using the same container image "nephio-operator:v1.0.1"

vjayaramrh commented 11 months ago

Looks like the line at https://github.com/nephio-project/nephio/blob/main/controllers/pkg/reconcilers/config/config.go#L34 needs to be updated to remove the GiteaClient and have a generic or abstract RepoClient?

johnbelamaric commented 11 months ago

I think that's only needed for the repositories and token reconcilers. I would prefer that we somehow refactor such that the shared config across all reconcilers only contains those things needed by all of them, and the per-reconciler configs are loaded / created by those specific reconcilers.

In this case, that may mean splitting all gitea related reconcilers into a separate binary. Or, it could mean just a refactor and doing something in main only if some flag or env is set.

vjayaramrh commented 11 months ago

10/12/2023: (cc: @rravindran123 ) IN preparation of making changes to the nephio-controller-manager operator and testing out changes

Created KIND cluster using podman on my development box. Followed the command at https://kind.sigs.k8s.io/docs/user/rootless/#creating-a-kind-cluster-with-rootless-podman with a minor tweak systemd-run --scope --user -pDelegate=true kind create cluster
Installed kpt on my dev box -> https://kpt.dev/installation/kpt-cli
Deployed the porch packages to the kind cluster using the below kpt commands a) kpt pkg get https://github.com/nephio-project/nephio-example-packages/tree/main/porch-dev@v1.0.1 b) cd porch-dev/ c) kpt live init d) kpt live apply --reconcile-timeout=15m
Tested out building the controller code by executing the below commands a) from the nephio/operators/nephio-controller-manager directory make docker-build-local b) from the nephio/operators/nephio-controller-manager/bin directory GIT_URL=https://github.com/vjayaramrh/ ENABLE_APPROVAL=true ./manager

vjayaramrh commented 11 months ago

10/16/2023

A draft PR has been pushed at https://github.com/nephio-project/nephio/pull/410

vjayaramrh commented 11 months ago

Per @henderiw 's suggestion, next step is to implement a singleton pattern to create and obtain Gitea client instead of creating multiple gitea client instances.

johnbelamaric commented 11 months ago

Done!

efiacor commented 7 months ago

@johnbelamaric Is the dependency removed? Do we have another task to have more options for git support?

johnbelamaric commented 7 months ago

Yeah - you don't need to run Gitea now. But for the automated provisioning of clusters, you do need a controller that can provision repositories in whatever your Git solution is. AFAIK, we have Gitea support and in the GCP installation I use Google's Config Controller to provision Google Cloud Source Repositories. We should be able to implement a GitHub one and a GitLab one, that would be really good coverage. I don't know if there are feature requests for that already; it's also possible there are already existing K8s operators that would enable KRM-based provisioning of repos in those environments. In that case, it's just a matter of trying it out and documenting how to do it.

efiacor commented 7 months ago

I'm a bit confused. Currently, the nephio operator only has support for gitea in the repo and token reconcilers. Are you saying you deploy the operator with those reconcilers disabled and manage the cluster and repo setup manually? I see there are a few issues open for github and gitlab - https://github.com/nephio-project/nephio/issues/356 I might take a look around to see if we could reuse and existing controller first.

johnbelamaric commented 7 months ago

For the GCP opinionated install, I don't need those. The GCP Config Controller provides a KRM-based API surface that allows me to provision new repositories, and the workload identity service means I don't need a token. So, in that installation, yes, I can disable Gitea altogether. I don't think I have made that update though, at the time I put it together, I needed to run Gitea. But with R2 I should be able to remove Gitea and disable those reconcilers.