►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220328
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220328
A
All
right
welcome
to
gateway
api
meeting
the
last
one
in
march
this
year.
We've
got
lots
on
the
agenda
today,
but
if
you're
new
to
gateway
api
meetings,
welcome,
I'm
rob
nick
also
leads
out
a
lot
in
these
meetings
and,
as
we
say
all
the
time,
there
is
never
a
stupid
question
we're
going
through
some
technical
stuff
or
just
stuff.
That
assumes
a
lot
of
built-in
knowledge.
A
lot
of
us
have
been
working
on
this
project
for
two
or
three
years
now.
A
It
seems
like
I've
lost
track
of
how
many,
but
it's
been
a
while.
So
please
do
ask
questions
or
make
comments
at
any
point,
but
with
that
let's
go
ahead.
I
think
nick
you're,
first
up,
you
had
a
draft
on
route
delegation
and
status
specifically
so
I'll
hand
it
off
to
you
yeah.
B
So
thanks
rob
yeah,
and
so
I've
just
been
working
on
this
to
go
along
with
jeff's
delegation
proposal.
You,
he
kind
of
assumes
knowledge
of
the
the
other
delegation
proposals.
So,
in
short,
remember
that,
that's
that's
we'll
add
an
allowed
routes
status
to
stanza
to
the
each
http
route
rule
a
http
route
rule
is
considered
a
parent
http
route.
B
If
a
single
allowed
route
stanza
is
non-nil
in
any
of
its
rules,
a
rule
may
have
back
ends
back
end
refs
and
allowed
routes,
so
a
rule
may
not,
a
rule
may
only
have
one
or
the
other,
but
a
http
route
may
have
multiple
rules,
one
of
which
is
a
back
end
ref
and
one
of
which
is
in
the
lab
routes.
B
So
that
background
is
relatively
important
because
we,
what
it
means
is
that
we
need
to
be
able
to
handle
both
cases.
But
we've
also
said
it
that
if
you
are
a
parent
I.e,
you
have
one
allowed
routes
at
least
one
a
loud
route:
stanza,
not
nil,
then
you
can't
also
have
a
parent
ref
pointing
to
a
http.
B
I
eat
their
child.
Okay.
So,
as
you
can
see
here,
my
proposal
is
pretty
simple.
We're
going
to
add.
I
propose
we
add
a
children's
stanza
to
sas
the
naming,
I'm
okay
to
argue
about
there
but
like
given
that
one
of
them
as
parents
seem
pretty
obvious
to
me,
the
other
one
children,
the
that
your
actual
children
struck
is
basically
the
same
struct
as
the
as
the
listener
status
on
the
gateway,
because
it
does
basically
the
same
function.
B
It
has
a
supported
kinds
struct,
which
I'm
a
bit
iffy
about
adding,
but
I
put
in
there
for
completeness.
So
we
can
talk
about
it.
It
has
a
attached,
a
num,
an
attached
routes
number
which
tells
you
how
many
routes
are
successfully
attached
and
then
it
has
the
conditions.
The
reason
to
have
the
reason
we
put
the
attached
routes
on
the
listener
is
to
give
you
some
feedback
about
exactly
how
many
routes
are
attached
without
you
having
to
keep
track
of
it
without
you
having
to
reference
every
single,
router
search.
B
The
reason
you
don't
want
to
do
that
in
status
is
it
creates,
fan
out
problems
when
whenever
something
gets
updated
and
you
really
don't
want
to
have
you
know,
2n
or
worse,
n,
squared
number
of
updates
to
the
api
server
every
time
you
update
one
one
object,
yeah,
so
that's
sort
of
the
headline
bits
I
wrote
down.
I
started
writing
down
some
actual
rules
in
the
document.
B
If
you
want
to
scroll
down
a
little
bit,
rob
that
just
sort
of
puts
out
like
you,
yeah,
like
you
gotta,
have
the
controller
name
is
the
same,
and
that's
the
other
one
is
that
I
put
the
controller
name
from
the
listener
status
on
into
this
one
as
well,
that's
necessary,
because
a
route
can
be
parented
by
multiple
resources.
It
can
have
multiple
parent
reps.
So
it's
conceivable
that
a
parent
route
could
itself
be
parented
by
multiple
gateways
that
are
controlled
by
different
controllers.
B
Okay,
there's
a
lot
of
caveats
and
clauses
in
that
sentence,
but
the
key
part
there
is
that
you
know
you
can
create
it's
considerable,
that
you
can
create
like
trees,
two
trees,
one
one
with
one
gateway
class,
one
with
another
gateway
class
and
end
up
with
the
same
route,
pointing
to
both
gateways,
and
in
that
case
you
need
a
way
to
record
the
status
that
does
it
so
that
you
don't
overwrite
the
status
from
both
controllers.
So
that's
why
controller
name
has
to
be
present
in
this
parent
one.
B
It
doesn't
need
to
be
present.
It's
not
it's
not
required
in
the
child
routes,
because
they're
relief
and
they
can't
yeah
and
that's
included
in
the
reference
to
the
paragraph
again,
because
the
parent
ref
is
the
paragraph
already.
Has
it
sorry
it's
the
parent.
Riff
has
the
controller
name
and
the
thing
the
the
actual
reference
object.
Sorry
rob.
A
B
Right
yeah,
I
didn't
want
to-
I
didn't-
want
to
do
something.
Wacky,
like
you
know,
name
spacing
both
parents
and
children
by
controller
name,
because
that
would
be
a
pretty
substantial
schema
change
that
feels
like
it
might
cross
the
border
into.
You
know:
api
rev
territory.
B
Yeah
yeah:
okay,
that's
a
good
point,
the
so
that
in
in
that
case,
we
would
need
to
move
the
children
under
the
that.
In
that
case,
we
need
to
have
it
name
space
by
both
the
the
actual
resource,
that
is,
the
parent
and
the
controller
name
like
we
have
the
parents
already.
A
A
A
You're
right,
I
I
think
this
is
a
real
education.
I
don't
want
to
waste
too
much,
but
what
so
just
to
throw
a
different
perspective
in
here
for
gk
we
have
one
controller
and
it's
implementing
multiple
classes
and
so,
for
example,
an
xlb
and
ilb
have
fundamentally
different
behavior
and,
in
some
cases,
different
capabilities.
A
B
Stood
out
to
me
is
yeah,
I
think
that's,
I
think,
that's
a
pretty
reasonable
thing
to
raise
so
yeah,
sorry
for
everyone,
who's
sort
of
a
bit
lost
here.
We're
definitely
talking
at
a
very
general
api
design
level
here.
But
the
idea
here
is
that
that
route,
delegation
and
inclusion,
as
as
you
lets
you
do
stuff
like
break
apart,
the
config
break
apart
a
large
config
and
split
it
up
via
either
for
some
sort
of
administrative
reason
or
for
to
split
the
ownership
across
teams.
B
B
So
team
a
owns,
the
the
parent
resource,
whether
it's
a
gateway
or
a
route,
and
then
team
b
owns
the
child
resource,
which
is
always
going
to
be
a
wrap.
Now
I
think,
in
terms
of
the
status
that
I
have
here,
the
reason
I
said
that
I
think,
supported
kinds
may
not
be
necessary,
is
that
I
don't
think
we
currently
want
to
allow
http
routes
to
reference
if
you're
doing
this
to
reference
any
parent
other
than
a
http
period.
B
D
I
guess
my
question
on
that
is:
would
it
be
forwards
compatible
thinking
about
if
we
do
want
to
ever
do
like
tcpd,
hdp
or
http
to
grpc,
or
something
like
that
to
introduce
that
in
the
future?
If
it
is
omitted
initially,.
B
So,
in
terms
of
the
status
yeah
like
adding,
adding
a
new
field
is,
is
backwards
compatible
because
it's
you're
adding
a
new
nanny
field?
That's
the
that's!
The
general
sort
of
guideline
is
that
if
you're
adding
a
whole
new
structs,
then
that's
100,
fine,
changing
the
behavior
or
removing
an
existing
struct
is
not
fine,
so
yeah.
So
we
could
add
this
later.
If
we
needed
to.
B
I
think
we,
I
think
the
examples
you
used
are
good
ones,
because
it
is
really
important
to
remember
that
in
general
we
don't
want
the
api
to
be
to
be
that
sort
of
there's
a
in
general
we've
conceived
up
to
this
point
of
the
api,
as
as
the
higher
layer
routes,
the
more
complicated
the
structure
that
your
route
is
describing,
the
more
of
other
routes
it
sort
of
subsumes
inside
it.
So
a
hd
period
implicitly
includes
a
tcp
route.
B
A
grpc
route
implicitly
clears
both
includes
both
a
tcp
route
and
a
http
route,
because
they're
kind
of
a
layer
cake
and
so
the
so
yeah.
I
think
it's
so
like.
I
think
everyone
has
said
that
the
sort
of
the.
Why
don't
we
have
like
the
tcp
route
points
to
the
http
route
and,
in
my
mind
the
reason
is
the
http
route
already
has
all
the
details
that
you
need
and
if
it
doesn't,
then
we
should
bring
any
extra
details
that
we
need.
B
I
could
see
a
feature
where
the
you
you
might
want
to
add
the
I
plea,
allow
list
and
block
list
that
we
have
in
in
tcp
route
to
review.
That
seems
reasonable,
rather
than
having
like
a
big
chain
of
routes
that
seems
extremely
flexible,
but
dangerously
so
to
me.
B
So
sorry,
I
just
wanted
to
clarify
that.
While
I
was
on
my
head
but
yeah
so,
okay,
I
think
you're
100
right
rob
that
it's
definitely
worth
considering
that
the
the
the
children's
status
be
named
space
by
the
parent.
B
I
think
that's
probably
the
way
it
go
now
that
you've
raised
it,
it's
a
little
harder
to
understand,
but
this
this
whole
delegation
inclusion
thing
is,
let's
be
clear,
a
very
advanced
use
case
right
like
we're
not
expecting
you
know
people
who
want
the
basic
functionality
of
the
hp
right
to
ever
touch
this
or
include
it.
That's
why
the
allowed
routes
are
the
allow
that
struct
is
defaulted
to
nil,
and
that's
why
this
stuff?
If
you
don't,
if
you
don't
set
any
of
this
stuff,
it
will
not
work.
B
You
have
to
you,
can't
just
set
the
parent
route
ref
of
some
random
http
route
to
another
hastily
period
and
how
things
work
the
there
has
to
be
that
two-way
handshake,
because
that
means
both
sides
have
to
agree,
and
also
both
sides
have
to
agree
that
you're
that
you're
activating
what
is,
at
the
end
of
the
day,
pretty
advanced
functionality.
A
Cool
yeah,
I
I
agree
with
that.
I
am
curious
for
next
steps
on
this.
Are
we
just
integrating
this
with
the
already
existing
gap
that
okay
great
and
so
then
we
can
do
a
final
review
on
this
in
that
gap,
pr
and
okay
cool
well.
This
is
this
is
a
huge
effort.
Thank
you
to
everyone.
Who's
contributed
to
route
delegation
excited
to
get
this
one
through
and
yeah.
Thank
you
to
nick
for
for
writing.
This
up,
it
looks
like
I
didn't
actually
scroll
down
all
the
way.
B
I
was
talking
here
about
the
conditions
we
wanted
to
add.
As
part
of
this,
I
spent
some
time
reviewing
the
route,
the
current
route
conditions,
and
they
definitely
are
underspecified
at
the
moment
and
needs
to
work.
B
I
mean
I
think,
jeff
you're,
you,
you
raised
the
discussion
a
while
ago
about
some
of
the
implementations
around
listener
around
listener
status
as
well
that
there's
some
stuff
under
specified
there
some
edge
cases
where
it's
not
clear
what
you're
supposed
to
do,
and
so
I
think,
as
we
start
as
we
start
kicking
off
the
process,
to
do
the
api
review,
rob
I
want
to
try
and
fix
some
of
the
things
I've
noticed
and
sort
of
be
a
bit
more
specific
about
when
you
set
conditions
and
stuff
like
that,
and
I
think
that
we
also
may
need
to
talk
about
adding
a
condition
or
two
in
here
I've
added
a
not
supported
condition,
which
I
think
we
may
want
to
sort
of,
promote
and
use
widely
in
the
rest
of
the
rest
of
it
just
so
that
there's
a
way
to
flag.
B
You
hey,
you
asked
you
it's
not
attached
and
it's
because
something
is
not
supported
or
not
no,
not
supported
or
not
implemented,
or
something
like
that
yeah.
That
was
one
that
we
needed
to
use
in
contour
as
well,
so
anyway,
yeah
so
there's
a
there's,
a
larger
thing
there
than
just
this
status
design.
But
I
will
follow
up
on
that
later
on.
A
Great-
and
I
I
would
echo
that
not
supported
seems
like
a
broadly
useful
condition
to
have
here.
C
C
E
Mean
nick
it's
your
you
wrote
it
up,
so
you
can
speak
otherwise,
but
I'm
pretty
close
to
putting
the
actual
gap.
Pr
up.
C
B
Yeah
cool,
I'm
fine
with
that.
I
just
wanted
to
get
this
out
so
that
we
could
talk
about
it
today
and
pick
up
any
early
things
like
rob's
great
suggestion
about
you
know
parent
parents,
so
I
think
I'll
probably
change
this
bit
to
to
fold
that
in
put
an
alternative,
considered
or
something
and
then
jeff.
You
can
pick
up
this.
This
info
I'll,
give
you
edit
on
this,
and
you
can
pick
up
this
info
and
just
drop
it
straight
into
the
gap.
B
I'll
update
that
today
cool,
I
think
the
discussion
of
conditions
rolls
straight
into
the
next
agenda
item
segways
for
the
win
yeah.
So
there's
nathan,
you
asked
a
question
about
right
now.
There's
the
conformance
says
kind
of
expect
that
things
will
be
ready,
but
there's
no
way
to
check.
If
it
is,
did
you
want
to
say
any
more
about
this
than
you
had
in
the
thread.
C
I
think
we
talked
about
this
two
meetings
ago.
Okay,
there,
it
was
basically
just
let's
not
work.
Http
route
is
accepted
until
the
thing's
actually
functional
right.
B
I'm
I'm
broadly
supportive
of
there
being
like
right
now,
that's
how
it
works.
I
I
think
that
that's
probably
something
that
we
should
consider
changing
before
we
go
to
beta,
though
I'm
quite
supportive
of
accepted,
meaning,
syntactically,
valid
nx
and
hangs
together
and
then
ready,
meaning
you
know,
has
been.
We
have
at
least
some
confidence
that
this
has
been
programmed
in
an
underlying
data
plan.
I
don't
think
that
at
this
stage
I
don't
think
that
many
implementations
can
guarantee
that
ready
means
actually
ready
but
ready.
B
At
least
you
can't,
because
I
know
for
envoy
things
getting
the
full
back
propagation
of
the
of
the
like
of
the
ack
back
up
to
the
kubernetes
objects
is
not
straightforward,
but
I
think
I'm
very
supportive
of
having
a
generic
ready
condition
on
everything.
A
Cool
and
there's
an
important
distinction
there
and
john
actually
raised
it
here,
and
I
missed
it,
but
nick
you
also
just
mentioned
it
too.
That
ready
is
maybe
not
the
most
broadly
supportable
term.
Despite
me,
suggesting
it
that
ready,
if
you
take
it
literally,
may
not
be
something
that
we
can
confidently
say,
or
at
least
that
all
implementations
can
confidently
say.
A
C
I
mean
that's
the
exact
issue
that
we're
dealing
with
right
now:
hey
this
thing
will
work
in
a
few
seconds,
but
I
think.
B
C
B
B
I
don't
think
that
that
will
that
should
ever
obviate
like
having
random
exponential
back
off
and
retries
in
whatever
thing
you're
using
that's
looking
at
that
status,
you're
like
if
it
says,
ready
and
you're,
and
then
you
go
to
like
start
probing,
you
still
need
to
have
like
retries
and
rab,
regardless
of
you
of
that,
because
this
whole
system
is
eventually
consistent
like
there
is
no,
even
in
the
case
that
you
do
have
the
information
to
be
pretty
confident
that
the
thing
is.
B
You
know
that
the
information
has
flowed
the
fact
that
it
takes
some
time
for
the
information
to
flow
from
your
data
plane
back
to
the
api
server
and
then
the
implementation
to
get
the
event
and
to
do.
That
means
that
it
could
have
changed
in
the
meantime.
There's
no
way
that
you
can
ever
be
100,
confident
that
that
and
have
it,
be
guaranteed
it's
impossible,
because
kubernetes
is
an
eventually
consistent
system.
C
Let's
have
some
implications
for
the
conformance
testing
framework,
though,
with
the
I
mentioned,
like
we
were
getting
connection
refused
and
then
the
test
just
fails
immediately,
so
we
might
need
to
make.
B
I
think
that
the
conformance
test
absolutely
should
have
you
know:
retries
and
reb
and
yeah.
A
So
what
I
agree
I
I've
been
struggling
with
what
the
appropriate
behavior
is,
because
we
can't
just
have
a
conformance
test
that
says
well.
At
least
one
of
these
10
requests
worked
and
so
therefore
we're
good,
you
know
so
it
seems
like
we
need
retries
to
a
certain
point
and
then
some
level
of
consistency
after
we
get
that
first
successful
request.
Maybe
that
does
slow
down
our
conformance
test,
but
it
does
feel
like
maybe
our
our
only
work
around
here.
I
don't
know.
B
A
B
C
B
Yeah,
I
think
that's
the
and
then
it's
just
a
matter
of
defining
what
you
know,
how
many
retries
and
all
that
sort
of
stuff,
but
I
don't
which
I
don't
think
functionally
the
details
matter
as
long
as
everyone
is
using
the
same
set
of
things.
It
doesn't
matter
yeah,
because
that's
what
performance
is
for
to
ensure
that
everyone
behaves
in
the
same
way,
yeah
yeah.
B
So
I
think
that
as
bowie
says
in
the
chat,
it
absolutely
should
be
that
we
don't
try
until
there
is
a
if
we
add
a
ready
condition,
you
don't
try
until
the
ready
condition
is
present,
then
once
the
ready
condition
is
present,
you
do.
You
know
end
successes
before
why,
before
m
failures
or
something
like
that.
A
Cool
that
makes
sense
I
I
can
create
an
issue
to
track
that
work,
but
certainly
if
anyone
wants
to
volunteer,
I
know
there's
a
few
people
working
around
conformance.
If
anyone
wants
to
volunteer
to
add
that
kind
of
retry.
That
would
be
awesome
because
I
think
it
does
affect
many
of
our
implementations
well
before.
B
We
go
on
to
the
next
thing,
while
I
think
of
it.
There
was
one
other
thing
I
wanted
to
ask
about
performance.
I
think
I
have
mentioned
it
before,
but
I
wanted
to
ask
and
get
everyone's
thumbs
up
before.
I
make
an
issue
and
start
actually
working
on
it.
I
would
like
to
add
conformance
testing
for
the
web
hook.
B
The
web
hook
will
soon
be
required
for
to
be
a
conformant
implementation,
so
the
conformance
testing
for
the
web
hook
will
be
a
separate
suite.
It
will
run.
It
will
run
the
same
test
as
we
currently
run
in
the
edes.
Basically
exercise
the
full,
like
all
of
the
ways
in
which
the
web
hook
could
not
validate
objects,
and
so
the
idea
will
be.
We
try
to
apply
objects
that
are
invalid
and
check
that
the
workflow
successfully
throws
them
out.
That
will
be
the
compromise
test.
A
So
there's
two
different
ways
like
I'm
interpreting
this,
and
I
think
I
may
be:
are
you
meaning
that
a
web
hook
needs
so
so
our
our
existing
conformance
test
will
run
tests
that
expect
to
break?
We
expect
the
web
hook
to
catch
them,
and
so
basically
part
of
a
conformant
environment
is
that
this
validation
exists
somewhere?
Yes,
that
okay,
okay
right
yeah,
because
we
do
have.
We
do
have
the
example
that
that
kind
of
the
other
thing
you
were
describing
of
verifying
that
the
web
book
catches
everything
in
invalid
examples.
B
Yes,
exactly
adding
that
to
the
existing
performance
suite
as
like.
Another
suite
that
is
the
web
hook,
validation
that,
in
addition
to
the
the
gateway
and
http
route
elimination,
I
think
that
in
the
future
we're
going
to
have
we've
got
a
lot
of
work
to
do
on
the
performance
testing
suite.
You
know
we
need
to
have
like
performance
profiles
and
be
able
to
tell
for
the
implementation,
be
able
to
tell
you
what
objects
should
be.
You
should
be
testing
like
contour
will
never
support
tcp
router
udp
route,
so
you're
like
I'd,
be
upset.
B
B
It
is
tbd,
it
is
on
the
way.
So
yes,
so
obviously
that
that
work
is
gated
behind
the
workbook
being
easily
installable
and
the
yamaha's
being
provided,
which
is
on
me
as
well.
So
that's
why
I've
been
thinking
about
this
because,
like
once
I've
finished
this,
then
I've
got
to
add
this
to
the
workbook
suite.
E
Nate's
working
actually
on
our
performance
test
implementation,
so.
A
Cool
that's
great
and
that
that
actually
is
a
good
segue
I'll
skip
one
ahead
and
I'm
thinking
about
a
odot
4.3
release
that
could
include
a
few
things
one
I
I
was
also
working
on
a
way
to
install
our
web,
the
validating
web
hook
in
gke
and
it's
more
difficult
than
it
would
seem,
but
also
the
version
we
have
in
0.4
that's
released
has
a
number
of
bugs
in
it.
A
A
Maybe
at
the
same
time
like
has
been
alluded
to,
we
should
include
some
yaml
updates
just
so
it's
a
little
bit
easier
because
I
don't
I
don't
want
to
block,
tell
0.5.0
to
have
a
this
is
how
you
deploy
the
web
book.
I'd
like
to
have
something
just
a
little
bit
earlier.
A
A
And
stuff,
so
that
4-3
will
be
tagged
correctly
now.
Yes,
yes,
so
yeah.
I
think
this
will
knock
out
a
lot
of
things
and
finally
resolve
that
I
have
another
pr
that
actually
explains
how
to
deploy
the
web
hook,
but
that
how
was
kind
of
messy
so
technically
you
can
install
it
this
way,
but
it's
it's
not
great.
A
So
hopefully
this
can
clean
up
the
last
bit
of
that
all
right.
So,
with
all
that
background,
let's
take
a
look
into
v1
beta
1..
The
milestone
is
looking
reasonable
to
me.
The
thing
that
I
see
when
I
look
through
here
is:
there
are
no
api
changes
left
in
the
milestone.
A
Everything
is
either
web
hook
or
documentation
related.
I
think
there's
one
maybe
caveat
to
that
and
that's
what
we
discussed
earlier
in
the
meeting
of
adding
something
like
a
ready
condition.
It's
exactly
the
api,
so
we
should
probably
add
an
issue
in
the
milestone
just
to
track
that
that
is
that's
such
a
small.
It's
not
even
changing
an
api
type,
it's
just
adding
a
new
string
and
some
godoc
associated
with
it.
So
I
think
that's
going
to
be
small.
I
don't
think
we
need
to
get
for
that.
A
Start
working
on
a
pr
cool
I
to
me
this
feels
like
something
where
we
don't
need
to
block
at
least
sending
it
off
to
sig
network
reviewers.
Today
is
code.
Freeze
they're
not
going
to
see
anything
today
anyway,
they're
busy
on
every
other
thing
in
the
world,
but
it
feels
like
hey
by
the
way.
There's
this
one
condition
we're
working
on
adding
in
status,
but
everything
else
is
is
good.
I
don't,
I
feel,
like
that's
a
reasonable
thing
to
hand
off.
A
Is
there
anything
else
we
should
wait
for
or
okay
I
will
I
I
can
get
something
together.
The
last
time
I
had
a
sig
network
review.
It
was
really
just
a
diff
between
like
the
previous
release,
so
0.4
tag
and
what
would
be
current
main
master
branch
kind
of
thing.
So
I
can
get
some
kind
of
pr
set
up
just
to
show
that
diff
and
then
send
it
off
to
reviewers
tomorrow-ish.
B
A
Was
awful
I
for
for
anyone
who
who
may
not
have
been
around
the
last
time
we
went
through
this
exercise?
We
completely,
I
think
we
ended
up
with
500
plus
it
was
enough
comments
that
github
interface
was
just
awful,
so
hopefully
we
won't
run
into
that
many
this
time.
It's
basic
we're
basically
sending
the
same
api
back
and
saying:
hey.
Can
this
go
to
beta
now
so
yeah,
hopefully,
it'll
be
more
straightforward.
B
A
Okay,
well
cool,
if
I
don't
hear
anything
else,
I'll
plan
on
getting
something
underway
tomorrow,
at
least
this
week.
Just
so
we
can
get
that
process
started
it.
You
know
I
recognized
the
people
were
asking
for
reviews.
This
is
both
a
large
api
to
review
and
very
busy
people
were
asking.
So
I
don't
expect
this
to
be
a
really
quick
turnaround.
I
just
want
to
get
that
process
started.
B
Agreed
yeah-
and
we
want
to-
we
want
to
allow
as
many
weeks
as
possible
so
that
there's
so
that
there
is
a
fair
chance
that
we
can
get
the
beta
graduation
done
before
q
coin.
At
your
time.
Yes,.
A
Yes,
conference
driven
development.
That
is
the
way
to
go.
Okay,
all
right.
Well,
I
think
that
is
everything
we
had
on
the
agenda
and
we
actually
have
plenty
of
time
for
pr
and
issue
triage
before
I
get
there.
Is
there
anything
else
that
I've
missed
on
this
agenda
or
somewhat
something
we
should
cover.
B
So
yeah,
I
can't
say,
look
yeah.
I
think
that
it
will
definitely
be
in
before
we
move
everything
to
be.
A
B
With
us
doing
the
documentation
review
so
she's,
looking
for
for
things
to
work
on
so
yeah,
this
yeah.
A
It's
awesome.
She
has
been
working
away
on
one
of
our
milestone
issues.
This
is
really
the
last
thing
we
want.
We
need
to
do
before
our
v1
beta
1
release,
but
it
I
looked
at
this
briefly
and
it
seems
like
it's
on
on
the
right
track.
A
A
No,
no
he's
not,
but
this
also
looked
like
a
really
straightforward
one.
I
just
need
to
spend
some
time
reviewing
it
or
anyone
can
it's
just
an
environment
that
I
don't
personally
run
in,
but
again
seems
reasonable.
A
One
of
the
things
I
really
wanted
to
get
to
is
some
of
our
gaps,
and
I
think
these
two
well
no
there's
the
name
field
gap
which
I
think
we
can
delay
a
little
bit
until
we
get
the
route
delegation
gap
going
because
I
I
feel
like
those
are
very
closely
tied.
I
pretty
sure
route
delegation
includes
name
field.
Is
that
correct
yeah?
A
E
Already
it's
already
in
the
draft,
so
I
mean
I
don't
know
if
we
want
to
just
not
do
the
small
gap
and
just
do
it
all
as
part
of
the
the
round
inclusion
gap
for
for
what.
B
There's
just
enough
behavior
to
specify
in
how
the
name
works
and
what
we
do.
I
haven't
looked
at
it
for
a
while,
but
I
think
you
know
the.
I
think
the
things
that
I
would
like
to
see
in
there
are
just
some
some
more
description
of
like
how
should
you
use
it?
What
happens
if
it's
not
present?
What
happens
if
it's
not
present,
that
sort
of
thing.
E
Yeah,
I
thought
I
saw
those
comments
I
was
thinking
about.
You
know,
since
I
already
got
some
of
that.
Just
add
more
to
it
in
the
inclusion
gap.
A
I
yeah
I'm
fine
either
way.
I
don't.
I
don't
feel
that
strongly
here.
I
I
think
I
lean
towards
this.
This
is
one
that
can
be
split
out.
It
can
be
a
prereq,
the
gap
already
exists
and
it
I
think
it's
a
new
contributor
for
us,
so
I
I
think
it's
fine
to
let
this
get
go
in
the
the
reason
we
bit
we've
been
blocking
like
this.
This
gap
had
been
sitting
for.
A
Is
it
over
a
month
now,
at
least,
and
the
the
whole
reason
we've
been
blocking
as
well.
We
need
we
need
that
follow-up.
We
need.
We
need
that
concrete
use
case,
because
this
on
its
own
isn't
good
like
this.
A
We
need
a
reason
for
this
to
exist
and
I
think
your
gap
going
in
these
are
very
closely
tied
together,
but
I'm
fine
with
keeping
them
separate
and
as
long
as
we
have
broad
consensus
on
both
gaps,
I'm
fine
with
them
being
reviewed
separately
because,
like
like
nick
mentioned,
I
think
there
is
some
nuance
here
and
just
how
we
handle
you
know
like
even
beyond
route
delegation.
What
does
an
empty
name
mean?
How
is
it
interpreted?
How
is
it
I,
I
think,
there's
the
policy
attachment
angle
of
this
too.
E
Only
concern
I
have
and
maybe
completely
not
an
issue,
but
since
the
route
inclusion
gap
requires
a
name
that
we
couldn't
complete
the
implementation
of
that
gap
until
we
did
this
one.
So
that's
that's
the
only
concern
I
have
at
all
about
them
being
separate.
B
I
think
the
in
my
mind,
that's
actually
that
friction
is
actually
a
net
positive,
because
we
need
to
ensure
that
this
is
properly
designed
and
well
implemented,
and
we
don't
sort
of
yeah,
because
I'm
really
worried
about
having
an
optional
field.
That
can
mean
things
in
some
cases,
but
is
not
always
present,
and
I
that's
why
I
really
want
us
to
have
a
really
good
set
of
rules
that
set
out
what
happens
when
it's
not
present.
You
know,
can
you
refer
to
things?
B
You
know
what,
if
you're
using
this
for
things
for
like
what
happens?
If
it's
not
present,
how
can
you
refer
to
rules
in
the
absence
of
this
name
field?
So
I
think
that
practically
a
lot
of
people
who
are
doing
anything
more
advanced
than
very
basic
things
are
going
to
want
to
put
a
name
put
the
name
in
there.
B
That's
why
I
originally
proposed
to
be
required,
but
the
and
so
that
I
really
want
us
to
have
a
really
good
set
of
this,
and
I
think
that
having
to
do
that
before
we
can
move
on
to
implementing
the
thing
is,
is
good
because
it
means
that
by
the
time
we
get
to
the
inclusion,
then
this
then
this
set
of
rules
will
be
well
written
out
properly
spec'd,
and
then
we
won't
have
to
worry
about
doing
that
as
part
of
the
inclusion
like
actual
work
to
implement
in
terms
of
the
api
spec.
A
Yeah,
that's
fair.
Maybe
what
we
should
do,
then,
is
it
sounds
like
we
have
consensus
that
we
want
to
move
forward
with
route
delegation
and
as
part
of
that,
we
want
to
add
a
name
field,
http
route.
So
maybe
we
should
unblock
this
gap
and
do
another
round
of
review
on
it.
Get
some
feedback
going
get.
A
You
know,
update
the
author
of
this
gap
that
yes,
this
is
something
we
want
to
go
forward
with
if
it
ends
up
getting
stuck
a
week
or
two
from
now
and
just
not
moving,
then
maybe
at
that
point
we
consider
you
know.
If
this
is
really
blocking
the
other
gap,
then
we
can
try
and
pull
it
back
in
to
that
gap,
but
all
right,
I'm
fine
with
starting
this
way.
Let
them
split.
A
Cool,
okay
and
the
other
gap
in
here
is
grpc
route
to
richard.
I
see
you
here,
I
think
you're
waiting
for
another
round
of
review
or
feedback
or
I've
lost
track
of
this
one.
Sorry.
F
So
I
did
see
today
that
boy
and
nick
added
a
final
round
of
like
small
comments
and
they
gave
textual
lgtm.
So
if
you
look
up
at
like
all
of
the
reviews,
there
are
like
seven
comment
boxes
and
no
check
marks.
I'm
not
exactly
sure
what
the
approval
process
is.
Also,
there
was
one
person
like
the
very
first
reviewer
came
back
and
never
did
a
second
round
of
reviews.
So
I'm
not
super
clear
on
what
needs
to
be
done
to
you
know
get
this
over
the
the
curb.
C
That's
a
good
question
I
think
like
it
seems
like
if
unfortunately,
github
does
not
have
like
lgtm
but
fix
these
things.
So
that's.
E
C
See
a
lot
of
people
write
lgtm
without
actually
doing
lgtm,
because
if
you
did
the
actual
thing
it
just
accidentally
emerges
by
itself
right,
at
least
when
I
was
looking
at
it.
It
seems
like
it's
basically,
except
for
like
the
specific
comments
like
in
pretty
good
shape,
so
I
would
just
recommend
fixing
those
sending
it
out
and
then
people
can
just
officially
lgtm
and
get
it
in.
I
don't
know
if
anyone
else
had
some
more
like
larger
issue,
because
it's
just
a
proposal.
We
still
have
to
do
api.
A
Review
yeah.
Sorry,
I
think
this
is
kind
of
like
this
weird
practice
that
isn't
obvious
that
we've
kind
of
evolved
in
kubernetes
community
of
like
getting
around
that
there's
no
way
to
approve
plus
comment.
This
thing
so
yeah,
one
of
the
things
that
we
look
for
in
proposals
especially
is
trying
to
get
multiple
approvers
and
so
writing.
A
A
It
so
usually
what
we
try
and
do
is
for
gaps.
We
try
and
have
at
least
three
maintainers
lgtm
or
approve
or
say
yeah.
This
is
okay.
You
can
find
them
the
list
of
maintainers
in
our
owner's
file,
but
just
offhand
nick
bowie,
harry
and
james,
I
think,
are
the
current
list
of
maintainers
along
with
myself,
and
so
three
is
just
kind
of
a
majority
that
that's
the.
C
A
I
I
don't.
None
of
this
is
written
down.
It's
just
kind
of
what
has
happened.
We
should
be
better
about
organizing
and
describing
what
has
happened
so.
B
What
I
would
propose
is
I,
as
soon
as
we
finish
talking
about
this,
I
will
go
and
put
a
hold
on
the
pr
I
will
yeah
and
then
I'll
ping
harry
harry
and
john
howard
are
the
ones
who
have
the
outstanding
some
answering
comments,
so
I'll
ping
them
on
here.
B
I
think
we
give
them
yeah.
We
lose
your
consensus
this
to
like
a
few
days,
maybe
before
next
week's
meeting
and
then
so,
if
richard,
if
you
pick
up,
if
you
fix
up
the
comments
that
bowie
and
I
have
left
and
then
no
one
else
has
any
more
comments
by
next
week's
meeting.
I'd
say
we'll
call
it
done
then,
and
we'll
remove
the
hold.
B
Once
once
my
comments
are
fixed
up.
I
will
slash
lgtm
that
will
put
the
label
on,
but
because
the
hole
is
present,
it
won't
actually
merge
and
then
bowie
is
free
to
do
his
ltn
lgtm.
Once
once
his
comments
are
resolved
and
then
then
we
then
we
basically
just
need
rob
or
harry
or
james
to
lgtm
from
them
and
then
100,
good,
okay,.
A
Yeah,
almost
two
months
now,
so
thank
you
for
bearing
with
our
review
process
here,
but
this
this
is
an
awesome
gap
and
I'm
excited
to
get
this
one
in
me
too.
A
All
right
are
there
any
other
pr's
of
note
that
I
should
we
should
make
sure
we
go
through
here.
I
think
most
of
these
are,
I
know
all
my
pr's
are
waiting
for
myself
to
get
back
to
reviews
and
comments
on
any
other
things
that
we
should
cover
in
pr's
or
just
head
to
issues.
A
All
right
issues-
it
is
there's
this.
This
first
issue
really
interested
me
and
I
think
there
is
some
likely
something
unexpected
with
our
documentation.
This
is
a
feature
I
added
it's
adding
path
to
request,
redirect
it's
experimental
it's
in
0.50
or
intended
for
0.50,
but
somehow
somewhere.
A
Maybe
it's
in
our
api
spec,
but
someway
we
gave
the
illusion
that
this
could
be
done
and
it
can't
be
done,
at
least
not
until
we
release
experimental
o500,
and
so
I
I
will
take
it
on
myself
to
follow
up
and
figure
out
where
our
documentation
has
failed
us
here.
All
right.
My
guess
is
it's
our
api,
spec
and
yeah.
This
is
quite
the
issue
title,
but
either
way
it's
unfortunate
it
it.
You
know
this
is
going
to
be
a
confusing
part
of
our
api.
A
The
idea
that
we
have
some
fields
that
are
experimental
and
we
don't
label
them
as
clearly
as
we
should,
especially
in
the
spec
so
yeah
this.
This
will
take
more
more
effort.
I
I
think,
what's
actually
happening
here
is
expected.
It's
just
not
documented
at
all.
So
I
can.
I
can
take
this
one,
the
next
one
I
wanted
to
get
to
this
one.
This
one
also
is
straightforward.
I
think
we
can
redirect
them
to
other.
A
B
That
they
haven't
been
auto
closed
yeah.
That's
that's
true
good
point
and
make
sure
we
freeze
them.
Yeah.
A
Yeah
and
then
the
last
one
john,
I
don't
think
john-
is
on
this
call,
but
this
one
is
going
to
be
a
larger
discussion.
I
think
I
I'm
curious
of
implementers
out
there
or
users
who
are
interested
in
this
kind
of
feature.
A
E
Something
that
we
run
into
because
we
can
for
console.
We
can
have
services
that
are
outside
of
kubernetes,
it's
part
of
the
same
service
mesh
and
so,
and
so
those
services
aren't
known
within
kubernetes.
So
we
had
it
come
up
with
a
keyword
that
we
used
to
tell
us
that
it's
a
service
outside
of
kubernetes
so
somewhat
similar.
I
I
believe.
D
We're
still
using
backend
ref
for
that,
though,
it's
just
back
and
rough
of
a
different
type
of
this,
like
con
console
mesh
service
or
something
like
that.
Yeah
yeah.
D
Yeah,
actually,
if
I'm,
if
I'm
familiar
with
how
istio
is
using
this,
it's
to
point
to
something
like
a
domain
name
which
would
be
like,
is
a
use
case
within
console
service
mesh.
It's
how
we
use
like
turning
gateways,
basically
connect
to
outside
of
the
mesh
things,
whether
it
be
like
an
upstream
api
or
like
a
legacy
service.
That's
not
integrated
into
the
mesh
yeah.
I
don't.
B
So
I
think
I
put
in
the
I
put
a
comment
in
there
about
my
concerns
around
using
some
type
of
external
name,
and
that
is
basically
about
it's
super
easy
to
use
it
for
bad
things,
super
easy
to
to
use
it
to
do
all
sorts
of
bad
stuff.
B
B
So
this
is
a
type
external
name,
because
if
you
configure
external
names
for
localhost,
then-
and
you
have
an
inline
proxy,
then
that
means
that
you
were
accessing
the
inline
proxies
localhost,
which
means
that
if
you
are
running
the
say,
the
envoy
admin
web
interface,
you
can
then
create
a
any
user
who
has
access
to
create
services,
can
create
a
service
of
type
external
name,
with
the
name
of
localhost
that
points
you
to
the
web
interface
and
expose
the
web
interface
for
your
envoys
out
to
the
internet.
B
So
you
know
like
I
said:
it's
really
easy
to
use
this
to
do
really
bad
stuff,
and
so
I
think
that
you
know
we
should
my
feeling
is
that
we
should
say
no,
sir,
but
so
using
service.
Entire
external
learning
is
not
valid
that
you,
this
is
not
allowed,
and
if
you
want
to
do
something
like
that,
you
need
to
add
your
own
type.
That
has
its
own
rules
around
around.
You
know
what
host
names
are:
okay,.
A
Yeah,
that's
good
great
points
and
that
that
is
I
know.
Contour
was
not
the
only
only
implementation
that
that
had
a
similar
issue.
A
So
the
the
issue
that
I
referenced
here
is
a
cv
that
we
is
related
to
this
and
actually
came
out
of
gateway,
api
discussions
and
work
and
research
and
trying
to
figure
out
how
we
could
do
different
things
cross
boundaries
such
as
namespace,
but
also
to
external
name
and
wow.
This
is
really
scary,
and
so
that
we
have
to
be
very
careful.
The
you
know
you
it's.
You
know
you
forward
to
any
dns
name,
you
don't
know
what
it
resolves
to
you.
A
Don't
you
know,
do
you
just
you
know,
deny
list
a
subset
of
of
ips
that
you
know
are
dangerous
and
then
the
the
other
thing
is
that
the
whole
confused
deputy
attack
of
how
do
I
know
that
you
have
access
to
expose
this
endpoint
that
I,
as
the
controller
or
control
plane,
have
access
to.
So
it's
a
scary
thing
with
that
said,
I
had
a.
A
A
But
it's
there
are
huge
risks
here
and
it's
we
could.
We
could
probably
write
a
whole
page
in
our
documentation
around
external
name.
I
don't
know,
I
agree
with
your
ideas.
Nick
of
you
know
a
separate
resource,
or
some
some.
You
know
implementation
specific
thing.
If,
if
you
must
do
this
for
ingress,
I'm
less
sure
about
the
other
potential
use
cases.
A
I
I
think
this
is
good
to
leave
open
for
discussion.
I
don't
have
an
answer
right
now.
I
know
I
know
users
are
asking
for
it
and
I
know
it's
really
dangerous
and
maybe
there's
a
safe
way
that
we
haven't
found
yet
so
oh
open
to
others
other
thoughts
on
this
one,
but
this
is
1070.
B
Yeah
yeah
look
like
I
said.
I
think
egress
is
a
whole
different
thing
and
the
part
of
this
problem
is
that
you're
reusing
the
same
concepts
for
ingress
and
egress,
which
which
have
slightly
different
use
cases
and,
as
I
said,
I
think
that
if
we,
if
we
say
if
we
encourage
people
to
do
something
separate
for
egos
like
have
an
ego
service
type
or
something
like
that,
that
has
some
validation
that
ensures
that
you
can't
put
local
host
in
or
something
like
that.
B
Then
I
mean
that
doesn't
protect
that
doesn't
100
protect
you,
because
all
it
takes
is
someone
having
a
public
publicly
accessible
domain
name
that
refers
to
one
two:
seven:
zero,
zero
one
and
you're
back
in
the
same
pickle,
but
but
yeah
like
as
you,
the
as
long
as
people
are
aware
of
the
risks
of
doing
this
and
that
you
cut
out
the
obvious
stuff,
then
you
then,
I
think
it's
okay
at
an
implementation,
specific
level,
but
you,
like,
I
said,
have
just
opened
so
much
for
can
of
worms
about
allowing
any
domain
name
that
it's
pretty
scary.
A
Cool
okay!
Well,
I
think
at
the
very
least,
but
this
was
a
reminder
that
we
didn't
document
this
at
all
in
ingress
and
what
ended
up
happening
is
I
I
don't
think
so
to
be
clear.
I
was
not
involved
in
the
original
design
of
ingress
and
I
don't
know
anyone
still
around
is
was,
but
it
was
something
that
I
forget,
which
came
for
a
service
type,
external
name
or
ingress.
A
I
I
don't
know,
but
I
don't
think
anyone
planned
on
their
interaction
and
now
we
we
know
better
and
we
should,
at
the
very
least
document,
maybe
in
our
security
model
or
or
somewhere
that
watch
out
for
this.
A
B
Maybe
we
should
say
I
don't
know
I
I
I
lean
towards
saying
yo:
it
should
not,
it
should
not
be
allowed
and
that,
if
you
want
to
do
something
like
it,
then
don't
use
service
or
type
external
name
use
a
separate
resource,
and
that's
that's
a
way
to
make
it
more
safe.
That
way.
People
who
don't
want
to
have
anything
to
do
with
this
don't
have
to
you,
have
the
possibility
of
using
surface
or
type
exit
on
them.
I
think
using
the
service
object
has
far
too
much
magic
built
into
it
already.
B
This
is
a
good
example
of
a
place
where
the
magic
is
too
much
and
you're
explicitly
saying:
don't
we
don't
allow
this
specific
thing
because
of
these
reasons,
if
you
want
to
do
something
like
it,
you
make
your
own
make
your
own
object
that
that
solves
some
of
these
problems.
I
think
he's
much
safer.
A
E
Actually
I
was
gonna,
you
know
we
were
talking
that
first
issue,
the
top
one
there
you
know
rob.
You
made
the
comment
that
we
don't
really
document
which
of
our
which
things
are
experimental,
which
you
know
good
point.
So
how
do
we
want
to
address
that,
though,.
A
So
I
should,
I
should
add
one
thing
in
our
guides
and
our
proper
docs
that
we
manually
write
with
markdown.
We
have
little
yeah.
I
don't
know
it's
pretty
clear
that
this
is
an
experimental
feature.
What
is
much
less
clear,
unfortunately,
is
our
generated
docs
right.
Our
generated
docs
have
this
little
gateway,
experimental
tag
somewhere
in
the
reference
doc
somewhere.
If
we're
lucky,
that's
the
last
time
I
saw
about,
I
don't
have
any
tests
to
verify
that
it
still
exists.
A
B
Yeah
it'd
be
nice
if
we
could
update
the
generator
so
that
it
finds
those
tags
and
adds
like
a
big
new
neon
red.
This
field
is
experimental
thing
in
there
in
the
in
the
documentation
or
something
I'm
just.
A
Yeah
I
so
I
spent
a
bit
of
time
looking
around
at
different
generators
when
we
started
this
project,
the
generator
we're
using
was
really
the
the
only
one
that
I'm
aware
of
that
did
api
docs.
There
are
a
couple
alternatives.
Now
one
is
a
fork
of
this
generator
that
added
a
little
bit
more
stability
to
it.
A
I
I
think
our
solution
is
probably
going
to
involve
some
work
and
maybe
a
transition
to
a
different
docs
generation.
For
this
I
would
love
if
there
were
a
simpler
workaround,
but
I
haven't
found
one
yet
so.
B
I
should
also
note
that
you
know
I'm
pretty
confident
that
one
of
the
outcomes
of
the
documentation
review
that
is
doing
is
that,
with
a
strong
recommendation
that
we
move
to
hugo
and
to
a
side
versioning
scheme
like
the
overall
kubernetes
website.
B
If
you
look
at
the
overall
kubernetes
website,
it
has
a
little
drop
down
at
the
top
that
lets.
You
pick
the
version
that
you're
using
it
and
then
everything
inside
the
side
is
that
version,
it's
a
half
element
and
all
that
sort
of
stuff
right
now
we
don't
have
any
of
that.
You
have
to
sort
of
go
to
the
different
bit
and
be
like.
Am
I
looking
at
the
v1l
for
two
docs
or
the
v1r
for
one
box?
The
problem
is
only.
B
We've
got
to
do
with
the
docs
website,
and
I
think
that
you
that
we're
going
to
have
to
deal
with
the
experimental
thing
as
part
of
that
as
well,
and
then,
of
course,
there
also
is
the
other
of
the
other
thing
that
there
is
a
cap
upstream
cap
pending
that
will
that
will
when
it
goes
in,
allow
for
crds
to
have
feature
gate
fields.
Specific
fields
feature
gated,
which
we
will
then
be
able
to
use
pretty
easily
and
will
replace
the
existing
experimental
point
and
so
yeah.
B
A
Yep,
I
agree
cool
well,
we
are
at
time
I
I
think,
that's,
I
think,
that's
everything
that
has
happened
in
the
past
week,
though,
so,
if
there
is
nothing
else,
maybe
that's
it
for
today
anyone
any
last
thoughts.
Yeah
anyone
want
to
say
anything
before
we
finish.
B
A
Cool
all
right:
well,
thanks
everyone
we'll
talk
to
you
next
week,
thanks.