You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In short, it seems that during the Terraform cluster create procedure there is a call to ibmcloud ks subnets --provider classic (the provider probably varies but in this case - the customer ticket - that it what is being called).
That subnets call seems to be subsequent to a ibmcloud cluster create... call because I'm seeing clusters being created as part of this despite the overall failure of the Terraform cluster create. (Is that assumption correct, that subnets is called after cluster create ? Does Terraform also call cluster rm automatically when the subnets call fails, or is this something that the customer is doing manually?)
The subnets call as it is presently being made calls out to all regions. This should normally be okay, but at present we're seeing region-specific failures from IAM that we're trying to understand. Because Terraform is calling out to all regions, calling it in this way is greatly increasing the chances that a Terraform cluster create will fail sporadically.
I'd suggested to Harini that the subnets call use the -l LOCATION flag to specify the location of interest.
One could run ibmcloud ks locations to see the list of valid locations. The valid values for LOCATION are there in the output in parenthesis. (e.g. fra02, fra, de, eu are all options that would include the fra02, each one broader than the last. Any one of those would limit the call to the eu-central region, preventing the IAM-problem-in-another-region issue from affecting the current Terraform cluster create attempt.
So - for example, if the user is creating the cluster in fra02, that must be specified in the cluster create call (in the --zone fra02 parameter. Can Terraform also pass that zone into the subnets call, as follows: ibmcloud ks subnets --provider classic -l fra02 ? Or is there a reason to obtain other subnets as part of this call?
One could also drop the specific zone (drop the two digits) to arrive at the metro and in doing so list all of the subnets in the metro, if that is helpful. ibmcloud ks subnets --provider classic -l fra
The text was updated successfully, but these errors were encountered:
In short, it seems that during the Terraform cluster create procedure there is a call to ibmcloud ks subnets --provider classic (the provider probably varies but in this case - the customer ticket - that it what is being called).
That subnets call seems to be subsequent to a ibmcloud cluster create... call because I'm seeing clusters being created as part of this despite the overall failure of the Terraform cluster create. (Is that assumption correct, that subnets is called after cluster create ? Does Terraform also call cluster rm automatically when the subnets call fails, or is this something that the customer is doing manually?)
The subnets call as it is presently being made calls out to all regions. This should normally be okay, but at present we're seeing region-specific failures from IAM that we're trying to understand. Because Terraform is calling out to all regions, calling it in this way is greatly increasing the chances that a Terraform cluster create will fail sporadically.
I'd suggested to Harini that the subnets call use the -l LOCATION flag to specify the location of interest.
One could run ibmcloud ks locations to see the list of valid locations. The valid values for LOCATION are there in the output in parenthesis. (e.g. fra02, fra, de, eu are all options that would include the fra02, each one broader than the last. Any one of those would limit the call to the eu-central region, preventing the IAM-problem-in-another-region issue from affecting the current Terraform cluster create attempt.
So - for example, if the user is creating the cluster in fra02, that must be specified in the cluster create call (in the --zone fra02 parameter. Can Terraform also pass that zone into the subnets call, as follows: ibmcloud ks subnets --provider classic -l fra02 ? Or is there a reason to obtain other subnets as part of this call?
One could also drop the specific zone (drop the two digits) to arrive at the metro and in doing so list all of the subnets in the metro, if that is helpful. ibmcloud ks subnets --provider classic -l fra
The text was updated successfully, but these errors were encountered: