►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220523
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220523
A
All
right
welcome
to
gateway
api
meeting
for
may
23..
We've
got
a
few
things
on
the
agenda
today.
Just
as
always,
this
is
a
very
informal
meeting
feel
free
to
ask
questions.
Make
comments.
Add
things
to
the
agenda
as
you
see
fit,
anyone
should
be
able
to
edit
this
agenda,
so
please
feel
free.
A
This
is
just
suggestions
for
what
to
talk
about,
but
feel
free
to
add
your
own.
With
that
said,
the
first
thing
I
had
on
the
agenda
was
memorial
day
in
the
us
at
least
is
next
monday
and
I'm
not
planning
on
being
at
the
meeting.
A
Yeah,
it
seems
likely
that
be
pretty
lightly
attended,
so
I'll
plan
on
canceling,
but
if
again,
if
anyone
does
want
to
show
up
by
all
means
cool
all
right
next
up,
let's
run
through
the
0.50
milestone,
we
are
just
knocking
down
on
the
last
couple
things
you
can
see
that
many
of
the
issues
we
have
open
still
already
have
prs
that
will
resolve
them,
which
I'm
excited
about,
went
through
a
lot
of
this.
A
These
issues
with
nick
last
week
was
good
to
work
with
someone
in
person
on
this
and
yeah.
We
knocked
out
a
lot
of
these.
I
want
to
just
highlight
a
couple
that
I
think
are
straightforward.
One
there's
been
some
work
on
documenting
path,
rewrites
and
redirects.
This
is
by
travis.
A
I
added
well
both
nick
and
I
added
some
feedback
on
this
one,
but
travis
is
out
of
office
for
a
couple
more
days,
but
I
think
this
one
is
going
to
get
resolved
hopefully
this
week,
but
that
that
is
travis
did
a
great
job
with
this.
This
pr
feel
free
to
add
your
own
comments
on
this
one,
but
I
think
it's
in
a
really
good
place.
A
Next
up
is
actually
this
one
is
just
kind
of
the
last
thing
on
the
list,
so
no
changes
on
this
front.
The
other
one
I
wanted
to
highlight
is
something
that
came
up
in
an
issue
that
someone
had
raised
about
how
it's
confused
our
path.
Modifier
is
confusing
and
that
it
requires
a
specific
path
match
to
be
present
and
if
it
isn't
present,
it's
unclear
what
to
do
so.
A
This
just
adds
web
hook
validation
to
ensure
that
the
prefix
path
match
is
always
going
to
be
present,
so
this
is
less
than
an
issue
again.
This
is
just
for
an
experimental
feature
in
o50,
but
it
feels
better
to
have
this
in
early
than
to
not
so
we
agreed
that
this
should
be
in
the
milestone.
A
A
All
right
with
with
all
that
background,
I
want
to
get
to
what
I
think
is
has
been
the
most
controversial
of
the
bunch
and
that's
this
wild
card.
Hostname
matching
there's
been
a
lot
of
discussion
on
this
issue.
I
feel,
like
we've,
had
longer
term
discussion,
more
history
that
has
gotten
lost
here,
but
the
fundamental
thing
is
it's
unclear
what
a
wild
card
hostname
match
should
be
interpreted
as
so.
If
you
have
star.example.com
should
that
match
a.example.com
or
a.b.example.com
all
of
the
above
with
the
ingress
spec,
it
would
only
match
a.example.com.
A
I
am
thinking
that
was.
That
is
not
the
the
ideal
spec
and
is
certainly
not
something
that
matt
is
is
broadly
implementable.
A
So
my
argument
is
that
we
should
actually
deviate
from
the
spec
that
was
in
ingress
and
match
what
seems
to
be
more
broadly
implemented,
which
is
a
wild
card.
Hostname
match
is
really
just
a
suffix
match
and
it
will
match
any
level
of
subdomains
any
any
number
of
dns
labels
before
that
that
there's
more
discussion
here,
but
my
the
my
biggest
reason
for
this
is
that
there
are
some
implementations
that
simply
cannot
support
matching.
A
Only
a
single
dns
label
with
a
for
a
wildcard
hostname
match
and
that
that
includes
gcp,
but
that
also
includes
other
cloud
providers
like
azure,
and
I
couldn't
get
a
clear
answer
on
what
aws
currently
supports,
but
I
know
that
there
there
are
other
providers
out
there
that
just
cannot
support
the
single
dns
label
match
here,
so
that
I've
been
talking
a
lot
here.
I
know
others
have
commented
on
an
issue.
Any
anyone
else
have
thoughts
on
this.
One.
B
I
think
I
should
I
should
indicate
the
history
here
so
yeah.
I
definitely,
I
definitely
wrote
the
spec
originally
to
be
that
it
was
a
single
label
and
only
a
single
label
assigned
the
same
as
ingress.
B
I
think
that
I
and
like
to
be
honest,
I
would
kind
of
prefer
to
have
it
be
the
same
behavior
as
ingress.
Sometimes
we
have
a
very
good
reason,
however,
mandating
a
behavior
is
core
that
cannot
be
implemented.
That
we
know
for
sure
cannot
be
implemented
by
all.
B
Implementations
doesn't
seem
to
fit
well
with
how
we're
trying
to
do
things
in
general,
like
trying
to
make
it
to
be
to
mean
that
core
core
is
implementable
by
everything,
and
if
we
have
at
least
indications
that
some
implementations
can't
do
it,
then
that's
a
pretty
strong
thing
in
my
mind
that,
oh
maybe
this
shouldn't
be
cool.
B
So
I
think
rob
do
you
just
want
to
just?
Can
you
just
talk
through
like
what
your
suggestion
is
about
about
how
to
handle
this.
A
C
A
So
it's
really
treating
this
as
a
suffix
match
that
that
is
something
like
that.
You
know
matches
default,
behavior
and
envoy
engine
x
and
various
cloud
providers
with
that
said,
it
does
deviate
from
the
ingress
back
the
if
we're
uncomfortable
with
that.
For
any
reason,
the
alternative
is
to
leave
it
unspecified.
B
I
think
probably
james
did
raise
a
good
thing
that
multi-label
managing
doesn't
work
with
tls,
yeah
and
it'll,
be
it
will
be
hard
to
debug
yeah
as
as
he
said
like,
so
if
we
are
going
to
allow
it
like.
Maybe
we
need
to
allow
like
it's
going
to
be
a
little
wooly
in
how
we
allow
it,
and
so
I
think,
yeah.
I
think
that
I
personally
think
that
leaving
it
unspecified
is
not
an
option.
B
We
have
learned
the
one
thing
that
I
would
say
we
have
learned
from
ingress
is
that
leaving
things
unspecified
means
that
everyone's
going
to
do
something
different
and
it
won't
be
compatible
between
implementations
like
that,
is
one
of
our
goals.
Let's
not
like
dilute
that
goal
you
we
have
to
do
something
that
all
implementations
can
implement
and
then
it
has
to
be
fully
specced
both
with
things
in
the
spec
and
with
conformance
tests.
B
A
Yeah
now
I
agree,
I
the
the
thing
I'd
say
about
tls.
Is
you
know?
I
agree,
it's
it's
a
messy
and
unfortunate
thing,
but
it
is,
it
does
match.
You
know
if
you're
writing
to
envoy,
if
you're
configuring,
these
other
data
planes.
This
is
something
that
already
exists.
This
kind
of
conflict
of
matt
wild
card
matching
matching
multiple
labels,
but
that
not
working
well
with
tls.
So
maybe.
C
We
should
look
at
how
these
what
happens?
Sorry,
just
what
happens
in
that
case?
Does
it
just
drop
to
the
default
certificate?
B
Well
depends
not
all
implementations
support
a
default
certificate
but
yeah.
Essentially,
yes,
when
you
like,
when
you
make
a
wildcard
cert
like
it
only
it
will
only
match
a
single
dns
label
in
the
globe.
So
like
yeah,
if
you
get
stardust.com
in
your
cert,
it
will
only
match
a
single
dna.
C
C
B
Mismatch
yeah,
I
would
say,
if
we're
going
to
do
it,
what
we
need
to
do
is
just
call
out
to
say:
hey,
remember
that
if
you
are
planning
to
have
two
levels
like
more
than
one
level
of
wildcarding,
then
you
need
to
make
sure
that
you're,
if
you're,
using
a
wildcard
search
that
they
that
they
match.
You
know
that
they
match
the
number
of
levels
that
you
have
yeah.
So
I
think
you
could
probably
just
we
could
probably
just
have
a
caveat
in
the
docs
there
to
just
be
like
hey.
B
Maybe
maybe
we
can
say.
Maybe
we
can
say
something
like
implementations.
B
Must
you,
the
the
the
the
behavior
is
that
they
they
only
have
to
you
have
to
support
suffix
matching,
but
you
you
know
you,
may
you
sort
of
may
treat
it
as
a
single
label
or
no?
No,
like
we
recommend
that
in
most
cases
we
recommend
users
use
a
single
label.
In
most
cases
like
don't
do
multi
labels,
unless
you
really
need
it.
C
B
Or
yeah
like
or
star
dot,
you
know
startupbar.foo.com
and
then
start
on.
You
know
zug.com
and
like
each
other
sub
domain,
you
need
to
do
or
something
like
that
and
so
like.
That
seems
to
be
weird,
but
I
mean
all
of
this
is
like
pretty
edge
casey
just
saying
it's
a
suffix
match
for
users.
We
recommend
that
you
only
do
a
single
label
here
unless
you
have
a
very
strong
reason
otherwise,
or
something
like
that,
like
just
we
just
need
to
preserve.
B
In
my
mind,
we
need
to
preserve
a
little
bit
of
the
nuance
around
this
discussion.
Just
to
say,
hey
you,
it
can
have
other
effects,
don't
do
it
unless
you
really
need
to
something
like
that.
How
exactly
we
would
that
I
don't
know,
but
that
is
my
suggestion.
A
Yeah
that
seems
reasonable
to
me
before
we
move
go
ahead
with
this
kind
of
change.
Anyone
else
have
any
thoughts
or
comments
on
this.
A
I'm
going
to
take
silence
as
consensus
here
any
any
volunteers
to
to
go
forward
with
making
this
change.
The
spec.
A
I
can
I
can
probably
find
time,
but
if,
if
anyone
wants
to
volunteer
by
all
means.
A
Okay,
okay,
I'll
I'll,
follow
up
with
this.
I
think
this
is
going
to
need
some
some
good
review.
We
want
to
be
very
precise
with
this.
A
So
with
those
goals,
I'll
work
on
an
update
to
the
spec
and
similarly
conformance
tests,
cool
all
right
nick,
I
think
that
hands
it
back
over
to
you.
You
had
something
about
documentation.
B
Yeah
so
so
I've
been
working
with
maya
to
do
like
a
documentation
assessment
of
of
our
website.
It's
nicely
done,
she's
done
a
great
job,
and
one
of
the
things
that
came
out
of
it
was
that
one
of
her
one
of
her,
the
her
recommendations
that
I
100
agree
with
is
that
we
need
to
have
better
versioning
of
our
docs.
B
It's
only
going
to
become
more
important
as
we
go
forward
because,
because
of
the
way
our
versioning
works,
the
bundle
version
is
the
key
sort
of
dimension
on
which
we
need
to.
B
C
B
Are
going
to
move
around
on
our
release
basis,
so
it's
really
important
that
we
have
something
like
you
have
on
main
kubernetes,
docs
or
other
upstream
repos,
where
you
have
a
drop
down
or
something
like
that
that
lets
you
choose
the
that
lets.
You
choose
the
bundle
version
of
the
documentation
you're
looking
at
now
for
that
to
work,
it
doesn't
work
with
the
current
documentation
generation.
We've
got
and
also
with
the
way
that
we
do
the
versioning
of
the
model.
B
It
just
doesn't
work,
so
I
sort
of
recommended
looking
at
moving
the
website
to
hugo
and
then
after
that
done,
we
we
can
use,
there's
a
few
different
hugo
plugins
that
you
can
use
to
add
versions,
she's
going
to
have
a
look
at
someone
evaluate
them
and
all
that
stuff.
I
just
wanted
to
get
she
sort
of
asked
if
we
could
get
broad
agreement
that
we're
okay
with
doing
the
work
to
move
the
website
to
hugo,
firstly,
and
then
doing
the
work
to
implement
proper
versioning.
B
Now
the
prs
to
do
this
are
going
to
be
your
usual
I've
just
re-implemented
a
website
prs
in
that
they're
gonna
be
unreviewable
via
diff,
pretty
much
because
yeah
you
can
touch
every
line
in
the
website
pretty
much.
So
I
think
this
one
will
just
need
a
it'll
need
a
pass
over
it
using
the
deploy
preview
and
that's
really
going
to
be
all
the
review,
we're
going
to
be
able
to
do
in
general
yeah.
B
A
Yeah
yeah,
I'm
so
excited
that
she's
she's
been
working
on
improving
our
docs.
I'm
I'm
yeah
complete
agreement
for
this
one.
So
looking
forward
to
what
she
comes
up
with
and
yeah,
I've
taken
a
quick
look
at
what
she's
done
as
well
and
yeah
it'll
be
great
yeah.
B
So
yeah,
so
just
to
just
a
hundred
percent
be
clear.
So
meha
is
a
linux
foundation
summer
for
one
of
the
whatever
your
seasons
was.
I
don't
remember
which
one
it
was,
but
anyway.
B
Essentially,
so,
there's
a
there's,
a
mentor
relationship
with
the
linux
foundation,
where
people
get
paid,
maybe
winter
I
don't
know-
I
can't
I
lose
track,
but
we're
like
I'm
like.
Is
it
your
summer
or
my
winter
or
your
fault
anyway?
So
I
actually
had
a
conversation
with
nate
who
runs
the
program
cubecon
and
we're
going
to
rename
them
rename
the
the
linux
foundation
mentorships
to
like
the
month
that
they
started
rather
than
calling
them.
B
You
know,
fall
and
stuff
so
that
we
don't
have
to
do
this
mental
translation
yeah
so
that
we've
missed
the
one
that
we've
missed
the
next
one.
But
we
may.
I
may
look
at
doing
something
similar
again,
because
it's
really
helpful
to
get
more
people
involved
like
more
more
people
who
are
just
starting
out
involved
and
get
them
up
to
speed
on
what's
going
on
here,
so
yeah
yeah.
So
I
will
mark.
B
I
will
mark
that,
as
a
plus
one
tell
her
that
it's
recorded
in
these
in
these
meetings
that,
whether
we're
all
good
I'll
record
that
in
a
minute
yeah,
I
will
mark
that
was
done
thanks
mike.
D
Hey
so
this
is
mostly,
I
would
just
curious
to
hear
from
other
implementations
about
how
they're,
looking
at
the
recently
merged
change,
to
switch
the
recommended
status
codes
from
503s
from
a
bunch
of
stuff
to
404s
and
kind
of
like
what
I
stumbled
across
is
that
the
404s
definitely
seem
to
make
sense
for
some
cases
where
there's
like
a
definitive
gateway
knows
no
such
route
exists
where
it
feels
more
fuzzy
is
on
some
of
the
stuff
where
it's
like.
There
may
be
multiple
back
ends
and
one
is
unavailable.
D
Those
like
I
think,
4
4,
is
typically
like
a
response
that,
like
might
be
cached
or
something
like
that,
and
doesn't
really
lend
itself
well
to
like
retrial.
Retrying
might
succeed
type
cases,
but
was
mostly
just
curious
to
hear
from
other
implementations
and
other
thoughts,
and
some
of
this.
B
Yeah
I'll
admit
I
was
a
little.
I
was
like
I
kind
of
feel
more
comfortable
about
this
being
503
in
general,
this
sort
of
stuff
being
503,
and
that's
why
it
was
originally.
I
think
I
lost
a
little
context
here
over
the
last
couple
of
weeks.
Maybe
something
big
happened
that
I
can't
remember:
yeah
the
so
yeah
I'd
probably
be
supportive
of
doing
something
like
that
because,
as
you
say,
like
503
is,
does
sort
of
imply
a
more
retriable
error.
404,
it
applies
a
more
permanent
error.
B
Yeah,
I
kind
of
agree
a
bit
rob.
Maybe
do
you.
A
Want
to
talk
through
yeah,
so,
as
as
I
recall,
the
idea
here
was
that
a
50x
error
code
seemed
to
indicate
that
there
was
something
wrong
with
the
server
and
the
server
in
this
case
would
be
the
application,
not
not.
You
know,
envoy
or
contour
what
it
would
be.
The
underlying
application
had
some
kind
of
issue
was
temporarily
unavailable,
which
did
not
seem
particularly
accurate
as
a
means
of
describing
this
is
a
reference
to
something
that
does
not
exist.
A
If
you,
you
know,
if
you
think
of
a
404
as
a
reference
to
a
file
that
does
not
exist,
if
you're
just
you
know,
serving
static
content
as
a
rough
idea,
this
seems
at
least
somewhat
similar
to
that
in
the
sense
of
this
is
a
reference
to
a
back
end.
That
does
not
exist,
or
I
cannot
resolve
it
that
that
was
my
logic
here.
The
the
points
about
retryability
are
are
important,
but
I
I
think
I
so
I'll
be
to
be
clear.
A
I
don't
think
that
a
404
or
503
perfectly
represent
this,
and
I
can't
find
a
status
code
that
does
to
me
404
felt
like
a
better
representation
of
most
of
these
error
states,
but
yeah
interested
in
other
thoughts.
Here
I
I
do
get
that.
Neither
feels
particularly
precise.
A
And
for
anyone
watching
the
recording
comment
from
brian
that
nginx
returns
404
if
back
ends
are
not
present
or
fail.
Health
checks.
C
So
I
actually
have
to
drop
off
early,
but
are
there
very
specific
ones
that
we're
stuck
on
versus
like
the
overall?
I
think
so
attempted.
A
A
I
think
the
one
that
mike
highlighted
here
is
the
specific
thing
where
there
are
multiple,
multiple
back
end
refs
one
resolves
and
the
other
does
not,
and
so
you're
you're
splitting
between
unhealthy
or
non-resolvable
back
end
and
a
resolvable
one.
So
you're,
you
know
50
of
the
time
you're
getting
a
404.
A
Let's
say
like
let's
say
you
have
a
50
50
traffic
split
and
when
that
traffic
hits
that
unknown
or
unresolvable
back
end,
you're
gonna
get
a
404
and
that
at
404,
something
that,
as
mike
mentions,
is
not
something
you
expect
to
see
intermittently
you'd
expect
it
to
be.
What
does
unresolved
mean
simplest
case?
Is
it
refers
to
a
service
that
doesn't
exist.
A
B
I
think
yeah,
and
so
it's
important
to
consider
that
it's
the
difference
here
is
between
there's
a
strong
difference
between
zero
back
ends,
zero
healthy
back
ends
and
some
healthy
back
ends,
but
not
all.
D
B
C
D
The
trickiest
part,
and
not
just
for
like,
what's
correct,
but
also
like
potential
implementation
difficulties,
so
I'm
kind
of
curious
to
hear
from
like
feeling
like
what
nginx
allows
to
be
configured,
for
example,
versus
what
envoy
allows
to
be
configured
and-
and
there
is
definitely
like
a
large
chunk
of
like
two-thirds
of
it.
D
404
makes
a
lot
of
sense
for,
like
the,
and
I
think,
someone
folks
that
missed
some
of
the
original
contacts
like
the
in
the
context
of
which
this
came
up
was
that
the
behavior
for
an
unmatched
route
when
there
was
like
no
route
match,
http
route
match
or
all
possible
back-ends
would
have
been
eliminated
by
a
filter
that
was
currently
unspecified.
B
Yeah,
I
think,
there's
there's
an
important
crossover
here
with
inclusion
as
well
that
if
there's
no
valid
once
you
have
inclusion,
if
there's
no
valid
routes
inside
the
inclusion,
then
does
that
mean
that
the
whole
route
is
not
valid
like
what?
How
does
what
happens
with
accepted
and
stuff
there
in
those
cases,
and
also,
if
you're,
including
routes
with
a
if
you're,
including
routes
with
a
including
a
route
using
the
allowed
routes
that
has
a
weight
on
the
allowed
routes?
B
Like
you
know,
you're
saying
30
of
routes
goes
to
the
included
route
and
there
are
no
visible
routes
in
there.
What
happens
if
there
are
some
routes
in
there?
What
happens
if
there's
like
you
know
so
like
there's
a
lot
of
the
the
fact?
We
need
to
kind
of
get
this
close
to
right
now,
so
that
we
can
so
that,
then
we
can
it's
easier
to
figure
out
what
we
need
to
do
in
the
case
of
the,
in
the
case
of
the
more
complicated
stuff
later.
B
So
yeah,
I
think,
maybe
actually
I
think
that
seems
like
bowie
you're
at
least
listening.
If
we
could
have
someone
else,
who's
not
doesn't
have
the
context
or
any
other
people
from
the
community
who
don't
have
the
context,
have
a
look
at
the
state
as
it
stands
and
think
about
the
cases
that
mike
has
mentioned
in
there.
I
think
that
would
be
really
helpful.
I
think
that,
like
I
know,
I'm
too
close
to
this.
B
I
can't
like
I
can't
divorce
my
knowledge
of
the
history
and
the
con
and
the
context
around
it
and
stuff
it's
hard
to
start
from
scratch.
That's
what
we
really
needed,
someone
to
start
to
review
this
starting
from
scratch
like
okay,
you
know
what
happens
here
and
to
remember
that
you
have
to
take
into
account
that
the
the
difference
between
like
no
healthy
back
ends
and
some
healthy
brackets
and
what
what
it
looks
like
for
the
user
in
those
cases.
A
Yeah
this
this
feels
like
it
could
probably
use
a
table
somewhere
of
all
the
possible
cases
and
the
you
know,
ideal
error
code
for
each
one
I'll
say
like
this
is
something
that
is
relatively
easy
for.
When
I
say
house
I
mean
gcp
to
implement
because
we
deploy
a
static,
404
error,
page
that
we
can
route
to.
A
So
it's
just
you
know
like
this
is
a
back
end
that
we're
routing
to
50
of
the
time,
so
it's
implementable
by
us,
but
that
I
recognize
that's,
not
everyone
and
we
also
just
want
something
that
is
not
just
implementable,
but
something
that
makes
sense.
A
You
know
I
I
think
404
makes
sense
for
a
large
portion
of
the
error
cases
here,
but
this
is
a
weird
one.
You
know
like
if
we
say
that
that
a
503
makes
more
sense
when
there
is
one
healthy
backend,
but
not
I
don't
maybe
a
table,
maybe
some
kind
of
just
a
list
of
possible
error
states
here.
I
don't
know
why
mike
it
seems,
like
you've
already
been
been
doing
some
thinking
about
this.
I
am
happy.
D
To
translate
some
of
the
stuff
that
I've
already
written
on
this
into
a
table
and
yeah
like
one
of
the
big
outstanding
questions
here,
is
around
like
partial
acceptance
of
routes
too
of
like
is
there
a
should
there
be
a
difference
between
zero,
valid
things
and
one
valid
thing
on
a
thing
that
has
multiple
invalids,
yeah,
yeah.
A
All
right
yeah,
thank
you
for
raising
this
one.
I
remember
seeing
this
come
through
my
email
and
I
never
found
it
again
because
it
was
lost
in
a
closed
issue
somewhere.
So
yeah
thank
you
for
raising
it.
The
I
just
want
to
start.
I
want
to
head
back
to
the
050
milestone
for
one
second,
if
we
get
so
I'm
thinking
about
this
from
the
context
of
it
being
two
weeks
until
we
meet
again.
A
So
with
that
in
mind,
I
think
it's
possible
by
the
time
we
meet
next,
that
this
will
have
merged
this
document.
Redirects
rewrites,
the
the
webhook
validation
will
have
merged,
and
the
card
host
name
matching
behavior
will
have
been
resolved.
I
think
all
of
those
things
are
likely
going
to
be
done.
If
we
get
to
a
point
where
all
three
of
those
have
been
resolved,
do
we
feel
cutting
a
release
candidate
of
05.0.
B
Yes,
okay,
we
should
hear
from
other
people,
not
just
me,
but
that
is.
B
A
I'll
take
silence
as
as
a
good
sign
here,
but
cool,
so
I
I
would
love
to
get
a
v5050
release
candidate
out
in
the
next
couple
weeks
that
that's
my
goal
and
once
we
have
that
rc
out
again,
things
can
change,
but
I
expect
them
to
be
very,
very
minor
and
it
provides
a
good
release
time,
a
good
target
for
anyone
who's
working
on
release
on
supporting
this
release.
A
A
Okay
with
that
said,
let's,
let's
take
a
step
into
pr
and
issue
issue
triage
anyone
have
any
pr's
or
issues
that
we
should
highlight.
A
Yes,
yes,
I
at
this
point
I've
been
so
focused
on
0.50,
but
I
I
know
I
know
it's
basically
doable
like.
I
think
this
is
basically
the
identical
to
the
gap,
so
it
should
be
just
such
an
obvious
thing
to
get
in
right.
I
think
just
trying
to
avoid
expanding
the
scope
of
o50
right
now
right,
but
I
I
know
I've
looked
at
it
before
and
didn't
have
any
significant
issues
with
it.
I
don't
know
if
anyone
else
has
but
we've
got.
A
I
think
we
have
a
couple
big
changes.
Actually
you
know
why
don't
we
make
this
a
little
clearer?
So
there's
this
one
and
there's
jeff
skep
on
route
inclusion
and
I
think
in
my
head-
I've
been
considering
these
part
of
the
060
milestone,
and
so
I
hadn't
really
been
touching
them,
but
I
opened
to
other
other
feedback
on
this,
but
for
me
it's
I'm
just
trying
to
get
050
out
the
door,
and
then
we
can
talk
about
everything
else.
E
Yeah
no
worries
so
does
inclusion
in
0.6.0
mean
that
we
need
to
wait
until
like
there's
a
branch
cut
or
a
tag
done
for
odot
5.0
to
merge
it.
Yes,.
A
Okay,
yeah,
which
I
you
know
I
I'm
hoping,
is
very
very
soon
like
if
we
get
an
rc
out
in
a
couple
weeks,
I
think
that's
going
to
be
great
news
and
then
we
can
start
pulling
other
things
in,
but
really
the
branch
cuts.
Once
we
get
the
tag
out
like
once,
once
we
hit
the
release,
we're
not
we're
not
very
good
at
having
another
release
branch
going
before
we
get
another,
get
the
first
release
out
all
right.
A
No
thanks
for
the
reminder
on
that.
I
it
is,
I
think
you
know
speaking
for
myself,
it's
something
that
I
very
much
want
to
see
in
api.
I
just
you
know
trying,
as
as
we
can,
to
get
050
out
the
door
and.
A
Yes,
yes,
yeah
cool
yeah.
Thank
you.
Thank
you
for
the
reminder
on
that.
One
anything
else
that
we
should
highlight
here,
I
I
can
go
through
these
individually,
but
I
just
want
to
make
sure
that
if
there's
one
in
specific
that
I've
missed,
we
have
time
for
it.
A
Okay,
so
steve,
I
don't
think
steve
is
on
this
call.
A
This
one
oh
looks
like
mike
you've
already
lgtm'd
it.
Okay,
so
side
note.
If,
if
anyone
has
been,
if
anyone
has
been
involved
in
this
project
in
committing
and
pr'ing
feel
free
to
ask
for
org
membership,
I
know
nick
and
myself,
I
want
to
support
people
that
have
been
contributing
to
the
project.
You
know
don't
feel
like
you
know
you
can't
be
a
member,
yet
I
think
in
in
many
cases
the
people
that
have
been
contributing
still
don't
have
membership.
That
means
they
need
the
okay
to
test.
They
need
their
lgt.
They
can't
lgtm.
A
Where
really
you
know,
I
try
not
not
to
call
anyone
out
specifically,
but
there
are
lots
of
lots
of
great
contributors
that
don't
have
org
membership
yet
that
I'd
be
happy
to
sponsor
so
yeah.
B
A
Yeah,
so
it's
yeah
just
ping,
either
nick
or
myself
on
slack,
but
essentially
there's
you
open
an
issue
and
kubernetes
org
there's
a
checklist
that
you
need
and
one
of
the
key
things
is.
You
need
two
people
to
plus
one
it
from
different
organic
from
different
companies
that
are
owners
of
are
in
owner's
files
somewhere
in
kubernetes
org,
and
that
includes
nick
and
myself
and
others.
A
But
yes,
we
very
very
much
want
to
others
to
feel
empowered
here
to
lg
tmprs
to
not
need
you
know,
I
I
don't.
I
don't
want
it
ever
to
feel
like
nick
and
I
or
anyone
else
is
just
the
you
know
a
gatekeeper
for
this.
I
really
really
want
to
share
the
responsibility
contributions
whatever
so.
B
Although
gatekeeper
the
product
is,
is
awesome
other
than
that,
gatekeepers
in
general
are
bad.
B
So,
oh
yeah,
so
rob
do
you
think
I'm
kind
of
I'm
actually,
I'm
actually
technically
on
a
day
off
today,
I'm
just
dialing,
because
this
is
going
to
be
like
one
or
three
meetings
for
six
weeks,
but
so
do
you
think
that
you
could
drop
just
drop
the
link
to
the
org
repo
into
the
meeting
notes?
Just
and
the
other
thing
I
want
to
say
here
is
yeah.
I
would
encourage
everybody
if
you've
come
to
this
meeting
and
talked
more
than
once.
B
That's
like
you've
contributed
enough
to
be
an
old
member
right,
like
you
know
like
yeah
like
we
don't
want
to
keep.
The
bar
is
not
high
to
be
an
og
member
and
then
because
the
other
thing
we
really
really
desperately
need
is
more
maintenance
and
the
way
that
we
get
maintainers
is
by
people
being
all
members
being
active.
You
know
and
doing
pr
review
and
like
the
the
road
to
being
a
maintainer
at
this
point
is
not
long
right
like
for
you.
B
We've
got
four
or
five
maintainers
or
something
like
that,
but
like
really
rob-
and
I
are
sort
of
the
primary
maintainers
at
the
moment-
and
I
certainly
would
like
to
have
some
more
people-
you
know
spending
some
bandwidth
on
this.
So
if
you
are
interested
in
becoming
a
maintainer,
the
path
is
very
wide
and
very
open
and
step.
One
is
becoming
a
member
if
you're
not
already.
A
A
First
step
is
getting
org
membership,
but
that
path
is
wide,
open
and
yeah
cool,
so
yeah
I'll
I'll
drop.
A
link
in,
I
think
I'll
drop
it
in
slack
as
well,
but
I'll
drop
it
in
the
meeting
notes.
After
just
so
it's
it's
clear
how
anyone
can
can
join
up
yeah,
okay,
so
this
one
I
think,
mikey
already
lgtm
this
one.
I
yes,
we
there
were
some
confusing
skips
in
here.
A
I
think
that
was
the
gist
of
this
and
indentation
right,
yeah,
okay,
mind
your
cleanup
looks
good
cool
cool.
I
will
add
the
the
official
labels
on
that
one,
but
yeah
that
typo,
this
one's
really
straightforward
as
well.
A
I!
Yes,
this
is
cool.
Okay!
I
you
know
that
the
tricks
you
can
do
with
jsonpath
for
status,
very
handy,
okay.
What
else?
Anything
else
that's
coming
in
the
past
week
request
header
modifier
test
yeah.
I
know
I
need
to
get
to
this
one
and
I've
already
reviewed
this
one
and
everything
below
that.
I
think,
is
old
enough
nathan.
I
don't
think
you're
on
this
call.
I
think
this
one
may
be
blocked
on
me.
A
A
So
again
we
want
more
org
members,
but
org
members
also
mean
you
have
more
capabilities
to
review
in
lg
tmpr's,
which
also
selfishly
I'd
love
to
get
more
people
active
in
reviewing,
even
if
you
aren't
an
org
member
like
what
I
think
it
was
mike
reviewed
that
other
pr
that
was
great,
please
feel
free
to
to
add
comments
and
review
this
because,
like
like
yeah,
I
think
nick
alluded
to
earlier.
A
I
hate
to
be
the
bottleneck
on
this
project,
and
so
anyone
else
that
has
some
time
to
review
these
things
would
be
great,
and
you
know
I
just
appreciate
seeing
all
these
fixes
all
these
additions
come
in.
I
think
they're
they're,
all
net
positive
and
what
I'm
seeing
here
is
nothing
controversial.
It
just
needs,
you
know
a
round
or
two
of
review
yeah,
but
with
that
are
any
any
last
things
we
should
cover,
or
should
we
give
our
time
back.
F
F
I
looked
at
some
space
on
the
sample
example
example
exactly
yeah
some
of
the
implementations,
any
suggestions
which
one
I
should
look
at
more
closely.
I
looked
at
next
contour
quite
a
lot,
but
a
lot
of
stuff
is
wrapped
up
in
english
controllers
and
I'm
picking
the
gateway
stuff
is
possible
but
challenging.
So
I'm.
B
B
Where
to
start
right
right
so
in
terms
of
the
actual
code,
I
can't
speak
to
anyone
else,
but
for
contour
the
the
things
you
want
to
look
at
are
in
the
the
contour.
It's
like.
F
B
F
B
Yeah,
I
think
that
the
key
parts
just
are
the
key
parts
are
just
are
how
like
how
you
what
framework
you're
using
to
talk
to
the
api
server
and
then
how
you
turn
that
into
like,
whatever
internal
representation
you're
using
yeah
and
that's
the
tricky
part
is
because
the
the
system
of
crds
is
relatively
tricky.
You
gotta,
if
you're
using
controller
runtime,
you
have
to
sort
of
reconcile.
B
You
have
to
have
like
a
single
reconcile
that
handles
like
all
objects,
because
it's
like
they're
interrelated,
so
yeah,
that's
how
we've
ended
up
coming
to
it
there.
I
would
actually
say
if
you
really
need.
If
you
really
need
to
detail
technical
assistance,
I'm
going
to
army
volunteer
steve
chris
here
just
to
hit
him
up
on
the
kubernetes
slack
and
just
asking.
If
you've
got
the
chips,
he's
the
one
who's
done,
all
the
implementation.
B
A
Yeah-
and
I
I'd
echo
that
and
I'd
also
agree
that
may
be
coming
at
this
from
a
different
angle.
I'm
excited
to
hear
about
an
l4
implementation.
I
think
I
could
be
wrong.
I
think
istio
has
supported
some
of
the
l4
stuff
now,
but
the
number
of
implementations
that
are
supporting
l4
is
pretty
tiny,
at
least
that
I'm
aware
of,
and
so
I
I
really
want
to
hear
about
what
that
experience
is
like.
Does
it
make
sense?
A
Are
there
features
that
you're
looking
for
that?
The
api
doesn't
support?
You
know
I'd
more
more
implementations
on
the
l4
side.
A
I
think,
are
going
to
help
the
api
become
more
compelling
at
that
level,
because,
right
now
we
just
don't
have
a
whole
lot
there
so
really
interested
in
your
use
case,
and
you
know
what
that
what
that
could
look
like
so
yeah,
as
you
figure
it
out,
definitely
don't
be
surprised
if
parts
of
the
api
don't
quite
make
sense,
and
please
raise
that
to
you-
know,
issue
discussion
slack
wherever
would
love
to
hear
more.
F
A
Thanks
guys,
I
appreciate
help
cool
all
right.
Well,
I
think
that's
all
for
today,
then
thanks
everyone
for
good
discussion
and
we'll
talk
to
everyone
in
a
couple
weeks.