►
From YouTube: Kubernetes SIG Network meeting for 20230202
Description
Kubernetes SIG Network meeting for 20230202
A
This
will
be
my
first
time
hosting
the
meetings
so
I
figured
I
would
introduce
myself
I,
think
I
know
most
of
you
and
have
met
many
of
you
in
person.
But
for
those
of
you
who
don't
know
me,
I'm
Shane,
utt
I
work
on
kubernetes
networking
at
Kong,
I'm,
probably
best
known
in
the
in
the
community,
for
working
as
a
maintainer
on
Gateway
API,
along
with
Rob
Scott
and
Nick
Young
Mike,
Zappa
and
I
responded
to
the
call
for
chairs
for
volunteers.
So
this
would
be
my
first
time
hosting
today.
A
C
D
C
E
C
C
G
G
C
C
C
C
B
C
B
Think
what
you
really
want
is
a
gateway
like
this
is
kind
of
what
Gateway
is
aiming
for.
Rob.
Stop
me
if
I
oversell
it
or
anybody
else
is
working
on
Gateway,
but
I
feel
like
this
service
was
designed,
for
you
know
a
small
set
of
things
in
a
very
opinionated
and
sometimes
not
helpful
way,
which
I
think
is
what
you're
struggling
with
in
the
sort
of
concentric
or
stacked
model.
B
H
E
H
A
Up
I
was
just
gonna
say
it's
not
a
no
to
your
question
Tim,
but
it's
suffice
to
say
most
Gateway
implementations
today
or
I'm
in
cluster
Gateway
implementations.
They
actually
just
use
service
type
load
balancer.
So
there's
some
work
to
be
done,
certainly,
but
if
I'm
reading
the
room
right,
it
sounds
like
the
general
sentiment
here
is.
A
B
This
all-encompassing
thing,
which
we're
now
you
know
having
to
suffer
with
I,
would
love
it
if,
in
the
limit,
nobody
used
service
type
other
than
cluster
IP
and
everything
else,
maybe
not
even
cluster
IP
like
maybe
we
have
a
different
type,
but
all
service
load,
balancers
and
node
ports
and
everything
else
was
defined
as
gateways.
They
could
be
implemented
in
the
same
proxies
but
they're
defined
through
the
Gateway
API.
A
B
C
C
Believe
I
have
like
a
misunderstood.
The
Gateway
I
thought
it
was
more
of
a
replacement
for
the
Ingress
thing
if,
but
if
it
can
do,
if
you
can
Implement
a
an
old
load,
balancer
that
actually
load
balance
external
traffic,
yes
to
various
ports
through
another
Network
than
the
the
kubernetes
network,
then
certainly
I
should
check
it
out
yeah.
But
if
it's
too
long
in
the
future
or
that
might
not
be.
B
A
B
G
B
Great
and
as
a
as
a
reminder,
procedurally,
you
know
when
we're
doing
triage,
we're
usually
asking
for
somebody
to
volunteer
to
confirm
an
issue
so
Shane
you
can
go
further
than
that
or
you
can
get
to
the
point
where
you're
like
yup.
This
is
a
real
bug
and
then
triage
accept
it.
And
then
you
know
now
we
can
figure
out
who's
going
to
work
on
it
or
you
can
continue
to
work
on
it.
Roger.
A
G
I
F
H
Has
been
yeah,
this
has
been
a
long
running
issue
there.
The
the
current
state
is
that
it
was
closed,
follow-up
and
cap.
The
author
of
the
issue
did
not
want
it
to
be
closed
and
reopened,
and
it
is
stuck
in
a
I
think.
The
author
would
prefer
to
leave
this
this
issue
open
until
the
feature
request
was
implemented.
Not
you
know,
I
don't
know.
Procedurally,
what
the
thing
to
do
here
is.
B
We
don't
have
a.
We
don't
have
a
like
procedure
that
we
have
dictated
for
defining
a
feature
request
and
then
there's
a
cap
open
for
it.
Should
we
keep
the
feature
request
open
or
should
we
close
the
feature
request
in
favor
of
the
cap,
which
is
sort
of
what
we
usually
do,
except
in
this
case
the
cap
wasn't
exactly
what
he
was
thinking
about
it
or
didn't.
B
B
H
I
A
D
Sure
so
I
did
kind
of
what
you
asked
for,
and
also
something
a
little
bit
broader
I
noticed
that
we
have
a
great
deal
of
very
old
issues,
we're
talking
like
five
years
old
and
more
that
are
labeled
Frozen
and
so
that
might
be
low
hanging
fruit
to
like
hit
some
of
the
really
old
ones
and
be
like.
Oh,
we
already
took
care
of
that
or
oh
we're,
definitely
not
doing
that.
D
D
It
was
interesting
because
I
wonder
if
this
the
last
thing
was
Elena
hashman,
saying
what,
if
we
either
didn't,
do
this
or
pushed
it
to
cni
and
I
thought
this
sounds
like
low
hanging
fruit.
Do
we
actually
want
Sig
Network
to
add
a
scheduling,
resource
or-
and
it
looks
like
Antonio
and
Tim-
had
already
waited
on
this
years.
Yeah.
G
G
B
B
I
agree
with
Antonio
in
that
I
wouldn't
want
to
schedule
Network
bandwidth
like
like.
We
do
course
right.
You
have
access
to
one
gigabit
per
second,
and
that
means
there's
only
nine
gigabits
per
second
left
for
anybody
else.
Right
I,
don't
think
we'd
want
to
do
that.
I
do
think.
It's
interesting
to
question
whether
this
machine
is
a
one
gig
Machine
versus
this
machine
is
a
10.
Gig
machine
is
something
that
users
would
like
to
express
in
their
pod.
I
request
a
10
gig
machine.
B
They
can
do
it
through
things
like
node
selectors
today,
but
that's
really
sort
of
distant
from
what
they're
trying
to
express
and
so
I've
left.
This
historically
I've
left
this
open
because
I
don't
know
what
the
right
answer
is
and
I
don't
have
enough
signal
from
our
own
customers
as
to
what
exactly
they
would
want,
because
it's
not
it
doesn't
seem
to
be
anybody's
highest
priority.
B
B
You
know,
first
of
all
for
the
node
to
say:
I
have
these
Network
bands,
like
top
gold,
silver
bronze
and
for
a
pod
to
request
which
band
it
would
fall
into,
which
would
give
it
Priority
Access
to
the
bandwidth,
but
not
necessarily
a
guarantee
of
bandwidth,
and
you
know
that
that
proposal
would
seem
to
fit
well
with
network
I.
Don't
know
if
that
alone
satisfies
this
demand.
J
Yeah
I'm,
talking
on
muted,
no
I,
said
I
agree
with
what
you
said
and
I
was
going
to
say
something
similar,
because
we
should
never
put
numbers
I
mean
we
have
400
gig
interfaces
now
I
mean
110
1400
200
400
we're
going
to
get
the
terabit
interfaces.
So
this
is,
it
doesn't
make
sense,
but
gold
silver
bronze.
Then
you
can
do
that.
Mapping
for
each
system.
F
Attention
I
think
they
are
conflicting,
a
bunch
of
and
I
think
we
do
completing
a
bunch
of
things
together,
congestion
avoidance
and
all
of
that,
that's
having
a
bandwidth,
or
it
doesn't
mean
that
you
would.
You
will
have
con,
you
will
have
no
congestion,
meaning
the
only
way
like
we
don't.
We
cannot
say
expert
percent,
as
Antonio's
I
think
was
outlined,
that
what
you
can
say
is
Max
off.
F
It's
like
Microsoft
I,
don't
know,
100
makes
per
second
200
Megs
per
second,
and
even
if
you
do
that,
you
cannot
say
you
cannot
say.
Oh
because
I
have
one
gig
and
I
said
that
this
one
is
200
makes
then
I
have
800
makes
for
everything
else.
The
truth
is
kubernetes
when
it
runs.
It
doesn't
know
about
everything
in
the
node
all
right.
Take
an
example
of
Apt
upgrade
apt
update
that
upgrade
happening
during
some
intensive
network
activity
that
takes
some
Network.
F
So,
even
though
that
we
say
that
800
Megs
are
for
you,
you
can't
get
them
because
something
we
don't
know
about
is
running.
I
think
it's.
This
is
more
about
the
status
of
the
network
like
the
way
the
Azure
is
expressed.
As
do
you
want
to
play,
support
somewhere,
where
the
network
is
not
congested
and
move
it
if
the
network
is
congested,
that's
as
far
as
I
can
tell
from
the
reading
I
think
we
need
to
sit
down
and
just
agree
on
defining
what
we're
trying
to
what
what
this
like.
It
makes
sense.
F
J
F
F
Of
some
skew,
and
then
you
have
a
Max
transmission
rate
for
this
VM.
It
doesn't
matter
if
you
want
to
split
them
on
six
next,
one
like
it
doesn't
matter.
So
what
the
model
you're
talking
about
is
where
we
have
two
networks
truly
connected
to
different
switch,
where
every
every
neck
has
a
hundred
percent
of
the
capacity.
So
the
app
can
use
the
neck
that
has
10
gig
and
that's
how
you
can
reserve
10
gig
by
just
making
sure
that
no
other
apps
on
the
same
network
on
the
same
node
is
using
that
neck.
F
J
F
B
B
My
inclination
is
to
close
this,
so
we
don't
have
a
good
protocol
here
like
people,
please
weigh
in
I
like
the
idea.
I
think
there
is
a
problem
here.
It's
not
acute
enough
that
anybody's
working
on
it.
If
somebody
were
to
show
up
with
a
kept
in
real
use
cases
and
want
to
work
on
this
I
wouldn't
say
no
to
it,
but
I,
don't
think
it's
anything
that
anybody's
going
to
work
on
anytime
soon
and
I.
Don't
know
that
keeping
this
five-year-old
bug
open
helps
very
much.
A
My
inclination
is
to
close
it
with
a
comment
that
says,
like
explains
a
lot
of
the
context
that
we
were
just
talking
about
here
and
just
tries
to
very
graciously
just
say:
hey,
you
know,
it's
closing
doesn't
mean
it's
dead.
This
is
where
we're
at
with
this
right
now
we
don't
think
it's
actionable.
If
you
still
want
this,
please
feel
free
to
comment
here.
We
can
reopen
it
if
you
know
somebody's
willing
to
put
it
in
the
effort
here.
I've.
I
E
A
Yeah,
it's
an
interesting
one.
I
didn't
see
that
one
mine
stinks
I,
think
it's
not
great.
I
had
I
had
one
that
I
thought
was
fairly
good
a
couple
of
weeks
ago,
right
after
the
meeting,
but
then
Antonio
actually
kind
of
started,
updating
it
making
sense
of
it.
So
yeah
I
can't
remember
exactly
which
one
it
is
now,
but
I
picked
a
different
one
for
today,
I
thought
this
was
interesting.
A
A
G
E
G
Example,
you
have
a
lot
more
ipv,
but
it
didn't
happen
anyway.
I
think
that
was
less
who
opened
the
first
season
when
they'll
pop
it
up
that
there
was
cnis
that
configured
the
ports
with
leather
stack
and
the
API
was
showing
the
dual
stack.
But
the
question
was
single
stacked
and
then
then
we
see
in
the
cubelete.
So
the
problem
is
whatever
the
people
configure
in
the
cni.
You
kubernetes
is
going
to
eat
and
show
it,
and
you
don't
have
any
way
of
telling
the
cni
just
don't
use
this
IPS
for
this
family.
I
J
J
Don't
you
risk
getting
problems
when,
when
things
have
been
automatically
mapped
up
to
to
DN
to
DNS,
there's
one
thing
to
say:
I
don't
want
to
have
an
address
assigned
to
me.
It's
another
thing
to
say:
well,
an
address
was
assigned
to
me,
but
I
don't
want
to
use
it
see
what
I
mean
you
don't
want
to
have
any
quad
records
or
stuff
like
that
in
the
DNS
server
for
for
a
pod
or
a
service,
and
then
there's
no
one
answering.
C
J
C
C
J
A
So
it
kind
of
sounds
like
we're
in
a
situation
where
we
feel
like
we
could
do
this.
Our
ideas
about
how
to
do
it
right
now
are
a
little
call.
It
clunky,
but
we're
not
sure
if
we
should
is
this
a
situation
where
we
should
at
least
ping.
The
person
make
sure
they're
still
interested
in
this,
and
you
know
maybe
try
to
just
make
sure
they're
still
kind
of
I
mean
it's
been
a
year
check
in
and
if
they're
interested
in
this
get
somebody
to
try
to
drive
it
Forward.
E
B
Again
here
we
don't
have,
we
have
never
really
established
as
a
Sig
what
our
protocol
is
for.
Yes,
we
agree
that
this
is
probably
a
feature
request
that
is
reasonable,
but
but
nobody's
actively
working
on
it.
Nobody
will
be
working
on
it
anytime
soon.
Do
we
keep
it
open
in
perpetuity,
because
we
agree
with
it
in
principle
or
do
we
close
it
because
nobody's
working
on
it
and
it
just
adds
noise?
A
I
personally
lean
towards,
if
it's
not
actually
going
to
be
worked
on
closed,
does
not
mean
dead.
Close
just
means
you
can
reopen
it.
If
you
are
the
one
who
wants
to
like
implement
it,
but
we
are.
We
don't
have
any
way
to
push
this
forward
right
now.
We
don't
have
anybody
who's
going
to
work
on
this
and.
A
B
I
struggle
I
mean
if
we
have
a
way
to
designate
that
specifically
okay,
like
if
you
look
at
how
many
issues
we
have
open
versus
how
many
issues
we
have
closed,
like
as
a
project
when
I
go
to
an
open
source
project
and
I,
want
to
file
a
bug
or
ask
for
a
feature.
I
do
search
their
open
issues,
I,
don't
generally
search
their
closed
issues,
because
it's
going
to
turn
up
10x
as
many
things.
B
A
B
B
Mean
unless
we
have
a
label
specifically
that
says
that
way.
You
know
we
could
have
a
label.
That's
like
you
know,
without
prejudice
and
people
could
reopen
if
they
felt
the
need
to,
but
we've
also
sort
of
shown
that
we
don't
have
a
lot
of
discipline
when
it
comes
to
applying
labels
properly.
So
that's
my
biggest
concern,
so
you'll
find
a
lot
of
these
issues
and
and
I
did
like
Bridget
I
went
back
to
the
the
annals
of
History
to
look
at
the
oldest
issues.
B
A
B
A
H
Well,
I
think
that
means
it's
me
yeah
topology.
Is
this
big
unanswered
floating
void
where
we've
kind
of
gone
in
circles
for
a
while
now
I,
don't
know
that
anything
we
say
to
at
today's
meeting
will
solve
it,
but
I
wanted
to
provide
some
updates
and
and
open
for
a
few
minutes
of
discussion.
I
know
we
have
at
least
one
more
thing
on
the
agenda.
H
H
What
I
have
in
this
cup
right
now
is
it's
kind
of
an
older
thing
which
was
actually
going
even
further
in
Hanson
and
said:
hey
anybody
can
publish
hints
and
because
anybody
can
publish
hints-
and
you
know,
create
your
own
algorithm.
We
would
actually
start
going
the
other
way
of
requiring
data
planes
to
support
hints
and
the
more
I
think
about
that.
The
more
I
think
that's
kind
of
backwards
yeah.
So
so
these
are
just
my
thoughts.
H
I
I
think
I'll,
try
and
update
this
PR
and
get
some
small
additions
into
this
specific
cycle,
but
I
think
a
lot
more
of
the
meaningful
conversation
has
happened
on
Dan's
cap
PR,
yet
again,
more
more
Dan,
more
caps
for
Dan,
but
I.
Don't
know
that
that's
my
my
take
on
hints
is
that
hints.
Could
you
know
maybe
even
at
some
point
become
an
implementation
detail
of
a
policy
it
could
become
a
let's.
H
Just
imagine
that
we
have
a
prefer
Zone
policy
or
something
like
that
hints
is
one
way
to
Implement
that
desire
right.
Somebody
wants
to
prefer
that
their
traffic
stays
in
zone.
Hence
is
one
way
you
could
accomplish
that.
I
I,
don't
know
just
some
high
level
thoughts,
but
maybe
if
anyone
else
has
ideas
on
what
we
can
do
to
push
this
forward.
I
A
B
I
mean
obviously
I've
spent
a
bunch
of
time
on
this
in
the
last
week
or
two
with
caps
and
stuff
I
largely
agree
with
you,
Rob
I
think
that
hints
are
an
implementation
detail,
at
least
as
they're
currently
defined.
They
are
in
implementation,
detail
the
way
we've
got
it
now.
Is
you
know,
traffic
policy?
Cluster
means
all
of
the
cluster
is
eligible,
it
doesn't
mean
you
have
to
spray
to
the
cluster.
It
means
the
cluster
is
eligible.
We
didn't,
we
haven't
written
docs
that
are
clear
enough.
B
Well
and
that
that's
it
that's
part
of
the
efficacy
of
it.
It's
like
we're
hair
triggered
because
we're
unwilling
to
take
a
lot
of
Risk
by
default,
but
if
there
was
a
more
aggressive
heuristic
that
got
the
the
users
that
are
concerned
with
it
with
a
prefer
local
today,
if
it
got
them
to
98
in
zone
traffic,
not
a
hundred
but
98
or
95,
would
they
be
okay
with
that?
Or
do
they
actually
say?
No
really
I
really
need
a
hundred
percent
and
I'm
willing
to
take
that
extra
risk
right.
H
I
think
one
of
the
things
that
I
I
have
I
I
I
I
mostly
agree
with,
is
the
idea
that
hints
are
unpredictable
and
that's
frustrating
and
and
even
if
we
make
them
better,
they
you
know
the
the
more
magic
we
make
them
the
less
predictable
they
would
become.
You
know,
even
if
we
get
to
97
or
something
like
that,
whereas
you
know
I
I,
don't
know
I
I
get
both
sides.
H
B
B
This
is
an
implementation
specific
resource.
Would
it
have
changed
people's
perspective
on
what
hints
are
about
right?
If,
if
hypothetically,
you
wanted
to
replace
Cube
proxy
and
endpoint
slice
controller
with
a
different
Discovery
mechanism
right
that
went
off
and
and
did
its
own
evaluation
and
had
Dynamic
feedback
loops,
that
watching
connections
per
second
or
bytes
per
second
or
whatever
it
would
use
to
determine
overload-
and
it
was
smarter
than
our
current
implementation
is.
H
You
know
so
topology
spread
constraints
right
on
from
scheduling
perspective
are
decidedly
more
complicated
than
anything
we've
exposed.
That
is
similar
on
the
networking
side
right
and
so,
at
least
from
scheduling
perspective
kubernetes
has
said:
hey
we'll
we'll.
Let
you
be
very
specific.
We
we
will
let
anybody
configure
very
fine
grain
details
and
from
networking
side,
I
think
what
we're
saying
is.
Actually
we
don't
want
to
provide
that
same
level
of
granular
configuration
because
we
want
things
to
be
a
little
bit
more
automatic.
B
The
sad
truth
of
this
project
is
because
of
the
Sig
structure
and
this
the
the
enormity
of
the
whole
thing
you
know.
Different
groups
are
making
different
decisions
based
on
different
criteria.
Had
anybody
consulted
me
about
that
on
the
scheduling
side,
I
might
have
had
the
same
argument
on
scheduling
and
like.
Is
that
an
implementation
detail,
or
is
it
part
of
our
API
contract?
Now
that
it's
in
the
API?
It
makes
it
that
much
harder
for
anybody
to
implement
a
different
schedule.
H
Yeah
yeah
no
I
I
agree
with
that
I
guess
what
I'm
saying
is.
If
we
had
a
naive,
topology
approach
from
networking
side,
we
could
punt
the
problem
and
say
hey
it's
a
it's,
a
scheduling
problem
that
you
don't
have
enough
pods
in
a
specific
zone.
Right,
it's
it's!
Not
our
problem,
we're
just
sending
traffic
to
the
pods.
You
have
in
the
zone
and
yeah.
You
know
yeah,
but
I
know
a
time
check,
and
this
is
a
complex
one.
We
we
can
follow
up
more
yeah.
B
B
We've
got
a
couple
of
people
who
are
vocal
about
it
and
at
least
one
of
them
represents
Gardner,
which
is
you
know,
a
separate
community
of
its
own
I'm
reluctant
to
make
a
final
decision
on
this
unless
we've
got
some
real
user-facing
input.
So
for
those
of
you
who
act
as
front
doors
for
other
users,
please,
you
know,
ask
these
questions
and
see
if
you
can
solicit
more
feedback
so
that
we
can,
you
know,
push
ahead
to
figure
out
what
we
need
to
do
here.
M
Yeah,
so
this
is
kind
of
the
evolution
of
Scott.
We've
been
talking
about
for
a
long
time
today
or
last
night,
late,
I
added
a
whole
history
section
so
that
we
can
kind
of
hopefully
try
to
stop
spinning
our
Wheels,
the
history
section's
in
a
comment
at
the
very
bottom
right
now:
I'm,
adding
it
to
the
cap
right
now.
M
It's
long
but
I
think
you
know,
I
opened
this
cup,
which
is
really
just
mostly
a
copy
paste
of
a
cup
we
already
had
that
Jay
had
opened
talking
about
the
libraryification
of
coping,
so
kaping
went
out,
did
an
amazing
job,
Amazing
Project
we
got
feedback
from
the
Sig.
They
said
we
like
a
ping,
but
really
we
want
it
to
be
more,
like
a
library,
there's
more
details
on
that
in
this
history
so
enter
like
where
we
are
now.
M
Okay,
we
have
agreement
from
the
Sig
that
we
want
to
make
writing
new
back
ends
easier
in
the
future
and
we
need
a
way
to
move
forward.
But
we
don't
know
where
that
Library
should
live.
We
don't
know
we
haven't
decided
yet
should
the
existing
Cube
proxies
back
ends,
use
that
Library
and
those
two
questions
I
think,
are
kind
of
hanging
us
up
and
making
us
kind
of
go
round
and
round.
So
like
what
I
asked
this
group
when
you're
reviewing
this
cap,
it's
still
early,
it's
up
for
change.
M
We
have
a
lot
of
great
comments
already
like
try
and
ask
yourselves
for
any
future
work
around
Cube
proxy
new
back
ends
kapang.
Where
do
we
want
this
to
live?
We
wanted
to
live
in
tree
and
ask
ourselves
like
what
do
we?
What
does
it
mean
for
the
existing
Cube
proxies
like?
Do
we
want
the
existing
group
proxies
to
use
this
new
work,
or
is
it
a
totally
new
thing?
M
A
A
Shared
community-built
core
that
everybody's
kind
of
at
least
using
some
of
right.
Otherwise,
I
worry.
We
get
into
a
situation
like
Linux
got
into
like
15
years
ago,
where,
like
every
distribution,
was
so
different,
you
couldn't
really
get
things
to
work
and
I.
Don't
want
kubernetes
to
end
up
anything
like
that.
A
G
G
That
there
are
a
lot
of
the
cap
has
different.
Every
people
has
a
different
opinion
and
is
not
cohesive,
so
some
people
want
to
use
entry
to
test.
Other
people
want
to
have
a
shared
Library.
Other
people
want
to
do
move
to
proxy
out
to
three.
So
I
think
that
the
first
question
is
that
we
have
to
do
this.
What
we
want
to
do,
there
are
certain
things
that
I
I
don't
have
to
create.
So,
for
example,
is
people
want
to
write
proxies
I
really
I
was
checking
the
Andrea
coat.
G
I
lasted
a
great
job
there.
Looking
for
information,
the
entire
code
is
just
not
a
bendering
doing
a
new
process
Bender
in
a
binary,
instead
of
using
a
demon
set,
they
just
put
everything
and
ready
I,
don't
see
that
senior
obvious
kubernetes
or
another
I'm
going
to
write
new
proxies.
So
what
is
I
really
think
that
we
should
ask
the
question:
is
what
really
the
people
need?
What
is
the
people
needing
I
think
that
the
what
language
they
say
at
the
end
is
maybe
they
want
a
library,
but
for
what?
G
Because
moving
you
proceed
to
studying
what
they
are
going
to
Bender
the
old
AP
tables,
since
that
we
have.
That
is
very
that
they
don't
need
that
they
just
can't
build
the
binary
and
run
a
demon
said.
So
every
thing
that
we
need
to
understand
better
what
the
people
want,
and
once
we
have
these
requirements
we
we're
able
to
solve
or
to
provide
a
solution,
but
right
now
I
I
really
don't
understand.
You
know
what
is
the
real
demand.
M
G
The
future
yeah,
but
that's
the
thing
is
API,
has
19
vendors
and
they
don't
have
any
any
need
to
write
new
process.
That's
why
why
I'm
I'm
challenging
this
is
the
there
are
already
proxies,
and
this
is
a
seven
year-
soil
technology
Services
there
is
it's
really
it's
so
hard
to
write
a
proxy
that
we
need
to
write
a
library
entry
for
this.
A
Yeah
I
hear
what
Anthony
was
saying
and
I'm
thinking
Andrew
shouldn't
we
be
able
to
kind
of
go
grab
some
people
and
pull
them
into
the
cap
and
kind
of
say
exactly
what
they're
looking
for
like.
We
should
be
able
to
find
some
of
the
relevant
implementers
and
stuff
like
that
and
get
they
get
their
input
right.
Yeah,
I
think
a.
G
No,
no,
the
other
thing
is
you
just
say:
people
want
to
write
a
proxy,
so
you
I
went
to
the
campaign
project
and
you
have
five
proxies
in
three
months.
I
mean
all
the
people
here
can
write
approximately
a
week.
So
that's
the
other
question
is
who
needs?
Who
is
this
people
that
is
behind
this
demand?.
B
Why
don't
we
make
it
easy
for
them
to
consume
code
that
we
have
tested
and
validated,
and
then
they
can
do
the
part.
That's
interesting
to
them,
which
is
go
program.
Bpf
go
program,
NF
tables
go
program,
V
switch,
go,
do
something
else
with
the
information
once
we've
already
done
the
ugly
silly,
not
interesting
parts.
G
K
Mean
so
the
other
part
of
this
is
that
we
are
currently
massively
duplicating
effort,
like
we
have
one
team
of
people
maintaining
the
entry
proxies
and
the
library
code
that
they
use
and
then
another
team
of
people
working
on
a
completely
separate
code
base
with
out
of
tree
proxies,
and
wouldn't
it
be
cool
if
we
could
just
get
them
all.
Working
on
the
same
code
base.
G
B
Don't
count
on
the
the
teams
that
are
doing
the
out
of
tree
for
psyllium
and
the
out
of
tree
for
ovn
the
out
of
tree
for
entria
like
it's,
not
two
teams,
it's
actually
like
six
teams
that
are
doing
largely
the
same
work,
and
it's
not
the
interesting
work
right
like
it
is
bringing
no
net
value
to
the
ecosystem.
To
have
this
work
repeated
and
repeated
and
repeated
yeah.
G
G
And
and
that's
why
it
says
why
don't
we
put
that
in
the
cap
and
we
do
that
instead
of
you
know
doing
going
rounds
with
different
things.
It's
just
Define
these
interfaces
and
and
let's
work
on
that.
What's
the
problem
in
that
and
we
don't
need
to
shuffle
code
around
it's
just
migrate,
we
are
going
oh.
M
G
G
Know
no,
what
that's
what
I
say
is
if
you
write
interfaces
on
the
API,
it
has
to
be
in
three
and
I
say
that
like
100
agree
with
that,
what
kind
of
100
is
that
moving
clothes
around
and
then
change
everything,
because
that's
I
mean
you
have
to
work
for
something
and
understand
Neymar,
and
you
have
to
retest
everything
on
this
environment.
What
I
don't
know
I
agree
is
just
pull
a
whole
project
inside
the
project
in
in
one
shot,
because
that's
another
nightmare
I
mean
and
and
it's
just
it's
yeah.
I
G
B
Sorry
I
want
to
wrap
for
for
time.
I
haven't
read
the
entirety
of
this
cap
here.
I
think
the
only
real
decision
here
is
to
staging
or
not
to
staging
beyond
that
I
think
everybody's,
agreeing
that
having
a
library
of
some
sort
is
useful,
whether
we
seat
it
from
the
existing
code
or
whether
we
design
it
from
scratch.
The
kept
doesn't
need
to
cover
the
design
of
the
library
it
needs
to
cover
the
mechanics
of
how
we're
going
to
use
it
and
publish
it.