Exposing TopologyManagerScope as a separate field

[PiotrProkop]

Is there any reason why TopologyManagerScope was not exposed as separate field?
I would like to implement a Scoring Scheduler plugin that will favor nodes that requires least NUMA nodes to satisfy POD's resource requirements and I would like to do it when using restricted or best-effort policy.

[PiotrProkop]

@swatisehgal @fromanirh can you take a look?

[ffromani]

Hi @PiotrProkop . I will dig in the history to check the reasoning at time. In general I think this is a very fair ask to evaluate. The only drawback (of sorts) is adding the scope will probably fall in the v1beta1 bucket.
At this stage we're planning the content to evaluate to move to v1beta, there's no deadline yet.

[PiotrProkop]

Thanks!

[swatisehgal]

Hi @PiotrProkop . I will dig in the history to check the reasoning at time. In general I think this is a very fair ask to evaluate. The only drawback (of sorts) is adding the scope will probably fall in the v1beta1 bucket. At this stage we're planning the content to evaluate to move to v1beta, there's no deadline yet.

IIRC, it was because when we started working on this, Topology Manager scope didn't even exist! We designed the API such that topologyPolicies would take in only exisiting Topology Manager policies (none, restricted, single-numa-nodde). Later, when the feature was added we decided to continue using the same field and coupled the policy with the scope :(

I agree it is a fair ask to decouple policy from scope. It probably makes sense to figure out a way for us to represent the topologyPolicies in a more generic way to not only explicitly capture the Topology Manager scope but also the newly introduced policy options. Was thinking on the lines of a map so we have a kubelet flag as the key and value capturing the configured kubelet config value.

[ffromani]

we are addressing this need using top-level Attributes added in v1alpha2: please see #24 and #25