►
Description
Kubernetes Network Special Interest Group Biweekly Meeting for 20220106
A
B
The
danger
of
too
many
windows
to
github
open
at
any
given
moment,
okay,
so
looks
like
the
very
first
one
is
one
that
I
might
need
to
chase
down.
It
looks
like
this
person
unless
we
think
this
is
a
non-aks
specific
thing.
What
do
we
think
is
happening
here?
Not
saving
endpoint
for
unknown
health
check.
D
It
wasn't
clear
that
this
was
aks
specific
just
that
they
were
using
aks.
I
I
flagged
this
one
for
can
we
get
a
volunteer
to
see
if
they
can
make
heads
or
tails
of
what
the
error
really
means
and
what
might
lead
to
this?
Like,
I
don't
know
off
the
top
of
my
head.
What
would
lead
to
this
error
message?
I
have
a
vague
recollection
of
writing
that
log
line
or
reading
that
log
line,
but
I
don't
remember
what
it
was
for.
D
D
E
B
B
D
I
was
just
responding
at
the
end.
I
looked
at
this
one
a
few
minutes
ago.
It's
a
it's
a
feature
request.
So
there's
a
proposed
work
workaround
here
in
the
bug.
Already,
it's
not
exactly
what
the
user
was
asking
for.
I
don't
think
what
they're
asking
for
is
crazy,
but
it
would
require
a
cap
and
some
api
changes
and
either
loosening
of
validation
or
some
new
fields
and
it
doesn't
yeah.
It's
not
immediately
obvious
to
me
that
it's
worth
that
amount
of
effort
yeah
so
we'll
see.
D
D
B
B
D
B
D
Is
this
is
basically
a
one
of
the
family
of
bugs
that
are
related
to
node
ports
on
localhost
I
followed
up,
and
then
I
wanted
to
ask
here.
If
anybody
has
contacts,
because
because
I
ran
out
of
time
to
search,
do
we
have
a
general
like
an
issue
open
or
somebody
paying
attention
to
the
general
problem
of
like
moving
in
this
direction?
D
We
have
a
compatibility
problem,
but
it's
also
a
security
problem,
so
it
may
actually
be
worth
the
effort
to
try
to
drag
people
towards
the
light,
and
I
didn't
know
if
we
had
an
open
issue.
These
are
all
closed,
related
issues,
but
there's
another
nine,
two,
nine
three
there
you
go,
which
is,
is
really
the
the
real
issue
right,
don't
set
that
that
cisco
anyway,
the
question
is:
do
we
have
an
issue
for
this?
Should
we
open
it
issue?
Should
we
just
re-title
this
issue
and
call
it
eventually?
D
H
D
D
B
B
D
They're
looking
at
the
dns
side,
but
I
can't
imagine
how
dns
is
the
the
thing
yeah
I
mean
the
only
way
you
could
coordinate
this
across
nodes
would
be
through
something
like
cube
proxy
right
or
or
this
cilium
equivalent.
So
my
question
for
the
call
is
anyone
from
my
surveillance
here.
Anyone
who
knows
psyllium
really
well
wants
to
like
pontificate
about
whether
this
is
even
possible.
D
B
G
D
B
B
F
B
I
B
I
E
J
A
G
D
B
B
D
B
B
A
D
K
K
I
also
have
some
upcoming
dates
for
you
I'll
put
a
link
to
the
full
schedule
which
you
just
finalized
in
the
chat
a
moment,
but
upcoming.
Soon
the
release
starts
on
monday,
this
upcoming
monday
10th
of
january.
The
production
readiness
review
soft
series
is
on
thursday,
the
27th
of
january
towards
the
end
of
the
month
and
enhancements.
Freeze
is
a
week
later
at
2am,
utc
friday,
the
4th
of
february,
which
is
6
p.m.
D
So
we
as
a
sig
have
not
yet
had
a
discussion
about
which
caps
we
want
to
queue
up.
I
didn't
put
on
the
agenda
for
today
because
I
didn't
do
my
homework,
but
we
should
go
through
the
kep
board
and
make
sure
that
everything
that
we
want
to
be
making
progress
is
making
progress
and
decide
which
ones
we
want
to
let
in
the
gate
this
cycle
we've
been
pretty
good.
The
last
couple
cycles
about
keeping
the
gate
closed.
D
K
Not
really
we
as
a
release
team,
don't
pick
themes
of
the
logo
and
those
are
generally
informed
by
what
the
sigs
put
in.
Obviously,
the
big
one
we
know
about
so
far
is
docker
shim
everyone's
talking
about
docker
shimmer,
all
the
time,
but
other
than
that.
No,
not
not.
In
particular,
it's
not
like
a
maintenance
release
or
a
feature
release
or
anything.
We
have
no
such
concept.
D
K
B
A
I
Okay,
this,
I
hope
this
one
is
quick,
but
that's
probably
a
hard
discussion,
so
I
was
talking
with
team
before
new
year.
I
don't-
I
don't
know
if
you
remember
about
that
team,
because
we
are
trying
to
promote
and
part
to
ga
right
and
we
have
a
situation.
I
was
talking
with
jay
as
well
that
we've
got
we've
reached
the
the
bar
to
promote,
but
cedium
is
not
able
to
right
now
to
implement
imports
on
their
cni,
so
we
have
red
hat.
I
We
have
entria,
we
have
calico,
we
have
cube
router
and
I
guess
we
have
one
but
but
syrian
got
some
some
some
hard
time
to
promote
that.
So
my
thing
is
that
I
really
want
to
remove
that
thing
from
my
kiwi
and
maybe
get
that
that
cat
promoted,
but
on
the
other
hand,
I
understand
the
the
problem
that
this
might
be
a
problem
to
the
ecosystem,
because
sodium
is
getting
more
and
more.
I
I
It's
gonna
pro
we
are
gonna,
probably
have
the
same
problem
that
we
we've
got
with
sctp
for
a
long
time.
So,
like
like
people
jumping
into
kubernetes
issues
and
saying
hey,
fctp
doesn't
work
on
my
cni.
I
don't
want.
I
don't
know
what
to
do
so,
I'm
just
bringing
here
to
discussion
because
I
actually
I
don't
know
what
to
do.
I
don't
know
team
if
you
got
some
return
from
sydium
folks
as
well
or
if
we
just
should
like
okay,
whatever,
let's
wait,
one
more
cycle.
D
I
I
did
spend
a
little
time
talking
with
folks
over
at
psyllium
and
the
short
answer.
Was
it's
difficult
to
implement
efficiently,
not
impossible,
but
they'd
have
to
spend
person
time
on
it,
which
they
don't
have
a
whole
lot
of
reason
to
do
at
the
moment,
because
it's
not
been
super
important
and
what
what
we
are
missing
as
a
community
is
a
norm
for,
do
they
have
to
do
it?
Do
we
have
a
stick?
Is
there
a
carrot
like?
Can
we
encourage?
D
How
do
we
encourage
implementations
to
stay
up
to
the
current
and
to
do
things
which
you
know?
Maybe
they
have
other
priorities,
I'm
sure
they
do
and
and
if
the
carrot
doesn't
work
then
do
we
have
a
stick,
and
I
don't
know
that's
an
english
phrase.
I
don't
know
if
everybody
gets
it,
but
the
so
I
don't
have.
I
don't
have
a
real
good
answer
here.
We
talked
sort
of
a
little
bit
about.
Do
we
need
network
policy
conformance?
D
J
So
in
this
specific
case,
as
opposed
to
the
general
case,
where
yeah
we
maybe
do
need
some
solution,
but
this
was
a
very
poorly
motivated
new
feature
and
and
so
we
can't
have
any
stick
that
involves.
But
people
actually
want
this,
because
we
don't
actually
have
a
lot
of
evidence
that
people
actually
want
this
and
and
so
they're
choosing
to
not
implement.
It
might
be
the
correct
decision.
D
I
I
Folks,
using
that
and
saying
hey,
okay,
this
is
ga,
so
we
now
need
to
support
that,
and
some
cni
supports
us,
I'm
not,
and
maybe
we
need
to
have
some
conformance
like
meth.
That
has
been
doing
that
with
cyclones
on
past
he's
shown
that
to
us,
but
even
that
it's
a
big,
I
got
the
the
the
word
team
about
the
stick
and
the
carrot.
I
can
understand
that.
So
that's
a
that's!
That's
a
big
stick,
saying
hey!
You
are
not
conformed
with
kubernetes
anymore,
because
you
don't
implement
this
feature
right.
So.
D
And
honestly,
if
we
go
that
route,
we
probably
need
to
like
talk
to
cncf
folks
about
what
does
it
mean,
because
I
don't
think
we
as
a
sig,
like
we
can't
revoke
somebody's
permission
to
use
the
name
kubernetes
unless
we
put
it
in
the
real
conformance
suite.
But
network
policy
has
always
been
an
optional
feature,
so
we
can't
really
put
it
in
the
conformance
suite,
so
we're
on
sort
of
untrodden
territory.
So
far,.
J
Maybe
we
need
some
standardized
way
of
describing
what
network
features
a
plug-in
implements,
because
it
was
never
intended
that
everybody
was
going
to
be
or
never
assumed
that
everybody
would
implement
sctp.
It
was
just
if
a
plug-in
implements
sctp.
This
is
how
it
should
work
so
that
they're
compatible.
D
So
there's
another
cap:
there's
the
network
policy
network
policy
status
kept,
which
suggests
maybe
we
should
add
a
status
field
that
can
say
hey.
I
can't
implement
this
policy
because
you,
you
know,
feature
x,
isn't
you're
trying
to
use
feature
x,
but
I
don't
support
feature
x,
which
isn't
super
helpful
for
legacy,
clients
or
legacy
implementations
who
don't
know
about
the
status
or
who
don't
know
about
the
feature
to
indicate
that
they
don't
support
it.
They
just
don't
see
it
right.
So.
I
L
I
I
think
it's
a
it's
a
major
problem
like
with
cmp
with
cluster
network
policy,
we're
thinking
how
can
we
build
it
so
that
we
can
expand
to
new
types
of
selectors
in
the
future
and
it's
the
same
sort
of
problem
like
we
don't
know
if
we
should
be
doing
that
with
the
status
or
should
we
have
some
sort
of
like
sig
network
object?
That
states
like
this
is
what's
supported,
kind
of
what
dan
was
alluding
to
earlier,
like
there
might
be
a
better
way
to
do
this.
Besides,
just
focusing
on
network
policy.
D
J
I
D
J
D
D
So,
that's
not
shouldn't,
say
it's
off
the
table.
It's
it's
a
little
weird.
I
think
we're
the
only
subsystem
that
has
this
problem,
but
we
have
it
in
spades
right.
We
have
ingress
and
gateway
and
network
policy
which
are
all
gonna
fall
in
the
same
category.
Do
storage
providers
not
have
this
problem?
I
I
don't
know
a
lot.
D
D
A
C
L
L
H
H
D
D
D
H
D
D
M
M
M
D
M
D
J
D
D
I
O
L
L
B
F
D
O
D
D
If
you
have
it
go
through
and
mark
which
ones
you
want
to
shoot
for
24
by
we'll
just
decentralize
this
anybody
who's
got
caps
that
they
would
like
to
target
for
24.
Please
try
to
hit
it
with
the
milestone,
24
or
ping
me.
If
you
can't.
I
think
you
can
do
that
through
a
comment
and
that'll
help
us
when
we
look
at
this
next
to
prioritize.