►
From YouTube: SIG Network Gateway API meeting for 20230626
Description
SIG Network Gateway API meeting for 20230626
A
All
right
welcome
to
the
June
26th
meeting
of
Gateway
API,
thanks
to
everyone,
who's
able
to
make
it
today.
I've
got
a
pretty
full
agenda
but
as
always
feel
free
to
add
topics
below.
So
we
can
discuss
them
in
more
detail
before
we
go
too
much
further.
Just
want
to
mention
that
this
is
a
kubernetes
community
meeting,
which
means
we
abide
by
the
kubernetes
code
of.
B
A
At
a
very
high
level,
that
just
means
to
be
nice
to
each
other.
So
please
do
that
if
you
haven't
had
any
issues
there
and
then
one
last
thing,
I
do
see
a
couple
potentially
new
names
or
maybe
I'm
just
bad
at
recognizing
names.
But
if
anyone
is
new
and
wants
to
introduce
themselves
I
by
all
means,
you're
welcome
to
I'll
give
a
few
minutes
now.
If
anyone
wants
to
introduce
themselves.
B
Hi
hi
everyone.
This
is
Arun
from
nutanix,
so
this
is
my
first
meeting,
oh
with
the
Gateway
API
team
and
yeah
I'm,
just
trying
to
understand
how
how
Gateway
API
is
used
and
what
are
some
of
the
the
hot
topics
of
discussion
right
now
and
see
how
we
can
use
Gateway
API
at
nutanix
in
in
the
future
right.
B
So
that's
the
the
motivation
for
joining
the
group
and-
and
hopefully
we
might
have
some
inputs
going
forward
as
to
what
we
require
or
what
the
the
direction
that
we
want
to
suggest
and
stuff
yeah
so
good
to
be
in
the
meeting
and
hope
to
join
in
future
meetings
as
well.
A
That's
awesome,
welcome
good
good
to
hear
from
you
and
yeah
we're
always
looking
for
New,
Perspectives
and
obviously
new
implementations
or
anything
else,
so
definitely
interested
in
what
you
think
and
don't
hesitate
to
ask
questions
at
any
point
throughout
this
meeting
that
goes
to
anyone.
You
can
definitely
raise
a
hand
using
zoom's
feature
or
also
just
drop.
Someone
can
chat
as
well.
A
Cool
all
right
well
great,
to
see
everyone
here.
Let's
get
right
into
our
agenda,
then.
First
up
the
meetings
next
week
are
canceled.
If
you're
in
the
US-
that's
probably
not
too
much
of
a
surprise,
but
in
the
U.S
there
is
a
holiday
weekend.
Tuesday
is
July
4th.
A
So
as
a
result,
I
expect
not
many
people
will
be
around
next
week
for
our
meeting,
so
I'm
just
going
to
go
ahead
and
cancel
them.
Of
course,
if,
if
there
are
enough
people
that
do
want
to
meet
that,
definitely
can
won't
prevent
that.
But
historically
interest
has
been
low
during
these
weeks,
so
unless
I
hear
otherwise
I'll
go
ahead
and
cancel
those
meetings.
A
A
It's
it's
still,
I
know
pretty
painful
in
some
cases,
but
it
roughly
works
for
us
and
APAC
time
zones,
but
we're
we've
also
been
experimenting
with
earlier
times
that
work
for
for
different
different
continents
as
well,
and
so
we're
considering
moving
that
to
to
rotate
similar
to
what
gamma
is
already
doing
and
also
considering
moving
away
from
Monday,
so
maybe
Tuesday
or
Wednesday,
and
maybe
similar
meeting
times
to
what
gamma
already
has
and
then
there's
also
been
some
discussion
about
Gamma
moving
to
bi-weekly
meetings,
so
very,
very,
very
much
open
to
ideas
here.
A
This
is
just
what
we've
been
sketching
out
as
a
rough
direction
for
for
when
we
might
change
meetings
and
meeting
times,
but
please,
as
always.
If
you
have
ideas,
don't
hesitate
to
to
let
us
know,
and
then
next
up,
I
just
want
to
get
right
into
the
080
milestone.
A
This
is
coming
up
awfully
quickly
and
I
just
wanted
to
highlight
what
we
still
have
in
here.
I
cleared
out
some
of
the
things
that
no
longer
exist.
I'll
highlight
some
things
shortly
that
don't
have
anyone
working
on
them
right
now,
but
as
we've
done
with
some
other
releases,
although
we
have
an
aspirational
list
in
this
Milestone,
the
only
things
that
we're
going
to
block
the
release
on
are
these
release
blockers.
A
So
right
now
we
have
a
release
blocker.
That
Mike
has
already
filed
a
PR
for
which
is
great,
and
then
we
have
a
couple
release.
Blockers
that
are
related
to
documentation
and
Flynn
is
taking
those
on
there's
not
much
else.
This
is
actually
the
release
blocker
that
Mike
is
working
on
right
now,
so
there's
not
much
else
in
progress
that
we're
considering
where
you
release
blockers.
A
There
are
lots
of
things
we
would
really
like
to
include,
though,
so
again,
if
you
have
some
exercises
this
week,
would
love
to
get
some
of
these
issues
knocked
out.
I
chatted
with
people
that
do
have
something
assigned
to
them
and
and
checked
in
on
their
progress.
I
know,
Spencer's
gonna
take
another
look
at
this
one,
but
there
are
also
some
open
ones.
A
So,
yes,
this
is
the
080
Milestone,
we're
hoping
to
get
code
complete
end
of
this
month.
So
end
of
this
week
really
and
then
begin
a
API
review
early
in
July
and
work
on
a
final
release
by
the
end
of
July.
These
are
very
approximate
if
you've
been
around
a
Gateway
API
releases
before
you
know
that
we
usually
slip
our
dates
at
least
a
bit,
but
these
are
our
aspirational
goals
for
when
this,
for
when
this
will
hit
I,
see
a
comment
in
here.
A
Yes,
please,
if
you
can
add
that
to
the
agenda,
that
would
be.
That
would
be
great,
maybe
just
drop
it
right
before
triage
I
would
like
to
talk
about
the
egress
PR
thanks
for
thanks
for
adding
it
all
right.
So
the
things
for
the
080
Milestone
here,
first
up,
there's
one
that
Mikhail
had
added
for
a
problem
that
we
have
right
now,
which
is
conformance
tests,
require
a
listener
on
Port
8080..
A
It
sounds
like
we
have
two
tests
that
have
a
listener
on
8080
right
now
and
we
need
someone
to
clean
them
up
because
right
now,
we've
basically
said
the
only
core
conformant
ports
that
are
supported
are
80
and
443,
and
anything
beyond
that
we
have
to
be
very
clear,
is
extended
support.
A
So
if
we're
using
8080
in
concert
with
an
extended
feature-
maybe
that's
okay,
but
it
should
really
only
be
a
very
intentional
Choice
when
we're
doing
that.
We
do
not
have
anyone
working
on
this
right
now.
So
if
anyone
has
some
time,
I
would
be
great
to
get
a
volunteer
on
this
one.
Just
while
we
while
we're
at
this
meeting,
anyone
have
some
cycles
that
they
could
spend
on
it.
This
week,.
A
All
right
well
no
need
to
volunteer
right
in
this
moment,
but
definitely
the
choice
of
Open
Source,
the
the
more
people
that
are
are
able
to
contribute
the
faster
we
can
move
towards
a
release.
So
would
love
to
give
this
one
sorted
out
before
we
release
080.
But
this
is
not
what
we're
calling
a
really
release
blocker
next
up
1822.
A
This
is
something
that
really
is
just
a
tiny
godoc
update.
So
if
you're
new
and
and
wanting
to
make
a
a
small
contribution
to
Gateway
API,
this
is
one
that
I'm
sure
any
one
of
us
would
would
be
very
happy
to
help
you
with.
This
is
just
making
a
a
tiny
clarification
and
the
Gateway
class
godoc.
A
A
So
that
is
something
that
no
one
is
working
on
right
now
and
again,
it's
a
really
good
place
to
to
get
involved.
I'd
say
this
is
probably
one
of
the
most
straightforward
ones
to
jump
in
on
if
you're,
new
and
looking
to
contribute.
A
Awesome
awesome,
I,
don't
know
you're
a
GitHub,
but
if
you
don't
mind
commenting
on
this
one
I'll
drop
it
in
Zoom
chat.
Yeah
would
be
great
and
and
don't
hesitate.
If,
if
anything
is
unclear
here
don't
hesitate
to
ask
in
slack
or
on
the
issue
but
yeah
thanks
for
volunteering.
B
Yeah
yeah
I
mean
I
I
need
to
figure
out
whether
I
should
use
my
official
account
or
or
my
personal,
so
I
just
clarify
that
and
and
update
on
the
on
the
ticket.
Yeah
yeah
sounds.
A
A
Well,
one
of
the
problems
right
now
is
that
you
can
specify
an
HP
route
that
looks
like
this
and
is
basically
nonsense.
Right,
because,
if
you're
redirecting
it
is
going
to
go
through
a
different
routing
mechanism
right
whatever
and
a
redirect
and
a
back-end
ref
can't
really
Coexist
on
the
same
HTTP
route
rule,
it
should
be
fairly
straightforward
to
add
some
validation
to
our
web
hook
to
prevent
this
from
happening.
A
So
there's
a
link
here
to
where
that
validation
would
be
added.
So
it
would
be
just
some
go
code
that
you
would
add
to
prevent
this
case
both
of
these
being
specified
in
the
same
route
rule
and
then,
where
you
can
add
this
to
as
kind
of
a
test
case,
to
ensure
that
your
validation
worked
as
expected.
C
Rob,
do
you
happen
to
have
the
original
indent
for
this
when
this
was
it
something
to
help
with
the
transferring
all
HTTP
to
https
kind
of
thing,
or
was
this
something
else?
Oh.
A
Yeah
yeah
yeah
I
completely
get
that
so
I
should
link
to
the
original
issue
where
this
originally
came
up
is
I.
Think
it
was.
Someone
from
nginx
actually
raised
this
as
an
issue,
maybe
I'm
getting
that
wrong.
But
somebody
raised
the
issue
that
we
do
not
have
any
Clarity
on
redirect
loop
protection
right,
so
we
don't
have
any
Clarity
today,
an
API
of
if
you
hit
a
route
and
it
says
redirect
to
HPS
and
you're
already
on
HBS.
What
do
you
do?
A
What
this
is
kind
of
saying
is
well
at
a
minimum.
We
should
just
recommend
that
you
don't
try
and
combine
a
redirect
with.
E
A
A
This
is
kind
of
tangential
to
that
redirect
loop
protection,
but
it
is
related
in
the
sense
that
this
is
a
config
that
we're
considering
invalid
and
we
want
the
the
web
validating
web
hook
to
catch
that.
So
it's
just
more
obvious
to
to
users
and
better
user
experience
than
waiting
for
a
controller
to
have
an
issue
and
published
a
link
in
status.
A
So
yeah,
if
anyone
wants
to
volunteer,
please
please
do
comment
on
this
on
this
issue,
be
another
one
that
would
be
great
to
get
cleared
up
before
we
hit
oh
well.
A
The
one
other
thing
that
I
want
to
call
out
is
that
we're
we're
really
rushing
this
080
Milestone
because
we're
trying
to
get
it
in
July
because
we're
trying
to
get
another
release
out
and
that's
1.0
in
October.
So
this
is
going
to
be
a
pretty
Express
release
cycle
for
Gateway
API.
You
know
traditionally,
there's
been
closer
to
six
plus
months
between
releases,
but
we
released
0.70
in
May.
A
0.80
is
primarily
something
like
that
exists
to
state,
but
gamma
is
experimental,
so
it's
primarily
gamma's
release,
but
we're
also
trying
to
get
some
bug,
fixes
and
other
small
additions
into
the
API
as
part
of
that.
But
then
the
big
goal
is
1.0
coming
this
fall
in
October
any
questions
about
any
of
this.
Before
we
move
on.
A
E
So
this
is
the
gap
1897,
and
this
is
a
gap.
That's
talking
about
TLS
from
Gateway
to
back
end.
E
There
are
a
few
comments
on
it
that
I
wanted
to
bring
up
in
the
group
because
they
they
seem
they're
they're,
pretty
substantial
comments
and
I
just
want
to
see
what
the
the
group
is
thinking
about
this
there
hasn't
been
a
lot
of
traffic
on
on
this
pull
request,
but
thank
you
to
everyone
who
has
provided
feedback
on
it.
E
So,
first
of
all
in
in
this
enhancement
proposal,
it's
it's
centering
on
a
new
object,
called
TLS
connection
policy,
which
already
has
a
background
in
some
of
our
some
of
the
other
docs
in
Gateway
API,
so
mostly
everybody's
familiar
with
with
the
general
format
of
it.
Do
you
want
me
to
share
my
screen,
Rob
or
yeah.
A
That
would
be
great.
Let
me
make
you
a
co-host
real,
quick
and
I'll
stop
sharing
and
it's
all
yours.
E
A
A
E
E
I,
don't
want
to
show
comments
just
so
that
we
can.
We
can
talk
about
specific
issues,
so
there
is
the
here.
Let
me
show
it
in
a
better
format.
E
So
here
is
the
TLs
connection
policy,
and
this
is
the
main
struct
that
will
be
focusing
on
going
forward.
There
were
some
requests
within
the
pull
request
to
make
sure
that
we're
recovering
mtls
in
in
this
enhancement
proposal-
and
we
we
had
sort
of
we
had
from
the
beginnings
of
the
mtls-
would
be
out
of
scope
for
this
particular
enhancement
proposal.
E
But
within
the
pull
request,
a
few
people
asked
whether
we
can
make
sure
that
we
are
providing
a
way
where
we
could.
E
Where
we
could
sort
of
have
a
path
for
mtls
going
forward,
so
what
I
wanted
to
suggest
was
that
for
mtls
we
would
add
a
mtls
connection
policy,
not
within
this
Gap.
But
you
know
in
order
to
just
be
able
to
use
the
idea
that
we've
been
using
in
TLS
connection
policy
and
create
another
policy.
That's
an
mtls
connection
policy
specifically
for
mtls,
and
by
doing
that,
we
maintain
the
scope
of
the
original
enhancement
proposal,
which
is
not
including
mtls
from
the
beginning.
E
Does
anybody
have
any
objections
to
that
or
feel
like?
We
really
need
to
do
something
a
little
bit
more
substantive
for
mtls
at
this
point
in
The,
Proposal.
C
Well,
mcilus
would
be
driven
by
the
server-side
policy
right,
TLS
policy,
if
it
forces
a
mtls,
the
handshake.
You
know
adjusts
itself
appropriately
and
from
a
Gateway
API
perspective.
We
are
the
client
side
of
the
proxy
in
this
case
right
shouldn't.
It
be
automatic
for.
E
Us
well
they're,
not
necessarily
because
Within
by
by
using
mtls,
there's
a
lot
more.
That
needs
to
be
specified
in
the
configuration
than
by
just
going
purely
with
TLS.
C
Okay,
in
that
case,
would
this
might
have
to
be
included
in
the
same
object,
because
you
know,
but
these
the
server
side
will
drive
the
connection
and
you
can
even
so
in
theory,
you
can
switch
from
TLS
to
and
TLS
in
the
in
the
middle
of
a
connection
as
well.
A
Sorry,
no
I
I
agree
with
the
ideas
there
that
I
think
what
we're
configuring
here
is.
Yeah,
like
like
you're
saying
here:
okay
TLS
from
Gateway
to
back
end
and
mtls
from
Gateway
to
backend
is
really
just
building.
A
On
top
of
that,
it's
it's
adding
a
bit
more
information,
so
I
in,
in
my
opinion,
I
I
feel
like
a
solution
here
is
to
just
just
have
the
the
small
scope
that
we
have
today,
which
is
basically
just
CA
that
that
we're
using
to
to
validate
the
cert
served
by
the
back
end.
But
again
the
Gateway
is
doing
that
validation
and
then
expand
this
in
the
future
to
include
mtls
configuration
I.
A
So
my
thought
is
that
this
can
all
fit
in
the
same
policy,
but
it
does
not
need
to
come
in
the
same
Gap
and
it
and
I
think
Canada's.
Your
primary
concern
here
is
that
you
don't
want
this
Gap
to
just
become
you
know,
overly
massive
and
and
too
big
in
scope
and
so
I
think
I'm
agreeing
that
mtls
can
be
out
of
scope
for
these.
This
initial
resource,
sorry,
this
initial
work,
but
that
we
can
and
probably
should
think
about
adding
it
in
the
future.
In
a
future
version
of
this
API.
E
Yeah
I
think
I
could
add
something
add
some
text
to
that
effect
and
and
not
worry
about
necessarily
adding
a
empty
list
connection
policy
to
replace
this
one.
Okay.
E
A
It's
yeah
actually
just
I
I
want
to
write.
You
may
not
be
able
to
see
this,
but
John
left
a
comment.
I
think
he
had
to
drop,
but
in
in
Zoom
chat.
He
left
a
comment
saying
that
you
know
the
current
model
is
basically
broken
for
mtls
due
to
attachment
and
from
his
perspective
the
attachment
needs
to
happen
at
the
client
side,
which
would
be
the
Gateway
side
in
this
case,
for
mtls
to
be
used
effectively.
A
I
feel
like
this
same
policy.
All
of
it
could
be
attached
to
gateways.
Well,
I,
don't
know
to
be
determined,
but
I
think
I
think
that's
a
very
important
detail
where,
where
you're
actually
trying
to
Target
this-
and
this
comes
back
to
the
personas-
but
just
just
wanted
to
make
sure
that
John's
comment
got
got
mentioned
at
least.
E
Okay,
yeah,
if
you
want
I'll,
just
take
the
first
two
here.
If
there's
not
enough
time,
let
someone
else
talk
for
a
while
and
then
come
back
to
the
the
second
two.
E
Okay,
so
the
second
one
that
I
want
to
talk
to
I
talk
about
was
the
choice
of
for
trusted.
Ca,
cert,
roughs
I
chose
an
array
of
secret
object,
reference
which
has
gotten
a
couple
of
different
comments
in
in
the
pull
request
about
that,
not
necessarily
being
the
right
object
for
this
first,
because
well
for
for
one
because
secret
object,
reference
contains
TLS,
key
and
TLS
cert
and
both
are
not
needed
for,
for
mtls
I
mean
so
both
are
not
needed,
except
for
mtls
and
Rob
that
you
had
suggested
a.
E
I'm
good
with
the
config
map,
I,
don't
know
how
other
people
feel
about
that.
I
did
add
another
issue
2147
for.
E
Oh
sorry,
that
that's
someone
else
is
typing
there
and
my
my
focus
went
there,
so
we
could
aim
for
an
a
different
Gateway,
API
specific
object
to
store
the
the
certificate
references
in
the
future.
E
Is
everybody
okay,
with
the
config
map
to
begin?
Is
there
are
not
enough
people
here
to
sort
of
talk
about
that
at
this
point,.
C
E
A
A
Secret
Sorry
God,
no,
you
go
ahead.
Sorry,
the
secret
object,
reference
I
think
we
specifically
say
needs
to
reference
a
secret
of
type
kubernetes
iotls,
and
that
requires
those
two
keys
that,
like
those
two
keys
in
the
secret,
app,
basically
so
yeah
that
what
what
Candace
said
there
that
we
don't
really
have
anything
to
fill
those
and
then
kind
of
at
a
higher
level.
A
C
C
Of
the
CA
bundle
that
is
traditionally
imported
into
browsers
right.
B
C
A
No,
no,
no
to
I
think
there
was
some
confusion
there
that
a
we
could
benefit
from
a
secret
object
reference
when
we're
considering
the
client
cert
that
we
use
for
mtls.
But
it's
not
useful
for
just
a
caser
that
we
have
right.
B
B
A
A
Yes,
yes,
it
does
I
I
would
love
to
see
I
think
that
there
there's
been
some
encouragement
from
segoth
for
us
to
start
using
our
own
types
to
represent
things
like
certificates
and
certainly
CA
bundles
would
would
fall
under
that
I
think
it
just
the
more
the
more
types
you
have,
the
easier
it
is
to
to
Grant
meaningful
our
back
access,
because
that's
really
the
only
thing
you
can
grant
based
on,
and
so
in
this
case,
I
think.
A
Eventually
we
would
want
to
have
just
a
very,
very
simple
kubernetes
resource
that
was
just
for
representing
this,
but
it
you
know
well,
this
is
experimental.
Well
we're
just
testing
it
out.
I
feel
like
a
config
map.
It
broadly
is
just
a
place.
You
can
add
information
that
is
considered
public,
which
is
roughly
what
I
would
consider
this
to
be
on.
Configmap
also
has
some
some
nice
utilities
like
from
file.
E
D
Yeah,
just
just
for
those
that
don't
know,
there's
also
kubernetes
creates
a
CA
cert
in
every
namespace
in
a
config
map.
So
if
you
just
say
like
git
config
maps
for
your
namespace
you'll
see
what
is
it
called
Cube
Dash
root,
Dash
ca.crt
and
that
lets
any
pod
or
deployment
workload
like
do
a
downward
API
into
your
workload.
And
then
you
can
access
the
kubernetes
API.
E
A
Thank
you
cool
and
then
from
Zoom
chat.
Mikal
is
saying,
I
I
know
I'm
saying
your
name
wrong.
So
please
correct
me.
If
I,
but
yes,
I
I,
think
it's
a
good
question.
If
too
many
result,
different
resource
kinds
to
watch
can
become
problematic.
We've
definitely
been
doing
some
thinking.
You
know,
and
by
we
I
mean
the
gke.
Implementation
of
this
API
has
been
working
on
scalability
and
doing
some
some
testing
on
that
side
as
well.
It's
not
so
much,
at
least
in
my
experience.
A
It's
not
so
much
the
number,
the
different
number
of
Kinds
you're
watching
it's
just
the
number
of
resources
themselves
that
you
need
to
get
updates
for
so
yeah
you
you
want
to
avoid
watching
things
that
are
irrelevant
to
you.
A
One
of
the
things
that
we've
been
experimenting
with
is
watching
individual
resources
as
their
referenced
or
watching
things
that
we
know
are
only
relevant
to
our
controller.
You
know
it
would
be
very
expensive.
You
can
imagine
to
watch
all
config,
Maps
or
all
secrets,
but
it
becomes
much
more
reasonable
to
watch
only
the
config
maps.
A
Are
directly
referenced
by
resources
that
you're
implementing
so
yeah
just
just
some
thoughts
there,
but
definitely
a
consideration
that
we
should
take
in.
We
should
represent
somewhere
in
our
implementation
guidelines
at
a
minimum.
E
All
right,
so
I'm,
going
to
give
back
some
time
to
other
people
who
who
I
I
feel
like
config
map
is,
is
a
is
a
not
a
bad
way
to
go
for
this
and
I
feel
like
I
kind
of
got
a
little
bit
of
support
from
the
from
the
community
so
far,
so
I'm
going
to
give
some
time
up
rather
than
get
into
these
two
topics.
E
Although
yeah
I
can
put
these
two
topics
in
the
slack
Channel,
if
we
don't
end
up
getting
it
getting
to
it
today,
but
thanks
for
the
opportunity
to
talk
about
this
for
a
little
bit.
A
Yeah,
this
is
great.
Thank
you
for
all
you're
doing
to
push
this
forward.
Yeah
I
I'm
excited
to
see
this
move.
I
know
I
know
it's
been
a
kind
of
a
slow-moving
thing,
but
I
think
where
we
actually
are
getting
close
to
something
that
we
can.
We
can
release
so
I'm
excited
about
that.
A
Let
me
make
sure
I'm
actually
sharing
the
right
thing
all
over
again
yeah.
This
looks
proximately
correct.
Everyone
see
the
agenda.
A
Awesome
thanks
all
right.
I
just
want
to
do
a
quick
little
shout
out
here,
because
I
know:
we've
had
a
lot
of
gaps
and
that
have
just
kind
of
iterated
and
gone
through
hundreds
of
comments
and
a
couple
of
them
merged
today,
I
think,
but
very
recently
anyways.
So
one
was
the
timeouts
API
and
the
other
was
routability.
A
So
a
huge
thanks
to
the
many
many
people
that
commented
and
to
Dave
and
Frank
both
for
pushing
through
you
can
see
this
started
on
January,
16
and
may,
but
these
are
multi-month
100
comment
plus
PRS
lots
of
reviewers
I.
Just
really
appreciate
the
feedback
here
and
glad
to
see
these
moving
forward.
A
Yeah
I,
don't
know
if
I
think
Dave
you're
on
the
call,
but
Frank
either
either
one
of
you.
If
you
have
next
steps
or
things
we
can
help
to
move
these
forward.
You
know,
after
the
fact
let
us
know,
but
thank
you
for
for
putting
up
with
this
insane
feedback
cycle.
D
Just
a
clarification
because
I
was
gonna,
piecemeal,
small
changes
to
change
the
code.
Anything
you
want
kind
of
like
a
big
shebang
before
the
end
of
the
week.
Is
that
later.
A
Yeah
I,
don't
know,
that's
a
good
question.
I
think
piecemeal
is
fine.
I
just
want
to
have
all
the
pieces
present.
You
know
what
I'd
hate
to
do
is
release
half
of
a
feature
right,
that's
and
because
we
have
a
release
coming
up
so
soon
I
want
to
just
before
we
merge
anything.
I
want
to
make
sure
that
all
the
pieces
are
are
visible
and
and
fit
so
we
don't
just
have
half
of
it
in
or
or
worst
case,
we
have
some.
A
You
know
some
types
moved
out,
but
then
it
doesn't
really
make
sense,
because
yeah
anyway,
but
I
I
think
what
you're
doing
of
just
doing
small
PRS
is
sensible
just
as
long
as
they
all
exist
and
fit
together.
D
A
A
Awesome
well
yeah
this
these
two
are
exciting
to
get
through
and
then
we've
got
one
other
big
gap.
Thank
you
for
bringing
this
one
up.
Egress
you
you're
on
the
call
right.
A
What
so,
what
is
the
state
of
this
I
think
this
one
has
do?
We
just
need
more
review
on
this.
F
Yeah,
so
we're
just
I
understand
that
the
last
state
it
was
for
slash
hold
put
on
Shane
was
able
to
reveal
it
and
approve
it
and
wanted
to
make
sure
that
more
people
was
able
to
take
a
look
and
I
appreciate
the
attention
that
I've
been
given
to
this
yep,
and
you
know
my
newness
to
this
process.
F
So
I'm
not
really
sure
like
if
I'm
doing
the
correct
things
to
move
it
forward
and
I
just
got
an
email
that
says
that
you
know
this
might
go
into
like
after
90
days
of
inactivity.
F
There
might
be
a
life
cycle,
of
course,
that
slash
stale
applied
to
this
Gap
or
a
whole
request
and
I
just
quickly
went
ahead
and
put
in
the
remove
My
Cycles,
still
not
realizing
that
there
was
no
life
cycle
still
tag
put
on
this
Jack,
so
I'm
a
Poe
request,
kind
of
embarrassing
but
I'm
like
oh,
my
gosh
something's,
going
on
and
it's
the
weekend.
I'll
just
suggested
later
yeah,
but.
A
Yeah
no
I
completely
understand
it.
It
is
a
not
very
friendly
part
of
kubernetes
infrastructure.
Is
that
there's
a
bot
that
goes
around
and
starts
marking
things
that
haven't
had
activity
as
Dale
and
then
there's
a
few
different
levels
and
then
eventually
closes
it.
A
If
no
activity
happens,
it
is
sadly
reflective
of
the
reality
that
there
are
more
issues
in
PRS
than
there
are
reviewers
across
the
entire
kubernetes
ecosystem,
and
so
there's
just
it
you
know,
but
it's
it's
a
very
unfortunate
right
and
and
a
confusing
State,
especially
for
people
who
are
new
to
the
process.
So
so
sorry,
no.
F
Worries
yeah,
yeah
I
just
want
to
make
sure,
because
I
know
that
we've
kind
of
been
in
the
holding
pattern
and
that's
partially
our
fault
to
just
getting
busy
with
other
things
yeah.
But
this
is
very
much
a
big
interest
for
us
to
yeah
to
keep
it
moving
along.
So
what
whatever
we
have
to
do
to
jiggle
the
handle
to
make
sure
that
you.
A
Do
it
I
think
I
think
exactly
what
you're
doing
here
of
of
just
kind
of
bringing
it
back
up
to
to
meetings
is,
is
a
kind
of
way
to
to
bring
some
visibility
back
to
a
topic,
and
this
is
I
think
if
I'm,
remembering
correctly,
you
initially
proposed
an
API
and
then
you
kind
of
pulled
back
from
it,
because
Dad
had
gotten
a
little
controversial,
and
now
you
just
have
some
kind
of
use
cases,
goals,
non-goals
and
just
trying
to
agree
on
the
problem
at
this
point.
Is
that
correct?
Yes,.
F
B
F
A
No
I
mean
I.
This
is
this
is
one
that
needs
needs
attention.
I
know,
egress
has
come
up
constantly
and
we've
needed
someone
to
move
it
forward.
Yeah.
B
A
Trying
to
you
know
right
now:
we're
we're
all
pretty
focused
on
release
and
GA,
but
I
don't
want
to
to
let
this
one
slip
too
far,
because
I
know
everyone
wants
to
do
well.
I
shouldn't
say
everyone.
A
lot
of
people
want
to
do.
Egress
with
this
API
and
I
would
hate
for
there
to
for
lack
of
an
OSS
standard
for
there
just
to
be.
A
You
know,
10
different
ways
to
do
egress
with
the
same
API,
because
I
know
like
most
of
the
pieces
are
already
there
and
you
can
just
use
it
different
ways
to
represent
that
and
I'd
love
to
have
a
standard
before
we
go
too
far.
A
E
I
was
just
I
wanted
to
suggest
that
to
do
a
survey
of
implementations
and
see
if
anybody's
already
doing
egress,
like
does
istio
already
do
egress,
because
I
think
when,
when
I've
introduced
topics
in
the
past
I
there
are.
You
know,
representatives
of
the
implementations
as
part
of
the
group
that
that
want
to
see
how
others
are
doing
it.
If
it's
the
same
as
they're
doing
it,
and
if
your
proposal
takes
into
account,
you
know
any
prior
art,
or
you
know,
implementation.
F
Yeah,
that's
a
great
point,
and
maybe
that's
just
yeah.
Just
maybe
I
didn't
do
the
due
diligence
of
polling
or
searching
or
Scavenging
for
implementations
out
there,
so
yeah,
okay,
I
will
definitely
make
that
as
a
note
too,
because
there
is
a
note
that
if
there's
only
one
more
than
sorry
so
there's
a
note
from
Shane
that
says,
if
we're
unable
to
find
more
than
one
implementation,
that
would
want
this
kind
of
functionality.
You
know
this
might
jeopardize
the
Gap
become
declined
right
and
so.
E
D
F
E
A
Absolutely
does
that
yeah
thank
you
for
bringing
that
up.
Candace,
it's
it's
such
a
a
good
thing
that
has
happened
in
our
recent
gaps
and
I
would
love
to
see
it
happen
more
and
that's
absolutely
a
great
way
to
bring
more
people
into
this
when,
when
other
implementations
see
oh
here's,
how
our
API
relates
to
this
thing,
that's
being
proposed,
it
automatically
brings
you
know
more
interest
in
and
I
think
there's
a
lot
of
egress
representations
out.
A
So
if
you
look
at
the
timeouts
Gap,
if
you
look
at
the
session
persistence
Gap
and
if
you
look
at
the
TLs
Gap
that
Candace
is
working
on
those
ones
come
to
mind
as
ones
that
did
very
well
at
defining
the
the
status
quo
of
of
other
apis
out
there,
and
you
don't
have
to
do
everything
like,
for
example,
the
timeouts
Gap
tried
its
best
I,
think
Nick
tried
his
best
to
you
know,
understand
what
others
are
doing,
but
very
much
one
of
those
things
where
implementations
came
through
and
corrected,
as
they
saw
things
that
weren't
quite
right
and
that's
I.
A
Think
that's
exactly
what
we
want
to
have
happen
here
and
it's
also
very
helpful
for
reviewers
to
see
to
understand
the
full
state
of
the
world
as
we're
looking
at
a
gap
and
trying
to
build
an
API
that
works
for
as
many
of
those
as
possible,
so
yeah
that
that's
absolutely
a
great
Next
Step
and
another
thing
that
that's
not
particularly
controversial.
It's
just
really
helpful
for
laying
the
the
Grain
groundwork
and
foundation
for
everything
that
comes
after.
F
Okay,
that
makes
sense
we
were
thinking
like
do.
We
need
to
and
not
really
name
names
or
drop
some
names
to
other
people
that
have
expressed
interests
anyways,
we
weren't
sure
what
was
how
do
we
make
sure
that
other
people
are
interested
or
say
that
they
are
interested
parties.
A
Yeah
now
that's
a
good
question:
I
think
it
kind
of
comes
almost
I,
wouldn't
say
for
free,
but
by
by
listing
implementations
of
the
API
and
how
they
and
that
they're
already
implementing
similar
functionality
with
their
own
vendor
specific
apis.
It
almost
assumes,
but
certainly
communicates
that
there
would
be
interest
from
from
them
in
representing
this
further
there's,
maybe
a
better
way
to
do
it.
But
that's
that's
a
really
good
starting
point
at
least
and
I.
A
So
you
know
circulating
this
concept
in
gamma.
Meetings
which
are
on
Tuesdays
right
now
could
be,
could
be
really
helpful
as
well
just
to
gauge
interest.
F
Okay
should
I
I
guess
maybe
I
guess
I
could
attend
those
as
well
I
think
some
of
our
team
members
deal
with
them
that
I
do
not.
A
Yeah
it
just
it's
an
open
meeting
like
this.
Usually
the
agenda
is
pretty
light,
so
yeah
definitely
very
welcome
to
to
add
this
to
the
agenda
and
just
see
who's
interested
I
I
expect
most,
if
not
all,
mesh
vendors
are
going
to
want
some
way
to
represent
egress,
so
that
may
be
one
of
the
best
places
to
find
both
prior
art
and
interested
collaborators
on
this.
Okay.
A
Well,
thanks,
thanks
for
raising
this
sorry
was
there
anything
else.
A
That's
that's
pretty
common
I
I
understand.
Actually
one
of
one
of
our
maintainers
Nick
will
also
be
out
for
a
few
weeks
and
so
yeah
I
it
it's
summer.
I.
A
It's
completely
fine
I,
understand
vacations
are,
are
good
and
necessary,
so
yeah.
F
A
F
A
Right,
yeah
next
up,
I,
okay,
this
was
all
part
of
the
same
thing,
all
right
great.
The
next
one
I
just
wanted
to
highlight
was
triage.
We've
got
a
few
PRS
in
here
that
could
use
some
review.
A
First
up
is
Mike's
PR,
which
is
a
release
blocker,
so
one
of
the
most
important
ones
out
there
right
now,
so
it's
documenting
parent
ref
functionality
for
gamma.
Now
that
gamma
is
finally
considered
experimental,
it
means
we're
releasing
something
we're
releasing
a
version
of
the
API
that
officially
contains
support
for
the
gamma
way
of
doing
things.
A
So
that
means
we
need
to
update
the
API
spec
and
describe
what
that
you
know
and
update
it
to
under.
So
it's
clear
how
gamma
and
mesh
implement
the
API
as
well
so
Mike
took
an
initial
go
at
this.
I
am
overdue
to
actually
review
it
myself,
but
I
think
at
least
Keith
has
already
reviewed
part
of
this,
and
and
please
you
know,
this
is
a
pretty
big.
You
know,
although
the
pr
itself
is
actually
now,
the
PRS
itself
is
fairly
large
now
too,
but
please
yeah,
okay,
mostly
generated
okay.
A
Thank
you,
but
thank
you.
Mike
for
taking
this
one
on
and
because
it
is
such
an
important
one,
if.
B
A
G
I
think
the
biggest
thing
I'm
looking
for
is
any
areas
that
folks
have
thought
of
that
need
to
be
updated
for
gamma
that
are
other
than
just
the
route
parent
ref
stuff.
So
that's,
although
I'm
really
trying
to
address
in
this
PR,
but
if
there's
like
additional
scope-
or
there
should
be
a
separate
PR
to
update
other
parts
of
the
API
docs
for
gamma-
would
definitely
love
folks
to
bring
that
to
our
attention.
A
Cool
thanks
a
bunch
for
for
taking
this
one
on
yeah,
I
I
will
continue
to
try
and
think
of
other
places.
It
feels
like
we're
missing
something,
but
you
know.
Hopefully
this
really
is
all
there
is
yeah.
A
Okay,
then,
next
up
we
mentioned
before
that
the
timeout
Gap
had
merged.
So
big
thanks
to
Frank
for
his
patience
and
pushing
through
on
that
one
and
then
in
parallel
somebody
was
working
on
an
implementation
of
that
Gap,
which
is
awesome.
So
if
anyone
wants
to
review
this,
the
Gap
is
actually
largely
implemented.
A
I
think
at
this
point
and
needing
a
review
yeah,
so
I
think
this
really
just
needs
some
people
to
to
take
a
look,
make
sure
it
matches
up
with
The
Gap
and
if
you
haven't
paid
that
much
attention
to
the
Gap.
Please
pay
attention
to
this,
because
this
means
it
would
enter
the
API
as
experimental,
potentially
as
early
as
080,
which
is
a
pretty
quick
turnaround.
A
So
yeah
just
don't
miss
this
one.
Timeouts
are
a
pretty
big
deal
so
yeah,
then
the
very
last
one
that
I
wanted
to
highlight
is
there
have
been
some
issues
where
reference
Grant
reference
grants
are
difficult
to
implement
and
if
you
do
it
even
slightly
wrong,
you
can
get
into
trouble.
So
this
is
a
really
great
set
of
tests
where
they're
adding
a.
B
A
Of
invalid
reference,
Grant
examples
and
basically
showing
you
every
possible
way,
it
could
be
done
wrong
and
ensuring
that
none
of
them
are
effective
in
granting
access.
So
I
think
this
is
a
really
great
addition.
I
just
would
appreciate
a
few
implementations
actually
taking
some
time
to
test
this
out
before
we
merge
it
in
I.
A
Think
at
this
point,
Sunjai
has
added
some
comments
and
and
found
an
issue
when
you're
running
tests
I
think
that's
it
and
yeah,
but
otherwise,
please
any
any
additional
feedback
is,
is
very,
very
welcome
on
this
one,
hopefully
hoping
to
get
this
one
into
080
as
well:
yeah,
okay!
Well,
that's
all
I've
got
on
the
agenda
any
last
things,
or
should
we
call
it
good
for
today's
meeting.
A
All
right
well,
thank
you.
Everyone
we'll
see
you
in
two
weeks
and
enjoy
some
time
off
next
week.
If
you
get
it
and.