►
From YouTube: Gateway API GAMMA Meeting for 20230214
Description
Gateway API GAMMA Meeting for 20230214
A
A
A
Folks
can
see
this
so
last
video
we
spent
most
time
going
over
the
the
milestone
for
gamma
and
working
on
getting
cast
assigned
and
just
kind
of
trying
to
burn
down.
What
do
we
have
left
that
we
want
to
do
before
the
Gateway
API
is
zero,
seven
release
and
the
intent
of
that
release
is
to
submit
gamma
for
its
first
formal
API
review
from
Sig
network
with
yours.
A
It's
had
an
informational
only
review
previously
during
the
zero
six
zero
release,
but
this
would
be
kind
of
like
the
next
step
of
that
of
we
want
to
formally
publish
gamma
as
part
all
of
Gateway
API
in
mixed
metal,
Channel,
so
yeah.
This
is
where
we're
at
with
Milestone.
We've
got
a
lot
of
the
big
stuff
in
we've.
A
A
B
A
Eastern
3
P.M
West
Coast
time
on
alternating
weeks,
so
it
sounds
like
a
Gateway
API
is
going
to
attempt
to
do
something
similar
I
think
Shane
wants
to
talk
about
that
later
in
the
agenda
and
yeah
and
last
topic
was
about
kubecon.
Hopefully
we'll
try
to
get
some
folks
here,
specifically
at
folks
who
are
able
to
attend
this
meeting.
I'm
assuming
will
be
more
likely
to
be
present
at
kubecon,
euh,
so
yeah.
A
C
Yeah
I
can
add
a
couple
notes
if
you're
able
to
make
it
to
kubecon.
Obviously
we
love
to
meet
up.
There
is
the
contributor
Summit,
which
I
think
this
time
is
the
Tuesday
before
the
rest
of
the
conference
starts.
So
usually
the
requirement
I
think
that's
the
same.
This
time
is
to
be
a
kubernetes
six
or
kubernetes
org
member
on
GitHub.
C
If
you've
been
active,
contributing
in
any
way
to
this
this
project,
we
can
help
get
you
there
and
so
I've
always
found
a
career.
Some
are
very,
very
helpful,
and
last
year
some
of
us
were
able
to
meet
up
just
kind
of
an
informal
working
session
of
sorts
in
person.
I
again
it's
hard
to
predict
attendance
this
year,
but
if
anyone
is
able
to
make
it,
it
would
be
great
to
have
kind
of
a
small
in-person
working
session
as
well.
So
definitely
don't
hesitate
to
reach
out.
B
B
C
C
So
it
was
but
yeah
that
would
be
really
helpful.
I
I
agree,
maybe
even
just
I
think
one
of
the
most
helpful
things
would
be
getting
a
list
of
people
who
think
they'll
be
around
so
far.
I
haven't
gotten
too
many
responses,
but
if
we
can,
if
we
can
get
that
list
somewhere,
maybe
maybe
mentioned
in
slack
or
something
like
I,
don't
think
there's
going
to
be,
maybe
I'll
send
a
message
in
slack
and
people
can
respond
there
because
I
don't
know.
B
D
B
A
F
Conflicts,
it
does,
but
just
if
you
don't
make
it
to
this
one,
it
doesn't
necessarily
mean
that
we
won't
try
a
couple
more,
but
I
get
the
I
get
the
impression
we're
gonna
have
a
pretty
good
turnout
for
it,
either
way.
So
just
yeah,
just
even
just
saying,
you're
adding
your
support
if
you're
not
going
to
be
there
like
put
your
name
on
the
meeting,
notes
and
saying,
like
I
couldn't
be
here,
but
I
really
want
this
time.
That's
fine,
too
yep.
A
A
D
B
A
C
Yeah
I
yeah,
I,
I
I,
completely
agree.
I
forgot
how
lacking
our
documentation
is
for
this
yeah.
This
is
this
is
one
of
those
things
where,
if
you
didn't
know
any
better
you
you
would
think
we
hadn't
done
anything,
because
this
this
documentation
is
the
same
as
it
was
when
we
we
first
started
the
working
group.
C
C
You
know
initiative
that
it
could
have
its
own
Tab
and
we
can
certainly
reference.
You
know
if
you
look
in
our
reference
docs
right
now
we
have
a
list
of
gaps.
We
could
have
the
same
gaps
listed,
but
just
in
the
in
the
context
of
gamma,
so
anything
that
touched
gamma
could
be
under
the
gamma
tab
as
well.
B
A
Yeah
yeah
I
think
well,
there's
we
haven't
had
this
yet
is
because
when
we
first
started
this
it
was
very
much
exploratory
and
it
wasn't
something
we
felt
necessarily
ready
to
commit
to.
But
it
feels
like
we're
approaching
a
point
where
this
is
the
thing
that
we
want
to
do
and
we
want
to
make
it
known
and
yeah
get
more
folks
involved.
So
definitely
I
appreciate
the
feedback.
A
D
F
F
A
D
A
A
C
D
D
C
D
C
A
G
This
is
the
one
here:
I
I
do
have
a
one
question:
I'm
just
curious
any
discussion
on
the
target
of
the
you
know
the
HTTP
route.
These
things
has
it
this
kind
of
thing
to
come
up
before
how
people
normally
do
it?
And
today,
let's
say
you
know:
if
we
map
to
into
look
at
any
ALB
or
you
know
NLB,
will
you
know
AWS,
you
always
have
the
concept.
You
can
always
house
check
the
target.
G
C
Yeah
I
think
it's
probably
most
similar
to
what
we're
doing
on
gke,
because
we
have
a
similar
thing
where
our
load,
balancer
health
checks,
are
not
the
same
thing
as
kubernetes
health
checks
at
least
today,
and
so
what
we've
done
is
we've
created
a
policy
for
that.
It's
a
health
check
policy
and
it
just
enables
it
Maps
pretty
pretty
closely
to
what
can
be
configured
with
cloud
apis
and
we're
just
allowing
it
to
be
configured
with
gcp
apis
and
attached
to
one
of
our
gateways.
G
C
G
C
A
that's
a
good
point,
I
think.
Actually,
where
we've
attached
it
is
per
backend,
so
attaching
it
to
service,
but
I'd
have
to
double
check
on
where
we've
attached
it,
but
it
it
attaches
at
one
level
only
that
doesn't
support
any
kind
of
hierarchical.
You
know
defaulting
or
anything,
and
it
basically,
you
know
it
Maps
very
closely
to
our
Cloud
apis.
So
wherever
you
would
attach
a
health
check
using
those
apis
is
largely
where
we've
added
our
health
check
policy.
A
I'm
just
curious,
I
I
think
that's
an
interesting
discussion,
because
we
don't
have
anything
really
like
documented
or
written
about
that
anywhere
in
terms
of
health
checks
with
Gateway
yeah.
So
I
I
would
be
interested
in
hearing
more
from
implementers
about
how
your
work
got
problem.
But
that
seems
fine
if
it
is
out
of
the
scope
of
what
should
be
within
the
spec.
C
Yeah
that
that's
a
good
point,
you
know
we,
or
at
least
I,
had
thought
that
Health
custom
health
check
configuration
is
something
that
would
really
benefit
Cloud
providers,
but
maybe
not
as
clear
benefit
for
in-cluster
providers,
but
I.
Maybe
I've
missed
that
and
it's
more
broadly
useful,
and
if
it
is,
maybe
we
should
consider
something.
That's
more
generic
and
built
in
I
know.
We
had
earlier
discussions
yeah
year
plus
ago
about
some
kind
of
standardized
Health
checking,
and
that
was
you
know
in
addition
to
timeouts
we
looked
at.
C
Is
there
a
standardized
way
of
Health?
Checking
that
you
know
lots
of
implementations
can
support
and
there
was
more
variation
than
I
would
have
liked.
It's
one
of
those
things
where
I
think
there
were.
There
was
a
common
core,
and
then
there
were
you
know
all
these
add-on
little
bits
that
were
hard
to
represent
I'm,
not
sure
what
that
looks
like,
but
certainly
interested
in.
You
know
if
there's
more
implementations
out
there,
that
would
benefit
right.
G
G
So
my
question
is:
is
it
good
enough
say,
for
example,
if
you
have
HTTP
route,
if
the
health
check
flee
just
check,
if
I
can
establish
TCP
three-way
handshake
with
it
with
a
part,
I
would
consider
it
healthy
and
let
the
kubernetes
are
health
check.
The
livenessness
Deep
health
check,
the
the
pot
just
have
these
two
things
together.
Would
that
be
good
enough?
Yeah.
C
Cool
no
I
think
the
ultimate
source
of
truth
would
be
the
pods
Readiness
like
you're
describing
like.
Ideally,
we
should
just
read
the
information
that
kubernetes
health
checks
are
already
providing
us
and
work
with
that.
I
recognize
that's
not
always
possible,
but
that
feels
ideal.
I
know
there
are
some
implementations,
like
you
know,
gk's
old,
Ingress
implementation.
We
tried
to
derive
a
custom
health
check
by
default
by
reading
the
kubernetes
Readiness
probe
configuration.
C
A
B
I
know
also
that
lincolny
has
looked
at
this
to
figure
out
the
right
way.
To
summarize
this
one
looked
at
this,
not
just
from
the
perspective
of
custom
health
checks
and
such,
but
also
from
a
perspective
of
looking
at
the
way
the
Gateway
API
is
talking
about
routing
decisions
and
looking
at
things
like
okay.
B
So
if
you
have
something
that
has
two
back
ends
and
one
of
them
is
dead,
then
you
know
we
should
be
able
to
figure
out
that
one
of
them
is
dead
and
just
route
to
the
other,
one
which
I
think
actually
conflicts
with
a
very
literal
reading
of
the
spec
in
some
ways.
So
that
can
get
to
be
a
little
interesting
as
well.
B
C
So
I
think
our
goal
with
that
spec
and
should
double
check
but
I
think
our
goal
with
that
spec
is
in
the
world
where
we're
traffic
splitting
and
someone
has
two
services
and
they've.
Both
they've
said
both
should
get
50
and
one
service
has
no
endpoints
available.
We
should
not
send
50
of
like
all
traffic
to
the
other
service.
C
We
should
five
up
5xx
the
traffic
split,
the
end
points
whether
or
not
that's
correct,
but
what
I
want
to
clarify
for
sure
is
that
I?
Don't
think
anyone
had
the
intention
that
if
you
have
two
endpoints
behind
the
same
service
and
one
is
not
healthy,
you
should
you
should
just
send
it
to
the
healthy
endpoint
for
sure,
like
that,
yes,
I
think
that's
not
even
even.
B
C
Yeah
I
I
get
that
and
I
I
see,
there's
room
for
improvement
there
I
think
there
are.
You
know
when
we
were
writing
that
that
part
of
the
spec
I
we
had
a
real
focus
on
this
idea
that
if
we
were
going
to
fail,
it
wanted
to
fail
quickly
and
visibly
yeah
right
so
that
if,
if
somebody
made
a
change
and
their
config
wasn't
working,
it
was
obvious.
C
B
And
you
know,
that's
I
mean
that's
going
to
happen,
of
course,
so
yeah
for
sure,
but
sorry
I
didn't
particularly
want
to
derail
this.
With
that
specific
issue
too
much
I
was
more
just
bringing
it
up
in
the
context
of
we
have
done
some
reading
and
some
thinking
and
things
there,
where
yeah
some
sort
of
ability
to
talk
about.
How
shall
we
determine
whether
these
services
are
healthy?
How
should
we
determine
whether
a
back-end
is
healthy
and
things
like
that
right?
C
Yeah,
definitely,
and
if,
if
you
ever
run
into
some
some
weird
part
of
the
spec
that
you
know
we
just
haven't
thought
about
for
a
while
I
definitely
would
recommend
an
even
a
request
that
you
create
an
issue
just
so
we
can.
You
know
hey
that
thing
that
made
sense
a
year
ago.
Maybe
we
should
reconsider
it.
Yeah.
D
E
No,
the
the
health
checking
one
that
that
was
just
discussed
is
something
interesting
to
me,
because
it
feels
like
one
of
those
parts
of
the
Upstream
Upstream
game,
API,
spec,
that
what
were
the
I
guess
for
the
desired
Behavior
and
the
goals
are
a
little
bit
at
odds
with
how
we
typically
do
things
in
the
mesh
World
failing
quickly,
and
what
was
the
second
word.
Obviously
I
forget
what
the
second
part
of
that
description,
that
you
said
Rob,
but
that's
typically,
not
what
customers
are
wanting
from
their
mesh.
E
B
Now
you
you,
it
does
kind
of
depend
on
what
the
failure
is
right.
If
you
just
blatantly
misconfigured
something
then
yeah
failing
quickly
and
transparently.
It
obviously
is
a
great
thing
if
one
of
your
service
endpoints
goes
away.
Maybe
it's
not
such
a
great
thing
right,
they're,
two,
pretty
different
failure,
modes
or
failure,
situations
right.
E
Some
things
like
that
a
couple
of
times
I'll
go
back
and
try
to
find
them,
but
it
might
I.
Don't
know
there
are
things
where
you
know:
ingresses,
don't
typically
do
things,
but
measures
are
expected
to
do
things
from
a
user
experience
perspective
and
it
might
be
interesting
to
kind
of
have
a
I,
don't
even
know
what
I'm,
what
I'm
not
proposing
anything
yet
I'll
I'll
do
some
more
thinking
about
it,
but
yeah
interesting
topic
for
sure.
B
If
anybody
knows
the
way
we
schedule
stuff
on
the
contributor
day,
that
would
be
nice
to
hear
about
I.
Think
I'm,
also
on
the
hook
to
talk
a
little
bit
about
some
of
the
points
of
friction
that
Linker
you
ran
into
next
week,
so
that
we
can
make
hopefully
make
sure
that
Nick
is
around
to
Heckle
I
mean
to
offer
his
opinions.
B
B
C
Yeah
I
was
on
that
note.
I
was
just
having
a
discussion
with
Shane.
The
main
gateway
API
meeting
falls
on
President's
Day
in
the
US,
which
not
everyone
will
be
working
on.
So
we're
trying
to
figure
out
who
will
be
around
we'll
probably
have
some
kind
of
question.
In
slack
just
to
gauge
potential
attendance.