feat: fleetconfig-controller for declarative orchestration of OCM multi-clusters

[TylerGillson]

✨ Unlock the power of GitOps for OCM! ✨

🌱 Project Overview

This PR contributes the fleetconfig-controller project to the OCM community. The fleetconfig-controller introduces a new FleetConfig custom resource, which the controller orchestrates to manage the lifecycle of OCM multi-clusters. The controller is a lightweight wrapper around clusteradm. Anything you can accomplish imperatively via a series of clusteradm commands can now be accomplished declaratively using the fleetconfig-controller.

🔧 Installation

The controller is installed via Helm. By default the Helm chart will also produce a FleetConfig to orchestrate, however that behaviour can be disabled. To get started, check out the smoke tests. Within 10 minutes you can watch the fleetconfig-controller bootstrap two local kind clusters into an OCM hub and spoke.

🏗️ Support Matrix

• Orchestration of OCM multi-clusters on any vanilla Kubernetes cluster is supported
• Orchestration of managed Kubernetes clusters is partially supported
  • EKS and GKE are fully supported
  • Azure (AKS) is on our roadmap

[TylerGillson]

I had to make a bunch of assumptions around CI for the labs monorepo. I would appreciate input on the release and releaseimage workflows 🙏 (also on the whole PR in general 😄)

At the moment I have assumed that the following secrets will be added to this repository:

• OCM_BOT_PAT
• DOCKER_PASSWORD
• DOCKER_USER

The smoke tests are passing for me locally, so hopefully they’ll pass for you too.

Heads up that I will be away for all of next week. But I will get on any feedback ASAP once I return on the 30th.

[mikeshng]

CC @qiujian16 @xuezhaojun

[qiujian16]

thanks, looks fine in general. I would suggest we remove github action related for now. There will be multiple project in it and we have to figure out a more generic approach with gha

[mikeshng]

@TylerGillson do you have any recommendation on a generic approach with GitHub Actions?

[TylerGillson]

@mikeshng the approach I've proposed here is a generic approach for handling CI for multiple subprojects. Each project just has to conform to a handful of requirements that I've outlined in the top-level README.

---

From README.md:

GitHub Actions

All projects must follow certain conventions to ensure compatibility with the lab repository's Github Actions workflows.

Refer to the Test and E2E workflows for exact details.

make targets

All projects must define the following make targets:

• check-diff: Perform any automated formatting, Helm chart README updates, manifest generation, etc. Return a non-zero exit code if a git diff is produced.
• test-e2e: Invoke end-to-end tests and return an exit code accordingly.
• test-unit: Invoke unit tests and return an exit code accordingly.

Dockerfiles

All Dockerfiles for the project must reside under <project_name>/build/ and the default Dockerfile must be named Dockerfile.base.

Helm Charts

Any projects that require a Helm chart must be structured as follows:

<project_name>
└── charts
    └── <project_name> # chart name must match project directory name
        ├── Chart.yaml
        ├── templates
        └── values.yaml

Furthermore, values.yaml must contain the following top-level values:

image:
  repository: <project_image_repository>
  tag: <project_image_tag>

This is required so that a locally built image can be used consistently for Helm chart testing.

See the test-chart job in the Test workflow for further details.

[TylerGillson]

Would you like me to remove the vendor folder temporarily so that the PR can actually be reviewed on the Github UI? I can add it back later on once other feedback is addressed.

@mikeshng I'd be happy to set up an in-person meeting to review this PR with yourself and whoever else is interested/required.

I've set up the Github workflows to handle the monorepo structure in a reasonably straightforward manner. I'd be happy to replace the bash + jq logic in planner.yml with a python script if that would be preferable.

[mikeshng]

/lgtm

/assign @qiujian16

[qiujian16]

/approve

let's merge this as a good starting point. I'd like @xuezhaojun to also review the project onboarding part, but we can iterate on it later. Thanks for this great work!

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: qiujian16, TylerGillson

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:

• OWNERS [qiujian16]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment