►
From YouTube: Gateway API GAMMA Meeting for 20230321
Description
Gateway API GAMMA Meeting for 20230321
A
Hello,
everybody
welcome
to
the
March
21st
occurrence
of
the
Gateway
API
gamma
meeting.
As
a
reminder,
this
meeting
is
governed
by
the
kubernetes
code
of
conduct,
so
please
be
respectful
to
everybody
both
here
in
the
meeting
and
in
general,
because
that's
a
good
thing
to
do.
We
have
an
open
Agenda.
That
agenda
is
in
the
in
the
zoom
chat
here.
A
If
you'd
like
to
contribute
at
a
topic,
something
you
want
to
discuss,
then
we
will
get
to
that
as
we
go
through
also
as
a
kind
of
housekeeping
matter.
We
like
to
track
the
attendance
of
those
who
are
able
to
make
it
to
our
meetings.
So
if
you
would
go
to
that
agenda
link
and
put
your
name
and
organization
there,
that'll
just
help
us
make
sure
that
our
meeting
times
are
as
inclusive
as
possible.
A
We
currently
break
our
meetings
into
two
one,
with
a
kind
of
a
early
U.S
time
and
a
later
ux
time
to
try
to
make
sure
many
people
can
attend
as
possible
for
the
gamma
meetings.
So
your
attendance
record
helps
us
be
able
to
gauge
that
I'll
jump
in
before
I
get
into
our
main
agenda.
I'll
jump
into
our
recap
in
case
you
happen
to
miss
the
last
meeting.
A
The
first
topic
we
talked
we
chatted
about
was
Max
and
Flynn
gave
a
had
a
discussion
about
their
investigation
into
Gateway
mesh
interactions.
That's
one
of
the
things
that
we're
looking
to
try
to
Shore
up
before
we
have
a
formal
release
of
the
of
the
gamma
spec
there's
there
that's
been
a
work
in
progress
for
a
while,
but
we
are
expecting
some
changes.
A
You
can
either
do
round
to
the
front
end
to
the
IP
cluster
IP
for
that
service,
or
you
can
use
the
back
end
and
the
kind
of
guiding
principle
for
that
discussion
has
been
what's
the
least
surprising
thing
going
to
be
for
for
users
and
we've
discussed
some
of
the
options,
but
the
actual
changes
to
be
made
and
add
to
the
spec
are
are
yet
to
be
determined,
Flynn,
Mac
you're.
Both
here
do
you
want
to
add
anything
to
the
recap
here.
B
I'm
sad
to
have
to
admit
that
I
have
been
heads
down,
doing
content
for
what
feels
like
half
a
dozen
different
things
that
are
all
happening
next
week.
So
I
have
been
able
to
do
absolutely
nothing
about
this,
except
for
a
long
and
interesting
discussion
with
Daniel
around
that
hit
on
some
of
this
stuff
and
I
see
that
Daniel
has
commented
that
he
also
has
feedback
on
this.
C
Not
much
suspense
I
was
largely
focused
on
Rob's
topic
later
in
the
agenda
for
the
past
week,
but
yeah
kind
of
like
as
a
preview,
though
we
are
looking
at
prior
art
where
Ingress
supported
both
endpoint
routing
as
well
as
kind
of
like
best
aware
routing.
So
it's
potential
it's
possible
that
we're
going
to
explore
like
how
can
we
configure
one
or
both
options,
rather
than
forcing
an
exclusive
only
one,
because
they
kind
of
both
have
their
merits?
A
If
James
got
some
feedback
here,
so
I'll
move
on
to
the
the
next
topic,
since
that's
just
the
recap,
if
anybody
has
thoughts
here,
prefer
to
add
them
to
the
agenda
or
open
a
GitHub
discussion
in
your
chat
and
slack,
we
had
070
Milestone
checkup.
Our
kind
of
our
soft
goal
has
been
to
try
to
get
your
API
or
sorry
gamma,
part
of
the
spec
release
formula
API
and
the
070
release
we
felt
like
after
talking
with
Mike
and
Flynn.
A
So
Daniels
thanks
for
creating
the
issue,
although
I've
been
involved
in
get
AP
access,
prompt
exception,
I'm
also
been
new
to
gamma
I
can
the
content
of
a
route
having
a
parent
rep
and
back
and
rep
to
the
same
service
quite
confusing
I'm
concerned.
Future
users
will
feel
the
same
as
their
big
considerations
for
adding
a
backing,
a
field
to
back
and
ref
that
can
be
used
to
further
segment
a
back-end
ref.
Oh,
that
is
an
interesting
idea.
Daniel
do
you
want
to
add
some
more
context
to
this.
D
Yeah
yeah
thanks
for
the
time
to
to
discuss
this
comment
so
again,
I'm
kind
of
coming
at
this
as
a
new
user,
so
appreciate
all
the
time
that
you
know
the
community
has
spent
trying
to
you
know,
evolve.
Gateway
API
for
the
mesh
management
use
cases
I'm.
Also
relatively
new
to
service
meshes
well.
I
got
involved
in
istio
early
on
then
how
to
do
other
things
and,
and
now
more
recently
getting
involved
in
istio
for
for
istio
and
ambient
mesh
and
with
that
said,
is
I've.
D
D
So
typically
that
back-end
reference
is
a
service,
but
if
I
want
to
do
a
canary
where
I
have
hey
here's
my
service
Foo,
but
that
service
Foo
has
two
different
deployments.
V1
and
V2
and
I
now
want
to
you
know,
do
a
canary,
where
I'm
sending
90
of
the
traffic
to
V1
deployment
and
10
to
V2
all
right
everything's.
Looking
good.
Now,
let's
switch
the
weights
even
with
you
know,
gamma
sides.
D
If
we,
if
we
look
at
the
back
end,
rests
a
back-end
ref
does
not
have
that
kind
of
concept
and
I
just
wanted
to
kind
of
throw
it
out
there
of
like
you
know
who
do
we
attach
some
other
field
that
allows
us
to
flexibly
sub
segment,
that
back
end
rough
and
in
the
example
I
kind
of
provide
is
either
a
label
or
if
we
want
to
do
something
more
generalized,
maybe
it's
metadata
and
it
could
within
metadata.
We
could
support
labels
initially
and
then
expand
that
metadata
field.
E
D
D
Link
is,
is
my
understanding
is
that
the
route
has
a
parent
ref
of
a
of
a
service
and
a
back-end
ref
of
the
same
service
and
and
so
I
find
that
confusing,
and
my
understanding
is
that
is
done
in
a
way
that
allows
this
kind
of
sub
segmentation
of
a
back
end
like
in
this
example
we're
right
where
we
have
the
food
service.
But
there's
like
two
versions
of
the
food
service.
E
G
E
Is
really
that
service
has
two
parts
and
we're
splitting
that
more
explicitly
here
so
I'm
not
sure
like,
even
if
we
added
like
subsection
in
the
back
end
ref,
for
example,
and
fuzzy
on
the
details
of
how
that
works.
But
you
know
I'm
sure
we
can
find
a
way.
We
still
need
something
as
the
parent
ref
to
bind
to
to
actually
match
the
traffic
right.
So
it
doesn't
seem
like
that
alone,
solves
the
problem
of
the
confusion
between
the
service
use
in
two
places.
D
Right
in
this
particular
example,
it's
you
know
sending
a
certain
amount
of
traffic
to
one
version
of
a
service
and
another
amount
of
traffic
to
another
server.
So
keeping
consistent
with
the
route
would
have
a
parent
ref
of
a
Gateway
and
a
back-end
ref
of
a
service
and
then
using
some
new
field
labels
or
metadata
to
sub
segment.
That
traffic
that's
being
forwarded
so
yeah.
H
H
How
things
can
work
and
different
use
cases
that
I
can
see
yeah
and
like
the
problems
that
I
saw
I
think
it
has
been
pretty
useful
for
everybody,
so
yeah
the
basically
this
is.
This
is
sort
of
all
the
things
I
see
that
are
a
little
weird
about
it.
I
do
think
that
the
the
point
that
everyone
has
been
making
is
that
when
you're
using
a
service
mesh,
currently
people
expect
the
service
the
kubernetes
object
to
be
the
service.
H
That
is
talking
that
you're
talking
about
in
service
mesh
and
so
there's
a
very
strong
sort
of
user
expectation
for
mesh
users
that
the
service
is
the
thing
around
which
the
API
spins
yes
and
I.
Think
that
that's
the
that's
the
reason
why
you
know
I
said
basically
very
most
of
what
you
have
just
said
previously
many
times
I'm,
pretty
sure
everyone
got
tired
of
hearing
me
say
it
and
so
like
what
I
just.
H
Think
all
of
those
things
like
are
possible
options,
but
none
of
them
have
the
sort
of
the
the
usability
advantages
of
of
just
using
the
server
subject.
I
hate
overloading
the
service
object
more.
As
I
said
on
a
number
of
cases,
I
think
that
the
Upstream,
the
the
sign
Network
reviewers,
are
going
to
sort
of
feel
a
bit
the
same
and
so
like
what?
What
I?
H
That's
that's
sort
of
I
wanted
to
give
you
like
a
rough
catch
up
because
yeah,
like
everything,
you're
saying
like
is
I,
think,
is
completely
reasonable
and
we
have
talked
about
it
before
so,
but
yeah
you're
catching
up
so
I'm
trying
to
help
you
catch
up
as
fast
as
possible.
So
yeah
have
a
look
at
that
diagram.
B
Honestly,
I
was
just
kind
of
waiting
to
to
see
how
quickly
you'd
put
your
hand
up
on
that
one.
The
sub
segmenting
thing
and
the
idea
that
you
could
use
something.
That's
not
a
service
as
a
back-end
ref
is
something
that
has
been
discussed
at
least
a
bit
within
buoyant
around
the
idea
that
maybe
it
would
make
sense
to
have
something
that
I'll
just
call
a
topology
resource.
Where
you
know
it's
not
a
service,
it
describes
a
relationship
between
services
and
could
talk
about
Concepts
like
doing
a
canary
doing
traffic
mirroring
doing
traffic.
B
Splitting
doing
you
know
other
things
like
that,
so
that
concept
is
something
we've
kicked
around
a
bit.
It
has
not
gotten
to
a
point
that
we've
had
anything
concrete
to
propose
around
it,
but
I
I
would
tend
to
emphasize
what
Nick
had
said
earlier
to
the
tune
of
one
of
the
major
decisions
that
came
out
of
all
of
the
the
beating
of
dead
resources
or
dead
horses.
From
back.
B
A
Yeah
I
think
everybody's
done
a
really
good
job
of
giving
some
some
context
here.
I
wanted
to
add
to
Just
note
a
couple
of
short
a
couple
of
resources
that
I
think
might
be
helpful
and
understanding
yeah
even
more
context.
Daniel,
so
is
the
other
gap
that
you're
talking
about
for
service
mesh
and
Gamma.
It's
less
so
I'll
get
more
so
of
like
a
initial
well
together,
but
it's
a
what
and
why
for
service
measure,
Gateway
API.
A
This
was
the
result
of
a
lot
of
definitions.
The
Gateway
API
leads
were
very
helpful
and
asked
us
to
kind
of
get
some
straight
vocabulary
together
about
what
we're
referring
to
when
we
use
these
words
they're
at
one
point,
there's
a
document
and
we
had
like
100
uses
of
the
word
service
and
that
used
yeah,
four
or
five
different
definitions.
A
Each
time
we
use
the
word
service,
and
so
this
whole
service
front
end
service
backend
has
been
kind
of
one
of
the
foundational
definitions
and
then
in
Concepts,
in
the
gamma
stack
and
so
I.
Think
reading
through
this
service
section
will
be
super
helpful
in
understanding
kind
of
how
what
the
difference
is
between
the
parent,
ref
invocation
of
a
service
versus
the
back
and
draft
indication
of
the
service,
and
the
second
thing
that
I
want
to
share
is
the
alternative,
considered
section.
A
A
You
know
if,
if
we
ever
have
to
choose
something
different,
we'll
we'll
start
with
this
alternative
considered
section
and
think,
is
this
really
is
this
drawback
really
as
bad
as
we
thought
it
might
be
I'm?
Actually,
in
the
middle
of
doing
a
clarification
gap
for
binding
and
might
take
some
of
these
things
into
consideration,
but
I
want
to
try
to
close
time
boxes
a
little
bit.
I
might
go
ahead.
C
So
I
hope
that
that's
something
that
would
be
considered
if
and
when
that
effort
moves
forward,
but
I
I
think
it
would
be
unlikely
to
be
able
to
make
a
good
case
for
getting
that
in
now.
Considering
it's
like
it's
a
ux
simplification
over
I
think
it's
possible
rather
than
something
that
is
not
possible.
Currently,.
B
B
A
I
No
I
I
have
some
some
experience
with
going
through
this
process
and
whether
it's
good
or
bad,
it's
experience,
I
I,
would
say
yeah,
there's,
there's
interest
in
Upstream
of
splitting
out
service.
There
always
has
been.
That's
that's
been,
you
know
how
Gateway
API
came
about
really
is
service.
Was
too
complex
and
Ingress
wasn't
complex
enough?
Roughly,
and
and
here
we
are
and
I
think,
there's
some
really
interesting
stuff
happening
in
Upstream.
I
The
the
idea
of
bullying,
IP
allocation
Antonio
talked
about
that
in
a
previous
meeting
about
pulling
that
away
from
service.
Is
you
know,
step
one
pulling
DNS
away?
That's
you
know
also.
You
know
interesting.
These
are
huge
changes
and
then
bucket
them.
On
top
of
this
idea
that
everything
we
do
in
Upstream
kubernetes
is
tied
to
the
kubernetes
release
cycle
and
Gateway
API,
as
a
project
has
said,
we're
going
to
support
the
last
five
kubernetes
minor
releases,
which
is
a
really
long
window.
I
H
I
think
it
comes
down
to
at
the
end,
the
ga
guarantees
right,
like
Services
of
E1
object,
it's
going
to
be
there
forever,
like
that's
what
V1
means
like
you
know,
where
forever
is
a
long
enough
time
that
it
may
as
well
be
forever,
even
if
it
gets
deprecated
right
like
so.
The
you
know
so,
like
I,
think
that
that's
one
of
the
key
things
is
like
practically
we're.
H
You
know
like
there's,
like
probably
10,
to
20
000
words
written
on
how
to
make
changes
to
non-breaking
changes
to
apis
correctly.
It's
really
hard,
and
so
like
yeah
I,
think
that,
like
I,
don't
I
think
that
breaking
things
out
a
little
bit
at
a
time
is
going
to
be
the
thing
that
that
ends
up
being
the
so
yeah
I
think
I.
Think
yeah
Dave
after
the
chat
I
should
be.
It
should
be
considered.
H
Revisit
n
minus
five
I
think
that
probably
makes
some
sense
I
mean
that
that
decision
was
made
actually
after
we
moved
to
three
releases
a
year,
but
so
yeah
like
I,
think
there's
lots.
There's
lots
to
talk
about
that
so
like
that
was
always
intended
to
be
more
than
a
year,
so
yeah
I
I
could
talk
for
many
hours
about
release,
cycles
and
stuff
because
of
the
LTS
work
working
group.
H
A
So
first
I
didn't
item
out,
I,
don't
know
who
said
this,
but
this
is
a
a
great
news
that
the
mesh
conformance
testing
plan
has
been
merged
and
as
provisional.
Thank
you
thank
you
to
Michael
Beaumont
for
for
knocking
that
out.
This
is
getting
us
closer
to
be
able
to
release
this
and
to
the
formal
Gateway
API,
and
it
means
that
I
can
get
continue.
A
C
F
C
C
A
B
B
A
D
No,
no
I
think
we
covered
it
since
the
concept
of
Sub
sub
segmenting
a
back
end
is
not
mesh
specific
I'm
going
to
create
an
issue,
especially
since
it
sounds
like
other
people
are
interested
in
the
concept
so
I'm
going
to
create
an
issue.
We
can
bring
the
discussion
there
and
then
it
need
be
create
the
the
Gap
in
PRS
to
implement
the
Gap.
As
long
as
we
all
agree.
A
Yeah
I'm
I'm,
looking
forward
to
that
issue.
I
have
some
thoughts
here
around
like
something
that
fun
mentioning
with
a
topology,
some
sort
of
topology
resource
and
kind
of
the
idea
of
a
delegated
ref,
a
reference
to
something
that's
going
to
tell
you
how
to
do
subsetting
or
something
like
that.
So
looking
forward
to
that
I'd.
B
Like
to
understand,
let
me
let
me
be
clear
that
since
people
have
used
route
delegation
as
a
term
of
art
within
gamma
and
Gateway
API
before
I
want
to
be
clear
that
we
have
not
been
thinking
particularly
about
route
delegation.
We've
been
thinking
more
of
other
things
that
could
be
directly
used
as
a
backend
ref
I.
Don't
think
that
that's
opposed
to
what
you
were
just
saying,
I
just
wanted
to
be
very,
very
clear
on
that
one.
Since
you
said
delegation.
A
A
H
I
You
should
be
robbed
clearly
thank
you.
I
wanted
to
come
back
to
this
one
because
honestly,
I
feel
like
it
is
relatively
straightforward.
I
have
presented
this
at
Sig
multi-cluster
this
morning,
I
I
and
actually
at
previous
meeting
as
well.
I,
don't
think,
there's
significant
issues
from
their
perspective.
I
think
this
is
also
relatively
straightforward
from
the
Ingress
perspective.
I
Again,
this
is
my
bias
showing,
but
the
thing
that
I
am
most
interested
in
broader
discussion
is
for
mesh,
because
I
know
that
mesh
is
the
one
place
in
kubernetes
where
there
is
often
alternative
ways
to
to
you
know,
accomplish
multi-cluster
routing
and
what
I
am
proposing
here
is
fairly
strict
and
maybe
most
notably
it
says
that
a
service
is
really
intended
to
refer
to
Cluster
local
endpoints,
which
is
something
that
many
or,
if
not
most
meshes,
do
not
enforce.
Today,
I
am
very
interested
in
some
feedback
and
discussion
around
this.
I
I
B
F
B
F
G
The
only
reservation
I
have
is
that
we
should
also
support
in
addition
to
that,
some
way
to
indicate
you
know
cluster
local
versus
global,
for
putting
your
own
name
or
egress,
which
we
agreed
to
postpone.
So
when
we
start
discussing
about
custom
names,
we
need
to
reopen
this
discussion
a
bit,
but
probably
with
the
same
kind
of
resolution,
I
mean
we
should
have.
You
know
clear
in
the
understanding,
if
you
talk
with
example.com
that
it's
egress
cluster,
local
or
cluster
Global,
but
that's
for
later
yeah.
H
Yeah
I
think
there's
also
there's
also
some
related
things
there
like
a.
We
have
the
egress
sort
of
Gap
effort,
just
starting
up
now,
which
typically
I
think
is
probably
a
similar
amount
of
work
overall
to
the
entire
gamma
effort
correctly
and
then
B.
We
also
have
discussions
about
things
like
cluster,
local
and
cluster
IP
gateways
for
to
be
able
to
do
hairpinning
and
things
like
that
for
North
South
traffic.
So
there
are
some
existing
conversations
there.
That
I
think
will
heavily
play.
H
G
Yes,
I
mean
in
Eastfield
when
you
say
food.main
space,
it
actually
means
in
any
cluster,
so
it
spreads
the
traffic
across
all
clusters
set
or
some
expectations
that
it
will
stay
local
you're
out
of
luck
and
we
have
some
apis
to
to
fine
tune
it
and
control
it.
But
most
of
the
time
you're
out
of
luck.
H
H
I
Well,
while
we're
still
on
that,
I
think
what
I'm
really
looking
for
as
as
kind
of
next
steps
are
sign-offs
from
you
know
at
least
one
or
more
gamma
leads,
but
you
know,
because
this
has
an
impact
on
many
meshes
that
have
intents
of
implementing
Gateway
API,
I
I
would
love
to
get
as
much
feedback
from
that
side
as
possible.
I'm
really
not
as
concerned
about
the
other
aspects
of
this.
So
again,
I'll
I'll
probably
be
coming
back
next
week.
You
know
I'll
try
and
put
some
kind
of
time
limit
on
this.
I
You
know
if
you
have
objections,
please
raise
them
early.
That's
that's
my
biggest
thing.
I
think
I
would
love
to
get
this
in
sometime
soon.
I
know
there
are
a
couple
multi-cluster
and
Gateway
related
talks
at
kubecon.
I
know
we'd
love
to
have
something
formally
defined
as
what
this
means,
not
just
for
you
know,
Ingress,
but
also
mesh
yeah
go
ahead.
C
Oh,
my
my
comments
are
busy
already
addressed
in
the
multi-cluster
meeting,
so
check
out
the
recording
there.
If
you
want
a
little
more
color
on
this,
but
there's
two
points
that
I
feel
like
we
reached
agreement
on
around
this,
like
not
ruling
out
or
prohibiting
like
transparent
proxy
type
functionality
to
like
redirect.cluster.local
traffic
off
cluster.
C
Potentially,
if
a
message
is
configured
in
that
way,
and
the
other
one
was
that
endpoint
slices,
it
is
permissible
for
them
to
point
to
a
Gateway
rather
than
like
direct
pod
routing
off
cluster,
so
that
that's
something
that
we're
hoping
to
get
clarified
a
little
more
explicitly
right.
Now,
it's
kind
of
Allowed
by
admission.
So
those
are
also
reflected
in
comments
on
the
pr
for
the
skip.
B
H
H
H
H
That
I
am
going
to
spend
some
time-
hopefully
this
week
or
next
week,
to
start
trying
to
Wrangle
to
untangle
them
a
bit
and
get
something
a
bit
more
actionable
and
I.
Think
the
last
one
here
is
The
Binding
semantics,
one
that
Keith
opened
earlier
that
we
have
already
talked
about
I
feel,
like
we've,
actually
covered
all
of
these
open
issues
today
already
is
there
anything
else
that
anyone
wants
to
say
about
any
of
these.
B
F
B
The
surface
extent
yeah
there's
there's
a
whole
lot
of
stuff
that
we
could
talk
about
beyond
that,
but
yeah
on
this.
At
a
surface
level,
we
need
to
figure
out
what's
up
with
conformance,
which
we've
just
seen
some
significant
progress
on,
and
that's
the
gate
for
being
able
to
switch
over
and
use
the
real
API
Group.
B
B
The
first
chunk
of
that
video
is
our
CEO
William
Morgan
talking
through
a
lot
of
stuff
for
2.13,
and
the
last
chunk
is
me
going
through
a
demo
actually
using
HTTP
routes
to
go
and
do
canaries
and
a
b
routing
and
yeah.
You
know
Crank
It
Up
to
double
speed
or
something
and
skip
the
bits.
You
don't
want
to
pay
attention
to.
B
I'm
also,
actually,
let
me
well
never
mind,
there's
a
link
in
the
presentation
to
the
GitHub
repo,
where
you
can
see
the
code
that
I
was
using
to
deploy
crap,
and
you
know
the
the
actual
resources
I
was
using
and
actually
John
since
you're
on
the
call.
Do
you
want
to
point?
Can
you
point
me
to
how
to
try
the
latest
istio
that
does
this.
B
B
H
Psyllium
wise,
we
are
currently
focused
on
rounding
out
a
bunch
of
service
mesh,
other
civilian
service
mesh
features
like
mpls
and
stuff
so
yeah.
This
is
this
is
on
the
back
burner
until
later
this
year,
for
us
I'd
love
to
get
to
it,
but
you
know
between
being
a
Gateway
PM
container
and
doing
the
rest
of
my
day.
Job
yeah.
As
short,
as
is.