deploy to the Cloud

[bacongobbler]

This feature enhancement allows Spin users to deploy their applications to the Cloud.

><> cd examples/http-rust

><> spin build
Executing the build command for component hello: cargo build --target wasm32-wasi --release
    Finished release [optimized] target(s) in 0.01s
Successfully ran the build command for the Spin components.

><> spin deploy --hippo-server ***************
Open the Cloud's device authorization URL in your browser: ***********/device-authorization and enter the code: ******
The code has been copied to your clipboard for convenience.
Waiting for device authorization...
Device authorized!
Deployed spin-hello-world version 1.0.0
Application is running at spin-hello-world-61fr9ys5.*************

><> curl https://spin-hello-world-61fr9ys5.*************/hello
Hello, Fermyon!

A couple of open comments/questions for the reviewer:

1. Because of the reliance on copypasta, Spin developers will need to install xorg-dev to compile against Linux. Where should we document this? Docs? README?
2. On every invocation to spin deploy, the command will prompt for a new device code. This is because spin deploy does not store any configuration. Is this something we should track, or is the current behaviour okay?
3. There's a bunch of code duplication - specifically surrounding crates/cloud/src/registry/bindle and crates/publish. This is an area worth looking at a little closer. (cc @radu-matei)
4. All of the spin deploy flags are prefixed with --hippo-*. Is this worth re-naming these? (he says, as he asks the most difficult issue in the engineering world... Naming things)

TODO:

• Have spin login --status print as JSON
• Implement non-interactive login flow

[itowlson]

I thought we were going to do something like spin login for environments with persistent login tokens. Then spin deploy would gain a --token option to go alongside --hippo-password.

I feel like we could do with a SIP to figure out things like this and the clipboard overwrite issue and the persistence model and all that... what do you reckon?

[bacongobbler]

./target/release/spin login --status
You are logged into http://localhost:5301
Your session will expire on 2022-10-12 19:31:21 +00:00.

[bacongobbler]

Okay. Everything except for shunting back to spin login when the file is not found or the token has expired has been implemented. Please feel free to give this a test.

Note that the value for the cloud URL has been hard-coded to http://localhost:5309. If you want to point to a different cluster, you will need to change the hard-coded URL for DEFAULT_CLOUD_URL and re-compile the project.

[itowlson]

This is really nice and super smooth!

One niggle I spotted. In the GH auth scenario we proxy Bindle; if this is far away then you can get this:

ivan@hecate:~/testing/deploytest$ ~/github/spin/target/debug/spin deploy
<URL> is responding slowly or not responding...

<URL>/api/registry is responding slowly or not responding...

Could we spot the proxy case and emit only one sloth warning? Sorry to nitpick.

[itowlson]

Not sure if the PR is ready for feedback at this level, but the error mode if the Hippo server doesn't exist is that it does nothing for about 15 (?) seconds then prints Error: expected value at line 1 column 1.

(This was hitting a URL that had previously existed as a AWS Hippo instance, but had been terraform destroyed. Hitting a completely made-up domain gives the same message but a lot quicker!)

[bacongobbler]

To reproduce that issue, did you stand up a cluster, run spin login, shut down the cluster, then ran spin deploy?

[itowlson]

My specific scenario - and the weird and dev-specific way it happened may mean it's not a real issue - was:

• Build this PR
• spin login using GH auth and do a deployment
• Switch back to Spin main
• Create an AWS cluster using the installer, export the environment variables (all as per installer instructions), do a deployment
• Destroy the AWS cluster (terraform destroy)
• Switch back to this PR
• spin login which this time picked up the dangling Hippo environment variables

[itowlson]

To be clear, it was that last login which gave the error, not any deploy.

[bacongobbler]

I managed to reproduce #794 (comment):

><> env | grep HIPPO
HIPPO_PASSWORD=bar
HIPPO_USERNAME=foo
HIPPO_URL=http://localhost:5309
><> env | grep BINDLE
BINDLE_URL=http://localhost:8080/v1
><> spin login
What authentication method does this server support?

1. Sign in with GitHub
2. Sign in with a username and password

Enter a number: 2
Error: expected value at line 1 column 1

The actual error is this:

error in reqwest: error sending request for url (http://localhost:5309/api/auth-tokens): error trying to connect: tcp connect error: Connection refused (os error 111)

This is because the call to format_login_error on line 182 does not account for tcp connection errors. It always assumes the input error string will be JSON.

This issue was present on main as well. I'll see about fixing the error message.

[itowlson]

The last rebase introduced a call to wait_for_ready on the Hippo flow - flagging this up for the Cloud flow too. (Sorry, I should have looped you in on the PR where that was introduced.)

[itowlson]

This is working great for me! Thanks for battling through all the issues.