Proposal: Add http handler for manual descheduling process launch

[ergoz]

During testing and in some situations, we'd like to be able to initiate the descheduling process manually, for example, via an API request. Is this currently possible?

If this functionality doesn't exist, we're open to developing it. Would it be useful to you?

[a7i]

One easy option is to deploy it as a CronJob as well (but suspend it), and create ad-hoc Jobs from the CronJob.

[ergoz]

@a7i Thank you for your response. We are using kind Deployment and cant change it to cronjob. But our team has an idea for implementing the solution when using a deployment, and we are ready to implement it ourselves and submit a PR to you. However, we would like to get your approval for this approach beforehand.

Our proposal involves the following steps:

• In the file cmd/descheduler/app/options/options.go – add a TriggerCh chan struct{} field.
• In the file cmd/descheduler/app/server.go – create a channel and register a trigger endpoint, e.g., pathRecorderMux.HandleFunc("/api/v1/trigger", …). When this endpoint is called, a signal will be sent to the TriggerCh channel.
• In the file pkg/descheduler/descheduler.go – replace wait.NonSlidingUntil with a for + select loop. NonSlidingUntil will no longer be needed, as we will pre-set time.NewTimer as one of the branches in the select statement. The branches will handle: the timer, the trigger, and ctx.Done().

Schema:

server.go ──create──► TriggerCh (buffered chan, size 1)
                           │
                    ┌──────▼──────┐
                    │POST /api/v1/trigger  │  <- curl -k -X POST https://localhost:10258/api/v1/trigger
                    └──────┬──────┘
                           │ send signal (non-blocking)
                           ▼
               DeschedulerServer.TriggerCh
                           │
               descheduler.go  ──select-loop──► runDeschedulerLoop()
                    (timer OR trigger)

After that we can use Job with curl, or any our internal services to call something like curl -k -X POST https://descheduler.kube-system.svc.cluster.local:10258/api/v1/trigger and we will not need to create Job with copy of secrets, config maps or something else, or create Job copy from cronjob.

This approach would extend the functionality for cases like ours, where we need to use the deployment type, without breaking the existing system workflow.

[ricardomaraschini]

I think this relates: #696