►
From YouTube: SIG Network Gateway API meeting for 20230516
Description
SIG Network Gateway API meeting for 20230516
A
All
right
welcome
to
the
Gateway
API
meeting
for
May
16th
we're
trying
a
different
timeout
today.
Hopefully
this
is
more
helpful
to
people
in
different
time
zones
than
our
typical
meeting
times
again.
Just
a
quick
reminder:
this
is
a
kubernetes
community
meeting,
which
means
we
abide
by
the
cncf's
code
of
conduct.
A
really
high
level
overview
of
that
is
just
to
be
nice
to
each
other.
I
have
not
had
any
issues
with
that,
but
just
a
reminder.
A
B
C
Hi
I'm
Dan
I
am
I
surveillance,
but
I
also
maintain
another
layer
for
load
balancer
projects,
not
unlike
metal
LD
there's
been
bits
of
communication
that
I've
been
having
all
around
kind
of
the
TCP
UDP
route
implementation,
where
we're
not
in
charge
of
the
data
plane
where
we
need
Q
proxy,
and
things
like
that.
So
I've
been
working
on
an
implementation,
that's
going
to
be
a
new
controller
for
both
metal,
LLB
and
4qvip.
D
Hello
I
just
joined
so
I
had
the
wrong
link,
but
my
name
is
Jeremy.
Morris
I
recently
joined
Microsoft
on
the
service
mesh
team
with
Keith
Maddox,
so
yeah,
it's
my
first
time
attending
this
meeting
cool
welcome.
E
Hello,
Dan
hi
I'm
I'm,
a
software
engineer
at
redhead,
well,
I've
been
working
with
quadrant
team
on
policy
implementation
for
existing
Gateway
providers,
so
we're
not
actually
implementers
of
Gateway
API.
Rather,
we
are
providing
implementation
of
policies,
different
kinds
of
policies
for
the
existing
Gateway
implementations.
A
Great
welcome
and
that's
it
sounds
like
you've
picked
a
very
relevant
meeting
to
be
around
that,
because
I
think
policy
is
going
to
be
on
the
agenda
and
not
too
long.
So
thanks
for
being
here
cheers.
A
Great
I
think
that
that's
everyone,
but
don't
hesitate
to
to
as
always.
Oh
actually,
yeah
we've
got
one
more
person.
You
are
yeah.
F
Yeah
I
didn't
I,
didn't
understand.
Let's
introduction
like
John
just
now,
but.
C
C
F
With
Rob
based
in
London
and
that's
the
reason,
I
wasn't.
C
D
F
A
Awesome
yeah:
this
is
a
great
turnout.
It's
it's
really
cool
to
see
more
people
from
different
time
zones
here.
A
G
Then
so
yeah.
A
G
Think
I
I
spoke
last
time.
My
name
is
Alex
and
yeah.
I
am
joining
most
of
most
of
the
networking
meetings,
so
I
have
joined
forces
with
Jay
on
the
kpng,
so
I
hope
that
there
will
be
delivering
delivering
mainly
there,
but
trying
to
gather
all
knowledge
that
I
can
about.
The
networking
stack
that
we
have
actually
that
we
have
here
so
yeah
I'm
from
Europe
as
well.
I,
don't
know
if
it
matters,
but.
A
A
No
that
that's
good
to
hear
the
more
the
more
people
we
can
get
from
different
time
zones,
the
better
so
yeah.
That's
awesome.
A
Cool,
that's
awesome,
yeah
really
great
to
see
so
many
new
people
make
it
for
this
slot
great
okay.
Well,
let
me
let
me
jump
right
into
the
agenda.
Then.
Hopefully,
I
haven't
missed
anyone
I,
don't
don't
hesitate
to
just
jump
in
if
I
did.
A
H
A
Anything
oh
yeah
pop
in
yeah
yeah,
exactly
throughout
I,
that's
one
detail:
I
I
missed
in
the
intro
to
this.
This
is
meant
to
be
an
open
Agenda,
so
anyone
should
be
able
to
edit
comment
whatever.
So,
if
you
have
something
feel
free
to
add,
it
also
feel
free
to
drop
things
in
chat.
Raise
your
hand
whatever
works
best
for
you
all
right
with
that
I
think
we've
got
a
packed
agenda,
so,
let's
get
into
it
first
up.
We
finally
got
v0.70
out
the
door.
A
Thank
you
to
everyone
that
helped
contribute
to
this
one.
Yes,
it's
been
a
long
time
coming
and
real
real
excited
to
see
this
one
out
and
I
know
we
had
kind
of
Frozen
most
merges
until
this
release
went
out.
So
I
think
there
are
plenty
of
people
that
are
also
happy
to
to
see
PRS
coming
back
in
and
merging
again,
and
you
know
I
I-
imagine
that
there
are
some
that
I
have
left
lost
from
my
radar,
so
I
and
I.
A
Imagine
that's
true
for
many,
so
if
you
have
a
PR
that
has
been
on
hold
because
we
said
well,
we
can't
merge
right
now
because
we're
releasing.
Please
don't
hesitate
to
to
Ping
on
that
again
and
we'll
try
and
get
back
to
it.
A
The
one
thing
that
is
worth
pointing
out
here
is
John
Howard
raised
and
fixed
this
issue
with
conformance
tests.
There
was
a
change
that
made
it
into
rc2
that
apparently
made
I.
Our
conformance
tests
fail
when
using
IPv6
addresses
that
is
now
fixed,
but
it
did
not.
That
fix
did
not
make
it
into
0.70,
which
means
we
will
need
an
0.71
at
some
point.
So
with
that
said,
I
just
want
to
encourage
people.
A
We
have
we're
gonna
say
around
two
weeks
until
we
want
to
get
that
that
next
patch
release
out.
So
that
gives
us
a
window
to
find
any
other
bugs.
We
might
think
of
or
really
I'll
just
highlight
anything
that
we
consider
in
scope
for
a
patch
version.
That
includes
clarifications
updates
that
fix
a
bug.
A
So
basically
bug
fixes
and
then
conformance
test
fixes,
but
maybe
the
the
most
yeah
important
one
that
may
not
be
something
like
you
think
of
is
we
do
allow
and
even
encourage
additional
conformance
test
coverage
as
long
as
that's
for
existing
features,
so
features
that
have
already
been
released
were
willing
to
accept
conformance
tests
and
get
them
released
in
a
patch
version.
So
we
have
a
number
of
conformance
tests
PRS
out
there,
like
I,
think
ones
for
request
mirroring
as
an
example.
A
That's
a
feature
that
already
exists,
so
it's
fair
game
for
this
patch
version,
because
it's
a
patch
release
you
need
to
cherry
pick.
You
can
get
back
into
that
a
little
bit
later,
but
yeah
anyway,
that
that's
coming
up
soon
and
then
just
to
try
and
set
a
rough
timeline
for
where
we're
headed
as
a
project.
A
We're
probably
going
to
do
an
0.8.0.
That's
really
tiny
and
focuses
on
just
gamma
graduating
to
experimental.
It
has
largely
hit
all
the
requirements
for
that,
but
we
just
need
to
make
the
changes
in
the
API
itself
to
say
you
know
this.
This
is
how
you
use
it
with
gamma.
We
have
some
gaps,
but
we
haven't
written
that
in
an
API,
spec
anywhere,
so
I
think
that's
something
that's
going
to
come
pretty
soon.
A
Maybe
I
can
defer
to
I
think
Mike,
Keith,
John
I,
don't
know
if
any
of
you
are
on
the
call.
If
you
have
opinions
on
this,
but
I
feel
like
we're
awfully
close
to
to
ready
to
graduate
this
one.
I
I
guess
I
think
we're
pretty
close.
There
is
just
kind
of
one
well,
these
are
just
the
mesh
Gateway
interaction
and
I
think.
The
conclusion
is
that
we're
probably
not
going
to
be
able
to
be
too
prescriptive,
but
we'll
still
need
to
put
something
either
at
an
existing
Gap
or
just
and
something
about
the
reasons.
What
the
rationale
behind
that,
but
yeah
I,
think
I
think
we're
pretty
close
six
weeks.
It.
J
Was
right
later
today
and
hoping
to
get
that
into
where
he
revised
and
publicly
yeah
a
state
where
it
is
reviewable.
K
A
A
I
tried
to
do
some
some
rough
math,
but
if
we're
targeting
a
release
before
kubecon,
which
is
the
goal
that
gives
us
around
16
weeks
from
today
to
have
it
ready
for
API
review
so
yay
that's
a
lot
to
do
over
the
summer,
but
our
release
blocking
issues
for
1.0
are
getting
to
be
a
fairly
small
list.
So
again,
those
are
those
are
our
goals
and
I.
Think
we've
mentioned
this
in
previous
meetings.
A
But
again,
what
we're
considering
in
scope
for
a
1.0
release
is
graduating
gateway,
gateway,
class,
Gateway
and
HP
route
to
ga
there's
a
there's,
a
milestone
that
covers
it.
But
those
are,
you
know,
high
level
goals
for
1.0,
okay.
So
that's
that's
a
lot
and
I
want
to
keep
on
moving
because
there's
plenty
more
on
this
agenda.
Let
me
hand
it
over
to
Shane.
H
Yeah
this
one
is
just
a
single
tier
I
wanted
to
share
with
you
all,
but
we
did
get
into
multiple
pages
of
PR
reviews
recently
and
I'm
sure
now
that
we've
released
the
b070
we'll
be
able
to
Shore
that
up,
but
just
wanted
to
make
a
general
call
out
if
you're
a
reviewer,
we
appreciate
you
signing
up
to
be
a
reviewer
if
you're,
not
a
reviewer
still
may
be
very
helpful
to
us,
especially
over
the
course
of
these
next
few
months
to
help
get
GA
out
the
door
by
Chicago.
H
If
anybody
who
can
spare
some
time
to
review
just
jumps
in
helps
us
Shore
up
some
of
this
backlog
of
PRS,
even
just
jumping
in
and
being
like
hey,
what
can
we
do
to
kind
of
refocus
this
or
who's
blocked?
What
are
they
blocked
on?
Is
there
something
I
can
help
to
facilitate
that
kind
of
stuff
can
be
helpful
and
we
appreciate
it
if
you
have
the
time.
H
So
that's
all
we
have
the
the
project
on
the.
If
you
go
to
the
projects
page,
the
the
road
to
GA,
which
you
should
see
some
updates
on
soon
Nick,
Rob
and
I-
are
going
to
kind
of
sit
down
and
start
seeing
if
there's
ways
to
streamline
that
a
little
bit
better.
But
it's
currently
in
pretty
much
the
right
shape
and,
for
the
most
part,
I
think
everything
that's
4ga
that
needs
to
be
reviewed
is
on
that
board.
H
H
It
doesn't
have
a
history
in
any
other
apis
and
also
for
like
Ci
and
stuff
like
that
for
layer
four,
so
it
is
a
gateway,
API
implemented
load.
Balancer
only
does
layer,
four
TCP
and
UDP
route
right
now
and
it
the
data
plane,
is
written
in
Rust
with
ebtf.
This
is
an
interesting
fun
project
and
it's
on
its
way
to
the
cncf.
We
are
donating
it
to
for
the
purposes
we
just
covered,
but
there's
some
here.
Actually,
let
me
share
my
screen
a
little
bit
if
I
may
Rob.
H
So
for
those
of
you
who
don't
know,
there
is
a
little
bit
of
intrigue
going
on
with
the
cncf
which
you
can
find
in
the
discussions
board
for
the
project
here,
where
GPL
licensing
kind
of
unexpectedly
caused
some
I'll
just
call
it
Intrigue.
So
it's
taking
a
little
bit
of
time,
but
my
understanding
is
that
we
should
probably
be
looking
at
it
finally
being
merged
into
kubernetes
over
the
course
of
the
next
few
months.
H
A
couple
months
they
said
June
was
when
they
were
going
to
start
getting
sitting
down
and
like
finishing
their
legal
review.
So
anyway,
I
digress
a
little
bit,
but
I
wanted
to
give
some
people
some
ramp
up.
If
you're
interested
checking
with
us
offline
on
the
Gateway
API
Channel,
we
did
just
release
v020,
which
includes
the
very
basic
initial
support
for
TCP
route.
H
So
that's
what's
going
on
with
the
project
now,
and
that
was
a
huge
that
was
a
major
Milestone
to
get
us
ready
to.
Not
only
do
all
the
things
we
said
with
like
testing
and
stuff
like
that
with
Gateway
API,
but
it's
also
a
stepping
stone
for
us
to
start
helping
build
out
layer,
four
conformance
tests,
which
still
don't
exist,
though
we
have
several
implementations
doing
L4.
So
that
was
another
point
of
this
project.
H
One
of
the
things
we
kind
of
have
been
using
it
for
is
a
way
to
help
push
L4
forward
a
bit
because
it
there's
been
a
lot
of
static
in
that
area.
And
yet
we
know
there
are
implementations.
So
hopefully
it
can
be
helpful
in
just
kind
of
wearing
the
banner
for
that
and
everybody
else
will
jump
in.
That
sounds
like
Dan.
H
Finneran
might
have
something
that
could
kind
of
come
in
on
that
angle
and
then
I
know
we
have
the
stunner
project,
and
then
we
have
a
couple
other
UDP
route
implementations,
so
cool
cool,
I
figured
I'd,
give
a
quick
demo
I,
don't
know
we
don't
have
a
ton
of
time.
I'll
try
to
make
it
very
quick
and
if
it
doesn't
work
or
something
I
won't
try
to
sit
around
and
make
you
guys.
H
Watch
me
fix
it
or
anything,
but
I
thought
it'd
be
interesting
to
just
see
it
working
so
on
the
right
here
you
have
the
data
plane
logs,
basically
just
an
ebpf
program
sitting
in
the
kernel
that
will
more
or
less
there's
some
details,
but
more
or
less
respond
to
a
TCP
route
being
created
by
taking
the
VIP
the
IP
address
and
then
routing
it
to
whatever
back-end
pod
IPS.
H
G
H
L
H
It's
good
from
here.
Okay,
all
right!
Try
to
keep
this
quick
so
anyway,
on
the
right
data,
plane,
I,
hope
the
I
glossed
over.
What
it's
doing,
but
basically
sees
TCP
route,
makes
sets
up
a
BPF
redirect
to
the
Pod
eyepiece
and
then
on
the
left.
H
Here
we
added
so,
if
you're
interested
in
this
some
samples
for
CCP
route,
which
includes
a
little
basic
server,
the
TCP
route
and
the
Gateway
for
it,
which
will
deploy
here,
and
you
will
actually
see
some
errors
on
the
right
because
I'm
running
on
Main
right
now
and
we
just
updated
something,
but
it
should
work.
H
Aya,
our
BPF
library
in
Maine
we
updated
and
apparently
it
broke
some
stuff,
so
it
broke
logging.
So
the
logging
isn't
quite
right
at
the
moment,
but
everything
else
seemed
to
be
working
when
I
test
it.
So
when
we
create
the
Gateway,
it
should
give
us
a
gateway
with
an
IP
address,
so
there's
our
IP
and
then
we
have
our
TCP
route,
which
is
just
at
this
point.
It's
just
an
HTTP
server
behind
it
for
the
sample
and
it's
pretty
much
as
simple
as
if
it's
working.
H
Yeah,
so
there's
a
little
test
server
back
there.
This
is
a
little
test
server.
That
I
wrote
it's
kind
of
similar
to
http
bin.
If
you're
familiar
with
that,
it
has
a
couple
of
different
like
status,
endpoints
and
stuff
that
you
can
hit
and
you
can
see
on
the
right.
The
data
plane
is
picking
it
up
and
the
big
work
that
had
to
be
finished
recently
was
egress.
H
Tcp
Ingress
had
been
working
for
a
while,
but
we've
kind
of
been
off
the
blitz
project
for
a
few
weeks
because
of
kubecon
and
stuff
we've
got
back,
the
egress
is
now
working
if
you're
interested
It's,
all
under
the
data
plane,
ebpf
source
Ingress
and
egress
tcp.rs,
and
it's
all
very
it's
all
very
simple
right
now.
It's
not
doing
you
know
it's
not
ready
for
production.
It's
never
really
going
to
be
intended
for
that.
H
H
L
A
Awesome
well,
let's,
let's
keep
on
running
then
conformance
profiles.
Matia.
Are
you
on
this
call?
Yes,.
M
I
am
here
awesome:
okay,
hi
all
I
work
at
Kong,
and
today
we
wanted
to
Showcase
something
about
the
conformance
profile
feature
that
Shane
has
been
leading
and
he
broke
the
the
GB.
And
then
we
worked
together
to
make
it
working
in
the
you
know,
in
an
actual
implementation,
which
is
the
kubernetes
Ingress
controller
may
I
share
the
screen.
A
Yes,
definitely
one
second.
M
Can
you
see
it
yep,
okay?
Well,
basically,
the
the
first
intention
was
to
do
some
demo
of
the
conformance
profile
PR
that
I
Linked
In,
the
the
in
the
meeting
notes,
but
it
we,
it
would
take
some
time.
So
this
is
I
will
showcase
a
result
that
I
just
created
a
half
an
hour
ago.
So
here
we
wanted
to
show
how
an
implementation
could
use
this
new
feature,
this
new
experimental
conformance
the
suite
to
claim
a
conformance
on
a
certain
profile.
So
basically,
here
we
have
the
conformance
test
file.
M
This
is
for
this
is
for
con
kubernetes
Ingress
controller,
and
here
is
the
instantiator,
the
the
the
function
to
create
this
new
conformance
test
Suite,
with
the
set
of
options
of
the
usual
options
for
the
conformance
test
suite,
and
then
we
have
a
set
of
features
that
we
claim
to
be
confirmed
with
a
set
of
skipped
tests,
because
maybe
our
implementation
doesn't
support
such
such
tests,
and
here
we
have
two
additional
Fields.
M
M
The
HTTP
route
has
an
additional
set
of
extended
features
with
all
the
non-core
features,
while
the
TLs
conformance
profile
has
no
extended
feature
at
the
moment.
So,
basically,
here
we
we
are
trying
to
to
to
to
claim
our
conformance
with
this.
With
to
these,
with
these
two
profiles
and
the
the
let's
say,
the
path
is
the
same
as
usual,
so
we
instantiate
the
suite.
M
We
call
setup
then
run
as
always,
and
here
a
new
function
has
been
added,
which
is
called
report,
and
the
report
basically
gather
all
the
the
outcome
of
the
of
the
G
Suite
run
and
we'll
create
a
structured
information
of
the
of
of
such
a
ram,
and
here
we
can
see
this
information.
Basically,
this
is
the
outcome
of
the
conformance
profile
run
as
a
first
as
a
first
step.
M
We
have
the
implementation,
so
we
have
all
the
detail
of
the
details
of
the
implementation,
then
date
get
API
version
is
a
field
that
still
needs
to
be
addressed.
Basically,
we
want
to
have
the
specific
comment
of
the
Gateway
API,
the
of
the
Gateway
API.
We
are
trying
to
be
conformant
with,
but
this
is
again.
M
This
is
still
to
be
done
and
it
will
be
addressed
in
future
iterations
of
the
problem,
and
here
we
have
a
set
of
profiles,
as
we
saw
before
we
have
the
HTTP
and
TLS
profiles
and
some
information,
some
status
information.
The
first
one
is
the
one
related
to
core
then
extended
and
the
core
with
HTTP.
We
have
that
the
result
is
partial
because
we
passed
25
test
cases
and
we
have
three
Skipper
desks
for
these
reasons.
For
this
reason,
we
are
not
successful,
but.
C
M
Partial,
but
if
we
would
have
some
failing
tests,
the
result
would
be
failure
because
of
those
failing
tests
while
for
the
extended
the.
M
This
is
a
slightly
different,
because
even
if
we
are
not
passing
we
even
if
we
are
not
supporting
all
the
extended
feature,
we
can
get
the
success
badge,
because
we
are
explicitly
saying
that
we
are
going
to
support
only
HTTP
route
method
matching
in
this
case,
for
example.
So
if
we
pass
this
test,
we
can
see
that
here
is
number
one
for
test
passed
and
the
result
is
success
and
the
the
the
intention
is
that
by
having
this
this
statement,
success,
partial
or
failure,
along
with
the
supported
and
the
supported
features.
M
M
Which
are
related
to
the
Gateway,
and
this
is
happens.
This
happens
because
in
the
core
features
of
the
HTTP
route
and
the
TLs
TLS
route,
we
have
both
those
features
specified.
So
if
we
skip
some
tests
belonging
to
those
features,
they
will
be
marked
as
keypad
in
both
in
both
profiles.
So
here
here
is
a
very
quick
overview.
The
pr
is
is
is
in
review
at
the
moment,
and
it
will
need
some
further
iteration
on
the
problem
to
address.
C
A
Yeah,
this
is
awesome.
Thank
you.
Thank
you
for
sharing,
Matia
and
and
different
all
the
work
on
this
any
any
comments
or
questions
on
this
one.
K
L
Yeah
I'm
really
happy
with
the
partial,
the
yeah
filed,
partial
and
success,
metrics
and
I
think
the
beginning
of
the
the
fact
that
the
extended
part
is
you
claim
that
you
support
some
extended
features
and
the
success
is
based
on
whether
you
pass
the
test
or
the
features
that
you
claim
your
support.
That's
exactly
what
I
was
hoping.
H
J
H
Yeah
I
want
to
add,
on
top
of
that,
because
Matia
and
I
worked
on
this,
but
Our
intention.
This
is
underneath
an
experimental
go,
build
tag.
So
it's
not
part
of
the
regular
build
it's
a
it's
in
the
v070
tag,
but
not
by
default.
What
we'd
really
like
to
see
is
more
other
implementations.
It
would
be
nice
if
we
could
get
two
other
implementations
to
come
and
try
the
experimental
conformance
test.
H
Suite
I
think
we've
already
had
one
Sun
Jay
may
have
already
done
it
and
feed
into
the
Gap,
because
this
is
part
of
the
prototyping
stage
of
the
gap,
which
is
the
new
status
for
provisional
gaps.
Where
you
prototype
to
feedback
into
your
your
proposal,
it
would
be
very
great
if
we
could
have
more
than
just
us
at
Kong
as
a
writing
that
Gap
and
like
because
otherwise
I
expect
that
we'll
get
to
the
point
where
we're
in
experimental
and
we'll
have
to
come
back
and
do
stuff.
H
If
you
come
along
with
us
along
the
way,
we
should
be
able
to
get
things
more
right
and
it's
really
important
to
hopefully
get
at
least
this
part
of
the
Machinery
done
by
GA.
H
We're
basically
saying
I
think
we're
we're
at
the
point
where
we're
like
all
the
display
layers
and
other
stuff
doesn't
need
to
be
necessarily
done
by
GA,
but
we
do
want
to
have
the
core
conformance
profiles
and
Reporting
Machinery
done
by
GA,
like
in
a
ga
state
where
we
would
ship
them
to
people
and
say
you
can
run
this
and
then
send
us
back
your
reports
so
call
out
to
people.
Please
do
jump
in
it's
pretty
easy
to
get
it
up
and
running.
H
H
What
else
can
I
say
about
that?
I?
Don't
want
to
take
up
too
much
time,
except
I
think
we'll
get
a
much
better
result
if
we
can,
if
we
can
get
more
people
at
least
two
more
implementations
involved
in
these
early
stages,
because
the
next
big
step
here
is
probably
going
to
try
to
take
it
to
experimental
or
graduating
it.
And
we
should
be
doing
that
as
soon
as
we
can,
because
of
the
time
frame.
We're
aiming
for.
A
A
Yeah
yeah-
this
is
great
I
I
will
just
for
the
sake
of
time
and
seeing
our
agenda
still
have
plenty
on
here:
I'm
Gonna,
Keep,
On,
Running,
Nick,
I,
think
you're
up
next.
L
Yeah
the
that
I
just
wanna
put
a
note
here.
This
happened
to
us.
L
With
people
are
upgrading
between
psyllium
113
and
one
foot,
but
we
sort
of
leave
the
change
changing
over
the
crds
up
to
the
user,
and
so,
if
they
forget,
they
get
a
very
unhelpful
error
message
from
silly
I'm
saying
yeah
about
not
being
able
to
find
things
and
stuff
like
that.
L
So
yeah
consider
for
implementations.
I
just
wanted
to
know,
consider
checking
for
the
presence
of
different
versions
and
warning
about
them.
If
you're
not
going
to
we
right
now,
we
don't
provide
an
API
conversion.
We
book
for
for
Gateway
API
objects,
because
it's
a
bit
tricky
to
do
that
and
it's
a
lot
of
maintenance.
L
But
but
this
is
the
sort
of
thing
that
that
decision
enables
one
thing
that
I
did
think
was:
if
we
should,
if
we're
not
going
to
do
the
version
conversion
workbook,
which
I
don't
really
think
we
should
yet.
We
should,
however,
consider
warning
you,
if
you're,
creating
old
versions
that
aren't
going
to
do
anything.
L
So
if
you
create
a
V1
Alpha
2
reference
Grant
and
the
and
the
webhook
is
only
doing
the
on
beta
1
reference
grants,
then
maybe
we
should
have
for
the
older
stuff,
I
think
saying:
okay,
one
thing
when
you
do
did
I
lose.
Why
did
you
lose
the
admission
to
give
you
a
warning?
Sorry,
hello,
hello,
hello,
am
I
back
yeah.
A
K
L
Yeah
yeah,
okay,
so
let's
try
that
again
very
quickly.
Yeah,
please
consider
a
dynamic
version.
Detection
admission
control
we
should
I
wanted
to
ask:
should
we
consider
with
the
admission
controller
having
it
warn
you
if
you
use
outdated
versions
of
objects,
so
if
you're
doing
V1
Alpha
two
gateways,
you
know
have
the
admission
control
like
the
watch
would
be
one
alpha,
two
gateways.
If
they
are
installed
in
the
cluster
and
say
hey
chief,
maybe
do
speed
up
for
now
or
later
on,
say
you
know.
L
Have
you
heard
about
that?
You
know
those
shiny
new
V1
AP
guys
when
they
haven't,
rather
than
stopping
people
from
doing
it
just
say.
Remember
that
these
that
these
things
are
outdated.
Now
you
should
consider
you
should
look
into
that.
A
Yeah
I
think
that's
a
really
good
call
out
and
and
something
that
we're
gonna
have
to
spend
more
time.
Thinking
about
I
think
one
of
the
goals
and
ideas
of
having
crds,
annotated
or
labeled
I
forget
what
is
that
implementations
could
read
from
that
and
say.
This
is
a
crd
version
that
I
don't
support
and
do
something
with
that.
That's
theoretical
and
not
something
that
I've
seen
implemented
yet,
but
definitely
at
minimum.
A
It's
been
in
a
deprecated
state,
so
I
think
just
the
very
nature
of
it.
Being
deprecated
means
if
you
try
and
use
an
API
version.
That's
marked
deprecated
in
the
crd
you're
going
to
get
a
warning,
but
again
it's
just
yeah.
We
need
to
spend
it.
A
Yeah
yeah,
so
it's
it's
like
a
two,
a
twofold
thing
of
one:
the
controller
needs
to
be
able
to
warn
if
it
sees
a
crd
version
that
is
older
than
it
supports
and
then
two
or
something
like
needs
to,
but
probably
the
controller,
because
that's
the
only
thing
that
you
know
and
then
second,
the
crds
themself
need
to
warn
when
somebody's
using
a
deprecated
version.
I
think
that
last
part
is
happening.
It's
just
that,
like
you're
saying
people
may
just
not
upgrade
crds.
F
A
Correct
it's
only
when
you,
when
you
yeah
yeah,
so
there's
there's
another
thing
out
there:
storage
version
migrator,
which
we
should
probably
document
that
can
that
can
migrate.
All
your
things
for
you.
We
will
need
to
document
that
before
we
drop
any
API
versions,
I
honestly
I
think
the
only
API
version,
we'd
ever
drop
would
be
Alpha.
I
can't
imagine
us
dropping
beta
ever
from
a
crd,
even
if
we
get
to
GA,
but
I
don't
know,
but
with
that
I
know,
we've
got.
A
We've
got
to
keep
on
going
here,
because
this
agenda
is
quite
quite
long
and
this
policy
attachment
discussion
is
a
big
one
and
I.
Don't
know.
If
can
anyone
well
I'll,
just
I'll
take
a
circuitous
path
to
this
Gap
yeah.
Okay,
here
it
is
but
Flynn
you're,
the
one
who
who
wrote
I
think
the
majority
of
it.
So
maybe
you
can
give
an
intro
or
in
your
thoughts.
K
I
actually
have,
as
I
mentioned
earlier,
a
a
long
response
to
a
bunch
of
the
comments
that
I
got
into
shape
to
post
about
five
minutes
before
this
meeting
and
decided,
perhaps
I'll
wait
and
post
it
afterwards.
I
would
encourage
people
to
read
this.
One
I'd
really
appreciate
that.
There's
been
some
wonderful
feedback
on
it.
The
short
version
of
this
one
could
be
probably
summarized
as
the
more
that
I've
gone
through
and
kicked
around
this
stuff
with
people.
K
The
more
concerned
I
am
that
if
we
GA
policy
attachment
in
its
current
form,
we
will
end
up
with
a
bunch
of
people
who
find
it
extremely
difficult
to
use
enough
so
that
it
seems
like
it
would
be
a
danger,
and
a
lot
of
this
is
basically
trying
to
illustrate
at
least
one
particular
way
where
things
could
go
frighteningly
wrong
for
an
end
user
and
to
start
trying
to
figure
out
what
we
can
do
about
it.
K
I
should
also
probably
point
out
here,
and
this
is
in
the
response
that
I'm
going
to
be
posting,
but
to
be
clear,
nothing
about
this
Gap
should
be
read
as
me,
having
anything
other
than
the
utmost
respect
and
appreciation
for
the
work
that
Nick
and
Rob
have
done
on
this
one
and
other
folks
who
contributed
for
the
original
policy
attachment
Gap
in
particular,
I
think
Nick
deserves
props
for
bearing
the
brunt
of
the
complaints
with
Grace
and
Good
Humor.
So
thank
you
both
for
that.
K
H
Yeah
I
met
with
Flynn
about
this
one
beforehand
and
helped
to
like,
facilitate
and
be
a
part
of
this,
because
I
was
very
persuaded
by
the
you'll,
see
in
the
in
the
Gap.
It
doesn't
have
a
solution
specifically
right
now
it
had
it's
kind
of
illustrating
the
problem
in
a
I'll
call
it
a
playful
way,
but
it's
it's.
H
It's
certainly
in
a
way
that
helped
persuade
me
that
this
is
a
really
good
time
to
have
this
conversation,
because
you
said
if
we
GA
policy
but
I,
think
we're
actually
in
a
state
right
now
with
several
implementations
where,
if
we
GA
Gateway
API,
there's
going
to
be
a
lot
of
policies
coming
along
and
I
am
worried
about
the
state
of
that
for
people
who
aren't
as
technical
or
as
in
the
know
as
us,
it
there's
some
there's
a
lot
of
rough
edges
and
there's
a
lot
of
action
at
a
distance.
H
So
now
might
be
a
good
time
to
have
this
conversation.
I
think
Flynn
and
I
are
both
incredibly
sober
to
the
eye
to
the
fact
that
this
may
change
a
lot
as
a
over
the
course
of
conversation.
This
may
just
help
shape
the
future,
or
something
like
that.
So
just
keep
that
in
mind.
We're
not
like
this
must
go
forward
like
in
its
current
state.
We
must
find
a
solution
along
this
path,
just
that
we
think
this
is
a
great
time
to
have
the
conversation.
H
You
know
what
is
it
six
months
until
we're
saying
we're
going
to
GA.
It
gives
us
some
lead
time
to
try
to
get
ahead
of
some
of
the
problems.
H
A
K
A
Yeah
Mark
so
seven
minutes
from
now.
For
me,
I.
K
K
In
seven
minutes,
I
think
the
most
important
thing
is
first
yeah,
please
go
read
the
pr
please
chime
in
I'm,
honestly,
not
certain
if
there's
stuff
that
we
should
try
to
dive
into
in
this
format
in
seven
minutes.
But
if
there
are
people
who
have
read
the
pr-
and
there
are
things
that
you
all
want
to
bring
up-
that,
you
think
we
can
tackle
in
that
kind
of
time
all
ears.
Please
do.
L
Okay,
I'll
have
a
crack,
so
I
think
that
probably
the
best
place
to
do
this
is
to
discuss
it
on
the
pr
I.
You
know
I
put
a
comment
on
there
earlier
today.
Flynn
so
I'll
probably
wait
to
see
what
your
responsible
comment
already
since
you
typed
it
up.
L
Okay,
cool
yeah
but
I
think
and
I
think
the
key
thing
that
I
would
sort
of
want
to
say
about
all
of
this
was
yeah
like
I
think
when
I
yeah
that's
my
response
there
in
my
typical
yeah
or
very
concise
faction.
L
So
yeah
look
I,
think
yeah
I
think
it's
definitely
the
case
that
policy
attachment
is
not
anywhere
near
finished.
We
have
known
for
ages
that
the
that
we
needed
something
that
we
had
put
Rob
and
I
had
put
under
the
broadheading
of
status
I'm
making
air
quotes.
Now
you
can't
see,
but
I.
K
L
And
the
you
know,
that's
like
effectively
handling
the
the
two
things
that
are
the
two
things
that
are
the
the
bullet
points
there.
Those
are
probably
the
main
things
that
I
think
we
need
to
hit.
We
need
to
have
a
standard,
simple
way
for
an
owner
of
an
object
to
find
that
that
object
is
being
affected
by
some
policy
and,
if
possible,
what
policy
is
affecting
it
and
what
settings?
L
What
settings
have
been
changed
or
updated,
and
yeah
like
there
needs
to
be
a
way
in
some
fashion,
to
obtain
the
result
instead
of
policy
for
an
object
I.E
for
someone
who
owns
a
thing
to
say:
hey,
something
is
affecting
my
object.
I
need
to
know
what
all
of
the
settings
that
are
being
changed
on
my
object,
that
I
can't
see
in
the
spec
of
my
object
that
that
is
going
to
be
more
and
more
important.
As
we
add
things
like,
you
know,
there's
a
PR
to
add
a
timeout
timeout
config.hdp
route.
L
If
we're
going
to
have
policy
that
affects
that
timeout
config,
that's
policy
affecting
a
field
which
actually
is
I,
think
we
did
not
allow
that
in
the
current
version
of
the
of
the
Gap.
Because
of
this
discoverability
problem,
and
so
you
know,
I
have
plenty
of
thoughts
there
about
exactly
about
where
we
could
address
that.
L
L
Those
are
concerns
that
are
the
cluster
owner,
the
infrastructure
owner
the
Gateway
owner,
rather
than
the
HTTP
router
for
places
where
those
are
separate,
and
so
the
discoverability
for
the
HD
period
owner
Right
Now,
is
rubbish
because
we
were
focusing
on
solving
the
problems
of
the
other
people
right
like
and
like
I
think
I
always
I
always
knew
that
it
was
a
big
problem
that
we
needed
to
do
something
about
I,
think
you're
100
right
to
say
that
we
probably
need
to
do
something
about
this
before
GA,
simply
because,
as
Shane
alluded
to
before,
once
we
put
GA
on
the
API,
regardless
of
what
the
Gap
says
they
get
as
the
Gap
says
that
it's
like
experimental
and
not
finished.
L
Regardless
of
what
the
Gap
says,
people
will
expect
that
that
means
the
entire
API
is,
to
some
extent
GA
yeah,
exactly
yeah,
and
so
so
it
is
important
that
we
get
some
some
solution,
sort
of
at
least
roughed
out
for
this,
so
that
everyone
is
heading
in
general
in
the
same
direction
before
we
get
GA
I,
don't
think
it
needs
to
be
final.
L
You
but
I
do
think
that
it
needs
to
be.
We
need
to
have
some
sort
of
agreement
on
it.
Actually,
sorry,
there
is
one
more
thing
I
want
to
say,
and
that
is
that
it
is
that
there
is
one
dimension
here
that
has
not
been
captured
very
well
at
all
in
the
discussions
that
we've
had
and
that's
about
how
careful
we
need
to
be
with
the
API
design,
to
avoid
massive
API
server
loan
load
from
fan
out,
fan
out
status
updates.
That
is
one
of
the
biggest
concerns
that
I've
had
about
this
thing.
L
K
That
that
is
actually
a
that's
a
concern
that
I
have
with
respect
to
the
model,
with
policies
reaching
backwards
into
resources,
although
I
actually
do
need
to
rate
that
into
that
comment.
Yeah
I
basically
agree
with
everything.
You
just
said:
I
think
that.
K
I
tend
to
think
that
it's
not
just
a
discoverability
problem
and
I've
written
some
more
about
that,
so
I'm
not
going
to
try
to
tackle
it
here,
but
just
to
set
the
stage.
So
you
all
know
that's
coming
and
yeah.
I
would
absolutely
encourage
people
to
read
this
and
to
comment
on
it
and
we'll
do
more
of
that.
We'll
do
more
of
this
on
this
PR.
A
Oud
cool
thanks,
I
I
think
maybe
that's
one
thing:
a
good
place.
H
Okay,
I'll
end
it
I'll
end.
It
I
just
wanted
to
thank
everybody.
Who's
been
involved
in
policy
and
I
know
that
there's
a
lot
of
comments
on
this,
which
means
there's
a
lot
of
thoughts
and
feelings
on
this
and
I
want
to
reiterate
something
that
Flynn
said
that
everybody
has
done
a
wonderful
job.
This
is
a
problem
that
no
one
person
can
solve,
which
is
why
I'm
very
grateful
that
Flynn
is
joining
us,
because
what
we
need
is
to
do
this
together,
like
build
this
together
and
we'll
come
up
with
a
good
solution.
K
H
A
Yeah
awesome
yeah,
so
there
I
expect
there's
going
to
be
plenty
more
discussion
on
this.
Gap
definitely
welcome
comments
and
it
sounds
like
Flynn's
got
a
big
one
coming
sometime
soon,.
A
K
A
Yeah-
and
so
this
is,
you
know,
I
I
think
there's
broad
agreement
of
the
problem
statement
that
or
or
some
subset
of
the
problem
statement
that
policy
attachment
is
confusing
and
that
it's
it's
hard
to
understand
what
has
been
applied.
I
think
the
this
story
or
I
think
you
called
it
Parable
and
in
your
Gap
Flynn,
is
largely
at
least
from
my
perspective,
showing
that
the
owner
of
the
application
owner
did
not
understand
that
policy
had
affected
their
application.
A
So
from
my
perspective,
that
is
again
going
back
to
this
discoverability
problem
and
and
this
so
this
this
discussion
actually
technically
preceded
the
Gap,
but
where
it
came
from
is
I
was
talking
with
Shane
and
Shane
mentioned.
Oh
Shane,
he'd
been
talking
with
Flynn
and
that
policy
attachment
had
problems
I'm
like
oh
yeah,
it
does.
Maybe
we
should
just
open
a
discussion
and
you
know
like
create
and
then
I
didn't
I
didn't
realize
there
was
a
much
bigger
thing
coming,
but
I
think
these
these
two
coexist
in
parallel.
A
Well,
but
from
my
perspective,
this
is:
are
there
smaller
things
we
can
do
that
can
make
a
world
of
difference
on
the
existing
model,
and
so
this
is
really
meant
to
gather
ideas
because
kind
of
as
Shane
mentioned
originally
here
like
we,
we
are
better
together
and
you
know
any
any.
One
of
us
cannot
think
of
any
every
possible
idea
to
improve
this.
So
I
added
some
ideas
that
had
been
either
suggested
by
others
or
something
that
I
thought
about,
and
some
others
have
also
commented
with
their
own
suggestions,
which
is
great.
A
Please
please
keep
them
coming.
You
know
one
of
the
things
that
came
this
this
first
one
came
out
of
a
API
review
with
Tim
and
Cal.
This
idea
of
some
kind
of
resource
that
you
could
just
could
cuddle,
get
and
see
all
policy
that
had
been
had
affected
other
resources
with
one
single
command
built
into
Cube
cuddle.
It
could,
you
know,
contain
more
than
that,
but
it's
an
interesting
idea,
there's
also
the
idea
of
a
coupe
cuddle
plug-in,
which
has
been
around
since
the
very
beginning.
A
A
There's
a
lot
in
here
and
I
do
want
to
time
box
myself
here,
I
I
think
the
other
thing
that
is
really
critical
here
is.
We
need
some
concept
of
status
or
something
to
understand
what
has
been
a
flat
applied
or
what
has
affected
it.
There
has
been
yeah,
that's
a
big
one,
yeah
I
think
as
soon
as
I
had
an
idea
of
like
actually
an
effective
policy,
kind
of
status
or
resource,
or
something
like
that.
A
I
think
that's
somewhere
below
here,
yeah,
effective
policy,
configuration
I,
think
that's
a
really
good
idea.
So
yeah,
please,
please
don't
hesitate
to
to
add
comments,
add
suggestions
and
I
think
you
know
if
we
implemented
even
a
couple
of
these,
we
we'd
make
a
big
dent
in
the
problem
that
more
problems
that
we
currently
have
Okay.
H
A
H
A
And
that
yeah
yeah
thank
you
and
like
five
minutes
over.
But
we
didn't.
F
F
A
So
I
think
that
that
pushes
us
off
to
Dave.
Are
you
still
here,
yeah.
N
Yeah,
just
just
highlighting
this
gip's
been
Rewritten
to
use
the
app
protocol
on
the
kubernetes
service.
N
If
you
take
a
look
at
the
link,
there's
also
a
reference
to
like
adding
support
in
kubernetes
for
websocket,
so
we'll
see
how
that
goes
right.
Now,
it's
just
like
a
single
protocol
that
can
be
listed.
It
can
be,
or
are
you
still
on
the
call
or
do
you
drop
I'm.
F
N
I
think
the
question
is
about
like
changing
app
protocol
to
be
a
list
so
that
we
can
support
multiple
protocols
but
I
think
in
the
short
term.
N
A
Yeah
thanks
thanks
for
the
heads
up
and
thanks
for
Crossing
back
over
to
to
a
cap
as
well
here,
yeah
I
know
it
can
be,
it
can
be
tough
to
transition
between
Gateway
and
Upstream
kubernetes.
Here
the
the
one
thing
I'll
say
is
I.
Think
Leora
already
added
a
comment
along
these
lines,
but
yeah
I
need
to
I
need
to
just
add.
F
N
Yeah
so
yeah,
that's
why
I
mentioned
right
now:
I
think
what
the
gap
is
proposing
and
what
the
kept
sprozing
is
compatible
and
then
the
question
is
like:
how
do
we
support
one
multi-protocol
and
how
do
we
support
kind
of
like
new
protocols
that
might
be
kind
of
like
rebased
on
others?
Here's
an
example.
So,
right
now
the
websocket
standard
is
essentially
just
over
HTTP
and
over
TLS
there
is
newer
rfcs
for
websockets
over
HTTP.
D
N
And
also
hp3.
So
the
question
is:
how
do
you
specify
that,
like
those
new
ones,
I'm
less
concerned
about
that?
For
for
this
sort
of
thing?
But
like
do
we
do
like
websocket
plus
hb2,
so
like
we
changed
the
constant,
introduce
a
new
constant
or
can
like
someone
represent
that
with
the
list
like
I,
specify
each
V2
support
and
also
as
an
app
protocol
and
then
a
subsequent
one,
a
websocket
does
that
imply,
then
that
web
websocket
over
hp2
I,
don't
know,
like
so
I.
D
K
K
F
F
D
N
Why,
in
my
Gap
I
mentioned
this,
handles
I,
think
80
or
maybe
even
95
of
all
use
cases,
and
then
there
might
warrant
like
a
special
crd
for
these,
like
super
events,
use
cases
that
most
people
might
not
even
use,
and
that
might
end
up
being
just
like
a
specific
to
implementations.
A
Yeah
yeah
I,
think
that
makes
sense.
I
do
want
to
time
box
us
because
we
we
are
at
time
I
know
people
have
to
drop,
but
just
you
know
I
want
to
highlight
that
this,
although
it's
in
kubernetes
upstream
and
it's
a
cap,
this
is
this:
is
the
right
group
of
people
to
be
reviewing
it.
A
The
people
that
will
actually
be
implementing
application
protocol
are
not
Upstream,
kubernetes
they're,
basically,
that
the
group
of
Gateway
API
implementations,
largely
so
we
need
to,
as
a
group
decide
where
we
want
this
config
to
live
service
and
extending
app
protocol
makes
sense
to
me,
but
would
like
some
more
feedback,
and
so,
even
though
it's
in
kubernetes
Upstream
would
appreciate
some
comments
on
both
the
Gap
and
cap
if
you've
got
time,
but
with
that
we
are
out
of
time.
So
thank
you,
everyone
for
making
it
this.