[v2.7.1] Enable support for custom node roles for node groups

[a-blender]

Issue: rancher/rancher#29071

Problem

Enable custom node roles for node groups.

Solution

Changes

• NodeRole (string) is added to the NodeGroup struct for a user-defined node group node role in Rancher
• GeneratedNodeRole (string) is added to the config.Spec.EKSStatus for a node group node role generated and tracked by Rancher if a user doesn't provide one.

Testing

1. Provision 2 node EKS cluster with no specified node group node role. Cluster should come up active and node role should be viewable on spec.config.EKSStatus in the v3 object
2. Provision 2 node EKS cluster with user-defined node group node role
3. Provision 2 node EKS cluster with 2 node groups, 1 with no specified node group node role and 1 with a user-defined node-group role.

In the UI issue, it is specified

The value passed to the Rancher API should be a string. If no role is selected for a nodegroup, then the empty string should be passed.

I simulated rancher UI input by setting the empty string and a valid user-defined string on the existing node group NodeRole field in the code and verify the expected flow happens in the operator. NodeRole cannot be nil. Changes have been tested and verified with the PR rancher/rancher#38939.

[rmweir]

Are you using a test catalog in your setup that has the new crd?

[jakefhyde]

Couple nits

[a-blender]

This has been retested on rancher v2.7 head with PR comments addressed!

I had an issue with generatedNodeRole not being set on the Status because I had accidentally mod some previous code while testing that caused the config obj to be shadowed. So, config was being modified before a new node group was created causing k8s to throw an obj modification err when I tried to update the Status. This has been fixed and my solution is working fine - thank you @jakefhyde for the 2nd pair of eyes.

The changes to the fix include

• generatedNodeRole is not passed to the operator from rancher when building the upstream state.
• generatedNodeRole is now set on the Status in the handler instead of in nodegroup.go because it doesn't coincide with the utility of that function
• unnecessary deepCopies have been removed/reorganized

Ready for re-review

[rmweir]

LGTM

[jakefhyde]

config.Status.GeneratedRole is not set until after the first reconciliation, so every node group will end up creating a stack. Is that by design?

[jakefhyde]

LGTM, the only potential concerns I might have are that if an error returns later on, and we have to re-reconcile this object, it could potentially create more node groups than necessary (i.e. if another error happens between now and the time we end up updating the config object). I consider that outside of the scope of this PR because it looks like the entirety of this operator (and likely all the others) is written in a way that is contradictory to the design of wrangler's controller framework. We should revisit this at some point to prevent unnecessary thrashing by refactoring this. For example, once config.Status.GeneratedNodeRole is set, we should update the config object, and if it fails delete the node group and reenqueue the config object, and if it succeeds, return early since the next reconciliation will shore up the rest of the status updates. Once again, out of the scope of this PR though.

[rmweir]

LGTM