The issue was investigated and determined to be as follows. The service account is created with an iam api call, but the binding of roles to the service account is made with a cloudresourcemanager api call. It was found that there is a window of time in which the service account created is not yet visible to cloudresourcemanager, resulting in sporadic BadRequest errors. This PR reintroduces the functionality with an additional mechanism to make wif creation robust to these out-of-sync issues.
Additionally there is an improvement to the logic used to determine if a custom role should be updated. I was finding that the osd_deployer_v4.17 role was getting updated every time I called wif create. This was caused by the list of permissions not being in alphabetical order. The new logic will only update the role if the existing and proposed permissions do not have the same elements, regardless of order.
To test this, the following bash command was run. After the changes, the BadRequest errors previously received were not experienced.
for id in $(awk 'BEGIN{for (i=1;i<10;i++) print "rc-"i}') ; do ./ocm gcp create wif-config --name $id --project $project_id; done
These changes were pushed last week as part of https://github.com/openshift-online/ocm-cli/pull/663, but needed to be reverted due to a timing-related issue on the GCP side.
The issue was investigated and determined to be as follows. The service account is created with an iam api call, but the binding of roles to the service account is made with a cloudresourcemanager api call. It was found that there is a window of time in which the service account created is not yet visible to cloudresourcemanager, resulting in sporadic BadRequest errors. This PR reintroduces the functionality with an additional mechanism to make wif creation robust to these out-of-sync issues.
Additionally there is an improvement to the logic used to determine if a custom role should be updated. I was finding that the osd_deployer_v4.17 role was getting updated every time I called wif create. This was caused by the list of permissions not being in alphabetical order. The new logic will only update the role if the existing and proposed permissions do not have the same elements, regardless of order.
To test this, the following bash command was run. After the changes, the BadRequest errors previously received were not experienced.