-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ServiceAccountKey
gives error private_key: not a string
and never becomes ready after gcp-provider pod is restarted (for instance after a version upgrade)
#307
Comments
Some minimal analysis shows that the specific error is produced by the upbound/upjet library. I believe it has to do with the GCP API only responding with the |
Hi @jonnylangefeld, apiVersion: cloudplatform.gcp.upbound.io/v1beta1
kind: ServiceAccountKey
metadata:
annotations:
meta.upbound.io/example-id: cloudplatform/v1beta1/serviceaccountkey
labels:
testing.upbound.io/example-name: example-service-account-key
name: example-service-account-key
spec:
forProvider:
publicKeyType: TYPE_X509_PEM_FILE
serviceAccountIdSelector:
matchLabels:
testing.upbound.io/example-name: example-service-account-key
writeConnectionSecretToRef:
name: gcp-service-account-key
namespace: upbound-system Please note the If/when you do not do this, I think we are hitting a bug with the associated resource configuration here: I guess the paved object's So, if this is the case, we need to fix the configuration so that it does not assume the existence of the string But still, I think it makes sense to use a connection details secret with this resource. What do you think? |
A relevant testing issue is here: upbound/official-providers-ci#92 |
We don't use
But we use
and the I might have misinterpreted this part of your reply:
|
What happened?
We use the pattern of a
ServiceAccount
together with aServiceAccountKey
quite a lot, as suggested by the examples.However, we recently upgraded
provider-gcp
fromv0.27.0
tov.0.32.0
, which restarted the pod. After this process all ourServiceAccountKey
resources got a condition likeThis gets all resources depending on
ServiceAccountKeys
into a non-ready state.How can we reproduce it?
Create a
ServiceAccount
and aServiceAccountKey
as suggested by the example:https://github.com/upbound/provider-gcp/blob/a74e05300b59c0e804ee241a974122bfad0b82d2/examples/cloudplatform/serviceaccountkey.yaml#L1-L28
Wait for
ServiceAccountKey
to be synced and ready.Restart the gcp-provider pod.
What environment did it happen in?
v1.12.0
v1.32.0
1.23
The text was updated successfully, but these errors were encountered: