feat: add HEAD /api/v1/network/{network} route
#41
Conversation
MicaiahReid
changed the title
HEAD /api/v1/network/{network} route
|
All of these changes sound great 👍 Question on this:
Will this return some kind of |
| .try_log(|logger: &hiro_system_kit::Logger| slog::info!(logger, "{}", msg)); | ||
| Err(DevNetError { | ||
| message: msg, | ||
| code: 404, |
There was a problem hiding this comment.
To answer my own question - it looks like no, this would return a 404, not something indicating a "pending" state. To determine if a devnet is in process of starting up, would the right check be if this GET returns a 404 but the HEAD returns a 200? That implies that some, but not all, assets exist?
There was a problem hiding this comment.
Hmm, that's a good question. Having to check both endpoints would be tedious.
Whenever you create a devnet, all assets should nearly immediately be created*. If you immediately make this GET request, it should not return a 404 response, and the status should show as "Pending" for a pod that is starting up. Deletion, however, takes some time, so if you hit the DELETE endpoint, then query this endpoint, you should get 404 because some items are deleted and others aren't.
If you find that you're getting 404s a lot when you don't think you should, let me know. Maybe we can find a better fix than this. I definitely don't want you to have to see if GET returns 404 and HEAD returns 200 to know if a devnet is starting.
*There is currently an exception on all assets being created very quickly. When you receive a response from creating a devnet all assets should exist in kubernetes. However, if you query the GET endpoint before the creation request is made, you could get a 404 on the GET request. I currently have a 5 second delay in the middle of devnet creation, which I will hopefully be able to remove soon. This will make creating a devnet much faster.
There was a problem hiding this comment.
This makes sense, and should work just fine for the app. If I'm seeing more 404s than expected I'll definitely let you know.
## 1.0.0 (2023-11-16)
### Features
* add `HEAD /api/v1/network/{network}` route ([#41](#41)) ([1bf329f](1bf329f))
* add logging and network info route ([#20](#20)) ([2af0bab](2af0bab)), closes [#21](#21)
* proxy http requests to downstream pods ([#11](#11)) ([6ecdf0f](6ecdf0f))
* release develop ([#84](#84)) ([89a1a1b](89a1a1b))
### Bug Fixes
* add access_control_allow_credentials header ([a482a93](a482a93))
* add cors settings; refactor http responses ([#42](#42)) ([c46db4c](c46db4c)), closes [#21](#21)
* assert more general error msg ([#48](#48)) ([926e3a0](926e3a0))
* create namespace in deploy api script ([f5ff5e0](f5ff5e0))
|
🎉 This PR is included in version 1.0.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This PR:
HEAD /api/v1/network/{network}routeOK 200if any devnet assets exist for the provided network. If this endpoint is responding with 200, any attempts toPOST /api/v1/networkswith this same network key will fail.404if no devnet assets exist for the provided network. This indicates that aPOST /api/v1/networksshould be successful for that networkPOST /api/v1/networkschecks if any assets exist for the given network id before creating a devnet. If they do, no new assets are createdDELETE /api/v1/network/{network}checks if any assets exist before deleting devnet assets for the given network id. If any exist, devnet assets are deleted. If not, the function returns without attempting any deletions.GET /api/v1/network/{network}checks to ensure all devnet assets are created before getting devnet infoGET/POST /api/v1/network/{network}/*checks to ensure all devnet assets are created before proxying requestsFixes #36, fixes #39, fixes #5