►
From YouTube: Gateway API GAMMA Meeting for 20230411
Description
Gateway API GAMMA Meeting for 20230411
A
A
A
D
D
A
A
All
right
all
right,
yeah,
I,
guess
with
that.
If
there's
anybody
else,
we
can
start
with
a
recap.
So
yeah
last
week
was
a
relatively
short
reading,
mostly
dealing
with
logistical
type
things.
So
Shane
is
going
to
be
doing
the
Sig
Network
intro
at
coupon
EU
next
week
next
week.
Yes,
is
it
that
hurricane
yeah
and
just
wanted
to
mention
the
gamma,
we'll
get
a
shout
out
straight?
If
you
want
to
say
anything
else
about
that
again,.
F
No
I
mean
not
much
to
say
there
will
be
a
shout
out
to
gamma.
Let
people
know
that
this
let
people
in
general
kind
of
know
in
in
the
past,
it's
been
gamma's
been
kind
of
like
you
had
to
be
connected
to
Gateway
API
I
didn't
know
that
we're
kind
of
doing
this
we're
getting
far
enough
along
now
that
it's
worth
just
there's
a
page
there.
That
kind
of
says
hey.
This
is
something
that's
happening
for
service
mesh.
If
you're
interested
come
join
us
awesome.
F
A
A
A
All
right,
the
April
18th
meeting,
so
next
week's
meeting
it's
typically
a
different
time
slot,
but
it's
also
canceled
for
coupon
EU,
because
many
of
us
will
be
gone
for
that
we,
the
week
after
we'll,
have
meeting
at
the
regular
scheduled
time.
So
this
time
slot-
and
hopefully
we
will
start
off
with
a
recap
of
cute
Connie.
You
know
and
anything
interesting
and
discussions
happen
there.
A
G
That's
that's
definitely
the
case.
If
you
see
there,
there
are
some
comments
that
are
really.
You
know,
kind
of
a
good
first
issue,
type
comments
that
we
haven't
translated
to
issues.
I
think
the
goal
would
be
to
translate
them
to
issues,
but
if,
before
that
happens,
you've
got
some
time
to
run
through.
You
can
help
speed
up
the
0.7
release
simply
by
running
through
those
comments
and
seeing
if
you
can
tackle
some
and
please
if
you
are
working
on
them,
just
comment
on
the
comment
itself.
G
A
G
D
A
F
So
we
have
wait:
yeah,
okay,
so
we
have
a
a
workshop,
a
one-hour,
Workshop
I,
actually
don't
know
off
the
top
of
my
head.
They
just
accepted
it
when
exactly
it
is
where
it
will
be
kind
of
just
we'll
have
a
format
in
mind,
but
it's
kind
of
just
going
to
be
open
discussion
kind
of
like
what
we
did
last
time.
Potentially,
although
if
people
want
to
go
ahead
and
start
suggesting
like
specific
agenda
items,
we
can
kind
of
try
to
organize
that
do
that
soon.
Since
that's
a
week
away
and.
G
A
B
B
G
G
A
D
A
B
A
H
Yeah
I
just
wanted
to
like
let
everyone
know
that
you
know
there's
another
implementation
of
the
gamma
company,
we're
going
to
add
gamma
support
to
the
existing
Gateway
API
support
nothing
much
there
at
the
moment,
but
yeah.
So
that's
like
a
short-term
goal
of
ours
to
have
running
the
to
have
our
conformance
test,
also
running
the
mesh
tests
yeah.
So
that
might
be
interesting,
very
cool.
B
I
had
a
chat
with
John
earlier
today
that
I,
yes,
John
was
talking
about
the
differences
between
cluster
IP
gateways
and
so
binding
to
a
service
that
has
a
cluster
IP
I
thought
it
was
probably
a
good
idea
to
just
for
me
to
clarify
at
least
what
I
think,
because
we
worked
pretty
hard
originally
on
the
definition
of
like
what
is
a
gateway
and
I.
Think
that
definition
we
haven't.
B
We
don't
do
a
good
job
of
pushing
this
deposits
and
that's
really
relevant
for
this.
So
a
Gateway
we
kind
of
defined
originally
as
a
thing
that
it
translates
from
a
place
that
doesn't
have
a
context
of
inside
the
cluster
networking
to
a
place.
That
does
a
lot
of
most
of
the
time.
That's
outside
I.E,
the
internet
and
inside,
but
in
the
case
of
a
cluster
IP.
B
A
D
A
To
me,
I
think
there
are
definitely
roles
in
gamma
or
cluster
IP
gateways
that
Shield
context
So
like
for
constants
use
case.
It's
definitely
going
to
make
sense
like
at
the
edge
of
a
cluster
for
how
we're
doing
multi-cluster
networking,
where
we're
like
at
the
administrative
boundary
where
you
may.
C
A
A
E
It
make
sense
to
have
a
cluster
IP
assigned
to
a
Gateway
inside
your
cluster
that
doesn't
transit
to
someplace
else
that
where
both
sides
of
the
Gateway
are
administratively
securative,
you
know
with
respect
to
security,
et
cetera,
et
cetera
they're.
Both
sides
are
the
same.
Why
would
you
want
to
use
a
Gateway
in
that
case.
B
Obviously,
but
like
you're.
Logically,
that's
what
you're
doing
like
when
the
traffic
comes
in
that
firewall
it's
now
from
outside.
You
know
that
the
context
is
not
it's
not
coming
from
some
other
VLAN
in
the
same
network.
It's
and
that's
the
that's
the
sort
of
the
thing
that
I'm
trying
to
get
to
you
and
I
think
that
you
know
the
cluster
IP
Gateway
stuff.
B
We're
talking
about
sort
of
in
the
main
part
of
Gateway
API
is
important
for
that
sort
of
context
where
you
know
for
something
like
K
native,
where
you're
doing
you
want
to
go
East-West,
but
you
actually
want
to
lose
the
context
to
some
extent
right.
Like
you're,
you
know
you
know
that
they
want
to
sort
of
that's
kind
of
desirable
to
some
extent
and
so
yeah
I.
E
The
multi-cluster
case
is
also
pretty
interesting,
where,
if
you
use
a
gateway
to
sorry,
if
you
use
a
thing
that
serves
the
function,
that
we
commonly
call
a
Gateway
in
English
that
I'm
intentionally
separating
that
from
a
Gateway
resource
for
the
moment
for
communications
between
one
cluster
and
another
cluster
in
the
same
multi-cluster
setup,
then
there
I
could
see
getting
into
an
interesting
conversation
about
how
much
context
should
be
retained,
but
still
feeling
like
when
you
cross
the
cluster
boundary.
You
can't
rely
on
a
lot
so.
B
Yeah
and
that's
the
crossing,
the
cluster
boundary
is
sort
of
the
that's.
Almost
that's,
probably
a
more
succinct
way
of
saying
it.
You
know
I
I
avoided
using
those
terms
earlier,
because
then
you
have
to
spend
some
time
defining
on
what
a
cluster
boundaries
yeah
and
so
like
yeah.
So
that's
why
I
generally
tend
to
speak
in
very
general
terms.
G
Yeah
I
think
it's
covered
in
the
comments.
I
I
looked
through
what
the
Nick
and
John
had
in
the
comment
there
as
well
and
I,
think
they
they
covered
it
well,
but
I
think
so
far.
We've
we've
been
really
focused
on
the
idea
that
Gateway
is
what
it
is
today
and
it
may
happen
to
have
a
cluster
IP
address.
There's
also
a
future
idea
that
Gateway
behaves
very
similarly
to
service
front
end.
E
G
Yeah
I
agree
with
your
your
assessment
of
what
they
are
today.
I
think
there's
been
some
high
level
desire
that
a
service
just
becomes
a
way
of
representing
a
group
of
endpoints,
basically
and
gateways
handle
the
routing.
You
know
the
these
are
theoretical
and
I
don't
know
if
it
actually
makes
sense
to
get
there
and
I
don't
want
to
go
too
far
down
that
rabbit
hole
until
we
get
there
kind
of
thing
like
I,
we
may
never.
We,
it
may
never
make
sense.
I
I,
don't
know
it's
just
kind
of
a.
E
G
No,
this
is
this
is
this
is
definitely
not
that
this
is
kind
of
like
the
the
high
level
directive
or
like
not
even
directive
but
hey.
If
Gateway
API
was
successful,
you
know
four
or
five
years
from
now
or
whatever.
Then
it
would
have
replaced
the
service
front
end
that
that's
one
of
many
things,
I,
don't
know
if
that's
actually
going
to
happen,
but
part
of
the
idea
of
Gateway
API
was
to
try
and
relieve
the
pressure
on
service
at
a
minimum.
We're
gonna,
try
and
replace
service
type
load,
balancer.
E
Type
load
balancer
by
definition,
is
hey
cluster.
Give
me
a
way
that
the
external
worlds
can
get
traffic
from
that
totally
different
context
into
my
cluster.
That
makes
perfect
sense,
but
replacing
our
service
in
general
with
a
Gateway
does
not
make
sense
to
me,
because
that's
a
I
think
different
thing.
E
I
Yeah,
so
so
in
our
implementation,
the
you
know
for
the
VPC
ladder,
so
Gateway
is
kind
of
like
it's
a
Gateway.
It's
mapped
to
a
service
network,
it's
basically
a
VPC
data
construct.
You
know
for
the
cloud
info.
So
so
imagine
you
know,
in
my
view,
like
anyway,
it's
like
your
whole.
You
have
your
home
default
router
right.
You
go
out
to
the
Internet.
You
may
connect
to
one
provider.
You
may
provide
to
another
provider
so
in
in
our
case
the
Gateway.
You
know
as
a
part
of
VPC
or
kubernetes
cluster.
I
A
B
A
Yeah
and
yeah
I
I
think
that
all
of
us
kind
of
like
wrap
this
up
I
think
all
of
us
have
like
independently
seen
how
service
is
overloaded.
We
even
have
gaps
talking
about
how
the
service
resource
is
too
big
and
does
too
much
and
it's
awkward
that
it
has
two
completely
different
roles.
So
it
doesn't
feel
that
there's
a
lot
of
Ascension
around.
We
need
to
break
it
up.
A
Somehow,
we've
seen
in
gamma
that,
like
having
a
service
running
construct,
is
useful
and
it
feels
like
it
is
mostly
a
question
of
terminology
so
like
we're.
Seeing
with
gamma
2
like
HTTP,
is
a
useful
way
of
expressing
things
and
attaching
routing
Behavior
to
something,
and
maybe
it's
just
a
different
resource
that
has
a
different
name
but
functionally
could
serve
that
front-end
roles
and
all
definitely
excited
to
see
what
the
future
may
bring.
A
J
Yeah
I
I
thought
that
we
are
more
or
less
in
agreement
that
the
model
is
that
HTTP
route
is
attaching
to
something
that
has
some
characteristics,
meaning
a
VIP
or
a
hostname,
and
we
don't
really
care.
I
mean
service
is
just
one
of
those
things,
but
we
are
not
no
longer
tied
to
service
us
as
a
way
it
could
be
a
service
import.
It
could
be
something
else,
including
a
gateway.
An
implementation
are
free
to
do
whatever.
That's
my
understanding
of
the
recent
book
that
I
I've
read.
K
Changing
it
again,
I
think
I
think
that's
the
case
and
that's
what
the
Gap
is
proposing,
which
is
something
we'd
already
discussed,
but
I
think
it
just
wasn't
written
down.
I
think
what
the
controversy
came
from
was
me
saying.
Well,
Gateway
can
also
meet
that
role
and,
if
Gateway
is
me
in
that
role,
that
potentially
is
meaning.
This
group
says
that
that
is
a
core
thing
and
Cube
proxy
starts
understanding
it
and
et
cetera,
which
is
kind
of
a
different
story.
K
B
Of
the
the
that's,
what
I
was
just
saying,
Austin
that
the
whole
point
of
the
Gateway
thing
is
that
it
implies
a
translation
between
different
contexts
and
when
you're
doing
that
stuff
for
like
purely
east
to
west.
You
don't
have
that
translation,
and
so
you
get
it.
Could
it's
going
to
end
up
being?
You
know
like
confused
on
a
conceptual
level
which
which
will
end
up
making
things
which
can
end
up
making
things
weird.
You
know
that
is
what
I
am
saying
after
having
done.
B
You
know
this
sort
of
API
design
for
quite
a
while,
like
I,
don't
recommend
doing
that.
I
think
we
should
have
a
separate
thing.
That
is
the
whatever
the
name
of
that
thing
is.
It
needs
to
be
separate
to
Gateway,
because
Gateway
has
a
very
clearly
defined,
like
sorry,
not
clearly
defined,
because,
obviously
because
people
don't.
B
J
Specification
is
required
that
it
translates
I
mean
it's
an
enforcement
point.
It
applies
policies
it
may
as
well
translate,
because
even
if
it's
East-West
it
does
all
kind
of
Transformations
I,
don't
think
both
of
the
arguments
you
make
that
it
requires
to
do
some
transformation.
If
it
doesn't
do
transformation
are
kind
of
not
necessarily
okay,.
B
It's
not
specifically
written
into
the
spec
in
some
field,
but
it
is
designed
with
that
in
mind
and
so
like.
There
will
be
parts
of
this
design
of
the
spec
that
that
have
that
in
mind
and
if
we
try
and
use
it
in
a
different
way,
then
it's
likely
that
they'll
be
impedance
mismatches
between
the
way
that
Fields
have
been
designed
and
used,
and
us
trying
to
do
that
right.
So
it's
not
specifically
written
into
the
spec.
Otherwise
we
wouldn't
be
having
this
discussion,
but
it
is
absolutely
designed
with
that
in
mind.
B
Originally,
and
so
I
can't
say
what
decisions
we
have
made.
What
we
have
made
that
that
may
have
been
influenced
like
the
way
that
that
will
mean
that
they
don't
work
properly,
and
there
are
certainly
implementations
that
are
making
that
assumption
already
that,
if
we
decided
to
just
use
Gateway
as
a
service
replacement
would
be
would
not
work
in
the
way
that
people
expect.
L
Yeah
so
I'm,
just
gonna
I'm
gonna
go
back
to
Bill's
point.
The
point
of
this
Gap
is
really
just
to
open
the
the
door
for
more
things
to
be
apparent,
ref
and
to
describe
what
the
properties
are
that
it
needs.
If
we
want
to
start
talking
about
making
things
core
or
or
not,
that's
a
separate
conversation.
The
purpose
here
is
to
is
to
not
be
so
limiting
on,
say.
The
only
thing
that
HTTP
route
can
combine
to
you
is
sort
of
and
I
think
that's
sounds
like
I've
been
living.
L
A
Well,
that
sounds
great
yeah,
and
maybe
we
just
like
take
that
to
like
narrow
the
scope
of
the
Gap
to
what
is
agreed
upon.
That
seems
the
non-controversial
part.
We
wrap
that
up
and
get
that
merged
and
then
open
a
new
discussion
eventually
on
the
cluster
IP
stuff,
as
kind
of
a
separate
scope,
so
yeah
I
think
it's
definitely
interesting
and
there's
definitely
a
lot
of
potential
there,
but
also
it
kind
of
works.
A
G
Yes,
I
think
we
already
can
so
this
is
copied
verbatim
from
the
meeting
yesterday.
The
reason
I
wanted
to
bring
so
I
think
we
already
know
canceled
for
kubecon.
The
other
one
is
we're.
Looking
at
an
EU
friendly
meeting
time
for
the
main
meeting,
we've
been
experimenting
with
EU
friendly
times
yeah.
Thank
you.
So
we
are
considering
a
couple
times.
One
will
be
April
26th.
The
other
would
be
May
2nd.
G
G
G
G
We
covered
the
contrib
summit,
which
is
Tuesday,
there's
also
a
Gateway
APA
update
on
Wednesday
morning
and
we're
planning
some
kind
of
informal
lunch
sometime
afterwards
just
means
meet
up
and
eat
together
somewhere,
nothing
fancy
but
similar
to
what
Sig
Network
often
does
as
a
larger
group.
So
we
can
organize
on
yeah
Sig
Network
API
Gateway,
API
slack
yeah.
G
D
A
E
A
A
E
F
L
G
Yeah
I
mean
for
clarification,
I
think
most
gamma
gaps
are
still
in
the
provisional
State,
not
experimental
I
think
the
bar
for
experimental
is
much
lower
and
we
likely
are
near
or
at
that
point
so
for
for
reference.
I
can
link
this.
It
needs
to
be
implemented
by
several
implementation
or
actually
no
that's
Alpha
to
Beta,
but
two
experimental,
it's
a
fairly
low
bar.
We
do
want
conformance
tests
to
be
present.
G
We
do
want
implementations
to
be
committed
to
supporting
it,
but
I
I
think
we're
we're
very,
very
close
to
you
know
it
was
something
that
just
barely
missed
the
0.7
release.
I
would
be
very
sad
if
it
missed
the
next
minor
release
of
cable
API,
so
that
would
be
either
0.8
or
1.0
depending
on.
If
we
need
an
0.8.
G
So
0.7,
what
our
predicted
timeline
is
is
I,
think
May,
2nd
or
3rd
right
now
again,
you
know
we,
we
don't
have
full
control
over
when
that
happens.
We're
waiting
on
some
volunteer
reviewers,
basically,
but
second
to
that
would
be
the
our
next
release.
We
are
very
committed
and
and
and
working
as
hard
as
we
can
to
get
1.0
out
by
Chicago.
So
that
means
really
October,
so
we
will
definitely
have
at
least
one
release
by
October
if
we
need
an
8.0.8.
That
means
that
happens
between
now
and
October.