►
From YouTube: Gateway API GAMMA Meeting for 20230425
Description
Gateway API GAMMA Meeting for 20230425
A
B
C
B
B
E
B
C
A
Yes,
so
yeah
the
media
agenda
and
notes
are
linked
in
in
the
invite
yeah.
Please
feel
free
to
add
your
name
and
Company
student
keep
track
of
who
is
able
to
join
these
calls
and
yeah.
We
also
we
have
alternating
time
zones,
so
you
may
notice
that
today's
video
is
8
A.M
summer
time.
It's
intended
to
be
an
EU
friendly
time
on
all
trading
weeks.
C
C
C
I
have
always
tended
to
come
to
the
cloud
native
World
from
the
perspective
of
an
applications
developer,
and
there
are
clearly
others
who
come
in
from
the
perspective
more
of
a
cluster
provider
or
assisted
men
type,
and
it's
really
interesting
to
walk
around
kubecon.
Look
at
the
booths,
listen
to
people
talking
and
realize
that
this
seems
to
be
very
much
an
open
question
in
the
community
of
who
do.
C
C
F
C
So
Keith
in
the
chat
linked
Milestone
9,
which
is
gamma
HTTP
route,
support
ready
for
implementers
to
try,
which
is
not
quite
necessarily
the
same
as
things
we
must
have
ready
for
you
know,
1.org
or
whatever
you
want
to
call
it,
but
it
is
certainly
that
is
100.
You
know
a
unnecessary,
although
possibly
not
sufficient
thing.
G
Yeah
I
think
that
can
I
take
it
back
enough
of
that.
I
think
that
we
have
to
get
gamma
support
where
we
can
get
real
user
feedback
before
I
at
least
feel
comfortable
talking
about
the
gamma
gets
in
general
being
ready
for
a
1.0
or
like
a
state
or
GA
like,
but
when
it
comes
to
where
Gateway
API
goes
when
it
comes
to
burgeoning
and
what
a
1.0
means.
In
my
mind,
that
is
it's
pretty.
It's
helpful
when
I
think
almost
necessary
to
think
about
that
as
being
distinct
form
for
gamma's
maturity.
G
You
know
one
represents
a
lot
for
Gateway
API
and
the
resources
and
the
code
that
the
thing
get
your
API
because
gamma
as
of
yet
does
not
own
any
code
of
resources.
That
version
does
not
doesn't
really
mean
much
for
us
at
this
time.
If
that
were
to
change,
then
we'd
have
to
have
that
conversation
and
feel
like
and
be
more
I.
Think
specific
about
with
the
graduation
process
looks
like,
but
everything
all
the
gaps
that
gamma
has
at
the
moment
are
experimental
or
provisional.
G
G
C
If
anybody
disagrees
with
that,
I
think
that
would
be
a
lovely
conversation
that
we
should
have,
but
I've
been
that's
how
I've
kind
of
been
thinking
about
it
when
I
was
initially
talking
about
Gateway
API
1.0
before
Chicago,
that
was
I
was
trying
to
say
that
was
aggressive
in
the
sense
that
I'm
not
sure
Gateway
API
will
have
all
the
answers
they
need
to
really
get
to
a
1.0
before
Chicago,
as
opposed
to
gamma.
Being
you
know,
focusing
on
the
camera
piece
of
that.
A
A
That
is
kind
of
like
the
near-term
goal
for
gamma
to
get
to
a
point
where
we
can
start
having
implementations
available
and
start
getting
user
feedback
because
it's
like,
as
we
saw
this
Gateway
API,
there
was
definitely
like
a
substantial
period
where
user
feedback
can
form
some
of
the
API
design,
and
the
experimental
channel
is
just
that.
It's
for
figuring
out
what
works
and
what
is
actually
going
to
make
sense
to
move
forward
and
is
subject
to
some
change.
Potentially
so
I
don't
think
stable.
Ga
is
a
near-term
goal
for
gamma
yeah.
C
C
C
Yeah
gamma
in
particular,
has
a
really
really
nasty
chicken
and
egg
problem.
Where
we
need
the
feedback
to
be
able
to
get.
You
know,
make
sure
we're
doing
the
right
thing,
but
we're
not
going
to
get
the
feedback
as
long
as
people
think
that
we
can
just
change
it
out
from
other
than
constantly.
So
it's
a
weird
thing.
H
It's
not
really
a
good
parallel
because
of
the
difference
in
scope
and
stuff,
but
recently
added
a
prototyping
phase
to
the
Gap
phases
specifically
to
deal
with
that
problem
with
conformance
tests.
However,
the
damage
with
conformance
tests,
of
course,
is
so
much
less,
there's
so
much
less
potential
for
damage.
So
it's
not
really
a
great
comparison,
but
just
to
put
that
bug
in
your
head
that,
like
it
may
be
reasonable
to
expand
I
know
we
don't
want
to
have
to
change
process
to
do
everything,
but
it
may
be
reasonable
to
do
that
for
gamma.
C
H
A
A
Some
of
the
conversations
that
I
had
one
has
already
I,
already
added
it
previously
as
a
like
backlog
topic
for
discussion,
but
had
a
additional
conversations
with
some
of
the
folks
who
have
been
working
on
admin.
Network
policy,
as
the
shape
of
that
feels
like
it's
solving
roughly
similar
sets
of
problems
to
kind
of
what
meshes
need
for
RC,
namely
being
able
to
default,
deny
traffic
across
a
cluster
and
then
being
able
to
have
some
kind
of
granular
allowed
list
between
workloads.
A
So
in
their
case,
they're
focused
similar
to
network
policy
on
like
IP
addresses.
So
this
would
be
like
looking
at.
How
could
we
do
some
sort
of
extensible
design
that
could
be
compatible
with
that
similar
to
like
parent
ref,
the
Gateway
API
uses
to
be
able
to
support
instead
of
like
an
IP
address,
binding
to
a
workload?
Identity
such
as
we
had
earlier
discussed
like
service
account
as
kind
of
like
the
low
level
fruit
or
like
the
minimum
Implement
implementable
thing
for
money
meshes.
A
A
What
else
yeah?
Definitely
good
discussions
at
contributor,
Summit
I,
think
trying
to
remember
what
else
the
gamma
Gathering
that
we
did
through
the
song
Right
was
particularly
valuable.
Just
getting
all
the
all
these
folks
in
one
room
to
build
the
hash
and
stuff
like
that,
so
and
I
think
one
of
the
other
things
that
I'll
hand
over
to
Keith
in
a
moment,
but
gamma
is
more
than
just
Gateway
API.
A
B
A
G
G
G
G
You
know
which
totally
Blended
for
like.
If
it's
going
to
take
two
to
three
years
to
change
things,
it's
hard
for
them
to
take
a
dependency
on
something
Upstream.
It's
like
we're
running
off
of
a
fork
of
MCS
for
our
Fleet
Service.
So
that
was
what
started
my
brain
thinking
in
this
direction
that
you
know,
MCS
sits
in
this
kind
of
weird
intersection
between
multi-cluster
and
sync
Network.
G
G
A
G
F
A
Yeah
so
so,
there's
a
couple
points
I
think
the
closest
thing
to
a
mesh
like
implementation
that
uses
parts
of
MCS
is
by
AWS
PC,
lattice
and
I
want
to
plug.
We
went
and
Rob's
talk
from
kubecon
goes
into
some
of
the
technical
details
of
that
a
bit
more.
If
you're
interested
in
diving,
deep
and
learning
a
bit
more
about
that
and
how
they're
using.
I
Recording
yeah
yeah,
okay,
I,
can
put
in
the
GitHub
of
our
implementation.
We
have
a
lot
of
examples
there,
Yeah
Yeah,
so
basically
we
we
use
service,
import
and
service
export
and
the
class
of
the
set
in
our
implementation
is
a
federation.
We
have
VPC
lattice
as
the
way
of
Federate
all
the
cluster,
so
the
source
of
truth
of
every
single
cluster
information
endpoint,
it's
all
managed
by
the
VPC
ladders,
so
each
controller
each
cluster
is
a
local.
I
So
the
controller
do
not
have
to
know
every
single
cluster
except
itself,
and
and
that's
that's,
how
we
implement
it.
So
the
export
the
key
of
the
export
is
when
you
create
a
service,
and
you
want
to
export
two
VPC
ladders.
All
you
need
to
do
with.
Today.
We
have
an
annotation,
a
special
annotation
to
say:
hey
this
one
is
Federated
by
VPC
ladders
and
in
the
controller
one
service
look
you
can
find
out
a
trigger
buyer
service,
export
and
annotated
with
the
VPC
that
is
Federation
it.
I
They
will
create
a
Target
group
in
VPC
ladders.
Under
the
on
the
consumer
side,
we
want
to
use
a
service
import.
All
it
does.
Is
just
say,
backend,
ref
of
particular
name.
This
is
the
service
import,
because
the
HTTP
route
is
under
the
VPC
ladder,
Gateway
class,
so
our
controller
understand
is
going
to
look
for
service
import
and
it's
going
to
go
to
VPC.
Rather
to
say:
do
you
have
this
particular
Target
group
on
and
so
in
our
case,
service
Import?
In
addition
to
kubernetes
Services
can
be
extended
to
anything
to
VM.
I
G
G
G
G
C
G
D
G
Yeah
so
yeah
they're,
so
during
during
kubecon
I,
was
talking
to
several
people
about
some
of
these
things,
and
it
feels
like
gamma
is
the
place
where
we
want
to
have
people
talking
about
this,
but
Gala
is
is
again
so
focused.
It
is
very
focused
on
Gateway,
API
and
specifically
traffic
concerns
and
I.
Think.
G
If
a
working
group
isn't
necessary
and
I
think
that
you
know
maybe
not
immediately
but
I
at
least
see
a
lot
of
areas
where
having
a
full-on
working
group
with
where
we're
able
to
maybe
have
you
know,
multiple
meetings
and
get
a
wider
audience
would
be
beneficial
to
some
of
the
things
that
we're
trying
to
do
as
we
try
to
help
align
service
connection.
Kubernetes
we've
been
able
to
do
a
lot
of
good
work
in
gamma,
but
that
is
our
goal.
G
C
A
G
C
G
Yeah
SMI
was
it
wasn't
a
pretty
big
focus
of
that
tag.
That's
working
group,
so
maybe
that's
an
alternative
like
place
for
this
I
I
will
I
I
think
my
my
preference
should
probably
be
for
a
kubernetes
working
group,
initially
at
least
just
because
I
think
we've
seen
it
with
gamma
the
benefits
of
being
closely
aligned
with
the
kubernetes
and
the
kind
of
the
the
cross-pollination
that's
able
to
happen
there
has
has
been,
has
been
really
great
for
us.
So
again,
not
thing
doing
now.
G
C
One
other
thing
on
that
front,
which
is
that
obviously
we're
talking
about
kubecon,
which
is
all
about
kubernetes,
but
there's
obviously
also
a
lot
of
discussion
about
meshes
that
span
kubernetes
and
things
that
are
not
in
kubernetes
right,
so
yeah,
like
yeah,
actually
I,
think
everybody
on
this
call
could
probably
wave
their
hand
on
that
one
right.
Certainly
we
hear.
A
C
Certainly
we
hear
people
hear
people
ask
us
about
mesh
expansion
with
Liberty
on
a
regular
basis.
Yeah,
it's
a
it's
a
nice
easy
technical
problem,
yeah
yeah,
but
that
Keith
May
yeah.
Maybe
we
start
with
the
working
and
okay.
This
is
going
to
sound
facetious,
but
this
time
I'm
actually
being
serious
yeah.
Maybe
we
start
with
a
working
group
and
then
end
up
changing
interviews
hag
later
on
or
something
like
that
right.
A
G
G
A
No,
no,
you
have
a
long
rambling
recap
touching
on
a
lot
of
different
points.
Yeah
I
think
the
MCS
stuff
is
interesting
because
I
mentioned
this
briefly
in
my
talk,
I
think
to
some
to
a
large
extent
it
was
an
API
that
arrived
before
the
end.
Users
were
ready
for
it
and
then
there's
it's
some
stuff,
like
we've
seen
how
a
conformance
tests
in
Gateway
API
has
been
like
incredibly
helpful
to
facilitate
new
implementations
and
that's
something
that
MCS
are
Multicultural
is
working
on
for
MCS
API.
A
Currently,
so
some
of
that
stuff,
I
am
optimistic
about
and
yeah
I
think
that
we're
starting
to
see
that
this
is
a
problem
that
actual
end
users
are
trying
to
solve
now.
So
I
think
that
important
discussions,
it's
mostly
that
the
existing
API
is
not
expected
to
like
go
through
a
lot
of
churn
like
the
like
core
resources
feel
like
they're
generally
well
designed
and
stable.
A
But
yeah
there's
a
couple.
Different
multi-cluster
use
cases
and
I
think
that
we're
starting
to
see
end
users
care
about
them
and
they
existing
API,
like
IT,
addresses
a
subset
of
those,
so
yeah
I
think
we're
definitely
starting
to
see
a
more
experience
of
use
case
of
people
going
Beyond
a
single
kubernetes
cluster
and
needing
solutions
for
that.
A
G
C
A
A
Flynn
and
I
went
through
an
exercise
in
exploring
that
and
I
think
the
conclusion
that
at
least
I
came
to
was
well.
We
want
the
ux
well,
there's
a
ux
that
we
want.
It
is
difficult
or
impractical
to
actually
Implement
and
there
are
too
many
ways
around
it
for
it
to
be
like
required
or
expected
and
kind
of
the
long
tail
of
where
I'm
getting
to
now
is
figure
it
out
that.
A
B
A
There
may
be
some
variants
here,
and
it
is
not
expected
that
a
given
configuration
will
produce
exactly
the
same
routing
Behavior
between
implementations,
but
I.
Think
that
that's
going
to
be
okay,
because
largely
we're
not
expecting
people
to
switch
between
implementations
like
as
long
as
the
boundaries
are
clear
and
the
the
like
way
in
which
you
use
the
spec
is
clear.
C
A
E
C
C
G
C
C
There's
a
set
of
things
that
you're
probably
going
to
expect
to
happen
if
you're
a
measure
operator
and
you
put
in
a
route
that
you
think
is
bound
to
something
where
your
mesh
will
interpret
it.
There's
a
set
of
behaviors
that
you're
going
to
expect
to
happen
to
the
extent
that
we
can
avoid
completely
shocking
those
expectations.
That'll
be
a
really
really
good
thing.
C
Often,
implementation
pressures
that
run
counter
to
that,
and
but
but
that's
that's
the
stuff
that
I'm
thinking
of
here
is
looking
over
some
of
these
and
being
being
kind
of
worried,
so
yeah,
but
I
think
we
can
I
think
we
can
nail
it
down
in
the
next
couple
of
weeks
and
come
up
with
something
that
we
can
all
pick
apart
and
Heckle
and
I
will
probably
not
be
utterly
ecstatic
with
whatever
we
come
up
with,
but
I
think
I
can
come
up
with
something
I
feel
like
I
can
live
with.
So
that's.
A
C
A
Yeah
it
it's
not,
but
it's
like
okay.
So
what
can
we
actually
Define?
What
can
behaviors
can
we
actually
expect
and
trying
to
particularly
the
thing
I
want
to
focus
on-
is
writing
up
like
the
user
stories
of
for
a
given
Persona?
How
does
this
impact
them
and
how
would
they
manage
specific
workflows
if
our
configuration
works
this
way
and
I
think
that
that's
something
where
it
is
mostly
workable?
A
A
D
G
Image
is
easy,
I
mean
it
image
is
the
easy
one
code
depends
on
how
I
mean?
Can
we
just
take?
Basically
the
istio
test,
app
code,
slash
framework
and
put
it
in
its
own,
like
repo
under
kubernetes?
Would
that
be
sufficient,
I
think
yeah?
It
could
be
done.
It
would
yeah
I
think
that
that
works.
Okay,
I
might
be
able
to
tackle
that.
A
G
C
It
it
could
still
be
the
case
that
it
could
still
be
the
case
that
there's
you
know,
code
that
claims
copyright
by
Google
or
you
know,
titrate
or
whoever,
and
then
we
would
have
to
think
about
a
little
bit
further.
But
everything
in
John's
initial
PR
looks
like
it
already
claims
the
cube
authors
for
copyright,
so
cool
I'm
thinking
that
already
happened,
which.