Skip to content

[TASK] Backend can read data served by envtest #380

@andyatmiami

Description

@andyatmiami

Description

k8s (and KinD) are extremely powerful platforms, but with that power comes added complexity/dependencies. A developer willing to contribute front end code to the project may be discouraged by the added overhead of requiring a k8s cluster (including KinD), particularly if they have issues setting up and/or maintaining this dependency - particularly if its not working for any variety of reasons.

We believe envtest can play a critical role in not only helping in testing, but also in enabling a more streamlined experience for frontend developers, tackling the issue above.

With the separation provided by the backend (proxy) layer, we have a nice architecture to drive this solution. We want to be able to structure the code, such that when a feature flag is set, calls from the backend to read/interact with (today) a k8s cluster could instead by serviced by envtest.

This design pattern has already been implemented by Kubeflow Model Registry.

Please note the initial requirements for this work are much simpler as compared to the current Model Registry implementation. Model Registry should only be used as a reference to help understand the basic structure of the code.
- Specifically, this issue is NOT focused on adding the support of various authentication schemes!

At a high level, the desire is to have:

  • a "client factory" that encapsulates the current logic of the notebooks-v2 branch
  • a "client factory" that allows reading data from envtest
  • a feature flag that gives developers the ability to toggle which "mode" to run the application

Acceptance Criteria

  • As a frontend developer, I should be able to run the frontend and backend process of kubeflow/notebooks locally without any k8s cluster available, and still be able to have meaningful interactions in the UI.
  • At least a single namespace, with a single workspace kind, with a single workspace should be able to be retrieved in the UI

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

Status

Hold

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions