[nexus] Add stubs for image APIs #749
Conversation
smklein
changed the title
nexus/src/external_api/params.rs
Outdated
| pub identity: IdentityMetadataCreateParams, | ||
| } |
There was a problem hiding this comment.
We need more here to actually be able to create the image.
Do we want this to be an enum implying "Please provide one of a {file, snapshot UUID, URL}"? Do we want that to all be done through the same endpoint?
There was a problem hiding this comment.
Probably, yeah - this maps almost directly to the read only parent Volume. "file" seems dangerous to expose externally, but snapshot UUID and URL could be our start. It may also be that an extra field is only necessary for non-global images (aka you don't have to specify anything for Ubuntu 21.10, Nexus knows what that is)
There was a problem hiding this comment.
Added an enum of "snapshot UUID or URL". We can continue to add extra params as necessary.
common/src/sql/dbinit.sql
Outdated
| time_deleted TIMESTAMPTZ, | ||
|
|
||
| project_id UUID, | ||
| volume_id UUID NOT NULL, |
There was a problem hiding this comment.
Once the image has been constructed, it'll refer to a particular volume.
For the case of e.g. POST-ing an image by URL, would we immediately download + store the image as a part of invoking the POST request?
- If yes: Cool, this structure should work. We'll create a saga that does that work.
- If no: This structure may need to be more complex - we'll need to store the URL too.
There was a problem hiding this comment.
This is currently an unsolved problem, though that answer will likely be the same as others: some block migration task will move blocks from the read only parent to the volume region set(s), then remove the read only parent later. We can't gate the instance boot or image creation on that download though.
There was a problem hiding this comment.
Okay. I'll leave this question open as an implementation detail for follow-up PRs
| @@ -370,6 +370,26 @@ CREATE INDEX ON omicron.public.disk ( | |||
| ) WHERE | |||
| time_deleted IS NULL AND attach_instance_id IS NOT NULL; | |||
|
|
|||
| CREATE TABLE omicron.public.image ( | |||
There was a problem hiding this comment.
RFD 4 mentions the following fields which are not yet stored here (nor a part of the API):
- version
- digest
- status
| #[endpoint { | ||
| method = GET, | ||
| path = "/organizations/{organization_name}/projects/{project_name}/images", | ||
| tags = ["images"], |
There was a problem hiding this comment.
| tags = ["images"], | |
| tags = ["projects"], |
There was a problem hiding this comment.
Is there documentation on what tag should be associated with what endpoint? I think I might not be understanding this fully. I thought that an operation acting on:
path = "/organizations/{organization_name}/projects"
Would be tagged with projects, but an operation acting on:
path = "/organizations/{organization_name}/projects/{project_name}/foobar"
Would be tagged with foobar(s).
Are both supposed to be tagged with projects? If we keep nesting, is it just projects all the way down?
| #[endpoint { | ||
| method = POST, | ||
| path = "/organizations/{organization_name}/projects/{project_name}/images", | ||
| tags = ["images"] |
There was a problem hiding this comment.
| tags = ["images"] | |
| tags = ["projects"] |
| #[endpoint { | ||
| method = GET, | ||
| path = "/organizations/{organization_name}/projects/{project_name}/images/{image_name}", | ||
| tags = ["images"], |
There was a problem hiding this comment.
| tags = ["images"], | |
| tags = ["projects"], |
| #[endpoint { | ||
| method = DELETE, | ||
| path = "/organizations/{organization_name}/projects/{project_name}/images/{image_name}", | ||
| tags = ["images"], |
There was a problem hiding this comment.
| tags = ["images"], | |
| tags = ["projects"], |
|
sorry if the fmt is off in my suggestions. Wrote them by hand but will align well with #773 when merged |
|
Yeah that’s fair I missed 770, is there a way to grep replace of I can do by hand, the content is mostly what matters |
|
Hey @jessfraz , I incorporated your recommended comments. Regarding the tags, I added documentation for "images" to |
|
Awesome, tags and docs look great! |
First part of #734