►
From YouTube: Gateway API GAMMA Bi-Weekly Meeting for 20221018
Description
Gateway API GAMMA Bi-Weekly Meeting for 20221018
A
Hello,
everybody
Welcome
to
the
October
18th
instance
of
the
Gateway
API
gamma
Community
call
as
a
reminder.
This
community
call
is
governed
by
the
kubernetes
code
of
conduct,
which
boils
down
to
be
nice
to
one
another.
A
If
you've
got
questions,
you
can
go
to
the
kubernetes
community,
GitHub
page,
to
learn
more.
This
is
the
last
game
of
meeting
before
kukon,
which
is
exciting
and
scary,
depending
on
your
involvement
in
and
kubecon,
but
really
happy
to
be
here.
You
know
the
the
first
gamma
meeting
was
back
in
July
and
we've
made
a
good
bit
of
progress
since
then.
Having
some
great
conversations,
so
I'm
excited
to
dig
into
even
more
of
these
discussions
today.
A
Let
me
go
ahead
and
share
my
screen
and
we'll
begin
working
down
on
the
agenda.
As
a
reminder,
we
have
an
open,
Agenda
and
I'll
post
a
link
to
that
agenda
here
in
the
chat.
If
you've
got
topics,
anybody
can
add
a
topic
here,
so
please
feel
free
to
add
agenda
items
as
as
they
arrive
and
also
add
your
name
and
Company.
If
you're
representing
a
company
to
this
attendee
section
here
just
so,
we
know
who
is
you
know
part
of
the
community.
A
So
with
that
said,
if
there
are
no
questions
or
comments
at
the
beginning,
I'm
gonna
go
and
hop
right
into
our
agenda
for
today.
A
B
Yeah
I
will
be
mostly
off
camera
this
video.
So
if
you
want
to
run
through
that
briefly,
but
I'm
happy
to
kind
of
fill
in
any
missing
context,
though.
A
Sounds
good
thanks,
so
yeah
to
this
was
I
actually
been
having
to
miss
last
week's
meeting,
but
apparently
Lynn
Sun
had
a
great
suggestion,
which
I
am
very
much
in
support
for
of
doing
a
recap
from
previous
meetings,
since
gamma
does
have
alternating
time
slots
I
think
doing
a
recap
will
be
helpful
from
folks.
For
folks,
so
looks
discussion
was
mainly
around
North
South
Gateway
integration
with
East-West
routing
rules.
A
So
you
know
part
of
the
big
one
of
the
big
goals
of
gamma
is
to
try
to.
You
know,
use
Gateway
API
for
East-West
routing,
East,
West
routing,
as
well
as
my
South
routing,
and
our
initial
get
getting
immediately
tackle
the
integration
piece.
It
looks
like
that's
we're
focusing
on
last
week
there
was
some
desire
to
scope
the
Ingress
Gateway
operator,
persona
set
to
be
separate
from
these
Tervis
mesh
own
software
persona.
A
Apparently
those
are
different
roles
for
in
different
places,
and
this
is
you
know
there
is
there
of
mesh
aware
routing,
but
it's
difficult.
So
the
actual
implementation
details
are
difficult
to
do
without
deploying
a
sidecar.
Next
to
your
gateway
are
treating
your
gateway.
Special
route
delegation
might
be
a
path
forward,
but
there's
still
some
exploration
being
done
here.
There
is
a
document
here
in
the
chat
about
you
know:
ways
to
go
about
exposing
mesh
Services
through
gateways.
A
I've
taken
a
look
at
this
in
less
a
couple
of
comments.
Please
everyone
else.
If
you've
got
interest
in
this
integration
Point,
please
take
a
look
at
this
document
and
and
let
I
think
John
wrote
it.
Let
folks
know
your
thoughts.
Does
that
kind
of
cover
that
topic
well
enough,
Mike
or
you've
got
other
thoughts.
I.
B
Think
so
so
I
wrote
the
stock
the
stock.
It
was
based
on
conversations.
I
was
John
previously,
but
it
was
basically
a
one
hour
brain
dump,
so
it
is
very
much
an
early
draft
that
is
actively
seeking
contributions
for
explicit
use
cases
or
flushing
out
either
the
two
proposals
or
any
alternatives.
At
this
point.
A
Okay,
awesome
thanks
for
that
clarification.
I
was
not
sure
the
duck
so
appreciate
the
clarification
there.
It
sounds
like
this
doc
as
well
as
kind
of
the
other
thing
that
was
talked
about.
Auth
Z
proposes
I
was
part
of
I.
Was
there
for
some
of
the
previous
previous
discussion
on
off
z?
A
You
know
we
are
you
know.
Game
is
relatively
you
know
new.
Like
I
mentioned,
we,
our
first
meeting
was
in
July,
and
so
we've
we've
done
a
lot
of
good
work
and
nailing
down
some
definitions,
trying
to
get
folks
on
the
same
page
vocabulary
wise,
but
we're
looking
for
Champions.
You
know
we're
looking
for
folks
who
can
you
know
outside
of
just
Mike
John
and
myself,
who
are
willing
to
kind
of
invest
time
to
drive
some
of
these
things
forward.
A
I,
I
I'm,
very
aware
that
kubcon
is
next
week
and
that's
gonna
take
a
lot
of
folks
time,
but
after
we
kind
of
come
back
from
from
con,
it
would
be
great
to
try
to
find
some
folks
to
own
some
of
these
different
questions
and
to
bring
those
their
investigation
and
discoveries
back
to
the
meeting.
So
we
can
discuss
more
yeah,
that's
kind
of
the
the
recap,
any
questions
or
comments
on
that
for
folks
who
either
weren't
or
who
have
interest
here.
A
Thank
you
and
thank
you
for
raising
that
costume.
A
All
right
cool
next
Flynn
had
a
topic,
but
Flynn
is
not
here,
but
apologies
for,
if
I,
if
I
butcher,
this
name
liaison.
Yes
hey.
You
want
to
talk
about
some
of
onward
Gateway
thoughts
on
offense
I'll,
see.
C
Right
so
the
basically
that's
I
attacked
a
document
there.
That's
current
like
draft
proposal
for
and
what
Gateway
about
the
authentication
policy.
C
The
goal
here
is
like
I
want
to
talk
about
this
to
the
gamma
API
initiative.
I
think
we
had
a
couple
of
folks
over
there
and
we
have
goals
overlapping
as
well,
so
it's
it
might.
It
makes
sense
to
get
some
salts
from
folks
in
this
group,
and
potentially
we
can
do
some
common
API
between
the
gamma
and
by
Gateway.
C
So
this
so
we
can
support
same
set
of
extension
instead
of
like
the
developing
our
own,
like
different
apis
back
for
photos
like
authentication.
That
makes
sense
for
both.
A
Awesome,
thank
you
for
sharing
this
I
agree
that
you
know
this
is
a
some
a
place
where
we
should
try
to
collaborate.
Someone
who
was
on
last
week's
call.
My
might
need
to
correct
me
here.
I.
Think
one
of
the
questions
that
we
asked
early
on
with
gamma.
When
it
comes
to
author
and
auth
Z
is
you
know
how
how
much
of
that
should
gamma
prescribe
via
a
resource?
How
much
of
that
should
be
a
set
of
patterns
and
a
sex?
A
You
know
just
merely
be
a
set
of
patterns
on
how
to
implement
a
Gateway,
API
flavored
off
the
Aldi
policy
and
I
I.
Don't
remember,
I
I
think
the
jury
was
still
out
on
that.
One
I
do
think
you
know,
with
Envoy
Gateway
being
an
implementation
bucket,
API
it
absolutely.
If
I'm
gonna
get
was
going
to
have
a
resource,
we
should
work
to
make
sure
it
at
least
follows
any
patterns
that
we
that
we're
thinking
of
prescribing
Mike
I
saw
you
come
off
through
your
camera
on
you
got.
B
I
think
where
we've
kind
of
ended
up
at
it's
like
a
starting
point,
is
assuming
a
baseline
of
service
account
for
auth
n
so
for
health
services
are
able
to
authenticate
themselves
so
leaving
that
out
of
this
place
for
now,
maybe
exploring
how
to
make
it
modular
spiffy,
whatever
as
alternative
identities
in
the
future,
but
not
focusing
online.
C
Yeah
Flynn
as
well
so
I
think
that
that
led
to
the
next
question
is
what
the
credentials
is
sent
to
each
service
account.
Are
we
using
like
tokens
or
or
like
x509,
so
it's
or
like
what?
How
and
how
we
describe
them?
C
The
authentication
policy
for
Envoy
gateways
primarily
targeted
to
authenticate
the
user
incoming
rates.
The
current
portfolio
is
targeted.
Northwest
traffic,
but
I
I
do
also
worked
with
some
East
West
before
so
that
and
I
think
we
need
to
figure
out
those
Primitives
and
we
can
discuss
about
the
policy.
A
Okay,
that
sounds
that
sounds
right.
We've
talked
in
the
past,
thus
far.
We've
kind
of
tried
to
keep
like
mtls
x509,
relatively
out
of
the
gamma
apis
on
purpose.
A
I
I
I,
haven't
thought
all
the
way
through
okay.
What
does
it
look
like
if
we
Elevate
that
to
an
API
level?
What
does
that
look
like
from
the
user
experience
perspective?
So
that's
absolutely
a
conversation
I'm
willing
to
have
that
conversation.
Now
if
you've
got
comments
or
something
you
want
to
add,
please,
you
know
use,
feel
free
to
use
the
raise
hand
feature
or
of
Zoom
to
chat,
but
yeah.
Anybody
have
other
thoughts
on
that.
D
Yeah
so
I
think
the
I
think
like
I
I,
had
a
look
at
this
for
because
on
my
Gateway
for
for
North,
South,
stuff
and
I,
think
it
looks
great
I
do
think
so.
Legend
I
think
to
say
it
a
little.
In
a
slightly
say
what
Keith
was
saying
in
a
slightly
different
way.
One
of
the
things
that
John
and
Howard
has
pushed
for
pretty
strongly
that
I've
actually
come
to
agree
with.
Is
that
it's
really
important
that
we
leave
the?
D
D
You
know
like
whether
or
not
it's
mtls
or
something
like
that
I
mean
now
that
I
work
for
eyes
of
Allen
I
also
have
a
vested
interest
there,
because
psyllium
uses
a
completely
different
identity
for
service
for
for
service
to
service.
Auth
I
think
the
I
I
think
that
I
I
have
a
gut
feeling
that
this
is
gonna
may
end
up
being
like
the
the
back
end
capabilities
discussion,
where
part
of
what
we're
doing
here
is
sort
of
saying
for
the
not
South
case.
D
It's
kind
of
about
saying,
regardless
of
any
magic
when
you
get
to
the
process,
that's
actually
running
in
the
back
end
pod
like
how
do
you
do
off?
That's
the
that's,
the
sort
of
the
the
thing
you
need
for
the
north
south
case
because,
like
like
it's
unusual
that
you
would
have
a
north-south
implementation
that
does
the
that
does
a
lot
of
magic,
whereas
the.
D
Normal
is
the
norm
for
East-West,
implementations
and
I.
Think
that's
probably
one
of
the
biggest
impedance
matches
between
the
North
South
cases
and
the
East
West
cases
is
that
you
know
north
south
most
of
the
time.
People
want
to
be
very
explicit
and
not
have
any
magic,
and
the
East-West
case
is
the
opposite.
People
want
magic
more
and
don't
want
to
have
to
be
very
explicit
about
everything
and
I.
Think
that's
that's
one
of
the
things.
D
That's
a
bit
tricky
to
design
around
I
I,
really
I,
really
like
your
proposal
for
the
for
the
north
south
stuff,
I
I,
don't
know
how
it
worked
for
the
East
West
stuff,
because
most
of
the
time
in
the
east
west
case,
the
user
is
not
the
is
not
the
you're,
not
doing
user
or
then
anyway,.
D
So
sorry,
customers
next.
E
Yeah
I'm
pretty
interested
in
this
topic
as
well.
I
think
one
thing
that
we
need
to
address
in
particular,
given
the
integration
within
Gateway
and
and
Gamma,
is
how
do
you
delegate?
Because
in
many
cases
the
authentication
happens
in
in
the
Gateway
when,
before
for
traffic
from
the
internet,
and
sometimes
it
may
be,
past
accreditation
can
be
past
passes,
sometimes
not
because
it's
an
access
token
or
some
other
type
of
token.
That
support
will
not
be
able
to
verify
so.
E
Some
mechanisms
to
delegate
identity
will
need
to
be
defined
between
between
gateways
and
and
you
know,
the
trust
model,
also
between
Gateway
and
and
gamma,
because
if
we
any
any
delegation
of
identity
will
imply
some
requirement
of
trust
establishment
between
between
Gateway
and
Karma
and
are
pretty
complicated
topics.
But
it's
important
to
to
think
about
them
early,
because
it's
very
difficult
to
make
it
work
without
those.
C
C
Really
good
point
so
from
African
website
as
a
query
on
the
first
Target
is
the
data
authentication
I
think
that's
that's
probably
first
and
as
Michael
changed
at
the
they're
interested
as
well.
So
yeah
I
would
like
to
getting
more
comment
and
feedback
on
this
document
to
how
to
fit
this,
because
every
Gateway
is
primary
as
the
north
south
Gateway,
but
like,
for
example,
the
dedication
should
be
taken
into
consideration,
and
so
please
read
through
this
document
and
give
me
some
feedback
and
we
can.
A
Yeah
awesome
appreciate
you
bringing
this
up
to
us
sounds
like
the
action
item
then,
like
you
just
said,
is
to
read
the
doc
and
provide
feedback
I'm.
Looking
forward
to
the
conversations
that
we'll
have
around
this
is
some
interesting,
interesting,
stuff.
Yeah
last
call
for
any
other
yeah.
F
Discussion
items,
yeah,
I,
I,
think
I
want
the
plus
one
on
this
for
Nick's
comment,
I,
think
different
platform.
You
know
cloud
provider,
we
may
provide
different
kind
of
authentication
say,
for
example,
on
AWS.
We
use
IM
row.
So
basically
each
part
every
part
you
can
associate
to
it.
You
know
it
had
its
service
account
and
service
count.
Basically
and
we'll
use
it
to
assume
a
role.
That's
how
we
get
authentication
and-
and
another
thing
is
instead
of
using
YouTube
TLS.
You
know
you
need
to
have
certificate.
F
We
use
a
Sig
V4
as
a
way
of
presenting
the
identity
of
a
client
which
is
used.
You
know
it's,
it's
integrated
into
the
cloud
provider
on
AWS
I.
Just
want
to
point
that
out
so
instead
of
say,
Okay
speed
fee
is
only
way.
F
You
know
which
you
need
have
a.
You
know:
certificate
Authority,
all
those
kind
of
things,
wow
AWS
you
get
it
for
free
you
seek
before,
and
all
the
parts
will
have
the
service
count
along
with
the
iron
row
and
get
all
these
credential
by
the
platform.
E
Aws,
you
you,
what
what
do
you
get?
You
get
the
identity
as
a
token
or
how
yeah.
F
So
today,
the
way
you
know
I
think
I
put
in
the
link
to
the
chat
is
how
it
works
is.
Basically,
you
associate
your
cluster
to
your
open,
ID
or
different
identity
provider
and
and
found
the
from
the
park
perspective.
If
the
particle
Camp
is
a
temporary,
what
do
you
call
the
service
account
right,
which
is
a
token
to
a
service
account
and
what
it
does
is.
Basically,
it
will
assume
row
the
part
will
get
because
of
the
account
it
will
get
this
temporary
key.
F
You
know
which
lasts
15
minutes
so
when
the
service,
when
the
on
the
service
provider
side
when
they
receive
the
packet
from
this
part,
it
has
this
particular
token
assigned
the
packet
you
can
see
before
and
the
service
can
go
through
the
internal.
What
we
call
the
OS
runtime
server.
We
will
present
this
okay.
This
is
coming
from
this
guy.
With
this
particular
signature,
it
will
come
back
to
see
who
that
guy
is.
What's
the
account?
What's
the
privilege,
then
you
can
Define
your
observation
policy
to
see
if
this
guy
is
allowed
to
do
this.
F
F
So
that's
it's
basically
used
it's
a
you
know
pretty
well
adapted
you
get
it
for
free.
When
you
run
in
iws
and
customers,
AWS
customer
familiar
with
this
kind
of
things,
you're
going
to
use
IM
policies,
they
write
the
root,
so
it
works
for
kubernetes
and
also
for
easy
to
everything.
E
Yeah
I
agree
with
you,
something
that
we
should
support.
I
mean
I
mean
I,
don't
know
is
instead
of
what,
in
addition
to
is
a
correct
solution,
because
mtls
has
its
own
benefits
in
terms
of
you
know,
efficiency
and-
and
you
know
it's
it's-
that
part
of
the
handshake
and
and
both
of
them
are
well
established,
Solutions
but
I.
Think.
E
Yeah
is
there,
for
example,
supposed
you
know
you
can
authenticate
either
with
an
oidc
jot
token
or
you
can
authenticate
with
the
Mt
Elizabeth.
E
F
A
Yeah
I
I,
as
you
were
talking
to
me
when
I
was,
was
taken
back
to
my
town
as
a
devops
engineer
and
we
used
that
exact
functionality
on
AWS
and
it
would
be
fantastic
if
that
were
just
like
natively
done
in
kubernetes
this
API.
So
I
did
everything
that's
been
said.
This
is
something
we
want
to
try
to.
We
want
to
try
to
make
sure
is
configurable
at
the
cloud
provider
level.
A
Okay,
awesome!
That's
thinking
about
like
how
we
push
this
forward.
You
know
post
kubecon,
I'm
sure
there
will
be
another
conversation
about
this
after
kubecon
is
over,
but
I
I
think
that
you
know
it
sounds
like
authorization
and
authentication
is
it
feels
like
the
place.
People
are
wanting
to
spend
the
most
time
like
I
mentioned
earlier,
looking
for
other
Champions
to
to
push
these
things
forward,
so
you
can
maybe
maybe
try
to
parallelize
this
work.
A
We've
got
a
couple
of
different
work
streams
at
the
moment
between
continuing
down
the
the
routing
apis,
so
exposing
this
to
the
integration
between
Gateway
and
Earth
service,
stuff
HTTP
route.
We've
got
authorization
policy,
I'm
sure
that
TCP
route
will
be
a
you
know,
something
that
naturally
follows
this
work
stream.
So
lots
of
chances
just
want
to
take
a
second
and
highlight
lots
of
changes
for
people
in
the
community
to
get
involved
if
they
would
they
desire.
So
all
right,
any
last
thing
before
we
move
on.
A
All
right,
one
last
thank
you
to
Liaison
for
bringing
this
bringing
this
to
gamma
I'm,
looking
forward
to
the
collaboration
between
game
and
on
the
Gateway
on
this.
A
Right,
yeah,
absolutely
okay,
so
next
topic
is
mine.
I
wanted
to
get
a
quick
update
on
the
HTTP
route,
Gap,
PR
and
and
just
kind
of
talk
about
where
we
are
on
that
we
like
I
mentioned
this-
is
canceling
this
meeting
next
week
for
coupon
and
we've
got
some
comments
on
here
that
have
had
a
good
bit.
A
There's
been
a
good
bit
of
work
on
it
since
I
last
commented
and
then
I
got
Sean's
healing
who
posted
in
slack
as
well
as
here
in
the
GitHub
PR
for
posterity
Sean's,
got
kind
of
a
different
approach
towards
HTTP
routing
in
gamma,
and
so
I've
commented
on
this
or
been
a
couple
different
comments.
If
you,
if
you've
got
interest
in
a
different
kind
of
work
stream
towards
YouTube
HTTP
route
that
you
want
to,
you
know,
take
a
look
at
and
circle
back.
A
After
probably
after
the
pr
was
merged,
then
the
link
is
here:
it's
also
in
slack
I,
don't
believe
Sean
is
here,
but
if
you've
got
thoughts,
like
I
said
at
this
comments,
but
yeah
going
back
to
the
original
PR
I
honestly
am
not
sure
what
the
current
state
of
this
is
right.
Now,
with
all
the
different
conversation,
I
love,
the
conversation
is
great,
but
I'm
not
I'm,
not
sure
where
we
are
so
Mike.
A
Do
you
want
to
get
I'm
sorry
for
calling
on
you
so
much,
but
you
want
to
give
a
kind
of
a
brief
update
of
the
status
of
the
pr
oud.
The.
B
Brief
update
is
I
have
been
preoccupied
with
other
work
and
have
not
had
a
chance
to
look
at
this
in
the
past
week,
so
I
need
to
get
up
to
date
on
the
current
conversations
and
probably
update
this
in
response
to
anything
there.
So
I
I
need
to
get
back
to
this.
B
A
Sounds
good,
yeah
again
really
I
I've
called
on
folks
in
meetings
and
I'm
sure
everyone's
happy
as
well
to
take
a
look
at
this,
this
PR
and
and
y'all
have
so.
We
appreciate
the
thoughts
and
all
the
work
that's
gone
on
on
Mike's
part
and
on
others,
part
communicating
being
in
this
call
and
shaping
this
up
like
this
is
the
first
like
concrete,
gamma
PR,
it's
proposing
making
changes
to
apis
and
such
so.
This
is
very
exciting,
very
exciting
for
me,
and
hopefully
for
y'all
too.
A
All
right
that
is
actually
all
we've
got
on
the
agenda
today
took
the
comments
right,
quick
talking
about
identities
in
lieu.
If
you've
got
any
other
agenda
items,
then
please
please
at
them,
but
if
we
don't
have
any
others,
I
have
no
problem
going
into
this
mesh
Services
through
gateways
conversation
and
fleshing
out
of
it
and
Talking
Through.
How
folks
might
expect
that
to
work?
You
can
also
go
back
to
onward
Gateway
authentication
policy.
A
A
Tough
crowd.
Okay,
so
oh.
A
The
critiques
good
idea
so
yeah
we
can
talk
through
some
of
these
critiques.
If
that's,
what
folks
want
to
do?
There
is
a
lot
here.
Sean
did
a
pretty
nice
job
of
going
through
and
getting
together
lots
of
all
his
thoughts.
A
I
am
not
I've
read
through
it,
I'm
somewhat
familiar
with
the
arguments,
but
I
I'm
wary
of
trying
to
represent
them
to
everybody
because
they're,
not
my
arguments.
So
I'm
probably
going
to
say,
let's
not
discuss
these
right
now
since
Sean's,
not
here
to
represent
like
his
perspective
and
wait
for
Tom,
either
Sean
Ken
computer
synchronously,
or
for
folks
to
comment
on
the
document.
Asynchronously.
B
Yeah
that
that
seems
fair
to
me,
I
I,
will
say
that
like
having
read
through
this,
my
general
like
response
to
it,
is
the
the
model
of
being
of
a
service
producer
owner
being
able
to
have
traffic
redirected
transparently
to
or
sorry
opaquely
to
the
consumer.
So
the
consumer
should
not
have
to
opt
in
or
change
their
configuration
is
a
desirable
property
of
most
implementations.
B
So
the
where
this
document
uses
the
word
like
hijack
I
would
say
that
is
actually
intended.
Functionality
and
I
want
to
go
back
and
add
that
to
the
goals
of
the
Gap.
That's
currently
pending
right
now
to
be
more
explicit
about
that.
A
Yeah
that
I
I,
that's
a
plus
point
for
me.
My
my
general
thoughts
on
the
dot
can
be
found
in
this
comment
here,
but
I
I
could
what
Mike
said
I
feel
like
users
at
this
point
have
been
using
meshes
for
over
six
years,
not
all
use
but
there's
a
large
segment
of
mass
Shooters
who
use
the
way
things
work
and
you
creating
a
kind
of
Unified
Service
resource
and
a
controller
to
manage.
A
That
feels
like
it's
a
lot
of
work
to
maintain
a
certain
level
of
correctness
as
far
as
what
the
surgery
is
supposed
to
mean
to
kubernetes
that
doesn't
actually
gain
as
much
except
breaking
the
mental
model
and
Nick
as
you're
fond
of
saying
you
really
get
to
really
break
that
model
once
and
I'd,
rather
not
spend
that
Capital
right
now
on
something
like
this.
A
A
Okay,
so
I
opened
that
twice
by
accident,
I'm,
going
to
I'm
deleting
way
too
much
stuff.
Where
is
no,
where
is
my
here?
It
is
at
the
beginning,
first
tab
getting
lost
in
the
Taps
here,
so
I'm
gonna
in
from
lack
of
opinions.
It's
exposing
mess,
Services
document
and
start
working
on
it.
If
you
don't
care,
then
you
can
drop
and
if
I'm
by
myself,
I'll
just
end
the
meeting.
A
A
Okay,
cool
all
right
so
come
here
to
this
Gap,
so
this
I
am
a
bit
more
familiar
with
so
I
feel
and-
and
you
know
Mike's
here
so
I
feel
comfortable
kind
of
chatting
through
some
of
this.
A
You
know
the
state
that
the
current
HTTP
route
Gap
leaves
us
in
is
okay
cool,
there's
a
way
for
users
to
create
HTTP
route
resources
for
their
services
and
have
a
mesh
implementation
use
that
resource
to
send
traffic
to
that
service.
We
Bond
the
service
resource,
it's
a
kind
of
an
intuitive
binding,
it's
what
we
usually
probably
reach
for
great,
but
how
does
that
interact
with
Gateway
Services
or
Gateway
HTTP
route
resources?
How
does
that
delegation?
A
But
how
does
that
work?
The
point
is
made
here
in
the
in
the
dock
that
north-south
Gateway
resources
should
not
implicitly
follow
mesh
routed
rules
right.
This
is
something
that
we
kind
of
deferred
a
lot
in
our
early
conversations
with
HTTP
route
to
get
to
where
we
are
and
I'm
glad.
We
did
that
because
this
is
complicated,
but
there's
that
question
right
of
okay
implementations
pick
up
on
any
HTTP
routes.
A
A
There's
you
know
elevating
that
yeah
implicit
measure
routing
by
the
Gateway
I
feel
breaks
the
abstraction
layer
between
the
two
different
directions:
levels
of
a
routing
that
existing
the
cluster
I
see
cost.
And
you
just
added
a
comment:
do
you
want
to
speak
to
that?
Instead
of
me
trying
to
butcher
my
way
through
reading
it.
A
And
we've
got
some
over
top
level:
gold
I
messed
that
up
there.
You
go
because
some
top
level
goals
here
that
you
know
assert
as
a
service
owner.
You
want
to
expose
your
service
outside
the
cluster,
well
applying
the
same
routing
and
traffic
splitting
rules
as
inside
the
mesh.
So
this
is
the
really
common
use
case
right.
A
This
is
the
I
want
my
servers
to
be
routed
from
a
service
figure
out
the
exact
same
way,
regardless
of
whether
I
am
whether
the
traffic
is
coming
from
outside
the
cluster
or
the
traffic
coming
from
inside
the
cluster
and
then.
Secondly,
as
a
north,
south
Gateway
piano
implementation,
you
shouldn't
be
required
to
understand
or
add
support
for
any
kind
of
East-West,
Gateway,
API,
routing
mesh
routing,
so
classic
cases
like
Contour
Contours
shouldn't
have
to
understand.
A
Gamma
East
West
traffic
router
can
order
to
Route
its
traffic
cost
and
go
ahead.
I'm.
E
Curious
is
this
a
requirement
that
goal
for
the
user
or
for
particular
implementations,
because
I
mean,
as
a
user,
do
I
get
any
benefit
if
I
use
a
cluster
with
the
Gateway
implementation?
Is
that
cluster
is
not
aware
of
the
mesh
implementation
and
what
is
just
the
way
for
implementers
to
you
know:
go
for
implementers
to
not
have
to
support
different
measures
in.
A
A
How
does
it
benefit
the
the
second
Point?
How
does
the
second
Point
remember
to
benefit
the
user?
Okay,
so
in
my
mind
the
reason
the
second
Point
benefits
to
user
is
it
allows
users
to
pick
the
solution
of
them.
So,
for
example,
let's
say
that
I'm
on
a
computer
and
I
can
get
supported.
Nginx
Ingress
by
uses
Gateway
API
right
we're
talking
in
the
future
game.
You
know
get
apis
everywhere
and
you
know
I
can
get
nginx
supported.
A
Why
would
I
it
helps
user
because
the
cloud
provider
does
not
have
to,
or
rather
that's
the
wrong
letter
worth
this?
The
user
doesn't
have
to
rely
on.
You
know
a
cloud
provider
or
somebody
else
to
understand
mesh
for
their
Gateway
implementation.
They
can
take
whatever
implementation
they'd,
like
you
decouple
those
and,
and
so
that
gives
using
for
Freedom,
maybe
you're
in
a
mesh
like
open
service
mesh,
where
you
can
and
think
you
bring
any
Ingress
Gateway
osm
and
you
know
you've
got
your
choice
out
there
because
you
know
they're
decoupled
does.
E
That
make
sense
is
that
games
with
the
cost.
Basically,
because
then
they
will
have
a
lot
of
complexity,
so
basically
they
will
not
know
what
works
or
doesn't
work
and
and,
as
we
add
authorization
another
more
interesting
part,
it
will
become
quickly
very
dangerous,
because
if
it's
not
I
mean
it's
not
already
routing,
maybe
it's
a
bit
not
a
big
deal,
but
when
we
start
to
add
authorization
and
and
other
things,
I,
don't
know
how
how
well
it
will.
Maybe
it
will
be.
Okay,
I,
don't
know.
A
I
I
I
think
the
authorization
question
is
significantly
different
enough
for
the
well
yeah
I.
Think
authorization
use
cases
are
usually
different
enough
between
the
East-West
north-south
use
cases
to
where,
especially
for
the
for
the
common
case
users,
it
won't
be.
It
won't
be
too
bad,
but
that's
just
my
my
hunch
I
could
be
wrong
reading
through
the
comment
for
the
chat
here.
One
advantage
to
keep
the
couple
could
be
a
native
like
re-encrypt
from
Gateway
into
mesh.
A
That's
a
good
point
from
Mike
and
then
John
says
I
think
there
are
use
cases
for
applying
both
routes
or
to
supplying
one
possibly
or
on
a
per
route
basis,
I'm,
guessing
both
routes
being
like
Gateway
and
mesh
wrapped
and
fear
with
the
theory
possible
with
different
back-end
ref
config.
Okay,
so
strong
man
would
be
like
service
front
end
service
back
in
yeah.
So
that's
what
kind
of
was
one
of
the
questions
that
came
up
when
we
were
designing
the
HTTP
route
resource
for
for
East
West?
A
We
I
think
Nick
yeah
Nick
at
the
mirror,
Board
of
the
difference
ways
to
go
about
it
and
if
you
find
a
service
okay,
if
you've
got
a
Gateway,
that's
got
a
back
and
react
to
a
service.
That
is
a
parent
wrap
of
HTTP
route
message
reading
and
this
kind
of
nested
chain
thing
here,
because
using
different
roles
of
the
service
resource
and
I
think
that
there
is
for
that,
but
I
think
we
probably
want
to
be.
A
If
we
want
to
enable
that
use
case,
we
have
to
be
very
specific
of
what
we're
not
going
to
allow
Cycles,
wise
and
I.
Think
we
do
do
that
in
the
HTTP
route.
Gap
I
think
we
only
allow
I
mean
There
Are
Rules
there
that
you
can't
have
a
parent
ref.
That
is
a
back
end
ref
for
a
non-gateway
resource,
so
you
don't
get
into
any
levels
or
we
have
to
just
allow.
A
Yeah,
so
we
did
something
somewhat
similar
in
and
get
API.
We
have
a
separate,
separate
Envoy
like
cluster
for
the
Ingress
that
we
allow
traffic
to
come
through.
I,
don't
know
what
John
is
trying
to
say
here.
D
Think
I
think
that
Jon
Jones,
just
trying
to
say
like
the
the
sort
of
the
the
basic
thing,
is
what
we
say
in
the
dock
and
then
and
then
you
know,
but
you
can
do
some
other
type
for
back
end
and
then
maybe
get
a
different
Behavior.
But
then
that
would
be
customer
implementation,
support
right,
custom
support.
A
Okay
got
actually
yeah
yeah.
That
makes
sense
to
me.
Cool
yeah,
I
agree
with
that
I
one
of
the
benefits
API
designs.
You've
got
these
different
levels
and
toggles
to
use
with.
As
far
as
like
what
support
model
you
want
to
do
for
beta
or
Alpha
extended
core,
the
doc
has
some
API
suggestions,
and
one
of
them,
which
is
very
intriguing
to
me,
I
think
this
is
the
main
one
to
allow
the
specifying
service
and
Gateway
parent
HTTP
route.
A
This
would
on
httpr
specifically
only
to
allow
this
is
to
move
the
host
names
field
from
HTTP
route
to
parent
ref,
to
allow
four
different
host
names
in
different
parent
Rifts.
This
is
very
intriguing
to
me.
I
understand
what
it's
trying
to
model
I
I
really
wish.
There
was
a
I
should
go
back
and
add
a
an
example
here.
I
think.
E
D
I
think
this
is
this
is
so
that
you
can
have
the
you
so
that
you
can
have
a
host
name,
a
different
host
name
for
the
for
the
exposure
via
the
Gateway
and
a
host
name
for
the
Gateway
for
the
exposure
via
the
the
internal
East-West
exposure,
because
remember
that
host
the
HTTP
route
has
like
a
hosting
field
so
like.
If
you
set
the
hostname
field
to
like
external.com,
then
that
would
be
expected
to
some
extent
to
be
the
hostname
for
the
internal
one
as
well.
D
If
you're,
if
you've
got
one
HTTP
route,
that's
bound
to
a
Gateway
and
a
service,
you
need
some
weighted
between
the
different
host
names.
I
would
probably
say
that
in
my
mind,
it
seems
like
it
would
be
better
to
to
have
that
handled
at
the
you
know.
D
The
rule
should
be
don't
use
hostname
in
one
of
these
in
one
of
these
HTTP
routes
and
and
let
the
listeners
on
the
Gateway
sort
out
the
external
host
names
for
you
and,
and
then
this
and
then
just
just
don't
mention
the
hostname
would
be
sort
of
my
preference
there.
Yeah.
E
I
mean
from
my
experience,
I
mean
it
usually
it's
a
host
names
are
important
to
know
what
I
want
to
accept
and
and
I
I
always
thought
that
it's
implicit,
that
for,
if
you
attach
a
route
to
a
service.
E
It's
implicitly
added
to
the
list
of
host
names
and
any
other
list
of
host
names
are
for
access
from.
You
know
other,
because
my
service
can
be
called
with
multiple
names
and
you
control
what
names
you
you
want
to
allow,
but
I
don't
think
that
there
is
a
useful
use
case
for
specifying
the
routes
as
a
parent
only
for
a
particular
hostname,
and
if
the
hostname
is
listed
in
the
list
of
hostname
for
the
route,
who
doesn't
nobody
cares
who's
scoring
I
mean
it's,
it's
I,
don't
know
if
it
I'm
making
my
point.
A
D
It's
a
very
big
change
to
the
HTTP
route
for
the
north
south
use
cases,
because
the
hostname
being
present
in
the
main
part
of
the
HTTP
route
spec
for
the
for
the
north-south
use
cases
is
like
that
was
the
result
of
a
month's
wrangling,
have
exactly
how
that
worked,
so
I'm
extremely
reluctant
to
remove
that
field
without,
like,
like
a
extremely
compelling
case
like
that,
has
a
really
important
use
case
in
the
north-south
east
coast.
I
mean
again.
D
This
is
one
of
the
problems
of
trying
to
use
the
same
thing
for
two
purposes.
I
mean
you
do
have
you
don't
have
a
host
name,
but
you
do
have
a
section
name.
So,
like
I
mean
it's
it's
very
possible
that
you
could.
You
know
Define.
You
could
name
The
Listener
in
the
Gateway
by
the
by
the
hostname.
Somehow,
and
then
you
use
the
section
name
to
pick
the
hostname.
D
It's
hacky,
you
know,
but
that's
you
I
mean
we're
trying
to
use
the
same
object
for
two
things
like
it's
gonna
end
up
acting
because
because
the
things
are
slightly
different
and
we're
trying
to
use
like
the
same
object
to
perform
two
purposes.
E
E
D
So
so,
if
you
have
the
host
name
in
the
main
part
of
the
route,
yes,
that's
how
it
will
work
if
the
so,
if
you
have
so
no
it's
the
the
hostname
matching
rules
are
a
little
bit
complicated,
because
if
there
is
no
hostname
specified
of
The
Listener
it
it
means
match
any
hostname
on
the
route.
D
If
there's
no,
if
there
is
a
wildcard
hostname,
you
can
have
a
single
the
single
label
at
the
start,
be
a
wild
card,
which
means
you
could
have
star.example.com
on
The
Listener
and
then
having
staging
dot
example.com.example.com
in
the
normal
hostname
field
on
the
route
would
would
mean
that
the
the
thing
would
attach
the
you
know,
and
also
you
can
yeah
so
and
obviously
the
other
option.
D
D
So
the
yeah,
like
it's
kind
of
yeah,
if
the
outside
address
of
the
staging
Gateway
in
the
example
you're
giving,
is
points
to
staging.example.com,
then
then,
just
just
parent
wrapping
that
HTTP
out
to
the
to
the
to
the
staging
Gateway
will
get
you
that
thing.
You
don't
need
to
specify
the
hostname.
D
You
know
like
I
I.
Think
that
having
like
specifying
the
hostname
here
like
is
one
of
those
things
where
you
might
not
really
need
to
do
it.
It's
just
that
the
the
like
the
the
app
needs
to
understand
that
like
it
needs
to
be
good
about
not
expecting
only
certain
names
like
and
and
using
the
the
base
URL
that
it
gets
rather
than
stuff
like
that.
So
yeah
yeah.
E
D
Very
I'm
pretty
strongly
minus
one
on
doing
and
like
I'm
removing
the
hostname
field
as
it
exists
right
now
from
HTTP
right.
There
are,
there
are
a
lot
of
implications
and
it
will
deeply
screw
up
the
North
and
the
north
south
implementation,
yeah
and
so
yeah.
For
all
of
those
reasons,.
B
So
one
proposal
that
we've
discussed
is
is
not
just
remove
it
entirely,
but
rather
moving
it
from
a
CP
route
to
the
parent
reference
object.
So
in
north
south
it
actually
gets
us
the
flexibility
to
bind
to
different
host
names
on
different
gateways.
If
you're
buying
the
same
HTTP
route
to
multiple
gateways
say
like
a
stationary
production,
one,
something
like
that,
so
I
guess
it's
actually
additional
functionality
in
north
south,
in
addition
to
potentially
being
more
flexible
for
mesh
use
cases.
D
Yeah
I
think
it's
worth
writing
it
up
in
more
detail.
It
will
be
like
you
know,
adding
another
place
where
you
can
put
a
hostname
like
because,
like
functionally,
it's
going
to
be
very
difficult
to
remove
that
field.
D
Now
that
HTTP
router
is
beta
like
so
you're
like
moving
moving
the
field
means
removing
the
current
field
and
putting
a
new
one
in
right
like
function
effectively
and
so
like
doing
that
level
of
change
in
a
beta
resource
is
complicated,
like
we
will
actually
need
to
do
a
V1
beta
2
for
the
resource
to
do
that,
because
it
is
a
breaking
change.
So
yeah
like
I.
D
A
Yeah
I
mean,
and
also
to
just
make
sure
we're
clear.
What
would
probably
happen
is
that
we
would
probably
add
host
names
to
parent
ref
in
addition
to
the
code,
deprecation
thing
and
then
remove
it
later.
A
That's
also
got
some.
You
know
mental
cost
there
because
oh,
which
host
name
field,
do
I
use,
but
there's
that's
also
an
option.
So
sorry,
I
cut
you
out
costume,
go
ahead,
no.
E
No
I
just
don't
raise
my
hand
so
for
difference,
I
mean
in
initial
neutral
service.
You
can
just
specify
the
name
of
the
Gateway
and,
and
you
know,
mesh
and
I,
don't
think
any
user
complains
that
we
don't
have
this
kind
of
parallel.
It
is
that
you
need
to
pinpoint
a
particular
hostname
in
a
particular
Gateway
that
needs
to
be
referenced.
E
So
maybe
we
need
to
do
some
evaluation
of
how
many
users
need
this
kind
of
accuracy
and
maybe
add
it
after
we
have
enough
users
to
confirm
I,
don't
know,
but
requiring
it
to
be
catastrophic,
because
it's
it's
very,
very
difficult
to
to
manage
this
and
deploy
it.
When
the
route
doesn't
usually
know,
I
mean
you
have
Helm
or
you
have
some
other.
You
know.
Routes
came
with
a
commit
application.
E
Where
a
chart
you
have
three
services
and
and
routes-
and
you
know
it
will
be,
it
will
be
very
difficult
to
manage
with
Harmon
or
other
tools.
D
Yeah,
the
the:
how
does
how
do
these
resources
get
deployed?
Is
another
really
good
question
to
ask
yourself
like:
what's
what
does
the
resource
look
like
in
the
helm?
Chart
that
include
that
employ
that
deploys
an
app
right
is
a
really
good
question
to
ask
yourself
when
you're
thinking
about
this.
That's
one
of
the
reasons
why
we
have
the
the
hostname
available
in
the
HTTP
route,
because
some
people
absolutely
like
there
is
absolutely
a
use
case
where
people
are
like
I
want
to
be
able
to
do
star
dot.
D
You
know
example.com
and
then
I
want
to
be
a
people
to
be
able
to
attach
their
to
Barb
as
services
to
to
that
listener,
and
have
it
only
attached
to
that
to
that
one,
and-
and
you
know
you
want
that
thing-
that
there's
absolutely
a
use
case
where,
where
people
want
that
functionality,
I
think
that
a
far
more
common
use
case
for
simpler
things
is
going
to
be
that
you
don't
specify
the
host
name
in
or
out
at
all,
and
you
specify
the
hostname
in
The
Listener.
D
If
you
really
need
it,
you
know
as
as
JP
says
D,
you
know
that's
how
K
native
Works
K
native
needs
it
for
re,
for,
like
routing
reasons-
and
you
know
that's
what
that's
that's-
why
that
flexibility
is
there
to
enable
people
to
do
sort
of
a
more
magic,
self-service
kind
of
setup,
but
like
I,
don't
think
that
that
should
like
I,
don't
think
that's
ever
going
to
be
the
primary
use
case
for
how
the
API
is
used
and
like
I,
think
that
it
makes
doing
it
that
way
makes
makes
some
of
that
stuff
more
complicated.
D
You
know,
I
think
one
of
the
advantages
of
Ingress
was
that
you
didn't.
You
know
like
this.
Is
that
you
kind
of
a
lot
of
the
time
you
would
deploy
the
app
with
the
service
and
then
add
the
Ingress
later
Dave.
B
Yeah
I
just
wanted
to
Echo
a
good
frame
of
mind
to
have
with
designing
some
of
these
apis
like
it's,
not
just
a
user,
manipulating
them
think
of
it
as
like
a
bikinis
if
you
have
our
own
control
plane
that
will
produce
routes,
so
we
definitely
want,
for
example,
routes
or
host
names
in
the
HP
row,
and
we
want
that
type
of
fine-grained
control.
B
You
could
say
the
Gateway
might
be
configured
by
some
other
operator
and
someone
might
install
kinia
themselves
and
want
to
piggyback
off
of
that
existing
Gateway,
but
and
having
their
own
being
able
to
just
create
new
speed.
Rouses
look
lets
users
use
K
native
on
a
cluster
where
they
don't
have
access
to
the
north
South
traffic.
A
That's
a
great
call
out
completely
agree
there
lots
of
good
feedback
to
to
take
as
we
as
we
kind
of
design
this
integration
we've
got
five
minutes
till
and
I
think
that's
a
that
feels
like
a
really
good.
Like
conclusion,
unless
anybody
has
anything
else,
they
want
to
add
give
you
five
minutes
back.
D
Would
like
to
make
one
request
of
everybody:
I
know
you,
you
all
I'm,
hoping
that
you'll
have
some
kind
of
made
up
and
talk
gamma
stuff.
While
you
are
at
kubecon,
if
you
could
delegate
someone
to
try
and
keep
some
notes
and
stuff,
so
it'll
be
easier
to
catch
those
of
us
who,
sadly
can't
be
there
up,
then
that
would
be
much
much
appreciated.
E
One
one
related
comment
to
whether
it's
because
earlier
it
will
be
very
useful
for
most
proposals
to
consider
the
implications
on
on
deployment
on
helmet
and
other
tools,
because
we
find
it's
very
difficult
to
to
do
it
right
post
fact
and
puts
a
lot
of
difficulty
on
the
user.
They
will
need
to
know
the
Gateway
in
this
case
the
Gateway
name.
So
it's
it's.
You
know,
as
a
user,
I
want
to
deploy
an
application
with
Helm
with
a
single
click.
E
Now
that's
not
possible
because
you
know
to
not
need
to
find
out
a
way
to
go
into
that
cluster
figure
out
what
gateways
are
installed,
what
those
names
are
pointed
to
that
Gateway
and
after
you
find
out,
which
probably
requires
some
permissions,
because
you
cannot
list
all
the
gateways.
If
you
don't
have
permissions
and
you
only
have
permission
to
your
own
namespace,
then
you
need
to
figure
out
what
DNS
is
set
up
and
and
what
is
actual
Gateway
configuration.
D
Yeah,
the
the
I
mean
yeah.
This
is
a
pro.
This
is
a
pro
definitely
a
problem,
with
the
way
that
we
just
would
do
with
the
way
that
we
did
the
the
HP
art
Gateway
binding,
but
like
that
yeah,
that
that
process
again
was
like
extremely
evolved,
and
that
was
the
the
result
of
a
long
long
train
of
negotiations.
So
I
think
you
know
that
yeah,
it's
the
best
that
we
can
do
I
agree
that
it's
it's
it
sucks
a
bit
for
him.
D
Things
like
what
I
was
kind
of
what
I've
always
hoped
is
that
is
that
we
as
a
community,
can
standardize
on
some
like
common
Gateway
names
like
an
external
Gateway
like
a
name
of
external,
or
something
like
that
being
like
this
is
the
default
way
that
you
like
get
external
access
and
so
having
something
like
that
would
be,
would
be
sort
of
really
nice,
because
then
you
can
just
have
it
default.
Have
the
routes
default
to
the
external
Gateway?
And
then
you
change
them
afterwards.
C
D
E
As
we
are
adding
more
stuff
that
fit
into
the
same
category,
that
sucks
for
the
application,
developer
and
I
think
this
one
kind
of
fits
into
this
pattern,
because
DNS
names
are
very
difficult
to
know
ahead
of
time.
D
A
No,
no,
no
worries.
We
still
have
two
minutes
but
yeah.
Those
are
some
really
good
thoughts.
I,
hadn't
I!
Wasn't
really
you
know
myself.
I
wasn't
really
thinking
about
the
the
helm
use
case,
but
you
make
some
very
strong
arguments
there
from
a
persona's
point
of
view
and
just
a
developer
experience
so
I'll
take
another
crack
up.
We
have
where's
my
dog
I'm
gonna,
move
back
over
here
yeah
as
a
reminder.
Next
meeting
next
week
is
cancer
for
kukon.
A
That
means
because
of
the
way
we've
got
the
schedule
lined
up.
That
means
the
next
game.
I'm
meeting
will
also
be
at
3
P.M
Pacific
time,
because
they're
actually
two
separate
meetings
in
the
calendar
and
before
I
forget
because
I
know
that's
going
to
be
confusing.
Let
me
go
ahead
and
at
the
date
it's
gonna
be
like
November
1st.
A
Do
you
say,
put
my
calendar
yeah
number
first,
3
PM
PST,
so
tell
everybody
a
reminder
at
a
potion
slack
if
I'm
even
awake
after
kukon
I
will
post
and
select
room
on
folks,
so
it'll
be
at
this
time,
not
next
week,
but
the
next
week
all
right.
A
Thank
you
all
again,
looking
forward
to
seeing
some
of
y'all
in
person
at
kubecon
for
those
of
you
who
won't
be
able
to
make
it,
we
will
have
you
in
our
thoughts
and
we
will
take
notes
if
we
do
have
work
in
session.
I.
Don't
know
that
we've
got
a
formal
one,
but
that
has
two
working
sessions.
I'm
sure
can
crash
and
talk
about
all
right.
Y'all
take
care,
have
a
good
rest
of
your
day
night.
Whatever
it's
on
your
end,
cheers
cheers.