Skip to content

[Fleet] Cluster selection by display name still not performing as expected #16870

@krumware

Description

@krumware

Setup

  • Rancher version: 2.13.3
  • Rancher UI Extensions: continuous integration, elemental, harvester
  • Browser type & version: Chrome latest

Describe the bug
Looking for clarification on the resolution of this issue: #16370
It does seem as though the originating issue for the backend selection was resolved.
However, now the UI does not properly reflect the backend logic.

In the GitRepo view, this example is shown as targeting 5 clusters via clusterName, where the clusterName is the display name. (ignore the error message, the 5 clusters is the important bit.)
Image

When inspecting the yaml, this is the list of 5 targets:
Image

When I navigate to the editor, the Selected Clusters does not match
Image

In this example, the platform-services cluster is a kubernetes cluster managed by the Harvester cluster provider. krum-development is an AKS cluster. krum-prod is an EKS cluster. harvester-lab is an actual Harvester cluster. dev-desktop is an imported cluster.

If I remove dev-desktop from the list, then re-add dev-desktop, it will appear in the Selected Clusters list:
Image

But, when inspecting the yaml, it is not using the clusterName as the selector, it is using the Rancher-generated cluster ID:
Image

This indicated inconsistency of the matching logic between the (correct) cluster count versus the (incorrect) list of selected clusters.

(I believe the inconsistent use of the cluster metadata name between cluster providers to be a separate issue)

To Reproduce

  1. Clickops create an Imported cluster with a name foo
  2. Apply a GitRepo yaml with target configuration of
targets:
  - clusterName: foo
  1. View GitRepo table, observe 1/1 clusters selected in the table
  2. Edit/View GitRepo configuration with UI - observe foo is omitted from Selected Clusters

Result

Expected Result

ClusterName should select what appears to the user to be the Cluster Name.

Screenshots
in description

Additional context
n/a

Metadata

Metadata

Labels

QA/dev-automationIssues that engineers have written automation around so QA doesn't have look at thisarea/fleetkind/bug

Type

No type
No fields configured for issues without a type.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions