KEP-5008: Introduce Kubernetes Desktop #5009
Conversation
joaquimrocha
commented
Dec 19, 2024
joaquimrocha
commented
- One-line PR description: Adding new KEP 5008 for introducing a Kubernetes Desktop project
- Issue link: Introduce Kubernetes Desktop #5008
- Other comments:
Signed-off-by: Joaquim Rocha <[email protected]>
k8s-ci-robot
added
the
kind/kep
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: joaquimrocha The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
cncf-cla: yes
|
Welcome @joaquimrocha! |
k8s-ci-robot
added
the
needs-ok-to-test
|
Hi @joaquimrocha. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
k8s-ci-robot
added
the
size/XL
joaquimrocha
force-pushed
the
kep-5008
branch
from
d1740ee to
afba2eb
Compare
| Effectively this entails moving the Headlamp project under the Kubernetes | ||
| GitHub organization and under the auspices of Kubernetes SIG UI. To be | ||
| specific, we would propose that the Headlamp project be moved to a repo under | ||
| the Kubernetes project; something to the effect of kubernetes/ui. |
There was a problem hiding this comment.
Alternative: we could still call it Headlamp.
There was a problem hiding this comment.
As we are proposing to bring the project under the Kubernetes umbrella, our thinking is that having a separate branding (Headlamp) could be confusing for users and developers.
There was a problem hiding this comment.
- We could list "Kubernetes Headlamp" as an alternative to "Kubernetes Desktop".
- We need a name for the bits of Headlamp that are not Kubernetes Desktop
- We have a precedent for components of Kubernetes that have their own name; for example: etcd.
| ## Release Signoff Checklist | ||
|
|
||
| <!-- | ||
| **ACTION REQUIRED:** In order to merge code into a release, there must be an | ||
| issue in [kubernetes/enhancements] referencing this KEP and targeting a release | ||
| milestone **before the [Enhancement Freeze](https://git.k8s.io/sig-release/releases) | ||
| of the targeted release**. | ||
|
|
||
| For enhancements that make changes to code or processes/procedures in core | ||
| Kubernetes—i.e., [kubernetes/kubernetes], we require the following Release | ||
| Signoff checklist to be completed. | ||
|
|
||
| Check these off as they are completed for the Release Team to track. These | ||
| checklist items _must_ be updated for the enhancement to be released. | ||
| --> | ||
|
|
||
| Items marked with (R) are required *prior to targeting to a milestone / release*. | ||
|
|
||
| - [ ] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR) | ||
| - [ ] (R) KEP approvers have approved the KEP status as `implementable` | ||
| - [ ] (R) Design details are appropriately documented | ||
| - [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors) | ||
| - [ ] e2e Tests for all Beta API Operations (endpoints) | ||
| - [ ] (R) Ensure GA e2e tests meet requirements for [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) | ||
| - [ ] (R) Minimum Two Week Window for GA e2e tests to prove flake free | ||
| - [ ] (R) Graduation criteria is in place | ||
| - [ ] (R) [all GA Endpoints](https://github.com/kubernetes/community/pull/1806) must be hit by [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) | ||
| - [ ] (R) Production readiness review completed | ||
| - [ ] (R) Production readiness review approved | ||
| - [ ] "Implementation History" section is up-to-date for milestone | ||
| - [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io] | ||
| - [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes | ||
|
|
||
| <!-- | ||
| **Note:** This checklist is iterative and should be reviewed and updated every time this enhancement is being considered for a milestone. | ||
| --> | ||
|
|
||
| [kubernetes.io]: https://kubernetes.io/ | ||
| [kubernetes/enhancements]: https://git.k8s.io/enhancements | ||
| [kubernetes/kubernetes]: https://git.k8s.io/kubernetes | ||
| [kubernetes/website]: https://git.k8s.io/website |
There was a problem hiding this comment.
There's a way to handle KEPs not tied to a Kubernetes release; I think this one wouldn't be. Have I got that right?
There was a problem hiding this comment.
I agree. I wasn't sure if for the sake of the KEP formatting I had to keep this around. Should I remove it then?
| views or links to my projects resources. This allows the user to easily | ||
| navigate between the projects. (Ex. Backstage plugin) | ||
|
|
||
| The current Kubernetes Dashboard only supports part of Story 3. |
There was a problem hiding this comment.
This looks like it is part of Story 3; consider moving it.
| As a vendor I want to create a new Kubernetes user interface for my system. I | ||
| take Headlamp Base and build a set of plugins and take some of the existing | ||
| plugins to create my custom UI. I customize the UI with my company/product | ||
| branding and provide that to my users with or without them knowing it’s | ||
| Headlamp. If I desire, I can even allow my users to extend my customer UI using | ||
| the same way I did. |
There was a problem hiding this comment.
Can this be done right now with the existing Headlamp? If so, maybe we should mention that.
There was a problem hiding this comment.
Yes, this is possible right now (all user stories are possible ATM, except when indicated by notes, like the minikube plugin being a POC still). How can we indicate that we do support these more explicitly?
| <!-- | ||
| Detail the things that people will be able to do if this KEP is implemented. | ||
| Include as much detail as possible so that people can understand the "how" of | ||
| the system. The goal here is to make this feel real for users without getting | ||
| bogged down. | ||
| --> |
There was a problem hiding this comment.
A few ideas for more stories we could maybe want to support one day:
-
as an add-on vendor / author, I define a custom resource using a Headlamp plugin CRD. Now, when people deploy my add-on, they can automatically benefit from the plug-in for my addon.
-
I have made a specialised control plane based on projects similar to Kubernetes [I'm thinking KCP and Crossplane]. I use Headlamp against the specialised control plane to deploy a Kubernetes cluster, or to update it based on my desired state.
-
as an appliance vendor, I build an edge appliance that bundles Kubernetes as a way to manage components. I make a custom version of Headlamp and have it serve as the administrative console for the appliance. Customers using the appliance can install addons that integrate with the main admin console.
There was a problem hiding this comment.
Thanks. I think the 2nd and 3rd suggestions here are already covered by Story 4, in that a Headlamp plugin can be used for a variety of goals (like using a different control plane, or as an admin console for an appliance), besides the actual user interfaces associated with it. Should we write these suggestions as examples in this story, or do you think they are not covered by our stories we should have it more explicitly?
About the 1st suggestions, can you elaborate a bit? Are you saying a CRD has info on what specific Headlamp plugin that is associated with it? This could be a good idea actually: e.g. Headlamp checks CRDs for a specific spec that indicates what plugin is associated with it (if any) and suggest to the user that they may install it (if not yet installed).
There was a problem hiding this comment.
I'm imagining an addon manager that deploys lots of elements for an addon: the CRD, the operator / controller, the Headlamp plugin, and more.
There was a problem hiding this comment.
Maybe there is an API kind named HeadlampPlugin, a bit like the Prometheus operators has an API kind named ServiceMonitor.
There was a problem hiding this comment.
Being able to deploy a Headlamp plugin via an operator would be a nice (eventual) touch, I think.
Signed-off-by: Joaquim Rocha <[email protected]>
