►
From YouTube: SIG Gateway API Bi-Weekly Meeting for 20220802
Description
SIG Gateway API Bi-Weekly Meeting for 20220802
A
A
A
I
want
to
kind
of
start
off
by
saying
that
the
goal
for
this
split
meeting
time
is
to
still
treat
this
as
one
meeting
and
to
continue
making
progress.
So
I
won't
be
kind
of
going
in
depth.
On
the
previous
thing
we
discussed,
we've
got
really
good
meeting
notes
that
go
through
what
we
discussed
so
there's
also
the
recording
on
the
YouTube
sick,
Network
Gateway
API
playlist
as
well.
A
John
I
think
I
saw
you
here.
Yeah
there
you
are
you
added
a
new
terminology
section
to
the
exploration
doc.
That
I
think
is
very,
very
useful.
Do
you
want
to
kind
of
briefly
go
through
and
I
can
pull
it
up
on
my
screen
here?
Do
you
want
to
kind
of
go
through
some
of
the
big
some
of
the
takeaways
and
definitions
here
and
discuss
this
terminology
and
the
racket's
not
behind
it?
Perhaps
yeah.
B
So
last
week,
if
you
guys
remember,
there
was
some
discussion
that,
like
we
were
kind
of
jumping
in
without
knowing
what
we
were
actually
doing,
okay,
so
I
took
the
time
to
kind
of
give
some
high
level
definitions
of
things
that
were
that
we're
talking
about
I'm,
not
here
to
Define
what
service
mesh
is.
This
is
just
like
this
is
what
it
means
for
the
context
of
what
we're
trying
to
do.
Everyone
has
their
own
ideas.
B
You
can
go,
read
100
blogs
about
it,
but
at
this
core
like
for
what
we're
trying
to
do
with
the
API,
the
service
mesh
is
really
just
something
that
is
doing
things
to
requests
within
a
cluster
Network
traffic
right.
So
it's
a
very
broad
definition,
which
is
intentional
because
we
don't
need
to
constrain
it.
To
say,
like
oh
service
mesh
is
something
that
puts
a
sidecar
Envoy
proxy
next
to
all
pods
right.
That's
that's
way
too
narrow
for
what
we're
trying
to
do
at
the
API
level.
B
The
important
part
really
is
just
that.
You
know
you
can
modify
requests
and
do
things
like
routing,
potentially
in
the
future
authorization
policies.
You
know
that
type
of
thing,
so
one
thing
that
was
described
for
Ingress
was
that
it
was
something
that
translates
things
from
without
context
so
like
outside
the
cluster
to
things
within
con
with
context
inside
the
cluster,
and
so
a
parallel
definition,
for
this
would
be
that
a
service
mesh
is
something
that
uses
the
context
of
the
cluster
to
modify
a
network
requests
in
the
cluster.
B
B
This
was
kind
of
defined
in
the
Gap
I
linked
here,
but
policy
is,
is
also
pretty
Broad
and
just
that
it
is
a
resource
that
attaches
to
other
resources,
so
that
could
be
attaching
to
a
route
a
workload,
the
entire
cluster,
it's
pretty
Broad
and
defined
in
the
Gap
kind
of
how
that
works,
and
these
are
all
kind
of
extension
points.
So
there's
no
core
policies,
at
least
today
in
the
API,
but
you
could
imagine
a
you
know:
someone
making
a
timeout
policy
or
something
for
their
for
their
product
or
an
authorization
policy.
B
C
B
B
C
A
B
Yeah
yeah,
so
I
think
one
of
the
main
you
know
one
of
the
confusions
with
services
that
I
think
it's
really
there's
two
parts
of
the
service
and
in
kubernetes
those
are
represented
with
one
resource.
But
when
we
start
looking
to
mesh,
it
ends
up
being
important
to
separate
those.
So
you
know
users
may
see,
there's
just
this
thing
called
a
service,
but
in
reality
at
least
how
I
like
to
think
about
it
is
that
there's
the
front
end
portion
and
the
back
end
portion.
B
So
the
front
end
is
like
how
you
actually
connect
to
the
service
right,
so
that
could
be
cluster
IP,
for
example.
That
could
also
be
the
hostname
that,
with
kubernetes
service
you
get
Auto
allocated
and
your
service
may
not
actually
have
a
front
end
at
all.
For
example,
a
headless
service
doesn't
have
either
of
those
allocated.
B
So
this
is
an
example
of
some
setup
where
we
have
a
Gateway
and
a
route.
The
route
is
actually
going
to
refer
to
a
service
in
a
back-end
ref,
which
is
very
well
named
for
this
slide,
so
we're
not
typically
accessing
the
service
through
the
front
end
in
this
case,
right,
like
the
Gateway
itself,
is
load
balancing
across
the
endpoints
as
part
of
the
service
backend.
So
we're
really
only
using
service
to
refer
to
this
grouping
of
endpoints
that
we're
going
to
send
traffic
to
now
in
the
mesh
world.
B
I
think
we
often
do
want
to
use-
and
this
is
maybe
controversial,
going
to
the
actual
design
but
I
think
there's
at
least
hypothetically.
We
may
want
to
use
the
service
front
end
as
well.
If
you
scroll
down
a
bit,
we
show
some
example
of
a
use
case
where
we
want
to
split
in
the
service
a
into
and
do
like
some
load
balancing
between
av1
and
av2.
B
D
A
The
the
thing
with
mesh
is
that
the
definitions
of
the
back
ends
are
not
defined
in
the
surface
resource
a
lot
of
times
right,
you're,
creating
arbitrary
slices
of
of
workload,
sort
of
endpoints,
so
I
think
that
having
these,
at
least
in
the
design
phase
having
those
that
front
and
back
end
split,
elevated
as
first
kind
of
first
order
ideas
is,
is
useful
for
design
and
I.
Have
my
other
question
in
chat
but
I
think
John
you
just
addressed
it.
D
B
I
mean
I
think
it
depends
like
there's
largely
two
cases
for
why
you
want
to
attach
a
route
type
object
in
in
a
mesh
right.
One
case
is
I:
I
want
to
apply
policies
of
various
sorts,
so
I
can
use
a
concrete
example
just
because
I'm
familiar
with
it
in
istio
we
have
virtual
service
and
that's
effectively
routes
and
policies
combined,
right
and
so,
for
example,
say
I
want
to
add
a
timeout
to
my
service.
I
would
create
a
virtual
service
and
I
would
say:
Okay
match
the
server
say
front
end.
B
Add
this
timeout
and
then
send
to
the
service
a
back
end
right
right,
and
so
that's
really
just
modifying
requests.
It's
not
actually
doing
any
routing.
The
other
case
is
actually
doing
routing
like
I
want
to
take
a
request
to
the
service
and
send
it
somewhere
else.
I
think
that
is
this
is
like
kind
of
the
bread
and
butter
Canary
use
case
right
here
now.
In
this
particular
case,
the
av1
and
av2
back
ends
are
probably
subsets
of
the
a
back
end
right
right.
B
C
I
think
this
is
also
one
of
the
things
it's
like
kind
of
unfortunate
consequence
of
the
like
kubernetes
service
object
being
so
overloaded
in
that,
like.
Maybe
it
would
be
clear
if
you
have
that
separation
of
a
front
interface
with
server
say
back
end
as
a
separate
box
that
points
to,
as
opposed
to
like
the
route
kind
of
like
being
an
abstracts
to
like
different
back
ends.
There
beautiful.
E
F
Yeah
I'm
just
I'm,
just
really
thinking
of
you
know,
maybe
I'm
just
stuck
in
istio
land
or
openshift
router
right.
Those
kinds
of
Technologies
in
the
Ingress
are
deciding
what
workload
to
send
the
traffic
to,
and
you
know
from
the
istio
aspect
right
you've
got
you
know.
Currently
you
have
things
like
destination
rule
where
users
can
configure
either
connection
pooling
or
load
balancing
rules
for
how
things
might
work.
I.
Think
if
you
were
looking
at,
you
know
Envoy,
maybe
more
directly.
F
A
Yeah
I
certainly
think
that
they're
phoned
buckets.
So
one
of
the
appeal
for
mesh
for
a
lot
of
users
is
I
can
keep,
for
example,
I
believe
with
istio
in
the
past.
I
can
keep
all
of
my
traffic
within
the
same
AZ.
It
originates
because,
on
the
the
proxy
Envoy
in
the
SEO
cases
is
using
the
kubernetes
topology
information
to
make
that
determination.
That
kind
of
advanced
load
balancing
is
not
possible
with
the
native
kubernetes
service
resource,
because
there
is
no
such
I
mean
technically
the
service
references
endpoints,
but
who
proxies
not
doing?
A
A
It
makes
sense
to
again,
at
least
at
a
conceptual
level
distinguish
between
the
two,
because,
when
it
comes
to
mesh,
implement
limitations,
we're
often
adding
metadata,
adding
adding
context
really
to
the
actual
workloads
or
endpoints
or
yeah
I
I
like
the
the
back
ends,
you
always
use
that
term.
We
use
you're,
adding
research
the
context
for
the
back
ends
that
are
receiving
that
traffic
in
order
to
add
really
arbitrary,
depending
on
your
proxy
implementation,
you're,
not
adding
arbitrary
groupings
based
on
context
available
to
you
and
kubernetes
services.
D
E
But
with
all
the
policies,
that's
very
useful,
but
let's
not
forget
that
everything
starts
with
an
application,
making
the
basically
request,
for
example,
to
a
particular
service,
Dot
mainspace,
which
must
be
resolved
by
DNS,
because
that's
how
it
is
implemented
and
must
result
for
cluster
fit
because
that's
what
when
it
is
written.
So
even
if
all
those
things
happen
behind
the
scene
or
other
Advanced
things
happen
ultimately
from
a
user's
perspective.
They
see
a
DNS
name
and
then
from
that
other
load,
balance
example,
foreign.
E
G
I
I
just
want
to
point
out
if
you
want
to
use,
exist,
I
really
like
the
existing
Gateway
model,
so
you
have
different
controls.
So
if
you
do
want
to
have
a
service
front
end,
you
could
use
the
listener
sections
in
the
Gateway.
You
know
to
specify
how
to
get
to
your
service
and
the
HTTP
route
really
is
a
complete
owned
by
service
team,
which
you
can
Define
all
the
policy.
How
do
you
want
to
route
to
the
back
end.
Just
want
to
point
that
out.
You
could
call
Gateway
a
different
object.
C
B
I
can
start
on
there,
so
producer
and
consumer
are
kind
of
two
words
that
we
have
been
using
to
almost
refer
to
like
not
concrete
things
but
more
of
personas.
So
the
producer
is
someone
that
authors
or
operates
a
service,
so
this
may
be
someone
that
creates
a
deployment
and
a
service
for
their
workload.
They
maybe
then
set
up
some
authorization
policies.
Maybe
they
set
up
routing
rules
to
handle
like
canaries
or
whatever.
B
So
this
is
really
the
you
know
the
person
that's
actually
running
a
service.
We
may
also
say
the
producer
workload
of
the
producer
service
producer.
Rule
like
this
is
all
referring
to
the
producer
things.
The
service
consumer
on
the
other
side
is
someone.
That's
actually
utilizing
those
Services
by
calling
it,
so
they
may
do
something
like
curl
hello
world,
so
they
are
consuming
the
Hello,
World
Service,
and
so
the
important
part
about
these.
B
The
split
is
that
these
are
kind
of
different
rules
and
possibly
in
different
trust
boundaries
right
and
so
in
the
Gateway
path
for
Ingress,
we
talked
a
lot
about
cross
namespace
boundaries
and
how
we
need
reference
grants
to
you
know
trust
those
and
that
type
of
thing.
This
is
a
very,
very
related
concept
right
if
the
consumer
and
producer
are
in
different
namespaces,
they
very
likely
do
not
want
to
have
one
person's
resources
impact
the
others
in
an
unexpected
way.
B
Right,
for
example,
if
a
consumer
created
a
rule
for
hello
world,
that
said,
like
add
a
timeout
for
five
seconds.
It
may
be
okay,
if
that
applies
for
their
own
request
to
that
service,
but
if
that
applied
somehow
to
like
the
entire
mesh
or
something
that
would
probably
be
a
clear
violation
of
this,
this
trust
boundary
right.
B
A
A
Can
you
do
with
service
finding
a
misrepresentation?
What
do
we
want
our
initial
scope
to
be
for
those
for
those
tasks
and
those
items
referencing
some
of
these
slides
from
the
PowerPoint
that
I
did
last
week
and
and
have
discussion
ensue
there.
So
we
can
start
breaking
this
out
and
get
out
of
this.
The
singular
Burdock
referring
to
it,
where
necessary,
I
want
to
turn
that
over
to
the
to
everybody
on
the
call.
What
do
you
all
think
about
that.
H
H
H
Yeah
I
think
just
another
plus
one
for
you.
Keith
I
think
that
the
separation
between
like
trying
to
just
separate
out
like
how
you
talk
about
like
the
mesh
resources
versus
the
service
thing,
is
really
good,
because
I
think
the
service
thing
for
me
is
the
hardest
thing
to
think
about
right
now,
so
separating
those
out
was
wise.
H
He
so
in
the
doc
we
talk
about
service
binding
and
it
sounded
like
unless
I
misunderstood
this
Keith,
you
were
planning
on
having
service
by
two
gaps,
one
that
talked
about
like
how
you
actually
represent
the
match,
which
is
one
section
in
the
current
Google
doc
and
then
another
Gap.
That
was
the
surface
binding
and
try
to
separate
those
out
so
that
we
can
get
the
consensus
built
around
the.
What
and
the
why
for
those
separately,
is
that
accurate.
A
H
A
A
E
A
I
want
to
create
a
a
gap
for
that
discussion,
link
to
those
definitions
for
service
front
and
or
just
for
front
in
and
back-end,
and
then
again
not
discussing
how
we
represent
things
but
have
the
Gap
discussed.
Then
you
know
maybe
the
need
or
the
scope
for
representing
what
we
want
to
represent
with
this
model
for
service
bonding.
A
H
Just
real
quick
remind
everyone
with
the
get
process,
because
the
get
process
we've
had
a
couple
of
bad
like
swampy
PRS
that
were
geps
when
something
is
status.
Provisional,
if
you
can,
unless
you
have
really
really
strong
reasons,
not
to
try
to
err
on
the
the
side
of
letting
it
go
through
like
you
can
be,
you
can
become
a
stakeholder
in
that
we
can.
We
can
make
you
somebody
that
needs
to
be
involved
for
the
eventual
move
to
implementable,
but
it
can
get
really
swampy
if
we're
spending.
H
If
we're
thinking
this
PR
is
the
complete
end,
and
sometimes
it
can
be
really
helpful
to
remind
yourself
that,
like
okay
there's
this
one
bit
that
I
don't
super
like,
but
we're
really
close,
let's
merge
it.
I
can
actually
follow
up
with
my
own
PR
to
iterate
on
this
GIF
and
that's
how
it
ideally
should
work.
Is
that,
like
you
know
that
we
we
suss
out
a
lot
of
things,
but
when
it
gets
to
kind
of
the
St
the
edges
of
things?
C
No
I
I'd
Echo
exactly
what
you're
saying,
Shane
and
I
to
add
that
in
each
one
of
these
provisional
gaps,
you
can
add
criteria
for
what
it
takes
to
move
from
provisional
to
implementable.
So
you
can
say
well,
here
are
all
the
outstanding
things
we
need
to
solve
before
we
mark
this
as
implementable,
and
if
we
get
consensus
on
that,
not
not
what
the
solutions
are.
Just
these
are
the
problems
we
still
have
I
think
that's
a
good
place
to
merge.
A
H
H
A
little
bit
no
I
appreciate
it.
It's
close,
it's
it's
I
do
not
have
a
good
reason
to
like
stop
the
the
the
mesh
initiative
so
just
to
throw
that
out
there
at
all.
In
fact,
I'm
eager
and
actually
really
wanted
to
be
a
part
of
this
initiative
and
I
actually
want
to
contribute
to
the
parts
that
are
mesh.
I
I
work
on
mash,
and
this
is
important
to
me.
H
What
I've
seen
in
the
document
so
far
I,
like
it's
kind
of
like
you
know
from
the
user
perspective
just
say:
I
need
a
mesh
and
then
you
know
you
go
and
you
provision
your
sdo
or
recuma
or
whatever
you
have
your
your
Linker
d.
That's,
all
great,
maybe
you
know
I
I,
don't
know,
I,
think
it's
going
to
be
less
contentious
than
the
service
binding
section
and
there's
some
things
that
just
don't
seem
like
right
now
to
me.
Don't
look
like
a
straight
fit
there's
this
like.
H
We
even
have
examples
in
the
service
binding
section
right
now
where
we
would
have
like
you
know.
Multiple
connections
like
we
would
basically
be
have
like
bridge
apis
to
service
and
HTTP
route
and
stuff
like
that,
and
it
just
doesn't
feel
right
yet
now
I'm
very
ready
to
be
convinced
that
we
can
make
it
feel
right
and
that's
part
of
what
we're
doing
right
now,
but
suffice
to
say
I
just
wanted
to
throw
out
the
the
call
out.
H
The
idea
that,
like
you
know,
don't
marry
yourselves
completely
to
the
idea
that
we
would
do
this
because
it
actually
might
be
better
for
everyone.
If
this
were
a
separate
API,
we
have
to
continue
to
think
about
that.
As
we
go
forward,
we
can't
get
tunnel
vision,
that's
all
it's,
but
on
the
other
hand
it
very
well
may
work
so
I,
don't
know
I,
don't
want
to
say
too
much
more
than
that,
because
I,
don't
I
feel
like
I'm,
just
I
sound
like
a
detractor
and
I'm,
not
really.
B
B
So,
if
we
look
from
that
perspective,
I
think
it's
very,
very
I
I
mean
I.
Don't
want
to
shoe
horn
too
much
if
it
somehow
doesn't
work
out,
but
it
would
be.
I
would
be
very
disappointed
if
we
somehow
could
not
use
the
same
apis
between
them
right
so
I
think
it.
It
should
be
a
strong
goal
of
this
group
to
find
a
way
to
make
it
fit
now.
B
H
H
It
sounds
good
like
it
does
on
paper
in
practice
over
I'm,
not
gonna
date
myself,
but
over
a
long
time
of
experience,
I
found
that
more
apis
tends
to
be
not
always,
but
tends
to
be
better
than
bigger
apis,
just
in
general,
for
maintenance
and
for
user
experience.
That's
been
my
that's
been
my
experience
over
like
most
of
a
decade,
so
that
said
and
I'm
not
trying
to
con
like
bind
us
with
that.
H
That
said,
I
do
have
like
this
back
of
my
head
kind
of
caution
about
overloading
apis,
but
I
also
have
the
other
point
that
that
you
made
like
Gateway
API
centered
around
the
Gateway
right
now
and
I'm,
not
saying
we
can't
change
that
actually,
but
that
is,
it
is
very
centered
around
the
Gateway
and
some
of
the
like
stuff
that
we
have
in
the
dock
right
now.
That
suggests
that
we
would
actually
use
the
Gateway
as
part
of
the
mesh
really
seems
frictional
to
me
like
we.
H
So
there's
friction
there.
I
think
with
using
Gateway,
and
the
lack
of
like
me,
feeling
like
Gateway
itself
is
really
compatible,
is
part
of
what
kind
of
makes
me
I'm
in
this
like
lurking
mode,
where
I'm
waiting
for,
like
the
everything
to
kind
of
flesh
out
a
little
bit,
because
it
doesn't
feel
like,
doesn't
feel
right
yet,
but
I
also
don't
have
anything
specifically
against
it.
Does
that
make
sense.
A
D
What
I
was
going
to
ask
all
the
way
at
the
beginning
of
this
call,
when
we
were
talking
about
this
a
little
bit
before
the
recording
started?
Was
you
know-
and
you
may
have
answered
this
already
by
saying
you-
don't
have
necessarily
have
good
specifics,
but
yeah
do
you
have
any
particular
use
cases
that
come
to
mind
that
worry
you
or
ideas
about
other
than
the
the
worries
about
the
Gateway
fitting
in
because
obviously
we
would
need
a
way
to
have
a
Gateway
be
present
in
in
interacting
with
a
mesh
in
some
fashion.
I
H
D
H
But
I
don't
feel
yet
and
again
I'm
I'm.
This
is
all
about
me
trying
to
keep
my
mind
open,
because
I
want
somebody
to
persuade
me.
I
want
to
be
persuaded.
I,
don't
feel
like
any
of
the
suggestions
that
we
have
for
HTTP
right
HTTP
route
and
how
we
would
kind
of
reuse.
It
feel
right
to
me
from
a
user
experience.
H
Like
I
want
what
I
really
want,
and
actually
this
isn't
exactly
answering
your
question
except
to
say
that
HTTP
route
doesn't
feel
like
a
shoe
into
me.
Yet
I
would
really
like
to
see
some
kind
of
like
a
a
Kube
cuddle
mock-up
of
how
a
user
is
going
to
deploy
a
mesh
and
then
start
connecting
these
routes,
like
I,
would
love
to
see
like
a
fake
documentation.
H
D
Actually,
like
I,
actually
like
the
coupe
control
mock-up
enough
I'd,
like
that
idea
enough
that
I
think
I'm
going
to
take
a
stab
at
that.
That
would
be
cool
for
the
next
time
and
yeah.
You
know
it
may
turn
out
that
we
take
a
stab
at
it
and
then
come
back
and
go
yeah.
Yeah
Shane
was
right.
This
isn't
going
to
work
at
all,
but
you
know
we'll
see,
it'll
be
a
good
exercise
right.
Ideally.
B
C
B
I
Interested
for
is
kind
of
to
have
a
split
between
kind
of
cluster
operators
and
application
developers,
and
that
was
why
I'm
kind
of
wanted
to
see
what
is
this
all
about,
because
we
want
to
actually
for
most
of
the
application
developers.
We
want
to
hide
any
aspects
of
the
mesh
at
all
because
it
was
kind
of
now
a
mess
with
managing
virtual
service.
We're
using
we're
using
istio
and
Gateway
would
be
a
clear
answer
for
that
and
I.
I
Just
don't
want
to
make
I
just
want
to
make
sure
that
kind
of
you
think
about
getting
reintroduced
mesh
topics
that
you
still
have
that
separation
of
the
focus
towards
the
cluster
and
application
developers,
because
in
General
application
kind
of
people
get
like
their
microservice,
they
they
know
what
their
route
is.
But
for
the
rests.
They
just
don't
care.
H
That's
that's
a
really
good
point
that
I
I
had
not
been
thinking
about
at
all.
Actually
I
I
think.
Is
it
fair
to
say
that,
like
so
just
to
make
sure
I'm
understanding
what
you
said?
To
paraphrase
it,
the
the
abstraction
for
the
developer
is
really
important
and
if
I'm
not
mistaken,
we
don't
really
have
a
ton
of
that
right.
H
Now,
there's
a
lot
of
decoration
that
we
have
in
the
current
models
that
you
know,
you'd
have
to
kind
of
know
that
you're
in
a
mesh
and
you're
you're,
suggesting
that
we
should
try
to
add
more
as
much
abstraction
as
we
can
to
get
as
close
to
you.
Don't
have
to
think
about
the
fact
that
you're
in
a
mesh
when
you
express
your
rights,
yeah.
I
I
H
One
for
me,
too,
I
I
hadn't,
really
been
thinking
about
this
enough.
I.
Think
a
good
action
item
actually
Keith.
You
might
want
to
consider
this
being
a
specific
motivation
in
the
bullet
points
on
your
cap
on
at
least
the
service
binding
one,
because
that's
where
that's
where
this
is
going
to
be
the
most
affected
right
like
or
where
developers
will
be
kind
of
required
to,
hopefully
not
have
to
do
a
whole
lot.
E
A
E
I
agree,
I,
I,
think
I
agree
with
you
partially
and
I
disagree
with
you
partially
of
course,
so
having
you
know,
separate
apis
and
and
because
a
mesh
and
Gateway
are
a
set
of
policies,
each
of
them
is,
you
can
think
of
it
as
a
listing
API.
That
is
more
routing
stuff
policies,
and
you
know
I
agree
with
you
that
that
we
should
focus
on
which
you
can
individually
without
caring.
If
it's
coming
from
the
internet.
E
You're
still
around
so
from
from
this
point
of
view,
I
agree
with
you
that
we
should
not
focus
on
on
the
vehicle
as
well,
but
I
think
that
the
ways
I
get
to
API
is
specified
today.
It's
not
about
you,
know,
Ingress,
it's
more
about
attaching
policies.
It's
it's
a
Cornerstone.
Is
you
know
polish
attachments,
they're,
defining
the
relations
between
namespaces
how
to
close
down
space
boundaries.
The
fact
that
the
route
is
attached
to
a
Gateway,
it's
an
action.
It's
not
necessarily
that
the
route
must
attach
to
an
Ingress
data.
E
E
D
E
Probably
so
not
to
focus
on
inventing
how
we
attach,
because
the
Gateway
API
defines
relatively
good
way
to
attach
things
to
other
things
and
different
good
policies
to
close
namespace
boundaries,
and
that's
really
important.
So
probably
we
don't
need
to
reinvent
them,
but
each
police
individually
should
not
be.
How
does
it
apply
to
an
interest
Gateway?
It
should
be
considered
independent,
so
a
route,
it's
a
route,
you
route
to
an
egress
router,
throw
me
from
extend
from
Internet
to
the
cluster
or
within
the
cluster.
It's
still
a
single
policy
to
route.
A
D
D
Think
I
get
at
that
time.
I
think
you're,
saying
that
I
think
I
heard
don't
reinvent
the
wheel
in
terms
of
attachment,
do
focus
on
the
idea
of
policies
and
routings,
and
things
like
that
being
composable
and
not
specifically
focused
on
Ingress
versus
mesh
did
I
get
that
right.
Yes,
absolutely!
Absolutely!
Okay,
awesome!
Thank
you.
G
Trying
to
if
I
heard
that
name
right
yeah.
Thank
you
guys,
I've
been
patiently
waiting
here
because
I
don't
know
if
it's
okay
to
chime
in
with
other
people
raising
hands.
So
a
couple
of
points
I
want
to
make
so,
first
of
all,
I
think
I
personally
also
struggle
with
Gateway
being
API
for
the
mesh.
Initially,
the
main
struggle
is
coming
through
Gateway
when
people
trying
to
think
about
Gateway,
it's
more
thinking
about
North
South
traffic,
but,
on
the
other
hand,
I.
G
Actually,
once
you
get
through
the
hurdle
of
you
know,
the
Gateway
API
could
potentially
config
with
mesh.
You
know,
I
searches,
think
you
know
it
needs
to
be
the
same,
because
I
really
want
to
reuse.
My
policies
I
really
potentially
even
want
to
reuse
my
routes
from
north
south
to
East-West
traffic
without
like
recreating
everything
new,
so
I
think
the
hurdle
is
there,
but
once
you
get
through,
you
know
it's.
It's
just
start
to
make
sense
to
me.
So
that's
one
thing
I
want
to
share
the
second
thing:
I
want
to
share
I.
G
I
think
the
model
that
John
laid
out
with
policy
is
really
going
to
help
with
that,
because
I
can't
even
Vision.
You
know
the
operator
providing
policies
for
everybody
to
use
and
then
the
developer
can
easily
just
opt
in
to
say
this
is
the
retry.
This
is
a
timeout
policy.
I
want
to
apply
for
my
service,
so
it
really
enables
the
developers
that
doesn't
have
to
learn
anything
other
than
maybe
just
create
the
routes
for
their
services.
A
D
D
And
things
like
you
know,
oh
I,
don't
know
messing
with
creating
a
ticket
with
the
Ops
people
to
go
and
Define
a
route
to
get
their
traffic
in
is
just
pure
friction
that
they're
never
ever
going
to
want
to
spend
attention
on
in
the
case
of
the
mesh
I.
Think
it's
also
kind
of
interesting
that
I
think
there's
an
interesting
distinction
between
the
cluster
operator,
baby,
the
cluster
provider
and
the
mesh
operator,
where
I
don't
think
those
are
necessarily
going
to
be
the
same
person
or
the
same
role.
D
That's
using
Google
to
you,
know,
they're
going
to
go
off
and
create
a
gke
cluster,
and
then
they
want
to
think
about
installing
a
mesh
on
it
and
defining
a
bunch
of
stuff
but
they're,
not
the
people
over
at
gke
in
the
gke
world
who
are
worried
about
creating
that
cluster
for
them.
Does
that
make
sense.
D
Know
exactly
and
I
think
that
that
distinction
is
important
to
remember.
Sometimes,
people
would
want
to
use
the
Gateway
API
to
define
a
mesh
and
talk
about
policies,
but
they
really
don't
want
to
be
the
one
who's
worrying
about
you
know
going
through
and
and
creating
the
cluster
itself
from
Whole
cloth
and
all
of
that
stuff.
A
I
D
A
Just
as
as
a
time
check,
we've
got
approximately
40
seconds
left
in
our
meeting,
so
I'll
I
think
I'm
gonna
go
ahead
and
and
and
call
this.
Thank
you
everybody
so
much.
This
was
fantastic
discussion
like
I
mentioned
earlier,
I'm
going
to
take
an
action
item
to
create
GitHub
GitHub
issues
on
the
API
repo
for
those
two
gaps:
Master
representation
and
service,
binding
I,
look
forward
to
your
invigorating
discussions
and
conversation
on
those
issues
and
maybe
even
clarifying
discussion.