►
Description
Meeting agenda: https://docs.google.com/document/d/1aPgGRl4WewM3txrCYvkepsxLUvGdMG1EzlVfCNeV74M/edit#bookmark=id.ye319lq9fwml
A
All
right
welcome.
Everyone
today
is
Wednesday
August,
23rd
2023,
and
this
is
the
API
server
Network
proxy
meeting.
This
is
a
sub-project
of
kubernetes
sigs
and
a
Sig
cloud
provider
and
Sig
networking
and
as
such,
we
follow
their
guidance
which
basically
means
treat
everyone
kindly
so
yeah.
There
is
nothing
on
the
agenda
currently
and
I.
Would
ask
folks
to
please
add
yourself
to
the
participant
list
on
the
agenda,
but
I
guess
we
have
some
next
topics,
so
I'll
open
the
floor.
A
C
Okay,
yeah
the
I
think
that
there's
probably
already
a
link
you're
presenting
your
screen
in
the
in
recent
meetings.
We've
discussed
that
yeah
issue
510
in
the
last
couple
weeks
or
more
I've
I
think
I've
had
a
few
people
chime
in
and
everybody
basically
is
in
agreement.
So
I
don't
think,
there's
any
I,
don't
think.
A
D
C
Yeah
and
then
late
last
week,
I
noticed
this
issue
come
in
there's
silly
kind
of
Nilda
ref
that
I
think
I
am
the
author
responsible
for
it
earlier
this
year.
We
think
that,
starting
in
tag
version
0.1.2,
this
became
an
issue
in
proxy
server,
but
only
for
certain
values
of
a
flag.
The
routing
strategy
has
to
include
like
desk
host.
If
you
just
use
the
default
routing
strategy,
you
won't
hit
that
code
path
and
I
sent
a
PR.
That
I
believe
fixes.
C
The
Nilda
ref
was
kind
of
a
larger
refactor
and
I
just
wanted
to
solicit
review.
I
already
got
a
co-worker
Tim
Montclair
to
who
took
a
first
pass
and
gave
a
bunch
of
feedback
which
I've
Incorporated
but
yeah.
This
is
just
to
solicit
additional
eyes
or
to
see
if
anybody
would
prefer
like
a
smaller
tactical
fix,
but
I'm
eager
to
get
this
out
and
then
stamp
a
new
tag
to
to
go
and
replace
the
bad
versions
with.
A
A
A
B
So
we
know
there
are
some
grpc
changes
in
coming
from
KK
and
they
involve
updating
libraries
ahead
of
what
we
consider
to
be
the
current
minimum.
So
I
think
the
don't
I
I
looked
this
up,
but
the
current
minimum
I
think
is
like
125
or
something
like
126.
Irrespective,
if
we
put
those
into
the
client,
then
we
are
forcing
KK
forward
in
a
way
that
we
don't
want
to
do.
B
So
that
suggests
that
it
is
time
to
branch
and
as
part
of
the
branching,
then
the
question
is:
how
do
we
want
to
bring?
Do
we
want
to
Branch
to
zero
two,
which
would
be
numerically
the
obvious
thing
to
do
after
the
current
zero
one?
Or
do
we
want
to
sort
of
accept
that
we're
probably
going
to
Branch
every
time
we
do?
B
We
we
have
a
new
KK
that
we
want
to
correspond
to
or
every
time
there
is
a
new
KK
and
do
what
things
like
client
go
do,
which
is
to
keep
their
minor
version
in
line
with
KK's
minor
version,
and
that
way,
it's
much
easier
to
really
reason
about:
okay,
which
version
of
KK.
Does
this
Library,
you
know
correspond
to.
C
Yeah
I
think
that's
basically
the
same
as
the
I
think
Walter
you
were
just
connecting,
as
we
were
talking
about
the
first
agenda
item
of
the
branching
strategy.
We
were
saying
over
in
the
issue
where
there
was
some
discussion.
There
was
pretty
much
unanimous
agreement
to
just
to
basically
Stamp
Out
per
minor
per
KK,
minor
versions
similar
to
client
go
so
I.
C
B
B
The
release
managers
there's
an
entire
group
of
release
managers
and
the
general
philosophy
is
the
original
reviewers
of
the
pr
a
test
that
they
believe.
There
is
no
problem,
checking
back
the
LG
TM,
then
the
release
manager
goes
in.
You
assign
that
it's
with
the
what
what
you're
doing
is
not
a
feature
that
is
being
backward
ported
but
is
just
a
bug
and
then
the
release,
managers
or
someone
else
goes
in,
does
one
final
check
that
they
believe
it
should
be
safe
to
back
port
and
then
then
they'll
go
ahead
and
backboard.
B
So
the
one
interesting
question
we
get
here
is
right.
Now
we
are
missing
all
of
those
groups
and
processes,
because
we're
small
and
I
I
just
to
be
clear,
not
a
fan
of
bureaucracy.
I'm,
not
saying,
let's
build
all
that
infrastructure
for
a
very
small
project,
but
I
think
it.
It
is
good
for
us
to
sort
of
have
a
quick
chat
at
minimum
and
come
up
with
guidelines
about
when
we
think
we
should
backport
fixes
right,
but
do
we
generally
think
we
should
pick
do
it?
B
A
I
guess
like
what
like,
what
do
we
need
to
do?
Do
we
need
to
actually
like
formalize
those
in
a
document
or
something
or
how
do
we
I
guess?
How
do
we
push
this
forward?
Because
what
you're
proposing
sounds
good
to
me,
but
I,
just
I,
don't
know
like
do
we
just
agree
to
it
and
then
we
do
it
or
do
we
actually
have
to
like
notify
someone
on
the
release
team
or
something
or
I.
B
Don't
think
we
have
to
notify
anyone,
but
at
minimum
I
think
it
would
be
good
to
have
it
in
our
notes.
Here,
even
better
I
think
would
be
once
we
agree
here
would
be
to
take
whatever
we
agree
to
and
put
it
into
the
the
markdown
file
that
we
have
on
the
project
that
has
to
do
with
releases,
but
I
think
that's
about
it.
C
Just
for
my
part,
I've
done
a
few
of
those
PR's
in
KK,
where
we
request
connectivity,
client
to
be
sort
of
backported
and
I
was
doing
it
mostly
for
bug,
fix
reasons
and
I.
Think
I
managed
to
get
a
few
back
ported
for
purely
adding
metrics
instrumentation,
but
I
agree
with
you
that
there
seems
to
be
a
bit.
C
There
was
always
kind
of
a
bit
of
ambiguity
around
process
or
like
showing
our
work
and
I
I
agree
with
you
that
the
new
branching
strategy
is
probably
going
to
allow
us
to
better
show
our
you
know,
changes
restricted
to
bug,
fixes
or
whatever
so
yeah
I
can
include
that
in
scope.
If
I
update
that
release.md
or
when
I
do.
C
B
Well,
so
so
do
we
actually
have
any
guidance,
Beyond
sort
of
what
we've
already
talked
about
I
mean?
Does
anyone
have
opinions
about
all
right?
So
one
interesting
thing
I'll
point
out
which
I
knew
but
had
forgotten
and
Joseph
reminded
me
anything
that
goes
into
the
library.
The
the
client
library
is
part
of
the
third
package
third-party
package
and
will
be
reviewed
on
the
kkpr
when
you
submit,
and
so
from
that
that
type
of
cherry
pick
the
KK
is
going
to
re-review
it,
and
presumably
someone
from
API
Machinery
is
going
to
have
to
approve.
B
A
B
Sure
so
so
as
an
example,
if
let's
go,
let's
live
in
this
magical
new
world
because
it
makes
talking
about
this
a
little
more
obvious.
So
when
we
get
to
129
on
KK,
we
are
fixing
r029
branch
and
we
discover
there's
a
problem
with
desk
host
and
we
think
hey.
You
know
what
I'd
like
to
get
this
desk
host
fixed
in
earlier
versions,
because,
even
though
129
is
what
we
just
cut
for
kubernetes,
the
majority
of
customers
are
on
128
or
earlier.
B
B
There
are
two
changes
that
we
make
and
they
are
technically
Cherry.
Go
through
the
cherry
pick
process
we're
talking
about
here
where
we
go
into
the
well.
In
fact
it
gets
normally.
What
you
do
is
you
check
it
into
head
and
you
cherry
pick
it
back
using
the
official
cherry
pick
process
for
us,
it's
a
little
more
complicated
where,
because
we
but
we'd
want
to
go
into
the
KK
and
we'd,
go
we'd
check
out
the
128
release
branch
of
KK
and
you
change
the
go
mod
file
for
the
cube
API
server.
B
That
would
pull
pull
in
the
new
version
of
the
bootstrap
code
or
sorry,
not
bootstrap
third-party
code,
wow
mixing
streams.
Sorry,
that's
going
to
update
the
third
party
or
vendor,
which
I
think
it
updates
the
vendor.
Sorry
and
specifically,
the
vendor
changes
that
it's
going
to
update
are
the
ones
that
come
from
our
client
directory,
so
our
client
changes
from
120
or
0
28
3
to
0
28
4
are
going
to
show
up
as
a
diff
in
KK
vendor.
B
A
B
So
there
is
one
compile
dependency,
which
is
from
the
cube
API
server
to
the
connectivity,
client,
gotcha,
okay,
cool
right
and
that's
what
specifically,
if
you've
ever
wondered
why
we
have
two
sets
of
go
mod
files
in
in
in
the
this
project.
We
have
one
which
is
for
the
agent
and
server
which
no
one
else
depends
on,
and
then
we
have.
The
second
go
mod,
which
is
the
connectivity,
client
go
mod
file,
and
that
is
specifically
so
that
we
can
see
we
can.
A
A
A
We
need
to
spell
out
that,
like
we'll
put
it
in,
you
know
this
branch
that
corresponds
to
the
minor
version
of
kubernetes
and
then
we'll
cherry
pick
from
that
or
we'll
we'll
reference
that
when
we
try
to
bring
in
the
dependencies
in
KK-
and
this
is
the
process
we'll
use
to
bring
it
in
there
is
that
that's
do
I.
Have
it
right,
I,
guess:
okay,
cool
sounds
good.
A
B
A
B
C
Well,
thanks
for
volunteering,
and
as
one
of
the
repo
admins
I
can
follow
up
and
actually
execute
like
create
the
branches
and
the
tags
for
the
first
set.
I
assume
we'd
want
to
probably
do
all
of
the
currently
supported
kubernetes
minor
versions
like
set
up
the
corresponding
branches
or
or
we
could
just
do
the
latest
I'm,
not
sure
any,
actually
any
any
opinions
on
that
it
might
be
getting
ahead
of
ourselves
a
little
but
like
in
the
initial
execution.
Yeah.
A
C
A
A
D
A
Yeah
sounds
good
and
I
would
say
we
can
probably
do
this
work
in
parallel,
like
I
can
work
on
the
documentation
and
if
you
want
to
get
started
on
you
know,
I
don't
know
if
we
have
a
branch
to
cut
yet
or
not,
but
I
guess
when
we
do
this,
when
we
do
the
1.28
release
or
whatever
the
0.28
release,
I
guess
that's!
When
we'll
cut
the
branch.
A
A
A
B
Let
me
just
so
quickly
where
I
am
I
mean
there's
one
or
two
tests,
failing
which
I
wanna
at
some
point,
I
need
to
get
at
it's
a
little
bit.
Oh,
it's!
It
needs
to
be
rebased
which
I
should
I
will
take
care
of
the
biggest
problem
right
now,
though,
I
think
with
it
is
that
so
it
introduces
a
brand
new
idea.
B
Oh
well,
it
introduces
two
new
things,
so
the
intent
had
been
to
involve,
rather
than
the
idea
of
there
being
a
load
balancer
based
system
between
the
agents
and
the
server,
and
you
use
the
number
of
servers
plus
one
with
Joseph's
stuff.
Has
the
number
of
things
you
try
to
connect
to
it
goes?
It
tries
to
go
to
the
okay
I,
don't
have
a
load
balancer
in
the
middle
and
I
can
configure
the
agent
with
the
set
of
connectivity
servers
that
it
should
connect
to
okay
I
got
that
much
working.
B
What
I
don't
have
working
that
I
need
to
do
is
some
of
the
edge
on
when
what
to
do
when
a
connectivity
server
fails.
So
it
needs
to
be
able
to
reconnect
and
really
be
reliable,
and
so
there's
a
little
for
that.
So
the
existing
system
seems
to
be
fine,
as
is
it's
still
the
default.
But
when
you
do,
IP
based
I
need
to
do
a
little
bit
of
work
to
really
make
those
connections
resilient
and
so
I
need
to
just
do
a
bunch
of
testing
breaking
connections
and
that
sort
of
thing.
B
It
was
better
if
we
just
had
a
relatively
clean
API.
Let
you
swap
out
that
logic
and
I'm
sure
other
people
will
want
to
implement
new
ones
and
it'll
probably
have
to
grow,
because
I
was
able
to
do
it
with
a
very
small
set
of
interfaces
but
I'm
guessing
that
that's
actually
going
to
grow
over
time,
but
I
I
can't
anticipate
what
the
next
Connection
Manager
is
going
to
need.
So
I'm
going
to
leave
it
small
for
now,
and
we
can
think
through.
B
You
know,
then,
when
the
next
request
like
this
comes
in,
we
can
see
what
we
want,
but
I
I
saw
I
got
an
LG
TM.
It
looks
like
from
El
Nico
I,
don't
know
if
anyone
else
took
a
look
at
the
code
and
has
any
feedback.
I
I
love
feedback,
I
love
discussing
this
thing,
I'm
sure
there
are
things
that
other
people
have
faced
in
the
past.
That
I
have
did
not
anticipate.
So
you
know
feedback
is
awesome.
C
A
D
C
B
And
in
fact
that,
if
you
hit
any
problems,
I
I
would
like
to
apologize
for
I
in
a
couple
of
the
early
folks.
I
think
you
will
be
the
first
non-googler
to
ever.
Do
the
the
that
that
kind
of
release
promotion.
So
this
is
actually
really
important
because
it
shouldn't
require
any
Google
permits.
Google
special
permissions,
but
I
can't
swear
that
it
doesn't.
But
we
will,
if
you
hit
any,
please
let
us
know
and
we
can
make
sure
those
get
fixed.
B
D
Well,
good
thanks
I
know
we
had
a
lot
of
time.
I
just
wanted
to
bring
one
a
small
topic,
and
that
is
about
videos
being
uploaded
somewhere
because
I'm
a
big
fan
of
re-watching
videos,
so
that
some
of
the
important
points
I
can
reinforce
like,
for
example,
you
explaining
you
know
about
the
version
branching
and
all
so.
If
there's
a
place
that
we
can
find
to
upload,
it
would
be
nice
to
have
them
really
watch.