Descheduling framework wrap up

[ingvagabund]

Remaining bits:

• create https://github.com/kubernetes-sigs/scheduler-plugins/blob/master/cmd/scheduler/main.go#L48-L63 like interface for users to easily register custom plugins and register the built-in plugins in https://github.com/kubernetes-sigs/descheduler/blob/master/cmd/descheduler/descheduler.go#L34
• simplify pluginregistry.Register in https://github.com/kubernetes-sigs/descheduler/blob/master/pkg/descheduler/setupplugins.go#L39C2-L49 to pass less arguments
• move creation of the cachedClient in https://github.com/kubernetes-sigs/descheduler/blob/master/pkg/descheduler/descheduler.go#L123-L144 outside of descheduler. So it can be replaced with a generic way of populating the fake clientset cache. I was thinking of some hooks since the cachedClient is recreated in every descheduling loop (and rewritting internal sharedInformerFactory).
• switching to v1alpha2 by default
• ...

[knelasevero]

As we discussed in the community meeting, wanted to list a few efforts that we can start looking at again with the current state of the framework (now that we unblocked a bunch of efforts that were paused before):

• We have a bunch of nodeFit discussions and feature requests:

  • https://github.com/kubernetes-sigs/descheduler/issues/640
  • https://github.com/kubernetes-sigs/descheduler/issues/845
  • https://github.com/kubernetes-sigs/descheduler/issues/1067
  • I think we started to draft something initial with https://github.com/kubernetes-sigs/descheduler/issues/1149 but it would come on the next API alpha version: https://github.com/kubernetes-sigs/descheduler/issues/1179

• OpenTelemetry tracing

  • We have a PR open with a lot of reviews, but outdated with new codebase: https://github.com/kubernetes-sigs/descheduler/pull/958

• Custom tags for eviction metrics

  • https://github.com/kubernetes-sigs/descheduler/issues/905

• Well, v1aplha3 itself is not exactly blocked and people can work on it https://github.com/kubernetes-sigs/descheduler/issues/1179

• Allowing event-triggered strategy runs

  • https://github.com/kubernetes-sigs/descheduler/pull/488
  • https://github.com/kubernetes-sigs/descheduler/issues/696

• Out of tree plugins:

  • https://github.com/kubernetes-sigs/descheduler/issues/1089
  • https://github.com/kubernetes-sigs/descheduler/issues/679
  • https://github.com/kubernetes-sigs/descheduler/issues/557

Let me know if I am forgetting something. We probably should give weights to those with regards to complexity and importance and the prioritize what we want as must haves first.

[knelasevero]

@damemi @ingvagabund @a7i

[damemi]

Like we talked about on the sig call, we have 2 categories of things to work on now for what's next: tech debt we shelved in the interest of moving along a framework release, and feature development that was blocked on the framework refactoring too much of the code.

I would like to prioritize the tech debt. But at this point, that shouldn't significantly block any more feature development, so those can happen in parallel.

For a long-term roadmap, the ideal "done" goal should be getting to a v1 api/v1.0 release. What that means right now isn't totally clear besides making the descheduler more extensible and maintainable. So, I think another good task would be to come up with some criteria for defining when we're ready to make that cut, and work tasks in toward that.

[pravarag]

@damemi @knelasevero @ingvagabund any idea if any work has been done on this issue https://github.com/kubernetes-sigs/descheduler/issues/923 or any priority on this one? I remember I decided to take it up but couldn't start on it last year. I'm available again to work on it and would be happy to contribute if it's okay to go.

[ingvagabund]

We have some examples under https://github.com/kubernetes-sigs/descheduler/tree/master/examples. Though, there's still no comprehensive guide for creating and registering a plugin to the framework. Yet, providing a guide on how to create a new plugin is already welcome. The part of registering a plugin can be done later once the WithPlugin mechanism is in place.

[ingvagabund]

@knelasevero thanks for the comprehensive list of todo. Work on any of the mentioned items can be started/resumed. The telemetry part might still experience a shifting code until the WithPlugin mechanics and removing the cachedClient client code are in place. Though, the work can always be delivered in steps.

[Dentrax]

This is really great list! Thanks for this. I'd like to get into #696, if someone enlighten my way and show where to start to initialize an "event-triggered strategy".

[damemi]

re: out of tree plugins it would be great if we could pick up https://github.com/kubernetes-sigs/descheduler/pull/1087 and https://github.com/kubernetes-sigs/descheduler/pull/1092, unless we want to wait and solve https://github.com/kubernetes-sigs/descheduler/issues/1089 first

[knelasevero]

re: out of tree plugins it would be great if we could pick up #1087 and #1092, unless we want to wait and solve #1089 first

I think we need a proper mechanism for out of tree plugins first

[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

[knelasevero]

/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