►
From YouTube: Gateway API GAMMA Meeting for 20221213
Description
Gateway API GAMMA Meeting for 20221213
A
Hello,
everybody
Welcome
to
the
December
13th
instance
of
the
gamma
API
gamma
meeting.
As
a
reminder,
this
meeting
is
governed
by
the
kubernetes
code
of
conduct,
so
be
nice
to
one
another
and
please,
as
you
join
a
reminder
that
this
is
an
open,
Agenda,
so
I'll
paste
that
link
here
in
the
chat.
If
you've
got
a
topic
you'd
like
to
talk
about,
please
add
it
to
that
agenda
and
we'll
make
sure
to
talk
through
it.
A
Also,
while
you're
there
go
ahead
and
add
your
name
so
that
we
can
have
a
record
of
your
attendance.
So
you
can
know
everybody
who
is
interested
in
the
work
that
we're
doing
so
without
further
Ado.
Let's
get
right
into
into
the
agenda,
one
on
name,
slash,
unmentioned,
agenda
item
that
I'm
gonna
talk
about
right,
quick
because
it's
just
oh,
let
me
share
my
screen.
That'll
be
helpful.
Sharing
my
screen
would
be
very
helpful
in
discussing
the
agenda
so
that
everybody
can
see
what
I'm
what
I'm
looking
at.
A
Yeah,
so
one
kind
of
secret
agenda
item
that
I'm
gonna
add
is
just
a
housekeeping
measure
that
we
did
decide
to
I
believe
we
decided
to
cancel
the
no.
That
was
Thanksgiving.
Let
me
not
get
ahead
of
myself,
then.
Do
we
want
to
cancel
next
week's
gamma
meeting?
I
would
be
on
paper
of
doing
so,
because
I
likely
won't
be
working.
D
D
D
B
A
A
Thank
you
Mike,
for,
for
taking
that
note
down,
I
wanted
to
make
sure
we
decided
before
I
forgot
and
didn't
have
everybody
here.
So,
okay,
it's
like
next
two
weeks
and
then
meeting
January
3rd
since
we
are
canceling
next
week,
if
you've
got
the
time,
join
the
Gateway
API
main
meeting
on
Mondays.
Some
there's
always
good
things
to
talk
about
there.
But
okay
housekeeping
note,
out
of
the
way
to
our
customary
recap:
I
was
unavailable
and
Mike
has
volunteered
to
to
add
the
recap.
A
B
I'm
happy
to
do
it
briefly
before
I
start
cooking
dinner:
okay,
appreciate
it
all
right,
so
it
was
only
one
major
topic
that
we
end
up
covering
last
time.
There
were
a
few
housekeeping
items
before
that.
First
up
is
the
Gateway
API
main
of
the
zero
six
zero
release
is
coming
up,
I
believe
we're
trying
to
get
an
rc2
tag
this
week
and
the
actual
GA
either
late
this
week
or
early
next
week,
I
believe
is
the
plan.
B
B
It
has
been
given
the
go
ahead
to
be
experimental,
but
it's
not
formally
part
of
the
060
release
yet
so
I
anticipate
that
we'll
have
more
to
do
and
to
play
a
heavier
role
in
the
API
review
session
for
the
upcoming
070
release,
whenever
that
happens,
for
Gateway
API
there
and
there's
some
discussion
further
down
on
effects
and
Sig
Network
to
extract
IP,
address
allocation
and
DNS
name
resolution
from
service.
So
we
don't
want
to
block
on
that.
B
B
And
the
primary
discussion
last
time
was
around
expanding
the
scope
of
the
initial
implementation
Gap
to
also
support
other
root
clubs.
Beyond
HTTP
route
got
it
and
John
added
a
little
clarification
on
conflict
resolution
and
basically,
we
picked
the
most
specific.
Only
I
think
Keith
has
proof
that
I've
approved
it
and
we're
just
waiting
for
a
final
set
of
approval
from
the
Gateway
API
and
that's
called
it.
That
was,
we
spent
a
lot
of
time
just
discussing
conflict,
Association
rules
and
how
that
should
be
handled.
A
A
A
This
PR
changes,
the
initial
implementation
of
you-
know
HTTP
route
for
mesh
to
to
essentially
add
some
semantics
to
what
namespace
the
HTTP
routes
to
find
in
to
define
whether
or
not
it's
a
consumer
or
a
producer
route
and
yeah.
The
rest
is
in
in
that
gif
I
think
there's
also
some
stuff
in
there
about
whether
or
not
the
consumer
route
wins.
A
We've
got
a
lot
of
good
discussion
here,
but
at
the
two
weeks
ago,
I'm
pretty
I,
remember
us
to
citing
to
move
forward,
try
to
move
forward
with
this
and
let
people
let
this
get
people's
hands
and
and
get
feedback.
So
I
approved
it
last
week
wanting
to
see
if
there's
anything
else
blocking
from
others.
You
have
reviewed.
We've
got
quite
a
few
reviewers
on
this
PR
one
it's.
A
B
I
didn't
early
past
of
the
review.
I
just
wanted
to
kind
of
Raise
This
is
a
significant
expansion
in
scope
to
basically
introduce
consumer
routes,
as
opposed
to
the
initial
implementation
with
producer
routes.
Only
the
implementation
like
overall
looks
solid
to
me.
I
did
an
early
pass.
I
need
to
get
caught
up
on
the
discussion
from
two
weeks
ago.
F
E
Like
to
hear
from
other
vendors
implementing
this
kind
of
stuff,
because
in
istio
it
does
come
with
a
price,
I
mean
it
kind
of
requires
applications
to
have
a
sidecar
for
sure
on
the
client
side
or
whatever
the
best
Gateway
or
some
pretty
complicated,
setups
and
I
want
to
make
sure
that
all
well
doors
are
comfortable
with
the
coaster
with
with
the
applications
of
this
it's
optional.
So
it's
not
a
problem
with
some
sorry
petition
is
not
supporting,
but
he
is
my.
E
C
I
think
that
if
we
don't
keep
that
in
mind
that
we
that
the
idea
here
is
to
enter
end
up
with
something
that
we
clearly
all
know
is
very
experimental
and
we
could
throw
away
at
any
time
you
know,
but
we
need
some.
We
need
to
try
out
something
to
see
if
it
works,
then
that
should
that
seems
fine
to
me.
Sorry,
John.
F
Yeah
I
was
just
I
feel
a
bit
of
dissonance
here,
because
I
wrote
this
PR
and
now
I'm
about
to
say
something:
it's
differs,
but
I,
I
kind
of
am
in
the
same
boat
in
E
Studio,
specifically
like
for
ambient
mesh.
We
had
kind
of
a
recent
decision
on
how
we're
going
to
handle
consumer
versus
producer
proxies,
and
the
kind
of
idea
that
who
are
starting
to
head
to
this
is
all
very
new.
So
that's
why
I
don't
have
anything
concrete?
F
Is
that
oh,
we'll,
probably
only
support
producer
policies
out
of
the
box,
we
may
support
consumer
policies,
but
not
necessarily
on
like
an
implicit
basis
where
everything
kind
of
it's
all
consumer-y
it'd,
be
more
like
you
say,
for
this
specific
service,
I'm,
specifically
opting
into
consumer
override
and
that's
going
to
have
a
real
cost,
an
extra
Network
hop.
You
know
all
these
different
things
rather
than
kind
of
the
simplicit
thing
where
all
the
proxies
know
about
kind
of
all
the
rest
of
the
world,
and
everything
like
that.
So.
F
To
say
is
that
I
I
propose
this,
but
I
also
think
that
maybe
it
should,
at
the
very
least,
be
optional
or
kind
of
opt-in
through
some
means
and
that
we
in
istio
may
not
even
or
actually
very
likely
will
not
enable
it
unless
the
user
there's
a
very
explicit
action
to
kind
of
enable
a
consumer
override
for
for
something
but
I'm
perfectly
fine.
Putting
this
in
here
as
is
and
saying
it's
optional
and
we
iterate
or
whatever
so.
D
You
know
next
steps,
Alternatives
Etc
I
feel
like
we
have
been
guilty
in
the
past
in
Gateway
API
of
letting
comments
like
those
get
lost
and
if
we
could
find
some
way
to
I,
don't
even
know
if
this
is
Alternatives
considered
or
potential
next
steps
or
okay,
whatever
it
is,
but
I
just
would
love
to
make
sure
that
before
we
merge
this,
we
capture
this
discussion
that
these
ideas,
because
it's
so
so
easy
to
just
lose
them
otherwise,
but
that's
all
I'll.
Let
Nick
continue
with
probably
more
relevant
discussion.
C
E
Okay,
can
I
do
one
more
a
quick
Point
here,
while
we
start
discussing
egress
gateways
or
egress
in
general.
We
may
revisit
this,
because
egress
is
almost
all
about
client
over
rights
and
and
properties.
That
is
based
out
some
kind
of
an
interest,
so
it
may
be
worth
considering
even
not
not
moving
to
better
whatever.
Until
we
start
at
least
a
discussion
about.
A
A
D
Sorry,
I
hate
to
add,
add
more
time,
but
I
wanted
to
spend
a
few
minutes
on
1492.
sure
the
item
Above
This
I,
haven't
really
spent
enough
time
looking
at
it,
but
my
understanding
is
right.
Now
it's
approved
from
gamma
perspective
and
looking
for
final
approval
from
Nick
Shaner
myself.
What
I
was
trying
to
understand,
like
there's,
still
some
open
comments
on
this
I'm
trying
to
understand?
D
If
we
should
wait
for
those
to
merge
or
or
be
you
know,
I'm
just
trying
to
understand
the
actual
status?
You
know
as
this
really
do
you
want
this
approved
right
now
or
should
we
hold
off
until
comments
are
resolved?
I
think
so
you
know,
one
of
the
things
like
including
grpc
route
does
seem
pretty
relevant
here.
C
Or
at
the
very
least,
resolving
the
things
that
that
yeah
resolving
the
comments
that
that
no
longer
require
action
will
at
least
let
us
let
those
of
us
who,
like
I,
mean
I,
have
paid
a
bit
of
attention
to
this,
but
I
haven't
like
I,
haven't,
read
everything
so
like
at
least
then
we
can
be
like
okay,
I!
Don't
need
to
worry
about
that
comment.
You
know
that
that
is
now
that's
done.
C
C
D
A
F
D
D
That's
yeah,
that's!
Basically
what
I'm
trying
to
understand
you
know
my
my
interpretation
of
I'm.
Attaching
an
HTTP
route
to
this
service
is
I,
want
to
match
all
requests
to
this
IP
on
this
port
or
set
of
ports
and
do
x
with
it.
What
I,
what
I'm
trying
to
understand
is
how
does
that
relate
with
any
matching
that
might
exist
in
HTTP
route
itself
right,
so
the
HP
route
also
specifies
matches,
and
so
there's
a
subset
of
requests
to
that
service
that
aren't
matched
by
that
HP
route.
What
what
happens
to
those
because.
C
Yeah
I
think
sorry,
sorry,
John
I
think
that's
particularly
relevant
because
in
the
Gateway
context
it's
expected
that
the
Gateway
will
40
for
them,
whereas
I
think
in
the
service
mesh
context.
It
feels
to
me
like
implicitly,
that's
like
pass
through
without
without
being
unchanged,
but
that
that
is
the
thing
that
we
need
to
be
explicit
about
here.
Sorry,
John.
F
F
Now,
one
thing
I
think
in
the
future.
Right
now,
the
grbc
store
is
following
the
Ingress
to
ABC
story,
which
says
you
don't
mix
HTTP
and
grpc
Route.
There
had
been
some
discussion
about
allowing
those
two
to
mix
using
some
precedence
rules
and
if
that
applies
on
the
Ingress,
we'll
pull
that
into
mesh.
F
But
I
think
there
is
some
consensus
that
we
don't
want
to
mix
HTTP
and
TCP
or
TLS
where
they're,
even
though
in
theory
like
you,
could
Define
a
way
that
those
like
work,
we
don't
really
want
that
crazy
protocol
mixing
okay,
at
least
for
now.
We
can
always
add
it
in
the
future
if,
if
we
need
to,
but
for
now
it's
easier,
not
to.
E
Yeah
two
quick
points
on:
if
you
have
insa
is
route
itself
or
aka
the
end,
if
you
attach
to
400
I,
think
I'm
pretty
strongly
that
you
know
you
attach
light
in
Gateway
to
a
particular
listener
listener
report,
and
then
whatever
you
have
is,
is
a
route
doesn't
matter
anymore,
because
you're
probably
attach
the
support.
It
will
be
very
inefficient
to
implement
it.
E
Otherwise,
because
it's
relatively
towards
the
implementations
to
put
all
the
routes
together
and
and
to
basically
use
the
different
layer
and
be
less
efficient
basically,
but
on
the
service
of
grpc
and
HTTP
in
particular,
since
grpc
is
HTTP
to.
After
all,
and
one
implementation
will
translate
grpc
route
into
HTTP
routes,
then
it
will
kind
of
imply
that
it
will
be
a
merge
so
for
some
implementation
that
don't
support
grpc
natively
I
rely
on
some
generic
grpc
translated
into
HTTP.
E
D
G
G
D
G
D
Maybe
to
keep
this,
you
know
focused
on
call
or
go
back
to
the
conflict
resolution
type
thing
like
what
happens
if
you
have
two
HP
routes
and
they
are
both
trying
to
attach
to
the
same
Service.
So
the
same
IP
port
combination
does
that
is
that
basically
the
same
as
two
HP
routes
attaching
to
a
Gateway
yep?
Yes,
okay,.
B
D
D
G
C
G
C
Like,
like
I,
said
before,
yeah
I
think
I've
raised
a
lot
of
these
objections
before
Rob
as
well,
and
so
like
for
now.
I
have
like
I,
have
agreed
to
let
my
objections
yeah
CMS
quietly,
but
in
the
background,
while
we
well,
we
get
something
implementable
so
that
we
can
see
what
happens
when
we
try
and
implement
it.
C
The
I
think
yeah
I
share
a
lot
of
the
concerns
with
what
you're
saying
Robert
again
I
mean
I
have
said
this
before,
like
and
I'm
not
trying
to
reopen.
The
discussion
like
as
I
said,
I
agree
with
the
current
Direction,
but
like
it
feels
to
me
more,
like
the
you
know,
like
I,
don't
think
that's
service
is
going
to
survive
as
the
final
thing
that
we
bond
to,
because
I
think
that
it's
going
to
be
difficult
to
get
a
past
API
review.
C
There's
a
lot
of
complexity
in
the
object
and
a
bunch
of
other
stuff
like
that
again
I'm,
not
trying
to
say
that
we
change
anything
right
now
and
that's
one
of
the
reasons
why
I
want
to
want
us
to
be
clear
in
this
Gap
that
we
say
like
we're.
Not
sure
if
this
design
is
final
because,
like
I
think
there
are
pretty
severe
objections
that
we
haven't
answered
yet
because
we
want
to
get
something,
go
and
get
something
like
implementable
for
now.
Yeah.
G
E
E
Ninety
percent
of
use
cases
service
works
perfectly
fine
and
we
don't
have
all
those
sort
of
reports
and
also
problems.
Most
users
are
just
attend.
Your
service
will
be
the
easiest,
but
I
think.
Yes,
we
may
need
to
have
far
more
fine-grained
than
additional
things.
Yeah
like
a
Gateway
internal
Gateway
or
something
similar
at
some
point.
But
that's
not
exclusive
with
service.
We
don't
have
to
choose
words
yeah.
It
can.
C
Be
both
yeah
again
I
think
that
it
seems,
like
90
of
cases,
work
just
fine
right
now,
because
we
haven't
done
enough
to
draw
out
the
confusion
that
is
implicit
in
the
service
construct
right.
There
is
a
big
confusion
between
the
front
end
and
the
back
end
and
consumer
and
producer,
and
all
this
sort
of
stuff
that
right
now
we
haven't
done
anything
to
addressing
the
types
and
again,
as
I
said,
that's
fine
for
now,
but
I.
Don't
think
that
this
is
going
to
be
a
supportable
API
until
we
have
reduced
or
eliminated
that
confusion.
C
I,
think
that
you
know
some
level
of
ambiguity
in
an
API
is
inevitable,
but
right
now
we
are
way
too
hard
on
a
ambiguity
scale
for
this
to
be
a
final
solution
like
oh,
that's,
a
bad
word
for
this
to
be
done
for
this
to
be
the
last
way
that
we,
you
know
this
to
be
the
final
design.
Sorry,
that's
a
better
way
to
put
it.
E
And
another
point
that
was
made
in
the
past
is
that
the
service
is
also
evolving
and
kubernetes
is
also
universities,
things
that
you
mentioned,
and
it's
no
point
for
us
to
kind
of
kubernetes.
So
once
you
have,
the
service
will
support
it
as
well,
and
we
can
dedicate
its
own
services
like
kubernetes
may
or
may
not
applications
on
service
remove
the
existing
service.
We
can
remove
it
as
well.
D
D
Right
we're
stuck
with
it
with
that
said,
I
think
there
that
there's
been
broad
effort
to
shove,
all
feature,
requests
and
all
future
work
towards
Gateway
API
and
to
get
to
a
point
where
the
resources
in
Gateway
API
can
represent
the
vast
majority
of
functionality
that
was
or
is
contained
in
service
and
Ingress,
and
you
know
beyond
yeah,
so
so
I
think
you
know
I
agree
with
what
everyone's
saying
here.
We
need
something
we
need.
D
We
need
something
that's
available
now
and
the
the
ideas
I'm
describing
are
not
available
now,
so
we
need
to.
We
need
to
move
forward
with
something
like
we
can't
be
stuck
forever.
At
the
same
time,
there
is
at
least
one
cap
for
IP
allocation
moving
out
of
service.
That's
you
know
a
first
step
to
this.
D
I'd
love
to
you
know,
keep
that
moving
as
well,
but
there's
there's
many
different
areas
and
we
need
to
at
least
have
something
like
that
is
makes
use
of
API
today,
but
but,
like
Nick,
said
I
this
this
I
have
to
use
my
words
carefully
here.
This
is
probably
not
the
ideal
long-term
solution,
but
it
is
a
thing
that
appears
to
work
right
now,
so.
G
I
mean
don't
get
me
wrong,
I'm
one
of
the
people
who
was
pushing
for
binding
to
service
in
the
first
place
and
I
figure,
it's
entirely
possible
that
I'll
start
messing
with
it
and
immediately
turn
around
and
go
oh
dear
God.
This
does
not
work
so
yeah
available
for
experimentation
seems
like
exactly
what
we
need
right
now.
A
A
Is
you
know,
helping
users
understand
the
front
and
back
end
Concepts,
even
if
it's
not
in
types
yet
using
that
in
any
conversations
that
we
have
in
in
design,
hopefully
preparing
them
for
the
the
IP
allocation
cap
that
then
we
can
start.
You
know
maybe
bonding
more
strongly
too
so
I
I
see
it's
still
kind
of
kind
of
blurry,
but
I
do
see
a
path
to
where
we
can
eliminate.
Some
of
this
ambiguity,
get
it
in
strong,
strong
types
and
not
have
so
much.
A
G
A
Yeah,
like
I
I,
realized
that
you're
can't
say
things
like
oh
wow.
This
is
like
this
is
the
last
meeting,
so
it's
it's
pretty
crazy
and
I
want
everybody
who's
here,
and
anybody
who
might
be
who
regularly
attends
but
couldn't
make
it
today
or
he's
watching
and
recording
to
just
think,
take
a
second
and
feel
feel
good
about
yourself,
be
proud
of
yourself
for
the
work
that
we've
done.
A
A
We
are
the
most
I
I
dare
to
say
the
most
successful
effort
for
merging
service
mesh
and
kubernetes
in
the
same
in
the
same
room
in
the
past
so
compared
to
the
past.
So
that's
super
exciting.
To
start
to
have
these
this
collaboration
and
we've
actually
got
a
resource.
You
know,
experiment,
experimental,
ex,
erratically,
experimental
you
know.
A
Resource
designed
and
Implement
should
be
implementable
soon,
but
2023
will
be
when
we
see
that
happen
and
I'm
very
proud
of
of
the
efforts
of
everybody
in
this
group.
I
look
forward
to
continuing
to
work
with
you
all
in
the
new
year,
and
so
as
part
of
that,
I
would
say.
Think
about
where
you
want
to
see.
Gamma
go
think
about.
You
know,
look
at
the
things
that
we've
accomplished
this.
A
This
is
great
stuff
to
tell
your
employer
to
convince
them
to
let
you
continue
and
dedicate
more
time
to
this.
I
have
no
shame
in
saying
that,
but
we've
seen
what
can
be
possible
and
I
think
the
next
phase
of
of
work
and
of
growth
for
gamma
is
going
to
be
continuing
to
find
Champions
continuing
to
find
people
to
advocate
for
their
users
for
their
customers
and
and
push
more
things
into
the
API
I
think
2023.
A
Once
you
get
the
the
traffic
management
stuff
out
there
I
think
2350
is
going
to
be
the
year
of
policy
and
finally
getting
some
concrete
stuff
around
policy
attachment
done.
Can
you
put
what
you'd
like
to
see
from
gamma
and
Gateway
API
as
well?
Rob
I
think
you
had
a
agenda
item
for
yesterday.
Asking
that
same
question.
A
C
C
C
C
Yeah
totally
totally
but
yeah,
but
but,
like
you
know,
like
yeah
I,
think
it's
really
important
to
take
a
moment
to
appreciate
how
how
far
we've
come
in
a
very
short
space
of
time.
You
know
and
I
say
that
to
being
someone,
who's
put
the
brakes
on
pretty
firmly
and
on
a
number
of
occasions,
so
yeah
well
done
everyone
and
thanks
for
putting
up
with
me.