feat: listvalues endpoint WIP by divysinghvi · Pull Request #875 · kubeflow/notebooks

divysinghvi · 2026-01-31T10:26:10Z

Stub /listvalues endpoint (#691)

Implements stub POST /api/v1/workspacekinds/{name}/podtemplate/options/listvalues endpoint.

Changes:

Returns filtered imageConfig/podConfig options with rule_effects.ui_hide: false
Supports context-based filtering by imageConfig.id and podConfig.id
Includes Swagger documentation

Note: Full compatibility selector rules to be implemented in follow-up work.

…#691) Signed-off-by: Divy Singhvi <divysinghvi5@gmail.com>

google-oss-prow · 2026-01-31T10:26:16Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign andyatmiami for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

workspaces/backend/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

andyatmiami

@divysinghvi

Really appreciate you raising this PR and starting to make real some of the abstract thoughts we have had in this area.

Seeing the code really made me think through what this would look like from a golang perspective - which the API Proposal and guidance I had provided you thus far didn't really speak to (instead really focusing on the JSON structure itself).

As we are still clearly trying to harden and establish "best practices" in this repo - feel free to push back and/or question any of the comments I have made. Happy to continue discussions as necessary to ensure you understand the underlying motivation as well as agree on the outcome.

Look forward to continuing to collaborate and getting this PR eventually merged! 💯

andyatmiami · 2026-02-08T16:27:24Z

workspaces/backend/api/app.go

We should discuss if ListValues is a "good enough" prefix vs. something (sadly wayy more verbose and) specific.

ex: PodTemplateOptionsListValues

Hard to know right now - but if/as we add non PodTemplate data structures in the future - its possible ListValues is misleadingly vague.

@andyatmiami Yes I agree, this will be more detailed even though it is a bit verbose.

andyatmiami · 2026-02-08T16:41:57Z

workspaces/backend/api/workspacekinds_handler.go

+	// parse request body
+	var requestBody models.ListValuesRequest
+	if err := a.DecodeJSON(r, &requestBody); err != nil {
+		a.badRequestResponse(w, r, err)
+		return
+	}


After decoding the request payload - we want to make sure we are validating the contents. Existing codebase strives for a clear/repeatable pattern in how this is accomplished:

Handler Pattern (e.g., secrets_handler.go, workspaces_handler.go)

// validate the request body dataPath := field.NewPath("data") if bodyEnvelope.Data == nil { valErrs := field.ErrorList{field.Required(dataPath, "data is required")} a.failedValidationResponse(w, r, errMsgRequestBodyInvalid, valErrs, nil) return } valErrs = bodyEnvelope.Data.Validate(dataPath) if len(valErrs) > 0 { a.failedValidationResponse(w, r, errMsgRequestBodyInvalid, valErrs, nil) return }

Model Validate Pattern (e.g., workspaces/types_write.go)

func (w *WorkspaceCreate) Validate(prefix *field.Path) []*field.Error { var errs []*field.Error // validate the workspace name namePath := prefix.Child("name") errs = append(errs, helper.ValidateWorkspaceName(namePath, w.Name)...) // validate nested struct podTemplatePath := prefix.Child("podTemplate") errs = append(errs, w.PodTemplate.Validate(podTemplatePath)...) return errs }

ℹ️ As your request payload simply acts as filters - your model definitions defined in a types.go is the proper way to be structured!

I would follow/adhere to existing patterns when calling DecodeJSON

For instance, in secrets_handler.go (and/or most files) - you see this pattern:

// parse request body bodyEnvelope := &SecretCreateEnvelope{} err := a.DecodeJSON(r, bodyEnvelope) if err != nil { if a.IsMaxBytesError(err) { a.requestEntityTooLargeResponse(w, r, err) return } // // TODO: handle UnmarshalTypeError and return 422, // decode the paths which were failed to decode (included in the error) // and also do this in the other handlers which decode json // a.badRequestResponse(w, r, fmt.Errorf("error decoding request body: %w", err)) return }

Lets structure similarly in this PR.

Done in #972 (WIP for comments below)

andyatmiami · 2026-02-08T16:45:50Z

workspaces/backend/internal/models/workspacekinds/types.go

This it TOTALLY MY FAULT and I humbly apologize for the oversight, but we use camelCase in our backend API - and I have no idea why I forgot this when originally drafting up the API spec 😢

The following kebab_case attributes should be moved to camelCase:

rule_effects -> ruleEffects

ui_hide -> uiHide

Done in #972

andyatmiami · 2026-02-08T16:51:30Z

workspaces/backend/internal/models/workspacekinds/funcs.go

+}
+
+func buildImageConfigValuesWithRules(imageConfig ImageConfig, context *ListValuesContext) []ImageConfigValueWithRules {
+	values := []ImageConfigValueWithRules{}


Suggested change

values := []ImageConfigValueWithRules{}

// Pre-allocate to avoid repeated allocations and copies

values := make([]ImageConfigValueWithRules, 0, len(imageConfig.Values))

Done in #972

andyatmiami · 2026-02-08T16:52:33Z

workspaces/backend/internal/models/workspacekinds/funcs.go

+}
+
+func buildPodConfigValuesWithRules(podConfig PodConfig, context *ListValuesContext) []PodConfigValueWithRules {
+	values := []PodConfigValueWithRules{}


Suggested change

values := []PodConfigValueWithRules{}

// Pre-allocate to avoid repeated allocations and copies

values := make([]PodConfigValueWithRules, 0, len(podConfig.Values))

Done in #972

andyatmiami · 2026-02-08T17:25:01Z

workspaces/backend/internal/models/workspacekinds/types.go

+
+type ListValuesRequest struct {
+	Data ListValuesRequestData `json:"data"`
+}
+
+type ListValuesRequestData struct {
+	Context *ListValuesContext `json:"context,omitempty"`
+}
+


Suggested change

type ListValuesRequest struct {

Data ListValuesRequestData `json:"data"`

}

type ListValuesRequestData struct {

Context *ListValuesContext `json:"context,omitempty"`

}

// REMOVE this - it duplicates Envelope

// type ListValuesRequest struct {

// Data ListValuesRequestData `json:"data"`

// }

// KEEP this - it has the "context" field

type ListValuesRequest struct {

Context *ListValuesContext `json:"context,omitempty"`

}

💡 Please note that I changed the remaining model here from ListValuesRequestData to ListValuesRequest

In api/workspacekinds_handler.go:

// Use the standard Envelope pattern wrapping ListValuesRequest type ListValuesRequestEnvelope Envelope[*models.ListValuesRequest]

Done in #972

andyatmiami · 2026-02-08T17:32:05Z

workspaces/backend/api/workspacekinds_handler.go

+		a.failedValidationResponse(w, r, errMsgPathParamsInvalid, valErrs, nil)
+		return
+	}
+


We want to be consistent with the other API endpoints in notebooks-v2.

After path param validation - given we are parsing a request body - we need need to validate content-type here:

// validate the Content-Type header if success := a.ValidateContentType(w, r, MediaTypeJson); !success { return }

you can see this pattern in effect (for instance) here:

https://github.com/kubeflow/notebooks/blob/notebooks-v2/workspaces/backend/api/secrets_handler.go#L166C1-L169C3

Done in #972

andyatmiami · 2026-02-08T17:33:56Z

workspaces/backend/api/workspacekinds_handler.go

 	a.createdResponse(w, r, responseEnvelope, location)
 }
+
+// ListValuesHandler returns filtered imageConfig and podConfig options for a WorkspaceKind.


Based on other PR review comments I have made - I think we need to update annotations to reflect other 4xx status codes that can be returned:

// @Failure 413 {object} ErrorEnvelope "Request Entity Too Large. The request body is too large." // @Failure 415 {object} ErrorEnvelope "Unsupported Media Type. Content-Type header is not correct." // @Failure 422 {object} ErrorEnvelope "Unprocessable Entity. Validation error."

reference: https://github.com/kubeflow/notebooks/blob/notebooks-v2/workspaces/backend/api/secrets_handler.go#L150C1-L152C86

Done in #972

andyatmiami · 2026-02-08T17:42:34Z

workspaces/backend/internal/models/workspacekinds/types.go

Given existing pattern we are starting to form (with SecretListItem and WorkspaceListItem - how do you feel about the following naming conventions?

Use <Entity>ListItem pattern for semantic alignment:

// Consistent with SecretListItem, WorkspaceListItem type ImageConfigValueListItem struct { ImageConfigValue RuleEffects RuleEffects `json:"ruleEffects"` } type PodConfigValueListItem struct { PodConfigValue RuleEffects RuleEffects `json:"ruleEffects"` } // Response structs type ImageConfigListResult struct { Default string `json:"default"` Values []ImageConfigValueListItem `json:"values"` } type PodConfigListResult struct { Default string `json:"default"` Values []PodConfigValueListItem `json:"values"` } type ListValuesResponse struct { ImageConfig ImageConfigListResult `json:"imageConfig"` PodConfig PodConfigListResult `json:"podConfig"` }

Done in #972

feat: stub /listvalues endpoint for Compatibility Selectors (kubeflow…

8907383

…#691) Signed-off-by: Divy Singhvi <divysinghvi5@gmail.com>

github-project-automation bot added this to Kubeflow Notebooks Jan 31, 2026

github-project-automation bot moved this to Needs Triage in Kubeflow Notebooks Jan 31, 2026

google-oss-prow bot added the area/backend area - related to backend components label Jan 31, 2026

google-oss-prow bot requested review from andyatmiami and kimwnasptd January 31, 2026 10:26

google-oss-prow bot added area/v2 area - version - kubeflow notebooks v2 size/XL labels Jan 31, 2026

divysinghvi changed the title ~~Feat: listvalues endpoint WIP~~ feat: listvalues endpoint WIP Jan 31, 2026

andyatmiami suggested changes Feb 8, 2026

View reviewed changes

google-oss-prow bot assigned andyatmiami Feb 8, 2026

This was referenced Mar 12, 2026

Akrem chabchoub/stub listvalues divysinghvi/notebooks#1

Closed

feat: enhance ListValues request handling with validation WIP #961

Closed

feat: implement and enhance ListValues endpoint with validation, transformations, and API updates #972

Open

	values := []ImageConfigValueWithRules{}
	// Pre-allocate to avoid repeated allocations and copies
	values := make([]ImageConfigValueWithRules, 0, len(imageConfig.Values))

	values := []PodConfigValueWithRules{}
	// Pre-allocate to avoid repeated allocations and copies
	values := make([]PodConfigValueWithRules, 0, len(podConfig.Values))

Conversation

divysinghvi commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Stub /listvalues endpoint (#691)

Uh oh!

google-oss-prow bot commented Jan 31, 2026

Uh oh!

andyatmiami left a comment

Choose a reason for hiding this comment

Uh oh!

andyatmiami Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akrem-chabchoub Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

divysinghvi commented Jan 31, 2026 •

edited

Loading

andyatmiami Feb 8, 2026 •

edited

Loading

akrem-chabchoub Mar 12, 2026 •

edited

Loading