Split scheduler framework implementation into a separate pkg

[ahg-g]

Split the scheduler framework into an interface pkg and an implementation pkg.

We can keep the interface files (interface.go, types.go, listers.go and cyclestate.go) under scheduler/framework/v1alpha1 and move the implementation to scheduler/framework/runtime.

Ideally plugins should only depend on the interface pkg.

/cc @Huang-Wei @alculquicondor
/sig scheduling

[Huang-Wei]

And we can use this chance to remove the "v1alpha1" literal from scheduler/framework/v1alpha1 as there is only one version of framework interface.

[alculquicondor]

+1

[farah]

Hi @ahg-g,

I was hoping that maybe I can pick this up as I'm looking for my first PR :)

I'll get started on this anyway and will attempt to break the package up . Will report in a few days.

What should be the names of the new package?

Any tips are welcome :) @Huang-Wei @alculquicondor

[ahg-g]

Thanks @farah, feel free to send a PR my way. For now, let's just move the implementation to scheduler/framework/runtime

/assign @farah

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[ahg-g]

/remove-lifecycle stale

[ahg-g]

I suggest we move the interface out of pkg/scheduler/framework/v1alpha1 to pkg/scheduler/framework or pkg/scheduler/framework/interface and close the enhancement issue kubernetes/enhancements#624

@Huang-Wei @alculquicondor what do you think?

[alculquicondor]

I vote for pkg/scheduler/framework

[Huang-Wei]

pkg/scheduler/framework looks good.

[ahg-g]

do you also agree that we should just graduate kubernetes/enhancements#624 and consider it implemented?

[Huang-Wei]

do you also agree that we should just graduate kubernetes/enhancements#624 and consider it implemented?

Agree. As (1) we're not maintaining a multi-versioned scheduler framework, (2) the in-tree scheduler has totally migrated to plugin-based execution path since 1.18, and (3) scheduler-plugins has provided a number of data points proving the maturity and the scheduler framework design.