/kind bug
What steps did you take and what happened:
[A clear and concise description of what the bug is.]
Following the quick start guide, I exported AWS_REGION, AWS_SECRET_ACCESS_KEY, AWS_ACCESS_KEY_ID, and run clusterawsadm alpha bootstrap encode-aws-credentials
I get a 302 redirect error.
Tried with both 0.4.8 and 0.4.6 binary linux releases from: https://github.com/kubernetes-sigs/cluster-api-provider-aws/releases
What did you expect to happen:
This command shouldn't even be calling the AWS api. I just want to encode my credentials, which work, as I use them all the time.
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Having to run this command to encode a struct rather than just create a secret that contains these values is a really terrible UX. Why are we creating some new one-off credential format when we could use a credentials file (like what's in ~/.aws/) or simple environment variables?
Environment:
kubectl version): v1.16.1/etc/os-release): CentOS 7, Fedora 30Also, error handling is not great here:
./clusterawsadm alpha bootstrap encode-aws-credentials
./clusterawsadm: line 1: syntax error near unexpected token `<'
./clusterawsadm: line 1: `<html><body>You are being <a href="https://github-production-release-asset-2e65be.s3.amazonaws.com...<sensitive url info>....redirected</body></html>
Looks like the results of that command are just a b64 encode aws credentials file. We should add some docs to produce it that way instead.
@michaelgugino I'm not getting a 302 redirect error. I'm wondering if perhaps this is due to the region you are using. Can you share which region you exported so I can try to reproduce the issue?
@aaroniscode I tried a variety of regions. Primarily I was wanting to use us-east-1.
I use other go libraries with the same credentials, I never have this issue.
Okay, with some help locally, I've sorted this out. I downloaded the binary release using curl, which doesn't follow the 302's by default. Thus, bash is trying to execute that 302 error as a script instead of the actual binary.
Most helpful comment
Okay, with some help locally, I've sorted this out. I downloaded the binary release using curl, which doesn't follow the 302's by default. Thus, bash is trying to execute that 302 error as a script instead of the actual binary.