[Proposal] - Split kube_features.go into a per-sig file

Ricardo Katz

unread,

Mar 28, 2022, 5:43:48 PM3/28/22

to kubernetes-sig-architecture

Hello folks,

While finishing some PR here before code freeze, I figured out I was suffering again for an annoying problem that happens always 2 days before code freeze: merge conflicts on kube_features.go file (everybody wants to deliver their features!)

I was talking with @thockin and one thing that came from that chat is that maybe we should think on splitting that file into a per-sig structure.

This wont solve the whole problem, but will reduce a lot the "push/lgtm/needs-rebase/all e2e tests again" loop.

I have no concrete proposal on the "how" to do it, as probably things like "how we do this for features that are multi-sig (like IPv6)" needs to be discussed. But at least you have the "what" and "why" here!

I'm aware this should not come for v1.24, so let's open the discussions for v1.25 :)

Thanks!

Clayton

unread,

Mar 28, 2022, 6:11:29 PM3/28/22

to Ricardo Katz, kubernetes-sig-architecture

On Mar 28, 2022, at 5:43 PM, Ricardo Katz <ricard...@gmail.com> wrote:

Hello folks,

While finishing some PR here before code freeze, I figured out I was suffering again for an annoying problem that happens always 2 days before code freeze: merge conflicts on kube_features.go file (everybody wants to deliver their features!)

I was talking with @thockin and one thing that came from that chat is that maybe we should think on splitting that file into a per-sig structure.

This wont solve the whole problem, but will reduce a lot the "push/lgtm/needs-rebase/all e2e tests again" loop.

I have no concrete proposal on the "how" to do it, as probably things like "how we do this for features that are multi-sig (like IPv6)" needs to be discussed. But at least you have the "what" and "why" here!

Multi sig can probably just be under sig-arch (which is the general catch all for inter sig negotiation anyway). But it’s a good idea for conflict separation and should have no real impact on end users.

I'm aware this should not come for v1.24, so let's open the discussions for v1.25 :)

Thanks!

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/f3576c98-f3cc-4159-84a1-e319d8817f88n%40googlegroups.com.

Tim Hockin

unread,

Mar 28, 2022, 6:11:44 PM3/28/22

to Ricardo Katz, kubernetes-sig-architecture

+1

--

Walter Fender

unread,

Mar 28, 2022, 6:26:29 PM3/28/22

to Tim Hockin, Ricardo Katz, kubernetes-sig-architecture

+1

Worth noting we have broken the features into 4 files already based on visibility/dependencies.

Are we suggesting further breaking down all of those or just the most contentious?

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAO_RewaBat4ULOp5E2tKeNh75oqp8OwP-PByjv5A2r%2By5eP-_A%40mail.gmail.com.

Antoine Pelisse

unread,

Mar 28, 2022, 7:03:12 PM3/28/22

to Walter Fender, Tim Hockin, Ricardo Katz, kubernetes-sig-architecture

Can we have one feature flag per file? e.g. `features/customresourcevalidationexpression.go` declares its own const feature gate and registers it.

That's still easy to find/parse and shouldn't ever cause a new conflict?

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAHSPUuztv-vxFhk_%3D0mvSw_v1kVGbC9PyxyibZH5yqBjcK9EhA%40mail.gmail.com.

Patrick Ohly

unread,

Mar 29, 2022, 7:44:30 AM3/29/22

to Ricardo Katz, kubernetes-sig-architecture

Ricardo Katz <ricard...@gmail.com> writes:

> Hello folks,
>
> While finishing some PR here before code freeze, I figured out I was
> suffering again for an annoying problem that happens always 2 days before
> code freeze: merge conflicts on kube_features.go file (everybody wants to
> deliver their features!)

Last week I had brought up a different proposal [1] for addressing the same
problem: sort these files by feature name and a lot of these conflicts
go away because changes are (probably!) going to land in different parts
of the files.

[1] https://kubernetes.slack.com/archives/C0EG7JC6T/p1647957284548959

--
Best Regards

Patrick Ohly
Cloud Software Architect

Daniel Smith

unread,

Mar 29, 2022, 12:05:10 PM3/29/22

to Patrick Ohly, Ricardo Katz, kubernetes-sig-architecture

Sorting by name sounds a lot simpler and less disruptive than splitting up the file.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/yrjhtubhrnje.fsf%40pohly-mobl1.fritz.box.

Michael Taufen

unread,

Mar 29, 2022, 12:35:22 PM3/29/22

to Daniel Smith, Patrick Ohly, Ricardo Katz, kubernetes-sig-architecture

> Sorting by name sounds a lot simpler and less disruptive than splitting up the file.

I like this idea. Avoids the problem of having to keep these categorized correctly, and probably less refactoring work.

We probably also need some line breaks in the defaultKubernetesFeatureGates section to limit the gofmt blast radius.

Maybe sort by name + extra newline between each default.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAB_J3bavjTP-JoLFt49io_j5Q%2BAAzQDTS%2BEGBSUMqsJWHoui-g%40mail.gmail.com.

--

NO TO WAR. go/give-ukraine

Michael Taufen

Google SWE

Clayton

unread,

Mar 29, 2022, 12:49:53 PM3/29/22

to Michael Taufen, Daniel Smith, Patrick Ohly, Ricardo Katz, kubernetes-sig-architecture

On Mar 29, 2022, at 12:35 PM, 'Michael Taufen' via kubernetes-sig-architecture <kubernetes-si...@googlegroups.com> wrote:

> Sorting by name sounds a lot simpler and less disruptive than splitting up the file.

I like this idea. Avoids the problem of having to keep these categorized correctly, and probably less refactoring work.
We probably also need some line breaks in the defaultKubernetesFeatureGates section to limit the gofmt blast radius.
Maybe sort by name + extra newline between each default.

Good idea - a good feature flag description is already required as godoc, and the extra newline makes them more readable anyway (at 2-5 godoc lines plus the flag var itself).

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAHJadQKj2YrHEji8p42iL0LrZfZXsTMiMxjVQnzpk_wAi30-AA%40mail.gmail.com.

Tim Hockin

unread,

Mar 29, 2022, 2:36:09 PM3/29/22

to Clayton, Michael Taufen, Daniel Smith, Patrick Ohly, Ricardo Katz, kubernetes-sig-architecture

SGTM - if that doesn't provide relief we can reconsider.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAA093F0-FC96-459C-A028-7657848FED61%40gmail.com.

Patrick Ohly

unread,

Apr 12, 2022, 10:33:46 AM4/12/22

to Michael Taufen, Daniel Smith, Ricardo Katz, kubernetes-sig-architecture

Michael Taufen <mta...@google.com> writes:
>> Sorting by name sounds a lot simpler and less disruptive than splitting
> up the file.
>
> I like this idea. Avoids the problem of having to keep these categorized
> correctly, and probably less refactoring work.
> We probably also need some line breaks in the defaultKubernetesFeatureGates
> section to limit the gofmt blast radius.
> Maybe sort by name + extra newline between each default.

Makes sense to me. I've create a PR for 1.25 with sorting plus this
extra newline: https://github.com/kubernetes/kubernetes/pull/109435

Reply all

Reply to author

Forward