sig-net KEPs and making progress

[Tim Hockin]

Hi everyone!

I spent some time this week converting our semi-undefined-purpose project borad into a KEPs-only board: https://github.com/orgs/kubernetes/projects/10

I started verifying that everything is in the right columns (starting right-to-left) but I am not done yet.  It showed me 2 interesting things:

1) KEPs themselves are not alpha/beta/GA - gates are (usually).  Some KEPs have no gates and some have multiple gates.

2) We have a LOT of outstanding KEPs, some with dubious ownership.

After all this I am left feeling a bit overwhelmed, and I'd like to make a proposal.  I propose that we slow down a bit.  Let's focus on the KEPs we have - finish them or abandon them, but not leave them to rot.  We have some really big ones open and a bunch that intersect with each other.  Once we feel like these are all stable and reasonably complete, we can start tackling net-new things.

I know that could be impactful to people and companies who have stuff in-flight, so before we declare this to be the plan of record, let's discuss.

Tim

[Andrew Kim]

+1 from me! I am definitely guilty of having too many open KEPs that haven't reached the finish line yet.

I would like to propose that we still allow new KEPs to be proposed in the meantime, but we should be more careful about which KEPs are allowed to be "implementable" in a release until our backlog is smaller.

Thanks,

Andrew Sy

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/CAO_RewaBw-r3UvDs7_5wp_txTAWpnHwcBBRNZ%2BWLXrq9R5t82Q%40mail.gmail.com.

[Tim Hockin]

My main concern with net-new KEPs is the implicit assumption that
someone will pay attention to it. I'd like to absolve us all of that
_responsibility_ for a while (though it can still be voluntary, I
guess). I'd like to encourage people to focus on getting existing
work done before starting new stuff, and I worry that if we allow new
KEPs, folks will still spend their time there (though I ACK that
non-KEP docs are ~equivalent).

[Andrew Kim]

Hi sig-network!

I wanted to follow up on this discussion now that we're past the v1.22 code freeze.

Do we feel like we've made a large enough dent in v1.22 to allow net-new KEPs in v1.23 or do we think it would be beneficial to only focus on existing KEPs in v1.23 as well?

Thanks,

Andrew Sy

[Tim Hockin]

We have about 10 proposals in pre-alpha and about a dozen in alpha or
beta. I'm hoping that 23 will see most of the betas go GA and most of
the pre-alpha go to alpha. I'll feel less anxious when I know the
intersections are being exercised by default.

Is that unreasonable? Is there something in particular you want to
see enter the pipeline?

I'd like to see terminating-endpoints be considered for non-local
services, myself. :)

[Andrew Kim]

Is that unreasonable?  Is there something in particular you want to
see enter the pipeline?

I don't think this is unreasonable. I just wanted to check-in on this topic so I know what to expect going into the v1.23 KEP cycle.

I'd like to see terminating-endpoints be considered for non-local
services, myself. :)

This is part of the reason I'm asking :) Is this a net-new KEP or can it be an expansion of the existing one for local endpoints? Expanding the scope to all endpoints vs speciifcally for local traffic from external load balancers will be a significant change I think.

Thanks,

Andrew Sy

[Tim Hockin]

On Mon, Jul 26, 2021 at 12:44 PM Andrew Kim <kim.an...@gmail.com> wrote:
>>
>> Is that unreasonable? Is there something in particular you want to
>> see enter the pipeline?
>
>
> I don't think this is unreasonable. I just wanted to check-in on this topic so I know what to expect going into the v1.23 KEP cycle.
>
>> I'd like to see terminating-endpoints be considered for non-local
>> services, myself. :)
>
>
> This is part of the reason I'm asking :) Is this a net-new KEP or can it be an expansion of the existing one for local endpoints? Expanding the scope to all endpoints vs speciifcally for local traffic from external load balancers will be a significant change I think.

On one hand it's net-new. On the other hand, I think it will
ultimately be a simplification of the venn-diagram of the the features
in that area. I don't want to make my own pet wants get special
permission unless everyone agress :)