Experimenting with adapting the linkerd labels module for general use

[clux]

Heavy WIP. The linkerd module is good and has nice patterns, but it is not super focused to fitting our interfaces, plus it does not have a way to serialize the query string for the API so am trying to write that plus make the builder interface on expression more ergonomic. Stashing here as WIP, will maybe get to it on the weekend.

• Selector extend with stringifiers for ListParams
• Extend ListParams::labels_from taking a Selector
• Builders for Expression (done 1)
• Labels revamp
  • Allow converting from ResourceExt::labels() to something we can compare against
  • remove Labels altogether? commented out for now (arc use seems unnecessary for us)
• combine Operator and Values? now there's the awkward representable case of In / NotIn but empty values...
• Feature flag in jsonschema derives? If we want to embed selectors inside ObjectMeta.
• Alternatively, more converters for selectors that can be injected into ObjectMeta

[paologallinaharbur]

I was about to open an issue, but then I've found this PR that I think it is implementing what I was looking for!

I was looking for something similar to this go package in order to filter on client-side a list of pods given a label_selector.

If you need review/inputs let me know 😄

[Danil-Grigorev]

Maybe on the side note… I ended up implementing another version similar to linkerd in crust-gather (without knowing): - https://github.com/crust-gather/crust-gather/blob/main/src/gather/selector.rs but skipping having a LabelSelector.

So this version also lacks conversion back to original LabelSelector and the use-case it was meant for is just an ability to deserialize the definition from a string, not a tuple of matchExpressions and matchLabels keys with values… I feel like the ideal state would be to leave on user to preserve the original LabelSelector, add a trait capable of matching stuff over it, and a default implementation like the Selector presented in this PR + the ability to convert from LabelSelector to this custom Selector (like Into/From). WDYT?

PS: opened a separate issue describing in more details the use case I’m trying to cover.

[clux]

So this version also lacks conversion back to original LabelSelector and the use-case it was meant for is just an ability to deserialize the definition from a string, not a tuple of matchExpressions and matchLabels keys with values… I feel like the ideal state would be to leave on user to preserve the original LabelSelector, add a trait capable of matching stuff over it, and a default implementation like the Selector presented in this PR + the ability to convert from LabelSelector to this custom Selector (like Into/From). WDYT?

Yeah, I also wanted a way to go from some arbitrary labels / ObjectMeta / K: Resource. Maybe some kind of SelectorExt trait would make sense here, as we could impl SelectorExt for ObjectMeta and hook in getters/setters that way. At any rate, do feel free to take this over. I have clearly not made a lot of progress on this issue in the last month.

[clux]

#1539 is a successor PR. closing this.