-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat/image builder api #614
base: kpack-resources
Are you sure you want to change the base?
Conversation
$ref: "#/components/schemas/ContainerImage" | ||
builder_id: | ||
$ref: "#/components/schemas/ULID" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we want a separate endpoint for creating builders and then have image and builder_id as properties here, or should they just be POST on this endpoint with a oneOf:
body?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was one of the main questions. I am open to both. Waiting for input.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The indirection adds complexity for clients. I do not think that we have an expectation of the relation going from {0,1}:1 to 1:N at any time. A "builder" belongs to a single session launcher.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it ? I'm currently unsure about all the implications. Let's discuss this in a technical meeting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed these endpoints. Now, BuildParameter
is part of session launcher API.
- CONDA | ||
- PIP | ||
- R | ||
- DOCKERFILE | ||
EditorKind: | ||
description: User's Editor Choice. | ||
type: string | ||
enum: | ||
- VSCODIUM | ||
- JUPYTERLAB | ||
- STREAMLIT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is consistent with what was in this apispec before, but I noticed that a lot of the enums in our API use lower-case values, and this file is the only place that uses UPPER case ones. maybe this build would be a good opportunity to make this consistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted. I will make it consistent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one thing, the UPPER CASE might have been because of the global
reserved keyword. How do you think this should be resolved ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I resolved it the way the python operator library does, by adding an underscore after the reserved keyword. It's now global_
. I'm not very happy with that but that would be a way of doing it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh I didn't think of that. I wonder if there's some customization that can be done in the datamodel codegen. Also note that this is a breaking change in the API and shoudl be discussed with the UI
@@ -531,11 +641,105 @@ components: | |||
description: A description for the resource | |||
type: string | |||
maxLength: 500 | |||
ImageBuilder: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should call this something else, as this is not really a builder. We have a BuildStrategy which references a Builder in k8s, having Builder here again could cause confusion. It's more like a build strategy reference with parameters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of ImageBuilder
would something like ImageBuildParameters
do the trick ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renamed to BuildParameter
for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments about the API spec:
$ref: "#/components/schemas/ContainerImage" | ||
builder_id: | ||
$ref: "#/components/schemas/ULID" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The indirection adds complexity for clients. I do not think that we have an expectation of the relation going from {0,1}:1 to 1:N at any time. A "builder" belongs to a single session launcher.
- global | ||
- custom | ||
- builder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing the casing creates an API breaking change. Do we want this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comments above, currently our API is inconsistent in terms of casing (most enums are lower case, this file is one of the few places where it's upper case). This isn't really related to this PR, my thinking was just, if we change the API here anyways, might be a good point to make it consistent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I undid this change since it requires a database migration as well. I'll re-introduce it later once working on the db.
35bcb23
to
36280a0
Compare
@m-alisafaee Can you fix the commit list? This PR is against |
36280a0
to
127e5f0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The type union on EnvironmentPostInLauncher
is nice 👍
I think the same should be done to Environment
and EnvironmentPatchInLauncher
because non-sensical values would be allowed.
I did the same for |
e993bf5
to
24e8145
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two invalid schema errors (see below). There are more potential pitfalls (see below), but we can start from here.
b982af2
to
05a69b1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 OK for api.spec.yaml
🙌
bf24f13
to
622accd
Compare
This PR provides a draft of what could be the updated API to include ImageBuilders.