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:

  • nodeFit = false doesn't work as expected with RemovePodsViolatingNodeAffinity #640
  • nodeFit flag should be removed from some strategies #845
  • NodeFit logic is incompatible with "includeSoftConstraints" option. #1067
  • I think we started to draft something initial with NodeFit Specification #1149 but it would come on the next API alpha version: Descheduler v1alpha3 API Proposal #1179

• OpenTelemetry tracing

  • We have a PR open with a lot of reviews, but outdated with new codebase: added otel capabilities for descheduler plugin #958

• Custom tags for eviction metrics

  • pods_evicted custom label #905

• Well, v1aplha3 itself is not exactly blocked and people can work on it Descheduler v1alpha3 API Proposal #1179

• Allowing event-triggered strategy runs

  • [WIP] Allow Node strategies to run with informers #488
  • Proposal: Long-lived deployment: Triggering Descheduler with Events (SharedIndexInformer rules, endpoints, etc) #696

• Out of tree plugins:

  • Decide on how to handle out-of-tree plugins #1089
  • Extend descheduler to support out-of-tree strategies #679
  • Descheduler strategies as plugins #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 #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 #1087 and #1092, unless we want to wait and solve #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