Issue deploying when using defaults
Closed this issue · 1 comments
Currently, when the Quick-Start scenario is deployed using the defaults (most pertinently, the Let's Encrypt env is staging), an error is seen when attempting to deploy a Spin app via spin deploy -k, e.g.:
thread 'main' panicked at 'Unable to create Hippo App: ResponseError(ResponseContent { status: 500, content: "{\"type\":\"https://tools.ietf.org/html/rfc7231#section-6.6.1\",\"title\":\"An error occurred while processing your request.\",\"status\":500}", entity: Some(UnknownValue(Object({"type": String("https://tools.ietf.org/html/rfc7231#section-6.6.1"), "title": String("An error occurred while processing your request."), "status": Number(500)}))) })', /Users/runner/work/spin/spin/src/commands/deploy.rs:117:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
While the command does pass on the -k (ignore cert errors) option for the bindle publish action at the start -- and which succeeds, as seen in a subsequent spin deploy -k attempt when greeted with a 'bindle already exists error' -- I don't believe the same option is successfully carried through the Hippo API calls. My hunch is that when Hippo goes to pull (GET) the bindle by its ID, it is error-ing out on the cert error, having not been configured to ignore them. See also deislabs/hippo#819 (comment)
We may also want to consider switching things such that the default Let's Encrypt env is the production one (so, happy TLS and no need to add -k).