[SURE-7333] Downstream AKS Cluster Management > Cluster details page not displaying accurate message during update

[Josh-Diamond]

SURE-7333

Setup

• Rancher version: 2.7.0
• Browser type & version: Chrome

Describe the bug

• When updating a downstream AKS cluster, Cluster Management > Cluster details page does not display accurate message.

To Reproduce

1. Fresh install of 2.7.0
2. Provision a downstream AKS cluster
3. Update downstream AKS cluster
4. Navigate to Cluster Management > Cluster Details page
5. Reproduced

Result

• The following message is seen:
  This resource is currently in a transitioning state, but there isn't a detailed message available.

Expected Result

• expected to show more detailed message, as seen in AKS operator logs:
  time="2023-03-07T02:10:50Z" level=info msg="Waiting for cluster [REDACTED] to update node pool [REDACTED]"

Screenshots

[kwwii]

@Josh-Diamond What extra information is provided by displaying the non-formatted text suggested?

[Josh-Diamond]

@kwwii the non-formated text suggestion came from AKS Operator logs, and instead of displaying, This resource is currently in a transitioning state, but there isn't a detailed message available, my request is to replace this message w/ the more specific log coming from AKS Operator, to read Waiting for cluster [c-REDACTED] to update node pool [REDACTED].

w.r.t. What extra information is provided by displaying the non-formatted text suggested?

The specific node pool being updated. If we have access to more specific details, we should pass them along to user w/o them having to navigate off Cluster Details page. From QA perspective this is a bug.

[kwwii]

Thanks, I agree that we should give the user as much information as possible

[gaktive]

This should be transferred to backend to provide the information via the operator.

[mjura]

I will look on this

[mjura]

It is needs to be discussed with UI team,

[kkaempf]

@Josh-Diamond is there a respective JIRA issue ?

@gaktive should I create a dashboard issue or will you ?

[gaktive]

@kkaempf You have the instant context so I'll allow you to file :)

[richard-cox]

@kkaempf @gaktive I don't think this is one for the UI team (rancher/dashboard#8877 (comment)). Whoever owns the provisioning.cattle.io.cluster metadata.state.message should take this on

[jakefhyde]

When you create a hosted cluster (e.g. AKS), although the cluster.provisioning.cattle.io does get created, the cluster.management.cattle.io is the tertiary object, and appears to be what the UI displays statuses from. Based on my testing, when creating on of these clusters, the Updated condition is not present on the provisioning cluster object, which leads me to believe the UI is pulling from the management cluster object; this is also reinforced by the fact that the management cluster object is one manipulated during cluster creation/update. Looking in the API, I see the following for the management cluster object:

"state": {
  "error": false,
  "message": "",
  "name": "provisioning",
  "transitioning": true
},

and the following for the provisioning cluster object:

state": {
  "error": false,
  "message": "Waiting for API to be available",
  "name": "waiting",
  "transitioning": true
},

With the following showing on the UI:

I think in this case, it seems like the correct path for the hosted team would be to set the corresponding condition on the management cluster, be it Provisioned or Updated depending on whether the cluster has been Provisioned successfully yet, since the message of the condition is ultimately what drives the metadata.state.message from the v1 API. @richard-cox feel free to correct me if any of the above information is incorrect. I may be a bit fuzzy regarding how the UI pulls metadata.state.message when relationships are involved in the v1 API.

[richard-cox]

Good spot @jakefhyde. I've investigated some more, interestingly it's different given the type of cluster

• RKE2 --> provisioning cluster state
• Non-RKE2 --> management cluster state, or if empty the provisioning cluster state

For tracking

• shell/models/provisioning.cattle.io.cluster.js _stateObj contains the logic to decide between prov or mgmt cluster state object
• shell/plugins/dashboard-store/resource-class.js stateDescription is the text shown in cluster lists
• shell/components/ResourceDetail/Masthead.vue banner is the text shown in the cluster detail page's banner

[gaktive]

cc @nwmac

@kkaempf since this isn't going to be in 2.9.1, should we change the milestone to the next minor version 2.10.0 and then assess? @mjura is chiming in that the CRD used to source messages needs to be changed.

[kkaempf]

Since @mjura is already on it, I moved it to 2.9-Next1

Michal, feel free to move to a different milestone as you see fit 😉

[nwmac]

@richard-cox The fact we use mgmt cluster is most likely historical - I thought we would prefer to move towards using the provisioning cluster where possible and ultimately remove the need for the UI to request the mgmt cluster. Would it not be better for the hosted operators to update the provisioning cluster and for the UI to be updated to look there?

[mjura]

Since @mjura is already on it, I moved it to 2.9-Next1

We talked with Gary and I moved it to v2.10, due it will be needed UI help, it this issue has low priority

[gaktive]

@richard-cox @mjura & @jakefhyde can you sync on this and determine the next step to take?

@nwmac to follow up with @mattfarina on the nomenclature used for what a cluster here is in this context, since that would drive some of the UI around here.

[mjura]

@richard-cox @mjura & @jakefhyde can you sync on this and determine the next step to take?

Please look on comment #179 (comment)

[richard-cox]

Following on from #179 (comment) and #179 (comment).

I think the proposal would be

• For AKS clusters the UI will use the provisioning cluster metadata.state to show cluster state (instead of falling back on the management cluster)
• For AKS clusters the provisioning cluster metadata.state will be updated given the state of aksclusterconfigs.aks.cattle.io(?)

If that's acceptable to everyone i can create a new UI issue to track that first point and we can use this issue to track the second

[mjura]

Following on from #179 (comment) and #179 (comment).

I think the proposal would be

• For AKS clusters the UI will use the provisioning cluster metadata.state to show cluster state (instead of falling back on the management cluster)

Problem is that any AKS, EKS or GKE hosted operator is not populating logs to provisioning cluster metadata.state for hosted providers logs should be sourced from aksclusterconfigs.aks.cattle.io

[richard-cox]

@mjura

Problem is that any AKS, EKS or GKE hosted operator is not populating logs to provisioning cluster metadata.state

The ask is to do so.

for hosted providers logs should be sourced from aksclusterconfigs.aks.cattle.io

The state and status message needs to come from the provisioning cluster. This is covered in #179 (comment).

To expand on the second part of the comment, soon the UI can only sort or filter lists of resources by properties within that resource (they will be cached in rancher which will be doing the pagination and then sending a single page to the ui).

If state and status need to come from a secondary resource (aksclusterconfigs.aks.cattle.io) the user can no longer sort / filter by cluster state, which is a pretty important feature.