KEP-5008: Introduce Kubernetes Desktop

[joaquimrocha]

• One-line PR description: Adding new KEP 5008 for introducing a Kubernetes Desktop project

• Issue link: Introduce Kubernetes Desktop #5008

• Other comments:

[k8s-ci-robot]

Welcome @joaquimrocha!

It looks like this is your first PR to kubernetes/enhancements 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/enhancements has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

[floreks]

In general, I think that Headlamp will be a great addition to the SIG-UI. The only requirements in my opinion for introducing new projects should be:

• Adds value to the community
• Is actively maintained

I think that both of these are met here.

[maciaszczykm]

I think bringing Headlamp to the Kubernetes organization is a great idea. It gives users to more options and hopefully allow Headlamp to grow even more. I think the document requires some updates but I really like the idea.

[floreks]

LGTM

[floreks]

/ok-to-test
/lgtm

[floreks]

/lgtm
/ok-to-test

[joaquimrocha]

Thanks for the lgtm @floreks + @maciaszczykm !
Pinging @johnbelamaric for approval.

/assign @johnbelamaric

[johnbelamaric]

I think bringing an external project in to K8s directly should be a @kubernetes/steering-committee discussion, like creating new SIGs or WGs. But I'll let the steering committee decide if this is in their scope or not.

[johnbelamaric]

I think @kubernetes/steering-committee should be involved in this decision.

Do you intend to follow K8s release cycles or be an independent, out-of-tree project?

[sftim]

Can we merge as provisional (and maybe iterate) before taking it to Steering?

[johnbelamaric]

sure

[aojea]

After a quick skim I don't understand well if this is a donation of a repository to kubernetes or kubernetes-sigs or try to open a new project based on the referenced here, repository rules are well defined here https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md#core-repositories also the SIG can sponsor a subproject https://github.com/kubernetes/community/blob/master/github-management/subproject-responsibilities.md

Can you please clarify what is the goal here?

[joaquimrocha]

Do you intend to follow K8s release cycles or be an independent, out-of-tree project?

We may add support for new APIs / resource kinds as they are released, but it would not follow release cycles. i.e. releases are independent in that regard.

[joaquimrocha]

Can you please clarify what is the goal here?

The goal is to have a Kubernetes Desktop app to serve as a great desktop experience for Kubernetes users, including novice and experienced, which also serves a base for other CNCF projects to built extensions on.

This proposal involves moving the headlamp-k8s/headlamp repo to Kubernetes, from which we would build the Kubernetes Desktop app. Whether the repo is to be under the official kubernetes org on Github or the kubernetes-sig org, is something I hope someone else can clarify. We are hoping to make this an official desktop app for Kubernetes, so initially we were thinking this meant that the repo could be under the kubernetes org, but the dynamics of where repos should officially live is not very clear to me.

[BenTheElder]

It would be in kubernetes-sigs (this is not a "core component that will live in every cluster" or at least I strongly doubt sig-architecture would disagree). Please see the linked documentation for the repo donation process.

This KEP is not the process to approve a new repo https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md#core-repositories

[BenTheElder]

(Note: kubernetes-sigs is very much official, the separate orgs is a bit of a historical thing, but we do have pretty clearly written rules and process for this)

[johnbelamaric]

please fill all of this out - it's an optionally deployed service, that could be how you do feature enablement/disenablement. But it should be documented.

[joaquimrocha]

Hi @johnbelamaric . This section seems to be aimed at standard KEPs in sense that they change core functionality in kubernetes/kubernetes . Our KEP is for a project that is run outside of Kubernetes, i.e. no feature flags involved.
Maybe some items apply, like having documentation on the kubernetes website, but I think it's a small section that applies here. Does this make sense?

[johnbelamaric]

please fill all of this kep.yaml

[joaquimrocha]

You mean the participating-sigs, right? I think only the sig-ui makes sense here. I will add it as the participating sig in a new PR.

[johnbelamaric]

/approve
/lgtm

for provisional status

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: joaquimrocha, johnbelamaric

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

The pull request process is described here

Needs approval from an approver in each of these files:

• keps/OWNERS [johnbelamaric]

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

[aojea]

This KEP is not clearly explaining the goal neither the implementation details, the folder is also wrong, it says 5008-template, I don;t think the provisional state means let's something merge this way, it is ok to have unresolved points but reading the KEP is not clear to me the goal

[aojea]

no reviewers or approvers?

[joaquimrocha]

I was not sure what to add here initially. Then I saw the bot was kind of guiding this so I assumed this would be added later. I will create a new PR to add these.

[BenTheElder]

This should not be merged without approval from leads of a sponsoring SIG, I think it only merged because @johnbelamaric approved it but that was for Production Readiness Review only. It needs both the approval of the involved SIG(s) and production readiness review (which is cross-sig and aimed and ensuring stability and the feature graduation process)

[johnbelamaric]

Ah sorry, I thought SIG-UI had approved. I should have waited but since it was provisional I went ahead.

[joaquimrocha]

@BenTheElder , the sponsoring SIG ( @floreks or @maciaszczykm ) members did give their LGTM. I thought that counted as approval. Is there something else needed from them?

[BenTheElder]

Ah, preferably this should be done via /approve which is recorded in the robot approval message, and also listed reviewers / approvers in the KEP metadata (this can be reflected elsewhere for KEP tracking). This prevents it being lost deep in the thread 🙃

[BenTheElder]

#5009 (comment) (Makes it look like John only, contributors are used to looking for the approval status in this comment which will be updated down the thread with the current status)

[johnbelamaric]

I think sig-ui was a new directory, so there were no sig-ui OWNERS

[aojea]

the metadata is wrong, I wonder if you really needed a KEP for this

[joaquimrocha]

Right. Our KEP is not changing kubernetes's core nor is dependent/following a particular version.
I think I left the milestones like this because this section was needed? I am happy to remove it or adapt it as appropriate.

[pohly]

The point is: does this need a KEP at all?

If it's only about contributing some source code to SIG UI, then talk to that SIG in their SIG meetings and then come back for repo creation following the process in https://github.com/kubernetes/community/blob/master/github-management/subproject-responsibilities.md

[sftim]

We do have KEPs for changes that don't have milestones.

If we want to change project policy (example: we'd encourage SIGs to ship Headlamp plugins and to build for Headlamp), a KEP is useful.

If we're only adopting a donated component, I don't see a need for a KEP.

---

I think we should propose making Headlamp (or some other name for the same component) official and endorsed. Personal opinion.

[joaquimrocha]

This KEP is not clearly explaining the goal neither the implementation details, the folder is also wrong, it says 5008-template, I don;t think the provisional state means let's something merge this way, it is ok to have unresolved points but reading the KEP is not clear to me the goal

Hi @aojea . I thought the summary of the KEP was clear, apologies if it's confusing. Hopefully my comment at #5009 (comment) clarifies this.

[soltysh]

Just to clear a few things, as a SC liaison for SIG-UI. I discussed with SIG-UI leads (2/3 which approved this PR) they will work on updating the missing and problematic bits in a follow PR. Those include, but is not :

1. the title, to clearly show the actual project name
2. all the missing fields (starting with approvers and reviewers)

Once the KEP is cleared up they will follow the usual process for donating repositories.

I will be personally overlooking the KEP updates and the donation process.

[joaquimrocha]

To maybe make things a bit clearer, there are 2 main parts being discussed: 1. Having Kubernetes Desktop which is a desktop application that provides a UI based on Headlamp for Kubernetes users and developers (main point of the KEP); 2. Moving the headlamp repo from the headlamp-k8s into the kubernetes-sigs, from which the Kubernetes Desktop application will be built.

[johnbelamaric]

I will be personally overlooking the KEP updates and the donation process.

Thank you Maciej

[soltysh]

1. Having Kubernetes Desktop which is a desktop application that provides a UI based on Headlamp for Kubernetes users and developers (main point of the KEP);
2. Moving the headlamp repo from the headlamp-k8s into the kubernetes-sigs, from which the Kubernetes Desktop application will be built.

Let's focus on 2 for now, since that's the main part to start with. The decision for kubernetes desktop should be carefully reconsidered, since that might suggest that being the one solution for k8s desktop, which I believe this project is not aiming to be. Once you achive the repository migration, we can return into those conversations afresh and please make sure to include me in those.

[BenTheElder]

(I also wouldn't suggest renaming unless it's tied up in a commercially owned brand name that cannot be donated, because it will lose existing brand recognition, versus just donating the repo named as-is, see eg karpenter for a recent example)

[joaquimrocha]

Let's focus on 2 for now

Sure! I will check from https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md#rules-for-donated-repositories what we are missing. I think we have already quite a few of these checked since we are a sandbox project.
If you know already something obvious I may be missing, please let me know. Also happy to chat on the Kubernetes Slack.