:seedling: Upgrade FL controller Flower path to 1.26.x SuperLink/SuperNode architecture by yanmxa · Pull Request #107 · open-cluster-management-io/addon-contrib

yanmxa · 2026-03-04T04:27:47Z

Related Jira Issue

https://issues.redhat.com/browse/ACM-30551

Summary

Upgrade the Flower path in the FederatedLearning controller from legacy Flower 1.x (server/client Jobs with own networking) to Flower 1.26.x SuperLink/SuperNode architecture
The controller now deploys only the application layer (SuperExec-ServerApp + SuperExec-ClientApp) on top of infrastructure pre-deployed by the Flower Addon
Replace per-cluster ManifestWork generation with a single ManifestWorkReplicaSet for automatic cluster management via OCM Placement

Changes

CRD: Added superlink (default: superlink.flower-system:9091) and supernode (default: flower-supernode.flower-addon:9094) endpoint fields to ServerSpec/ClientSpec

Controller: New reconcileFlower() path deploys:

SuperExec-ServerApp Deployment on hub (connects to SuperLink exec API)
SuperExec-ClientApp via ManifestWorkReplicaSet (connects to SuperNode ClientAppIO API)

Removed: Old Flower 1.x templates (server-job, service, route, client manifestwork) and associated param structs

Added: RBAC for apps/deployments and work.open-cluster-management.io/manifestworkreplicasets, workv1alpha1 scheme registration

Test plan

make generate && make manifests - CRD generation succeeds with new fields
make build - Go compilation passes
make test - All existing tests pass
Deploy to Kind cluster with OCM + Flower addon (cloud-user@10.0.11.238)
Verify SuperExec-ServerApp Deployment created on hub with correct args
Verify ManifestWorkReplicaSet created and ManifestWorks propagate to managed clusters
Verify SuperExec-ClientApp Deployments appear on managed clusters in correct namespace
Delete FederatedLearning CR and verify all resources cleaned up

🤖 Generated with Claude Code

openshift-ci · 2026-03-04T04:27:54Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: yanmxa

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~federated-learning-controller/OWNERS~~ [yanmxa]

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

chongshenng · 2026-03-05T21:35:46Z

+### Deploy a Federated Learning Instance (Flower)

-#### 1. Deploy a Federated Learning Instance
+#### 1. Create a FederatedLearning Resource


Suggested change

#### 1. Create a FederatedLearning Resource

#### 1. Create a Federated Learning Resource

Should there be a space between FederatedLearning?

No, the resource name is FederatedLearning

chongshenng · 2026-03-05T21:37:11Z

-	ListenerPort        int
-	CreateService       bool
-	ObsSidecarImage     string
+// FlowerServerAppParams defines the parameters for a Flower 2.x SuperExec-ServerApp Deployment on hub.


Do you mean 1.2x instead of 2.x? The latest Flower version as of today is 1.26.1.

Good Catch! You're right, the current Flower version is 1.26.x. I used "2.x" to conceptually distinguish the new SuperLink/SuperNode architecture from the old server/client model, but it's misleading. Will update all "2.x" references to reflect the actual version.

chongshenng · 2026-03-05T21:37:49Z

-	ObsSidecarImage     string
+// FlowerServerAppParams defines the parameters for a Flower 2.x SuperExec-ServerApp Deployment on hub.
+type FlowerServerAppParams struct {
+	Namespace        string // FL CR namespace (where Deployment is created)


Should we use the full form of FL CR so that it's clear?

chongshenng · 2026-03-05T21:38:20Z

+// FlowerClientAppParams defines the parameters for a Flower 2.x SuperExec-ClientApp ManifestWorkReplicaSet.
+type FlowerClientAppParams struct {
+	Name             string // e.g., "<cr-name>-clientapp"
+	Namespace        string // FL CR namespace (where MWRS is created)


Same as above.

chongshenng · 2026-03-05T21:39:36Z

+	return nil
+}
+
+// pruneOpenFLClientResources cleans up OpenFL client resources (per-cluster ManifestWorks + Placement).


Is this an alternate function used only for OpenFL (not Flower)?

Yes, exactly. pruneClientResources (line 226) dispatches by framework: Flower calls pruneFlowerClientResources, OpenFL calls pruneOpenFLClientResources. This split was needed because Flower now uses ManifestWorkReplicaSet while OpenFL uses per-cluster ManifestWorks — different resources require different cleanup logic.

chongshenng · 2026-03-05T21:41:23Z

+		return err
+	}
+
+	clientParams := &manifests.OpenFLClientParams{


Might be related to my comment above, is this part of the OpenFL function? If it doesn't impact the usage of Flower here, maybe this should go into another PR and focus only on the changes for Flower here.

To clarify further: the OpenFL code logic is unchanged — only the switch wrapper was removed since it had a single remaining case after extracting Flower. This is already isolated in commit 49a3955. Splitting it into a separate PR would introduce an awkward intermediate state (a single-case switch).

chongshenng · 2026-03-05T21:42:04Z

 	return ctrl.Result{}, nil
 }

+// reconcileFlower handles the Flower 2.x SuperLink/SuperNode architecture.


See my comment above about Flower version.

Will update to 1.26.x.

chongshenng · 2026-03-05T21:42:58Z

 	}

-	render, deployer := applier.NewRenderer(serverFS), applier.NewDeployer(r.Client)
+	serverParams := &manifests.OpenFLServerParams{


Please see my comment above about maybe moving this to another PR.

Same reasoning as the client file — see my reply here.

chongshenng · 2026-03-05T21:43:29Z

+
+## Architecture
+
+### Flower 2.x (SuperLink/SuperNode)


Please see my earlier comment about the Flower version.

Already updated to 1.26.x.

chongshenng · 2026-03-05T21:45:03Z

+  --app <your-flower-app> \
+  --federation <superlink-address>


Suggested change

--app <your-flower-app> \

--federation <superlink-address>

<your-flower-app> \

<superlink-connection>

You don't need to pass the --app or --federation flags. They are positional args.

Done, updated to positional args.

chongshenng · 2026-03-05T21:46:01Z

+<summary><strong>Deploy a Federated Learning Instance (OpenFL)</strong></summary>

-#### 2. Schedule the Federated Learning Clients into Managed Clusters
+### OpenFL Path


Could we move the changes for OpenFL to another PR and keep this PR focused only for the Flower-related changes?

Done, split the OpenFL docs into #108.

yanmxa · 2026-03-10T07:00:01Z

/retest

…ture Signed-off-by: Meng Yan <myan@redhat.com>

Remove unnecessary framework switch statements and embed.FS variables since federatedLearningServer() and clusterWorkload() are now only called for the OpenFL path. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Meng Yan <myan@redhat.com>

The new template files were missed in the initial commit because git add -u only tracks modified/deleted files, not new untracked ones. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Meng Yan <myan@redhat.com>

…R abbreviation, fix flwr run syntax, split OpenFL docs to separate PR Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Meng Yan <myan@redhat.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Meng Yan <myan@redhat.com>

ldpliu · 2026-03-13T04:04:37Z

/lgtm

* 🌱 Migrate Flower app-torch example to SuperExec architecture The Flower path in the FederatedLearning controller was upgraded to the 1.26.x SuperLink/SuperNode/SuperExec architecture in #107, but examples/flower/app-torch/ was left on the legacy Flower 1.x `server`/`client` entrypoint. The manifests produced by the controller launch the container with SuperExec args (`--insecure`, `--appio-api-address=<addr>`, `--plugin-type=<serverapp|clientapp>`), which the old entrypoint.sh rejected with `Unsupported command '--insecure'` (see #116). This rewrites the example to match the SuperExec contract used by the flower-addon's cifar10 reference app: - server_app.py / client_app.py now expose `ServerApp` / `ClientApp` objects via `@app.main()` / `@app.train()` / `@app.evaluate()`. - task.py loads MNIST via `flwr_datasets.FederatedDataset` with an `IidPartitioner`; partition-id is derived from the `cluster-name` / `num-partitions` node_config injected by the flower-addon SuperNode. - pyproject.toml pins `flwr>=1.26.1` and registers the new `[tool.flwr.app.components]` entry points. - Dockerfile switches the base image to `flwr/superexec:1.26.1` and bakes PyTorch / Flower deps in at build time. ENTRYPOINT is now `flower-superexec`. This also resolves the slow-startup feedback in issue #116 where the previous image re-downloaded ~2GB of deps on every pod start. - entrypoint.sh and app_torch/utils.py are removed (obsolete with SuperExec). README updates: - Add a step to enable the `ManifestWorkReplicaSet` feature gate on the hub (disabled by default in OCM v1.2.x, per the original report). - Point the sample `FederatedLearning` CR at `quay.io/open-cluster-management/federated-learning-application:flower-mnist-latest` (the legacy `flower-app:cifar10-v1.0.0` image referenced in main is unavailable on quay.io and is incompatible with the SuperExec args). - Clarify the SuperExec image contract and update the `APP_NAME` example to `flower-mnist`. Fixes #116 Signed-off-by: Meng Yan <myan@redhat.com> * Address CodeRabbit review feedback - client_app.py: replace process-randomized `hash()` with `hashlib.sha256` so the cluster-name -> partition-id mapping is stable across pod restarts. - server_app.py: make the final-model save path configurable via the `FLOWER_MODEL_OUTPUT_PATH` env var; skip the save when it's unset (the hub ServerApp Deployment has no PVC by default, so writing to /app was effectively a no-op). - task.py: cache the centralized MNIST DataLoader across rounds and drop the redundant `with_format("torch")` (overridden by `with_transform`). - pyproject.toml: cap `flwr` at `<2` to guard against future breaking major releases. Signed-off-by: Meng Yan <myan@redhat.com> --------- Signed-off-by: Meng Yan <myan@redhat.com>

openshift-ci Bot requested review from mikeshng and mrrr3d March 4, 2026 04:27

openshift-ci Bot added the approved label Mar 4, 2026

github-actions Bot added the federated-learning-controller label Mar 4, 2026

yanmxa changed the title ~~Upgrade FL controller Flower path to 2.x SuperLink/SuperNode architecture~~ 🌱 Upgrade FL controller Flower path to 2.x SuperLink/SuperNode architecture Mar 4, 2026

chongshenng reviewed Mar 5, 2026

View reviewed changes

yanmxa changed the title ~~🌱 Upgrade FL controller Flower path to 2.x SuperLink/SuperNode architecture~~ 🌱 Upgrade FL controller Flower path to 1.26.x SuperLink/SuperNode architecture Mar 9, 2026

yanmxa mentioned this pull request Mar 9, 2026

📖 add OpenFL deployment section to FL controller README #108

Merged

1 task

yanmxa mentioned this pull request Mar 11, 2026

CI: pr-verifier check failing due to deprecated gcr.io/kubebuilder image #109

Open

yanmxa and others added 6 commits March 12, 2026 15:05

Upgrade FL controller Flower path to 2.x SuperLink/SuperNode architec…

6a681fe

…ture Signed-off-by: Meng Yan <myan@redhat.com>

address review feedback: update Flower version to 1.26.x, expand FL C…

47a049a

…R abbreviation, fix flwr run syntax, split OpenFL docs to separate PR Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Meng Yan <myan@redhat.com>

trigger CI rerun

b3697a9

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Meng Yan <myan@redhat.com>

trigger CI rerun

9abaeda

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Meng Yan <myan@redhat.com>

yanmxa force-pushed the flower-controller-superlink-upgrade branch from b312554 to 9abaeda Compare March 12, 2026 08:38

yanmxa requested review from chongshenng March 12, 2026 09:49

openshift-ci Bot assigned ldpliu Mar 13, 2026

openshift-ci Bot added the lgtm label Mar 13, 2026

openshift-merge-bot Bot merged commit fcd1224 into open-cluster-management-io:main Mar 13, 2026
10 checks passed

yanmxa deleted the flower-controller-superlink-upgrade branch March 17, 2026 02:03

y-sera mentioned this pull request May 10, 2026

[Federated Learning] Can't work Getting Started(flower) #116

Closed

yanmxa mentioned this pull request May 11, 2026

🌱 Migrate Flower app-torch example to SuperExec architecture #117

Merged

3 tasks

	#### 1. Create a FederatedLearning Resource
	#### 1. Create a Federated Learning Resource

Uh oh!

Conversation

yanmxa commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Related Jira Issue

Summary

Changes

Test plan

Uh oh!

openshift-ci Bot commented Mar 4, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chongshenng Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chongshenng Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chongshenng Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yanmxa commented Mar 10, 2026

Uh oh!

ldpliu commented Mar 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

yanmxa commented Mar 4, 2026 •

edited

Loading

chongshenng Mar 5, 2026 •

edited

Loading

chongshenng Mar 5, 2026 •

edited

Loading

chongshenng Mar 5, 2026 •

edited

Loading