kubeflow / kubeflow/notebooks

[TASK] Expose structured workspace status in backend API

Open
#1,194 2 comments 0 reactions 0 assignees View on GitHub
kind/plan-task
Dominant language
No language data
Stars
84
Forks
149
Avg merge
5d 15h
Merged PRs (30d)
29

Description

### Certification

- [x] I certify I am an Epic Owner for Kubeflow Notebooks 2.0 and expected to create planning-related issues.

### Description

🛑 **Depends on:** #1193

Updates the backend API response models to expose the structured sub-states alongside the existing
summary state. The backend should NOT re-derive or transform the sub-states — it should pass them
through from the CRD status as-is. The controller is the single source of truth for state.

#### Goals

- Add sub-state fields to the Workspace API response model
(`workspaces/backend/internal/models/workspaces/types.go`)
- Add conversion logic to map CRD status sub-state types to API response models
(`workspaces/backend/internal/models/workspaces/funcs.go`)
- The summary `state` and `stateMessage` fields remain as-is for backward compatibility
- Regenerate swagger documentation (`make swag`)
- Unit tests for the new model mapping

#### Implementation Notes

The backend currently does a direct pass-through of `state` and `stateMessage`:

```go
State: ws.Status.State,
StateMessage: ws.Status.StateMessage,
```

The sub-states should follow the same pattern — map CRD types to API response types without
transformation. If the CRD sub-state types are simple enough (enums, bools, strings), the API
types may be identical. If they use k8s-specific types (metav1.Time, etc.), conversion is needed.

### Acceptance Criteria

- [ ] Backend API response includes structured sub-state fields alongside summary `state`
- [ ] Summary `state` and `stateMessage` remain present and unchanged for backward compatibility
- [ ] Sub-states are passed through from CRD status without re-derivation
- [ ] Swagger documentation is regenerated and includes sub-state schemas
- [ ] Unit tests verify sub-state mapping from CRD status to API response
- [ ] No changes to frontend-facing files (`src/generated/`, etc.)

Contributor guide

Open the contributing guide

Research direction

Start in workspaces/backend/internal/models/workspaces/types.go and funcs.go, then inspect the CRD status types used by the existing state and stateMessage mapping. Add the structured sub-state response fields and pass their values through without re-derivation. Verify the mapping with unit tests and run make swag; done means the API and Swagger schemas include the sub-states while the existing summary fields remain unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
api, backend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.