-
Notifications
You must be signed in to change notification settings - Fork 71
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
Deploying w/ Google Provider causing Halyard 500 - "spinnaker validation failed" #203
Comments
Ran into this as well when patching
Using Operation Version It gives the following error:
|
Did you ever find a workaround for this @EIrwin ? |
@nasonfish are you asking because you're seeing this behavior as well? |
I have similar behavior but with Google secret manager in my case: |
spec:
|
Having the same issue as OP. Using spinnaker-operator 1.3.1 in hosted in aws eks. I have the json credentials loaded as a k8s secret file and am loading it with jsonPath: encryptedFile:k8s!n:!k:.
|
As a potential fix for armory/spinnaker-operator#203 This fixes the getFileContentBytes to check for an encryptedFile rather than an encryptedSecret
I wanted to run a test for a fresh install of Spinnaker w/ OSS Armory Operator since I had patched it together to get it up and running.
I am using a very similar setup to spinnaker-kustomize-patches and deploying using Kustomize.
After removing Spinnaker, Operator, and external resources and running a fresh install, I am receiving the following error preventing Spinnaker from being deployed.
Investigating further, I see the following logs in the
halyard
container inspinnaker-operator
pod.Seeing this, I commented out
patch-google.yml
out of mykustomization.yml
file and I no longer receive the error.patch-google.yml
looks like the following:Since the log we see has the following, it seems to imply that the
jsonPath: encryptedFile:k8s!n:spin-secrets!k:gcp-sa.json
could be problematic.I have validated that
spin-secrets
in fact has thisgcp-sa.json
I have attempted to disable validation for all providers, but had no success:
One important thing to note is that I DID have this running with the exact same configuration prior to tearing it down and rerunning a full deployment. I am not sure if this suggests that there is either a race condition, or problem with sequencing, but wondering if there is a bug deep in there.
The text was updated successfully, but these errors were encountered: