►
From YouTube: Gateway API GAMMA Bi-Weekly Meeting for 20221011
Description
Gateway API GAMMA Bi-Weekly Meeting for 20221011
A
All
right,
hello,
everyone
good
morning
or
earlier
morning
or
afternoon
as
it
may
be,
welcome
to
the
October
11th
demo
meeting
of
the
Gateway
API
as
always
kubernetes
code
of
conduct.
The
rules
are
in
effect,
so
please
treat
each
other
respectfully
and
yeah
with
that
we
looks
like
we
don't
really
have
much
of
an
agenda
today,
but
as
always,
the
agenda
is
linked
in
the
meeting
notes.
It's
an
open
Agenda.
A
A
All
right
that
sounds
good
and
feel
free
to
jot
down
anything
that
you
want
to
expand
on
or
talk
about
next,
but
yeah
so
kind
of
like
current
state
of
things
is
we
have
a
gap
proposing
that
wait?
That's
actually
a
formal
Gap.
Now
it's
been
presented
initially
to
the
to
this
meeting
a
few
weeks
ago,
and
now
it
has
like
I
guess
two
weeks
ago
was
presented
Upstream
to
the
Gateway
API
full
north
south
group.
A
It's
proposing
using
HTTP
root
for
traffic
routing
and
splitting
for
mesh
use
cases.
It
simply
proposes
how
to
bind
to
Service
as
a
parent,
ref,
and
that
can
be
viewed.
I
will
add
that
to
3D
notes
so
that
that
can
be
filmed
there,
but
yeah
I
I've
had
a
few
folks
review
it
so
far
and
I'm
currently
in
the
process
of
entering
through
feedback,
mostly
just
like
minor
tweaks
and
deleting
some
sections
that
were
a
little
over
ambitious.
A
A
Do
we
need
to
figure
out
auth
n
authentication
like
how
I
service
identifies
itself
first
and
kind
of
where
we
ended
up
was
hopefully
not.
It
seems,
like
service
account,
is
kind
of
a
lowest
common
denominator
that
almost
every
mesh
that
is
participating
in
gamma
is
able
to
use
as
a
authentication
for
services.
So
just
like
kind
of
skipping
that
part
with
that
assumption
baked
in
for
now
it's
kind
of
the
hope
and
then
focusing
on
Multi
and
being
able
to
revisit
that
in
the
future.
A
Yet
it's
kind
of
proposals
for
how
to
integrate
the
gamma
work
and
traffic
routing
rules
for
meshes
with
the
north-south
Gateway
API
rules
and
what
should
or
should
not
happen
either
implicitly
or
explicitly.
There's
kind
of
two
main
paths
there
and
that's
going
to
be
really
important,
just
to
make
sure
that
we
don't
have
end
up
with
two
Divergent
implementations
that
sort
of
use
the
same
constructs
rather
than
having
something
that
is
cohesive
right
all
right.
A
B
B
A
C
A
B
D
A
B
A
B
So
I'm
hearing
two
questions
there.
One
of
them
is
do
I
think
we
should
try
to
flush
out
use
cases
for
off
to
Z
and
the
answer
to
that
one
is
absolutely
but
I'm
also
thinking
that
we
should
probably
revisit,
because
if
you
look
back
at
the
hack
mddock
originally,
that
was
actually
trying
to
flesh
out
a
case
where
we
had
both
a
north-south
Gateway
and
a
service
mesh,
and
that's
possibly
also
worth
you
know
revisiting
a
bit
more
I
know
that
John
did
a
later
cut
at
that
and.
B
B
E
A
E
D
B
There
were,
there
are
kind
of
two
common
cases,
but
the
actually,
let
me
back
up
a
moment.
The
overarching
common
case
is
that
as
a
practical
matter,
we
trust
the
Gateway
and
the
service
mesh
not
to
fight
over
routing.
If
that
makes
any
sense,
so
you
absolutely
could
configure
it
so
that
the
Ingress
chose
one
service
and
then
the
mesh
took
over
the
routing
and
sent
it
someplace
completely
different,
and
we
basically
treat
that
as
a
weird
Edge
case.
That
is
possible
not
really
supported.
Why
in
the
world,
would
you
do
that?
B
B
E
E
What
do
we
do
right
and
there's
kind
of
two
logical
things
like
in
one
case,
you
have
similar
to
your
setup,
where
you
have
two
things
that
can
route
along
each
request,
and
in
that
case
it
could
make
sense
to
have
the
Gateway
just
say,
like
I'm,
only
going
to
do
the
bare
minimum
routing
to
pick
the
service
that
I
want
to
send
to.
So
that's
probably
like
you
know,
slash
food
goes
to
Food
Service
or
food.example.com
Food
Service.
Absolutely
nothing
else
like
you
would
never
see
a
canary
there.
Probably
no
header,
manipulation.
E
Yeah,
if
you
and
then
at
the
mesh
layer,
then
that's
where
you
add
all
the
stuff
like
now
that
I've
picked
my
service,
what
happens
to
it?
Maybe
I'm
traffic
splitting
it
maybe
I'm,
adding
headers.
Maybe
in
you
know
all
these
other
things
which
kind
of
makes
sense,
and
let
me
explain
the
alternative,
which
I
think
is
probably
clear,
but
then
I'll
explain
why
I
kind
of
have
some
issues
with
that.
The
alternative,
of
course,
is
that
both
the
mesh
and
the
Gateway
have
all
the
routing
information
that
they
need.
E
E
That
would
work
and,
of
course,
that's
the
model
that
you
would
use
on
a
traditional
like
the
istio
console
wave,
where
you
don't
have
a
sidecar
next
to
the
Gateway.
So
both
options
kind
of
make
sense,
but
one
concern
I
have
with
the
like
kind
of
two-tier
routing
approach.
Is
that
if
you're
trying
to
transition
from
having
like
just
north
south
and
then
also
adding
a
mesh,
becomes
a
bit
less
clear
like
you
have
to?
If
you
want
to
add
mesh
logic,
then
you
have
to
go
likely
change
your
gateway
logic
as
well.
E
E
B
B
B
B
One
thing
that
I
like
about
doing
things
that
way
is
that
the
Ingress
doesn't
have
to
do
a
lot
of
special
mesh
custom
logic,
because
the
Ingress
is
being
treated
just
as
a
workload,
but
it
also
does
give
you
a
neat
way
to
separate
concerns
between
somebody
worrying
about
I,
don't
know,
API
routes
that
are
visible
to
the
outside
world
and
external
facing
policy,
and
somebody
who's
only
worried
about
things
like.
Oh,
hey,
a
new
version
of
this
thing,
deep
in
the
call
graph
is
coming
out.
B
B
So
I'll
pick
on
Emissary
Ingress
for
a
moment
where
a
person
deploying
Emissary
Ingress
gets
to
decide
whether
Emissary
will
choose
an
endpoint
as
the
destination
or
whether
it
will
just
choose
a
service
as
the
destination
and
choosing
Services
is
simpler.
So
people
who
can
barely
spell
kubernetes
are
much
more
comfortable
with
that
and
there's
a
ton
of
Emissary
users
at
that
level,
but
there
are
also
a
ton
of
Emissary
users
who
are
kubernetes
experts
and
they
may
want
to
do
sticky
sessions
and
fancy
load.
B
Balancing
algorithms
and
things
like
that,
in
which
case
they'll
set
it
up
to
route
to
an
endpoint,
so
I
do
I,
do
actually
see
both
use
cases
in
you
know,
I
saw
them
both
in
the
field
a
lot
a
lot.
A
lot.
Probably
most
of
those
users
were
not
explicitly
thinking
of
a
service
mesh
in
the
process,
though,.
E
Yeah
that
makes
sense,
I,
yeah,
I
I.
Think
it
generally
like
to
me
it's
at
least
for
that.
So
one
thing
as
well
like
the
routing
to
the
front
end
thing:
that's
very
hard
to
do
with
the
console
Easter
sidecar
model,
but
it's
something
that
obviously
Linker
D
can
do.
Probably
Cillian
can
do
and
istio
can
do
it
with
the
ambient
model
in
the
future.
A
One
thing:
that's
weird:
So
currently
console
API
Gateway
actually
does
this
model
where
we're
routing
to
this
terrorist,
which
is
it's
I,
think
it's
difficult
to
do
in
a
more
flexible
and
affordable
way,
like
the
the
sidecar
makes
it
very
intuitive
separation
of
concerns
of
thousands
to
the
sidecar.
All
that
logic
of
translating
service
to
mesh
lives
in
the
sidecar
console,
API
Gateway,
is
are
like
service
resolution
is
entwined
with
console.
So
when
you
target
like
a
service
that
is
present
in
the
console
mesh,
it
is
resolved
through
that
logic.
A
So
it
is
possible
for
us
to
do
that,
like
as
a
first
party
like
tightly
integrated
solution
where
you're
deploying
both
console
API,
Gateway
and
console
service
mesh,
it
becomes
much
harder
or
like
I,
don't
even
know
if
it
would
be
possible
without
like
introducing
new
Concepts
to
do
this
like
in
a
portable
way,
like
some
other
North
Gateway
API
north
south
implementation,
into
any
of
our
meshes.
Unless
you're
adding
an
extra
hop
through
a
sidecar,
it
becomes
a
lot
more
difficult.
B
A
A
B
E
Yeah
I
think
the
a
user
of
the
aapi
should
not
need
to
know
whether
you
know
there's
like
I,
don't
know
four
different
models
that
we
have
amongst
all
the
vendors
here.
They
they
probably
shouldn't
need
to
know
about
that,
but
those
architectures
do
help
us
guide
what
the
API
should
be
right.
We
can't
make
an
API-
that's
not
implementable,
for
example,
so
for.
C
E
E
E
Well,
I
mean
you
could
have
in
theory
we
could
say:
okay,
sure
route
to
the
service
front
end,
but
then
we
wouldn't
also
apply
the
mesh
routes
right
yeah,
because
you'd
have
to
do
both
layers
of
the
routing
in
the
same
process,
I
mean
technically,
we
could
like.
We
could
go,
make
the
Gateway
super
complicated
and,
like
somehow
do
both
routes.
We
said
we
can't
statically
immersion,
but
technically
we
could
like
forward
to
ourselves,
but
that's
like
terrible
yeah.
E
E
C
I
mean
we
do
support
protein
sidecar
right,
it's
just
not
natively
in
Israel
like
if
somebody
wants
to
bring
nginx
to
work
with
istio
I
mean
solo.
We
have
glue
ads
right
in
order
for
those
to
work
with
istio.
You
run
a
sidecar
next
to
it.
So
we
do
support
that
model,
and
it's
just
not
what
we
should.
We.
E
C
E
A
Well,
so
this
this
definitely
is
a
helpful
conversation
to
understand,
like
the
architectural
models
of
different
meshes
and
like
finding
a
comments
on
the
concerns
of
like
how
we
can
or
can't
assume
that
these
gateways
might
be
entered
through
a
mesh.
This
definitely
helps
think
about
like
what
we
can
build,
even
if
one
may
or
may
not
be
like
more
attractive.
For
other
reasons
like
like
the
Simplicity
of
the
separates
the
concerns
or
something
like
that,.
A
Well,
I
think
kind
of
the
next
steps,
for
this
is
to
definitely
like
take
some
of
this
discussion
into
the
doc
that
I
opened.
So,
if
folks
want
to
start
adding
sections,
it's
the
second
thing,
I
mean
you
know
it's
like
exposing
mesh
sources
through
gateways
and
start
adding
some
of
this
context
in
here,
specifically
the
constraints
or
deployment
models
of
different
meshes.
That
would
be
really
helpful
for
helping
to
advance
that
I.
Think.
B
E
E
Common
to
have
the
same
type
of
rules
on
both
places
right,
if
you
want
a
canary
you
oftentimes,
wouldn't
regardless
of
where
it's
coming
from
right
in
the
Easter
API,
it's
theoretically
possible,
to
have
one
single
route
that
applies
to
both,
but
it
ends
up
being
kind
of
tricky
and
I.
Doubt
most
users.
Do
it.
E
The
in
this
model
we
I
had
I,
don't
know
if
I
ever
added
to
a
public
Docker.
It
was
just
my
notes,
but
I
had
some
crazy
ideas
on
how
it
might
be
possible,
but
I
don't
think
it's
worth
the
complexity
because
oftentimes
you
end
up
with
even
if
they're,
very
similar
they're,
slightly
different
right,
yeah,
like
sure
I
might
want
the
canary
part,
but
on
the
Ingress,
I'm
matching
food.example.com
and
you
know
East
West,
I'm,
matching
it
cluster,
IP
or
I'm,
matching
slash
group
and
rewriting
it
on
the
Ingress.
E
But
I
don't
have
that
internal
or
something
like
that
so
I
guess
what
I'm
trying
to
say
is
that
they
end
up
being
very
similar
and
they
both
need
to
be
configured
but
they're.
Slightly
different
in
practice
is
what
I
see
a
lot
now,
if
you
did
have
like
the
two-tier
model,
maybe
you
get
rid
of
some
of
that
duplication,
potentially
any
other
issues
that
we
discussed.
Yeah
yeah.
A
That
was
the
model
that
I
felt
would
be
most
attractive
like
it.
I
feel
like
it's
less
common
to
exposes
service
directly
at
the
root
on
the
Gateway
like
at
in
a
host
name,
or
something
like
that.
But
you
might
want
to
like
direct
traffic
from
slash
admin
or
slash
cart,
or
something
like
that
to
follow
the
same
rules
as
resolving
that
service
within
the
mesh.
C
D
C
Without
exposing
to
the
Gateway,
and
also
there's
like
maybe
George,
processing
differently
on
the
Gateway
was
the
internal
routes,
so
that
could
potentially
be
different.
I
think
we
had
a
user
have
requests
like
the
services
from
external
of
the
clients
outside
of
the
cluster
was
inside
of
the
cluster.
They
want
to
handle
jot
the
sessions
differently,
so
that's
potentially
results
in
different
route
rule
as
well,
so
I
think
there's
definitely
some
value
to
have
it
separate
secretly.
If
they
choose
you.
B
A
B
B
Okay,
no,
no
switching
time
yeah.
Basically,
my
experiences
lines
up
pretty.
Similarly
with
lens
I
think
where
we
do
see
people
wanting
to
do
different
things
at
you
know
different
levels,
so
I
think
that
that
I
think
we're
seeing
that
this
is
something
that
we
should
support.
Is
that
you
see
some
broad
consensus
there,
I
guess
the
question
is
trying
to
arrange
it
to
not
be
ridiculously
complex.
If
you
don't
need
it.
E
What
we
think
users
do
and
what
makes
sense
to
them,
and
we
have
all
these
different.
We
have
actually
a
few
like
concrete,
different
ideas
on
how
things
can
work.
Is
there
some
way
that
we
can
like
do
a
survey
of
users
like?
Does
this
make
sense
to
you,
we're
like
which
one
makes
more
sense
to
you.
E
C
Idea,
I
think,
maybe
when,
when
we
have
some
of
the
initial
API,
we
can
build
some
example
and
maybe
run
some
survey
program
with
the
user.
I
think
I
think
most
of
users
would
be
able
to
understand
the
API.
If
there's
an
example,
if
this
is
just
the
API
without
example,
it's
too
hard
for
them.
They
wouldn't
spend
the
time
to
manually,
build
the
example.
They
would
just
walk
away.
E
E
B
I
think
it
might
also
make
sense
in
that
one
to
ask
you
know
sorry,
let
me
phrase
that
differently:
I
could
see
a
place
in
such
a
survey
for
a
more
open-ended
question
of
you
know.
Okay,
so
how
would
you
we
know
what
sorts
of
things
do
you
see
doing
differently
at
north,
south
and
East-West
levels,
and
things
like
that,
but
I
actually
really
like
the
idea
of
providing
some
examples
and
seeing
what
people
think
and
I
have
no
idea
how
to
do
that
survey
so
I,
don't
know
I.
C
E
C
A
I
think
one
of
the
tricky
things
too
is
making
sure
to
be
able
like
and
that's
why
I
think
trying
to
see
if
there's
anybody
in
the
cube
ecosystem,
that,
like
knows
how
to
do
as
well,
is
making
each
other.
We
can
do
it
in
like
a
vendor
neutral
way,
so
that
we
get
perspectives
from
console
users,
sdo
users
totally.
C
D
A
A
C
A
C
B
A
Feels
like
a
good
summary
of
like
there's
simultaneously
like
significant
contention
of
like
we're
all
over
the
place
with
a
dozen
different
ideas,
and
there
was
very
little
contention
on
like
starting
with
the
Baseline
of
Let's.
Ignore
often
for
now.
A
student
service
account
that's
a
common
Baseline
and
we
we
need
a
proposal
of
some
sort
that
will
eventually
have
more
discussion
over.