Open dims opened 2 years ago
/area github-management
/sig contributor-experience
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.
@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.
@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.
We had created https://github.com/kubernetes/kubernetes/pull/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 https://github.com/kubernetes/enhancements/pull/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.
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...)
Apologies @Huang-Wei and @fromanirh, I should have done a better job at keeping you in the loop!
Let's reopen https://github.com/kubernetes/kubernetes/pull/96275 and work on populating github.com/k8stopologyawareschedwg/noderesourcetopology-api then!
Thanks for chiming in on this.
@dims We have concluded that we should go ahead and populate https://github.com/kubernetes/noderesourcetopology-api/. Is it okay to close this issue?
@swatisehgal works! thanks!
/close
@dims: Closing this issue.
/reopen
https://github.com/kubernetes/kubernetes/pull/96275 was closed to inactivity and https://github.com/kubernetes/noderesourcetopology-api/ is still empty.
@nikhita: Reopened this issue.
/sig node
/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 https://github.com/kubernetes/kubernetes/pull/96275 as I have been busy but I will update it as soon as I have some time.
/assign
@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 https://github.com/kubernetes/noderesourcetopology-api/issues/1 to you.
@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.
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
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
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.
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?
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/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.
/cc @fmuyassarov
I hope we get the repo soon 😊
@swatisehgal do you plan to populate the https://github.com/kubernetes-sigs/noderesourcetopology-api?
@swatisehgal do you plan to populate the https://github.com/kubernetes-sigs/noderesourcetopology-api?
Yes, had pushed a PR: https://github.com/kubernetes-sigs/noderesourcetopology-api/pull/1 for this, waiting for reviews :)
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
/triage accepted to make the bot happy :)
@swatisehgal out of curiosity - what's the status of this?
@swatisehgal out of curiosity - what's the status of this?
I have an open PR: https://github.com/kubernetes-sigs/noderesourcetopology-api/pull/1. It is currently awaiting reviews from API reviewers.
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
andscheduler-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