Add capsul info endpoint #4
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I've implemented automagic creation of capsuls in our Co-op Cloud CLI over in
5294e84and currently you run it like so:abra server new capsul -I yolo.servers.coop -s sshkey@example.com mynewvm(We have the API changes patched into our servers.coop instance for testing)
I noticed that it takes around 10 seconds to respond.
It only returns the VM ID, and doesn't take into account the new specific on the CLI (mynewvm). Could we get that name set also instead of the auto-generated one?
It'd be great if we could get back some extra meta information in the response. IPv4 and what else? Not sure. Here is an example of what Hetzner Cloud sends back on server create: https://docs.hetzner.cloud/#servers-create-a-server.
Super exciting stuff, lemme know how I can help.
~threewordchanta month ago · edit
I'd like to see a human-readable name; that would require DB and UI changes elsewhere, suggest we open a separate ticket.
I don't think we can easily get IPv4 back on a create, because it takes a few more seconds for it to get assigned an address via DHCP. I was thinking of adding a "capsul info" API endpoint, would it be reasonable to get abra to run that after, to get the IP and other metadata?
~doubtsurgea month ago · edit
I'd like to see a human-readable name; that would require DB and UI changes elsewhere, suggest we open a separate ticket.
Will do :)
I don't think we can easily get IPv4 back on a create, because it takes a few more seconds for it to get assigned an address via DHCP. I was thinking of adding a "capsul info" API endpoint, would it be reasonable to get abra to run that after, to get the IP and other metadata?
Yes, sounds good! We'll just poll that endpoint and show "booting up" or whatever on the CLI side. I see that the web UI also provides this UI/UX so maybe there is something to re-use from there?
~doubtsurge referenced this from #92a month ago
~doubtsurgea month ago · edit
I've updated the title to reflect focussing on the capsul info endpoint then.
#92 is for the naming change.
~doubtsurgea month ago · edit
Depends on #84.
~foresta month ago* · edit
The flow in the web UI is that the user gets dumped back to the capsuls list page where they can see the new capsul and see that it is "booting" it does not have an IP yet. Then the user can click on the link to the capsul detail page where they can hopefully see the IP once it finishes booting up. This is similar to AWS and other providers AFAIK.
If we make the CLI block until the capsul gets an IP address, it could potentially cause usability issues... if the capsul takes forever to get an IP the user will press Ctrl-C, but the capsul already got created and most likely the create fully succeeded, now the users perspective of what happened is totally different from what actually happened. We should avoid that if possible.
I think this behavior should be hidden behind a command line flag if it is included at all.
By default, I think the CLI should display whatever information it can immediately post create, like:
Your capsul "capsul-sgx097av9" has been created and it is now starting up!
It should receive a public IP address within a few seconds...
You may check on its status with:
abra capsul get capsul-sgx097av9
or maybe "abra capsul info capsul-sgx097av9" or "abra capsul get-info capsul-sgx097av9"
~foresta month ago* · edit
EDIT: I thought about implementing a "transactional create" endpoint where it would create the capsul and then block until it gets an IP, but that was a bad idea. Sometimes getting an IP address might take an arbitrarily long amount of time. Blocking inside an HTTP request handler for an arbitrary amount of time is a HUGE nono, because the client can't always set their HTTP timeout. Sometimes its not possible.
~foresta month ago* · edit
...
~foresta month ago* · edit
...
~foresta month ago* · edit
Alternatively we could look into some sort of weird "required polling / keepalive" behavior where the transactional create endpoint doesn't block on anything, not even the VM creation, it instead returns the nonce request ID instantly.
And then the client has to keep polling that request ID until its done, otherwise it will treat it as a failed transaction and eventually delete the capsul. I have never seen any APIs that are structured like this before so it seems like kind of a bad idea for that reason.. but besides that I like it a lot, it makes it so the request is canceled if the client hangs up, and it makes it so the client gets status updates while they wait + when their operation finally "succeeds" it REALLY succeeds: it gives the IP address, the SSH host public keys, etc etc.
~foresta month ago* · edit
If we did that we should maybe put it under a very specific URL path like
POST https://capsul.org/api/automation_support/transactional_create
or
POST https://capsul.org/api/robots_only_beyond_this_point/transactional_create
as its obviously not curl-able by hand.
~doubtsurgea month ago · edit
Nice!
For our current needs, abra is just doing server creation and then initialising docker/swarm mode on them. Other VM lifecycle commands will probably come but that is Future Brain. We need to get an IPv4 address back for initialising (which Hetzner supports). I'd like to avoid having the user run create, read the output, copy/pasta the command, run it a few times until they see the IPv4 and then put that into the following init commands. If we get that IPv4 back in some reasonable time, we can use progress bars and such to keep the user informed on progress.
So yes, the transactional create approach with ID/nonce handling would be ideal.
~threewordchanta month ago · edit
I'm leaning towards shunting responsibility to API clients to poll for an IP after creation, at this stage. "transactional create" seems like a great long-term way of doing what Hetzner does, but given we get the Capsul ID in the create already, then the polling seems it should be fairly straightforward.
~foresta month ago* · edit
We need to get an IPv4 address back for initialising
You "need" the SSH host public keys too 🥺 👉👈... And that goes for other providers as well, not just capsul.
If you are already are running additional config steps on it after you get the full vm info, then polling on the client side makes perfect sense. its reasonable to just leave the VM there & not delete it if it fails half way through (user kill -SIGKILL's your process)
~doubtsurgea month ago · edit
You "need" the SSH host public keys too 🥺 👉👈... And that goes for other providers as well, not just capsul.
Right you are!