Consider all possible cluster states before passing them to StateChangeConf

[furkatgofurov7]

Issue:

#1003
rancher/eks-operator#84

Problem

When importing an EKS cluster using the terraform provider, sometimes rancher cluster reconciliation loop can be fast and go ahead with cluster creation (going from "pending" to "active" too fast) and the provider can miss it, resulting on provider waiting for the cluster to be in the "pending" state even though it went pass that state long before and provider simply missed that

Solution

Instead of predefining the expectedState beforehand and overwriting it later if need to be, define it as slice literal with keeping the same state ("active") and append the new states later if need to be (i.e. if cluster.Driver == clusterDriverImported || (cluster.Driver == clusterDriverEKSV2 && cluster.EKSConfig.Imported) == True) and pass it to
StateChangeConf struct. Anyways, StateChangeConf struct expects Target to be []string so nothing is changed behaviour wise but just all possible cluster states are considered before passing them.

[mjura]

LGTM

[a-blender]

@furkatgofurov7 I see that you were unable to repro this bug after multiple attempts #1003 (comment) and the original author of the issue saw a 30 sec timeout in terraform apply but the cluster still became active in about a minute. This was with using the latest terraform v3.0.0.

1. Is it still an issue for them?

2. What evidence is there that not predefining the expectedState in the provider fixes this particular issue? I'm fine to have it go in as a noted enhancement but I don't see how this explicitly resolves Intermittently imports of EKS clusters never finish #1003.

[furkatgofurov7]

1. Is it still an issue for them?

Hey @a-blender thanks for review, as per #1003 (comment) it should be still an issue

2. What evidence is there that not predefining the expectedState in the provider fixes this particular issue? I'm fine to have it go in as a noted enhancement but I don't see how this explicitly resolves Intermittently imports of EKS clusters never finish #1003.

Based on the logs from the linked issue description:

Error: [ERROR] waiting for cluster (c-xfbkg) to be created: timeout while waiting for state to become 'pending' (last state: 'active', timeout: 30m0s)

and this comment, considering all possible cluster states should not hurt and in case of provider missing to catch the state of the rancher it will still be able to move on.
Also, I forgot to mention that, the piece of code where expectedState is predefined beforehand appears only in this case, in all other cases, i.e clusterUpdate the target state is a slice with bunch of different states, so from that perspective this should align also with that.

Since the reproduction was not possible, maybe we should take this in as an improvement to the provider, WDYT?

[furkatgofurov7]

@a-blender can we merge this, based on #1003 (comment) it helps to fix the issue in #1003 ?