Cluster UUID missing in return from /cluster/metrocluster API call when it's not a MCC | NetApp | Page 1

drifting matrix Oct 21, 2024, 6:49 AM

#

Hey guys,

while doing some API stuff, I discovered that when you query the system to check if it’s a MetroCluster configuration on a non-MCC system, no UUID is returned for the cluster.

Feels a bit inconsistent, right?

Example:
HA-Cluster query

{
  "local": {
    "configuration_state": "not_configured",
    "partner_cluster_reachable": false,
    "cluster": {
      "name": "HA-Cluster"
    }
  },
  "_links": {
    "self": {
      "href": "/api/cluster/metrocluster"
    }
  }
}

MetroCluster query

{
  "local": {
    "configuration_state": "configured",
    "periodic_check_enabled": true,
    "automatic_uso_failure_domain": "disabled",
    "mode": "normal",
    "partner_cluster_reachable": true,
    "cluster": {
      "name": "MCC-Cluster-A",
      "uuid": "11ee11ee-11ee-11ee-11ee-11ee11ee11ee",
      "_links": {
        "self": {
          "href": "/api/cluster"
        }
      }
    }
  },
  "remote": {
    "configuration_state": "configured",
    "periodic_check_enabled": true,
    "automatic_uso_failure_domain": "disabled",
    "mode": "normal",
    "cluster": {
      "name": "MCC-Cluster-B",
      "uuid": "ee11ee11-ee11-ee11-ee11-ee11ee11ee11",
      "_links": {
        "self": {
          "href": "/api/cluster/peers/ee11ee11-ee11-ee11-ee11-ee11ee11ee11/cluster"
        }
      }
    }
  },
  "configuration_type": "ip_fabric",
  "_links": {
    "self": {
      "href": "/api/cluster/metrocluster"
    }
  }
}

I’ve opened a ticket, but it’s been a bit of a struggle explaining to first-level support that this is a real issue and not just "works as designed."

What are your thoughts about this?

swift wyvern Oct 21, 2024, 2:54 PM

#

Is that UUID the same as the UUID of the cluster object? If yes, I'd expect it to return. If no, then it's likely a UUID specific to the context of an existing metrocluster, and thus would not return for a non-MCC.

#

It's also possible that it's referencing database tables on the backend that were never initialized, because it's not in an MCC configuration.

drifting matrix Oct 22, 2024, 1:46 PM

#

I’ve checked and can confirm that the cluster UUID from /cluster/metrocluster is indeed the same as the cluster UUID you get when querying /cluster.
When you add the x-trace-threshold:0 header, entries like clusterID or cluster_id appear in the traces for both endpoints.

sharp bramble Oct 22, 2024, 6:11 PM

#

it sounds like an MCC misconfiguration.

short ember Oct 22, 2024, 7:12 PM

#

sharp bramble it sounds like an MCC misconfiguration.

Did you try it on a MetroCluster? Does it show the same UUIDs for you? I'm pretty sure the MC in question is not misconfigured 😅

#

But something in the cluster DBs might just be broken of course...

drifting matrix Oct 23, 2024, 6:37 AM

#

sharp bramble it sounds like an MCC misconfiguration.

Why would a missing cluster UUID in the response of a Single Chassis HA Cluster configuration indicate a misconfigured MCC? MCCs return the cluster UUID correctly; that was never the issue.

sharp bramble Oct 23, 2024, 1:02 PM

#

Sorry, am using the term "misconfigured" a little loosely. Not saying that the MCC piece was not configured correctly. There was a breakdown in the process somewhere that caused this to be a result. It is most likely a back-end data issue that would warrant a support case to help fix.

short ember Oct 23, 2024, 2:07 PM

#

sharp bramble Sorry, am using the term "misconfigured" a little loosely. Not saying that the ...

so the two "cluster" UUIDs are indeed supposed to be the same?

sharp bramble Oct 23, 2024, 5:58 PM

#

no. Each site's cluster has its own Cluster UUID. Which also means that all the node UUIDs are also unique. There is also no "Metrocluster UUID" that's shared between the 2 sites. Each site has a record of the cluster UUID and node UUIDs of the other site.

short ember Oct 23, 2024, 6:11 PM

#

sorry. you didn't understand me correctly. Let me ask it this way. Are the "local cluster uuid" that is returned from the MetroCluster query and the "cluster id" that is returned from the HA query supposed to be the same?

#

(which is basically the question OP has asked)

#

but from what I've read here I would assume that it is, and that support is wrong in saying that it's supposed to be different IDs 🤔

sharp bramble Oct 23, 2024, 6:16 PM

#

oh... yes. The ClusterUUID returned by the cluster info and the metrocluster query are the same

swift wyvern Oct 23, 2024, 6:43 PM

#

But if the cluster is not configured as a metrocluster, the backend tables that configuring the cluster as MCC would initialize are likely not initialized and populated with data. That's likely why the UUID of the MCC API call of a non-MCC doesn't provide that data.

Honestly, I believe the truer issue is that the \metrocluster API for a non-MCC is returning anything more than 'not configured as an MCC'.

drifting matrix Oct 23, 2024, 8:11 PM

#

swift wyvern But if the cluster is not configured as a metrocluster, the backend tables that ...

That would be fine, honestly 😬. But would it really be that resource-intensive to always include the cluster UUID in the response when querying /cluster and all its children? I mean, even when I query the nodes, the cluster UUID isn't returned. I could’ve really used that already.

swift wyvern Oct 23, 2024, 8:15 PM

#

Reviewing the the provided sample data again, thank you for that, I see it is returning 'not configured'.

always include the cluster UUID in the response when querying /cluster and all its children
Context matters. You were asking about the info missing from the /metrocluster API.

If it's not returning from the /cluster API, that's 100% an issue.

I wonder, if you use the fields parameter with /cluster and explicitly request the UUID and other info you need, does that return correctly?

#Cluster UUID missing in return from /cluster/metrocluster API call when it's not a MCC