empty noderesourcetopology-api repository in kubernetes-sigs

[dims]

Describe the issue

https://github.com/kubernetes/noderesourcetopology-api/ is totally empty

Looks like instead there is a github.com/k8stopologyawareschedwg/noderesourcetopology-api repository

Is k8stopologyawareschedwg operated by k8s github management team?

Looks like node-feature-discovery and scheduler-plugins uses code from this new repository as well:
https://cs.k8s.io/?q=noderesourcetopology-api&i=nope&files=&excludeFiles=&repos=

Should we cleanup references to kubernetes/noderesourcetopology-api from our sigs.yaml / test-infra etc? (and delete the empty repo?)

cc @swatisehgal

[dims]

/area github-management

[dims]

/sig contributor-experience

[ffromani]

Hi there, commenting as member of the k8stopologyawareschedwg group.
I feel that it should be the other way around. AFAIK the plan was to have the node resource topology API merged (in a sufficiently matured/evolved form) into k8s, so we should eventually move the content from github.com/k8stopologyawareschedwg/noderesourcetopology-api to github.com/kubernetes/noderesourcetopology-api . I for myself I only learned the latter exists at all in the last couple days. My 2c.

[mrbobbytables]

@fromanirh it's the opposite for k8s projects - things that are for the project should be developed inside one of the k8s managed repos. There is significantly more work required for vetting to donate or import an external code base and if the intent is to do that with github.com/k8stopologyawareschedwg/noderesourcetopology-api then we basically have to start from scratch and go through that process.

[ffromani]

@fromanirh it's the opposite for k8s projects - things that are for the project should be developed inside one of the k8s managed repos. There is significantly more work required for vetting to donate or import an external code base and if the intent is to do that with github.com/k8stopologyawareschedwg/noderesourcetopology-api then we basically have to start from scratch and go through that process.

Thanks for pointing this out. This is unfortunate indeed. In this specific case it should be less painful because that repo holds a CRD definition and code autogenerated out of it.
Anyway, looking forward for other group members (@AlexeyPerevalov @swatisehgal and also @marquiz) to chime in and comment.

[swatisehgal]

We had created kubernetes/kubernetes#96275 to populate https://github.com/kubernetes/noderesourcetopology-api/ but at that time we had created this we were proposing changes in the default kube-scheduler and there were concerns around dependency of a native component on a CRD API. In order to move things along and to let the project and the API mature we created: github.com/k8stopologyawareschedwg/noderesourcetopology-api/

Maybe it is time for us to revisit this given that we have Node feature discovery and NoderesourceTopology scheduler-plugin in the kubernetes org as consumers of this API!

Having said that SIG scheduling had recommended that we move the scheduler plugin to natively in the kube-scheduler and we had started working on this kubernetes/enhancements#2787 but weren't able to pursue this all the way due to other higher priority items.

I think it boils down to our long term plan and timelines, do we want to enable this capability natively in Kubernetes or are happy enough with the current framework? If we want to go with the former then is it still worth populating github.com/k8stopologyawareschedwg/noderesourcetopology-api/ in the interim.

Would be nice to see what others (@AlexeyPerevalov @fromanirh @marquiz @Huang-Wei) think about this.

[Huang-Wei]

No matter we will end up with in-tree noderesourcetopology API or not, hosting it under the kubernetes org sounds a good idea. (I also get to know the existence of https://github.com/kubernetes/noderesourcetopology-api/ today...)

[swatisehgal]

Apologies @Huang-Wei and @fromanirh, I should have done a better job at keeping you in the loop!

Let's reopen kubernetes/kubernetes#96275 and work on populating github.com/k8stopologyawareschedwg/noderesourcetopology-api then!

Thanks for chiming in on this.

[swatisehgal]

@dims We have concluded that we should go ahead and populate https://github.com/kubernetes/noderesourcetopology-api/. Is it okay to close this issue?

[dims]

@swatisehgal works! thanks!

/close

[k8s-ci-robot]

@dims: Closing this issue.

In response to this:

@swatisehgal works! thanks!

/close

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/test-infra repository.

[nikhita]

/reopen

kubernetes/kubernetes#96275 was closed to inactivity and https://github.com/kubernetes/noderesourcetopology-api/ is still empty.

[k8s-ci-robot]

@nikhita: Reopened this issue.

In response to this:

/reopen

kubernetes/kubernetes#96275 was closed to inactivity and https://github.com/kubernetes/noderesourcetopology-api/ is still empty.

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/test-infra repository.

[nikhita]

/sig node

[swatisehgal]

/reopen

kubernetes/kubernetes#96275 was closed to inactivity and https://github.com/kubernetes/noderesourcetopology-api/ is still empty.

Thanks Nikhita for reopening this issue. I didn't get a chance to update kubernetes/kubernetes#96275 as I have been busy but I will update it as soon as I have some time.

/assign

[nikhita]

@swatisehgal wanted to follow up on this. https://github.com/kubernetes/noderesourcetopology-api is still empty. Are you still planning to work on this or would you prefer archiving the repo?

I'm also assigning kubernetes-retired/staging-noderesourcetopology-api#1 to you.

[swatisehgal]

@nikhita Thank you so much for following-up on this.
I wasn't able to work on this but certainly plan to do so. I will prioritize this work in the upcoming release cycle.

[upodroid]

Forgot to mention this in the meeting but can you look in to moving the repo instead? You can retain the issues, PRs, and releases instead of just moving over the git repo alone.

https://github.com/k8stopologyawareschedwg/noderesourcetopology-api

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[mrbobbytables]

We can move repos (issue filed in k/org), assuming everything in the repo meets our criteria for donation.

We should probably clean up the empty repo if there is no plan to stub out content in it vs donating the other repo.

[swatisehgal]

Forgot to mention this in the meeting but can you look in to moving the repo instead? You can retain the issues, PRs, and releases instead of just moving over the git repo alone.

https://github.com/k8stopologyawareschedwg/noderesourcetopology-api

Sorry for the delay in respose. I somehow missed these messages and am following up now.
@upodroid We would be more than happy to donate the existing repo.

@mrbobbytables I have a PR open to bootstrap the repo and was planning to add the API definition as part of a follow up PR but donating the repo altogether shouldn't be a problem from our side.
After reviewing the donation criteria, it looks like we might be able to meet all of them either already or with minor modification to the existing repo. Are there other requirements that we should be aware of to donate the repo? What is the procedure to do so?

[vaibhav2107]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[swatisehgal]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[swatisehgal]

/remove-lifecycle rotten

We got an approval for the repo to be created yesterday. Once the repo is created, we would be populating it in the upcoming cycles.

[fmuyassarov]

/cc @fmuyassarov

[marquiz]

I hope we get the repo soon 😊

[SergeyKanzhelev]

@swatisehgal do you plan to populate the https://github.com/kubernetes-sigs/noderesourcetopology-api?

[swatisehgal]

@swatisehgal do you plan to populate the https://github.com/kubernetes-sigs/noderesourcetopology-api?

Yes, had pushed a PR: kubernetes-sigs/noderesourcetopology-api#1 for this, waiting for reviews :)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[swatisehgal]

/remove-lifecycle stale

[MadhavJivrajani]

/triage accepted
to make the bot happy :)

[MadhavJivrajani]

@swatisehgal out of curiosity - what's the status of this?

[swatisehgal]

@swatisehgal out of curiosity - what's the status of this?

I have an open PR: kubernetes-sigs/noderesourcetopology-api#1. It is currently awaiting reviews from API reviewers.