►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210510
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
We
are
recording
happy
monday,
everyone,
thanks
for
making
it
to
the
new
time
for
gateway
api
meetings.
This
is
may
10
and,
of
course,
we're
rotating
between
different
times
now
going
forward,
and
hopefully
that
allows
more
of
us
to
show
up
at
different
times
and
be
involved,
but
with
that
thanks
to
everyone
for
making
it.
The
first
topic
I
wanted
to
get
through
here
is
the
reworking
of
gateway
and
route
binding.
Now
this
is
kind
of
the
we're
starting
a
whole
lot
of
new
things.
A
Today,
one
we
have
themes
for
every
meeting.
A
I
think
it's
going
to
be
pretty
familiar
to
many
of
us
and
I
think
we
already
mostly
have
consensus
here,
so
I
wanted
to
start
with
one
that,
although
it's
large,
maybe
familiar-
and
maybe
something
like
that,
we
are
close
to
agreement
on
so
with
that.
Let
me
run
through
and
open
up
the
issues
that
started
this
discussion
mark.
I
think
you
had
the
first
issue
on
this,
and
this
was
really
suggesting
that
our
open
selection
by
default
was
not
a
great
experience.
A
This
is
something
that
we
talked
about
briefly,
but
we
immediately
identified
hey.
This
is
a
breaking
change,
so
we
can't
do
anything:
let's
wait
until
v1
alpha
2.,
and
what
do
you
know
we're
at
v1
alpha
2
now,
so
this,
I
think,
is
one
that
one
of
the
inspiring
issues,
probably
the
first
one
that
came
up
and
then
the
other
issue
is
really
related
to
this
dock,
and
it's
one
that
I
created
here.
It's
594
and
this
explored
some
different
ways.
A
We
could
try
and
improve
this
round
selection,
and
this
really
is
this
issue
is
really
coming
from
this
dock,
where
I
was
writing
through
all
these
different
approaches.
I
think
many
of
us
have
seen
this
already,
but
stop
me
if
there's
places
that
seem
unfamiliar
strange,
don't
make
sense
whatever
this
was.
A
Actually
I
remember
this
and
it's
it's
called
out
right
in
the
intro
watching
tgik
actually
and
seeing
a
number
of
new
people,
try
this
api
out
and
and
see
what
they
expected
and
then
see
what
actually,
our
api
did
made
it
clear
that
it
was
more
confusing
than
I
think
we
wanted
it
to
be
so
that
combined
with
mark's
earlier
feedback
in
that
issue
made
it
seem
like
hey.
We
need
some
some
room
for
improvement
here.
A
A
Our
cross,
namespace
selection
is
relatively
complicated
because
you
have,
you
know,
arrows
in
each
direction,
lots
of
different
things
that
have
to
agree
with
each
other,
not
necessarily
the
end
of
the
world,
but
it
is.
It
does
add
a
lot
of
complexity
when
we
do
that
cross
name
space
bit
but
yeah,
there's
a
variety
of
open
issues.
Route
should
be
able
to
forward
to
cross
namespaces
this
I
pushed
off
punt
it
off
till
next
week.
A
Route
should
be
able
to
select
gateways
by
class.
I
think
we
ended
up
closing
this
john.
You
may
be
no
okay,
john
yeah
you're
on
this
call.
Do
you
remember
what
happened
here?
I
know
we
yeah.
I
guess
it
helps
but
doesn't
completely
solve
the
specific
use
case.
A
B
I've
talked
a
bit
with
you,
I
think
individually,
like
we
could
have
the
idea
of
I'm
not
sure
if
everyone's
familiar
with
the
new
selector
labels
that
they've
added
to
namespaces
by
default,
it's
like
kubernetes.metadata.name,
it's
automatically
added
to
every
namespace.
B
B
B
B
There's
some
examples
here
like
one
would
be
if
your
route
say
has
like
some
nginx
authorization
policy
attached
to
it,
and
you
want
to
make
sure
that
no
gateway
classes
other
than
nginx
selected.
You
could
you
know
explicitly
say
this
must
be
something
that's
in
the
nginx
class.
So
then
would
ensure
that
nothing
else
reads
it.
That's
obviously
solvable
by
saying
that
it's
like
a
required
policy,
and
maybe
we
should
solve
that
a
different
way.
C
I
mean,
but
I
mean
today
the
way
you
would
kind
of
address
this.
Is
you
you'd
reference
specific
gateways
by
name?
So
I
guess
what
I'm
curious
about
is
like
what
are
the?
What
are
the
operational
or
the
deployment
use?
Cases
where
you,
where
select
where
sorry
specifying
a
gateway
by
name,
is
kind
of,
is
awkward
or
insufficient.
B
A
I
I
think
an
argument
could
be
that,
instead
of
selecting
by
name,
you
might
choose
to
label
your
gateways
in
a
in
a
meaningful
way,
but
I
I
know
that
does
lose
some
bit
of
the
the
trust
I
I
guess
maybe
a
core
concept
I
had
is
you're
really
granting
trust
to
namespaces.
A
I
don't
know-
maybe
maybe
that's
reaching
too
far
there,
but
that
was
at
least
my
thought
with
this
proposal
was
that
once
you
trust
someone
in
a
namespace,
then
you
know
if
they're
a
gateway
admin.
They
can
recreate
the
gateway
name
foo
and
do
whatever
they
want
with
it.
There's
not
much
difference
with
the
specific
name
of
a
gateway
or
or
class.
A
Okay,
I'll
keep
on
running.
This
is
one
that
I
need
to
follow
back
up
with,
because
I
had
missed
this.
As
I
was
running
through
things
today,
the
other
ones
were
just
yeah.
We
need
better
coop
cuddle
output,
I'm
working
on
that
upstream
and
the
one
that
mark
described
for
a
non-empty,
selector,
so
yeah.
So
I
think
many
of
you
have
seen
this
before
I.
Yes,
we
can
absolutely
improve
documentation.
A
Yes,
we
can
require
a
gateway
route
selector
to
specify
labels,
but
what
I
really
want
to
get
down
to
before
going
through
all
these
you
know,
relatively
smaller
changes,
is
the
larger,
more
dramatic
option,
which
is
the
third
option
which
I
proposed
in
the
issue
above
and
so
this.
This
is
really
just
trying
to
take
everything
that
we
have
in
gateway
and
recreate
it
on
route,
which
may
seem
like
too
much
almost,
but
it
does
buy
us
a
great
deal
of
consistency.
A
I
think
so.
What
we
would
have
is
again
gateways
would
be,
would
allow
routes
to
connect
to
them
within
the
same
name.
Space
by
default,
but
routes
would
have
to
specify
some
kind
of
selector
would
have
to
go
out
of
their
way
to
select
gateways
to
connect
to
so
what
this
means
is.
A
The
focus
shifts
from
gateway,
selecting
routes
to
routes,
selecting
gateways
and
both
both
options
still
work.
Here,
it's
entirely
possible
to
do
the
same
workflows
we
had
before
minus
the
gateway,
selects
everything
by
default,
that
that
one
thing
doesn't
work,
but
the
big
difference
with
this
approach
is
routes
are
selecting
gateways,
and
it
looks
something
like
this
so
in
this
case
from
selector
from
same
namespace,
etc.
A
It
allows
what
I
think
is
a
fair
amount
of
flexibility
and
a
shift
in
focus
that
matches
the
kind
of
feedback
we've.
At
least
I've
been
seeing
initially,
which
shows
that
users
create
a
route
and
then
they
want
to
attach
that
route
to
a
gateway.
A
So
if
that's
the
model
that
we're
seeing
something
like
this
seems
to
make
sense
to
me,
it
enables
almost
all
the
existing
functionality
that
exists.
It
keeps
up
with
that.
You
know
that
use
case
that
we've
been
presenting
of.
I
have
a
gateway
as
a
gateway
admin.
I
want
to
replace
it
with
another
one
that
can
happen
seamlessly.
There's
kind
of
this
loose
coupling
going
on
and
I
think
maybe
most
importantly,
instead
of
the
route
and
gateway
config
being
slightly
different.
A
They
become
nearly
identical
in
in
shape
and
function,
and
I
think
that
may
be
easier
to
understand
yeah.
So
any
any
questions
with
this
approach,
any
any
feedback
hesitation,
I
recognize
it's
a
big
change.
C
A
No,
no
I
this
is
I'll,
clarify
that
my
feedback
is
from
internal
testers
when
we
were
in
private
preview
for
gke.
So
it's
a
fairly
small
set.
C
So
I'm
wondering
if
you
know,
if
we're
altering
that
that
model
are
we
altering
it
in
response
to
feedback
for
people
who
are
like
trying
to
do
things
in
production?
Or
is
it
that
you
know
people
who
are
just
kind
of
playing
with
it
and
experimenting?
It
are
not
doing
the
same
sorts
of
things
that
you
would
do
when
you're
trying
to
trying
to
manage
a
real
app
or
don't
have
the
same
sort
of
organizational
structure.
E
Isn't
part
of
it
that
we
were
that
this
is
direct
results
of
feedback
of
people
having
a
hard
time
understanding
what
was
going
on.
A
Yeah,
I
I
think
you're
both
right.
I
I
think
that
this
this
is
the
direct
result
of
confusion
from
users,
though
I
would
say
I
I
don't
know
of
any
users
right
now
that
are
using
this
api
in
production.
They
they
very
well
could
exist.
A
F
We
did
get
both,
I
mean
we
got
users,
we
get
both
classes
of
problems,
we
got
users
that
were
just
confused
by
it,
and
then
we
also
got
users
or
field
folks
that
used
it
and
said
this
is
totally
not
going
to
work
for
my
customer
and
specifically
the
empty
selector
that
would
select
routes.
You
know
all
routes
was
the
biggest
source
of
friction.
F
F
We
heard
a
couple
of
times
and
so
yeah
and
we
and
the
two
kind
of
persona
use
cases
that
we
saw
are
one
where
the
gateway
administrator
wanted
to
be
the
ones
that
basically
determined
which
routes
were
exposed
like
basically
they
they
looked
at
the
routes
and
said:
okay,
I
will
determine
how
these
routes
get
exposed
and
there
is
another
gateway
persona
that
was
interested
in
just
more
self-service
like
here
are
the
gateways
that
exist.
You
can
choose
how
to
expose
yourselves,
and
so
those
are
kind
of
the
two
paths
that
we
saw.
A
Yeah,
that's
really
helpful
and-
and
I
should
clarify
mark-
is
much
more
in
touch
with
customers
than
I
am
on
this
side,
so
yeah.
Thank
you
for
the
clarification
there,
yeah
and
and
that
matches
my
expectation
at
least
that
having
more
sane
defaults
or
more,
I
hate
to
say,
secure
defaults,
but
anything
anything
like
this
would
would
help
with
visibility
would
help
with
buy-in
from
those
larger
organizations
that
are
more
security.
Conscious
and
really
like
mark
said
that
that
concern
about
exposing
things
accidentally.
A
A
Okay,
any
any
more
questions
or
comments
on
this.
A
So
I
do
want
to
highlight
here
that
this
is
obviously
not
all
just
wins.
You
know
this
is
very
clearly
a
breaking
api
change
and
a
relatively
significant
one
at
that.
I
also
have
to
recognize
that
this
two-way
selection
model
could
get
more
confusing.
It's
not.
You
know
this
is
different,
but
I
don't
want
to
just
make
a
change
for
the
sake
of
being
different.
I
want
it
to
be
something
that
is
easier
to
understand.
A
I
think,
from
my
limited
perspective,
this
is
easier
to
understand,
for
the
simple
use
case
of
my
route
is
going
to
bind
to
this
set
of
gateways
or
this
gateway
specifically,
so
I
just
want
to
say
gateways
xlb
or
whatever,
whatever
implementation
I
want
here
and
it
works,
and
that
feels
pretty
compelling
to
me.
A
On
the
other
hand,
I
recognize
the
more
options
we
provide.
It
does
mean.
The
most
complex
case
is
still
quite
complex
here.
If
you
have
real
two-way
selection
happening
that
could
get
messy.
A
The
other
proposal
is
the
other
thing
that,
I
think
is
unfortunate.
Is
we
have
this
precedent
in
kubernetes
that
a
empty
selector
should
select
everything?
I
think
that's
really
not
a
great
standard,
but
that
is
what
is
in
the
kubernetes
api
definition
for
meta
v1
label
selector.
A
A
E
Any
thoughts,
I
think,
the
the
the
fact
that
the
route
to
like
the
behavior
is
like
the
service.
You
makes
that
one
less
of
a
big
problem
in
my
book,
the
defaulting,
the
defaulting,
meaning
yeah,
not
select
anything.
I
think
it's
better
for
security,
as
you
say,
and
also,
if
you
know,
given
that
that's
how
the
service
works,
I
think
we
can
be
like
look
where
yeah
we're
working
in
the
same
space
as
the
service,
and
it
makes
more
sense
to
do
it
this
way.
So
the
prior
art
is
quite
a
good
case
here.
E
A
Yeah,
I
know
I
agree-
I
I
can't
imagine
the
ux,
if
service
empty,
selector
selected
all
pods
in
the
name
space
that
just
I
I
can't
imagine
what
that
would
result
in,
but
yeah
so
glad
we
have
that
prior
art,
I
think
yeah.
This
is
just
a
simple
example
to
try
and
show
what
this
could
result
in
so
you've
got
a
gateway
with
a
simple
label
and
you
just
say
hey:
I
want
to
expose
my
route
using
gateway
of
class
with
this
label
and
similarly
for
the
multi-listener
example.
A
This
is
a
little.
This
is
a
lot
funkier,
but
you
this
is
kind
of
showing
how
bi-directional
selection
could
work.
So
in
this
case
you
add
this
thing
of
okay,
I
want
to
select
routes
that
support
http
and
rouse
is
for
hps,
and
this
is
one
potential
way
to
do
that.
This
is
again
a
little
funky,
but
in
this
case
this
this
way
of
labeling
the
http
route,
says:
okay,
http
gateway.
Yes,
I
want
to
support
this,
but
I
don't
want
to
support
https
or
or
vice
versa.
A
This
feels
like
a
bit
of
a
stretch.
There
may
be
a
better
way
to
do
that,
but
this
was
one
way
to
work
around
this
kind
of
bi-directional
approach.
I
don't
know
if
this
is
the
best
example
here,
but
I
just
tried
to
explore
what
a
multi-listener
world
may
look
like
where
you
don't
want
a
route
to
bind
to
every
listener
in
the
gateway.
A
Okay,
well
I'll
keep
on
I'll
keep
on
going
with
this
there's
a
lot
a
lot
in
this
stock,
so
I
want
to
encourage
people
to
take
some
time
to
review
it.
I
think
james
asked
if
I
could
send
this
out
to
the
mailing
list
again.
I
think
that's
a
good
idea
to
get
some
more
eyes
on
this
and
and
see
what
what
the
broader
audience
thinks
of
this
kind
of
change.
It
is
a
pretty
significant
one,
and
you
know
I
recognize
it
is
likely
not
perfect,
but
any
any
feedback.
A
Any
ideas
would
be
really
helpful
on
this.
Let
me
run
back
through
this
issue,
because
I
think
there
was
at
least
a
little
bit
more
conversation
here,
john.
I
think
you've
mentioned
yeah,
so
we
had
some
consensus
here,
but
more
recently,
john
mentioned
that
we
don't
have
a
good
answer
for
port
matching
right
now,
so
it's
possible
to
do
that
kind
of
last
example.
I
showed,
but
that
may
not
be
everything
we
ever
want
to
do.
A
So
I
think
this
is
maybe
a
little
bit
something
we
can
move
outside
of
this
conversation
potentially
and
if,
if
we
really
need
port
matching,
we
could
do
it
as
like
similar
to
how
host
name
works,
where
it
is
almost
like
a
matcher
on
the
route
as
opposed
to
something
that's
tied
to
gateway
route
binding.
A
C
So,
to
be
completely
honest,
I
haven't
read
any
of
this,
so
I'm
seeing
all
this,
I
I
need
to
sit
down
and
read.
C
I
think
at
the
point
where
you're
duplicating
things
or
making
the
same
api
available
across
like
gateways
and
routes,
then
I'm
not
sure
if
it
feels
simpler,
yeah
yeah,
I
wonder
if
you're
like
making
the
model,
you
know
by
moving
things
by
being
able
to
do
the
same
thing
now
in
two
different
ways,
your
you
know,
the
responsibilities
of
objects
in
the
model
become
blurry,
which
means
makes
the
whole
thing
kind
of
more
harder
to
reason
about
so
yeah
and
I
need
to
read
it
properly
to
have
better
feedback,
but.
F
The
api
changes
I
I
I
think
I
actually
did
a
pretty
good
job
of
making
the
most
common
use.
Cases
really
easy
and
the
least
common
use
cases
require
a
little
more
work
like.
So
if
it
feels
like
it
does
prioritize
kind
of
on
the
the
things
that
are
most
likely
to,
but
the
types
of
matches
that
are
most
likely
to
be
used
so
yeah
anyways,
yeah.
A
Yeah
I
know
I
I
appreciate
that
feedback
from
both
of
you.
I
I
think
mark
like
you're
saying
this.
This
emphasizes
this
simple
example,
and
I
think
the
simple
example
is
better
than
our
simple
example.
Today,
that's
my
naive
interpretation,
but
I
I
also
get
where
you're
coming
from
james,
especially
looking
at
all
the
config.
All
the
potential
config
that
is
available
here
is
rather
overwhelming,
and
there
are
lots
of
different
ways.
A
You
could
do
this
that
could
get
quite
confusing
and
when
you
start
to
look
at
those
more
advanced
use
cases,
you
could
very
very
likely
start
to
wonder.
Well.
Is
this
actually
simpler.
E
C
C
A
Yeah,
that
makes
sense,
and
I
I
do
think
that
fundamentally,
what
we
should
focus
on
here
is
trusted
namespaces
right.
So
if
really,
what
what
we
care
about
is
as
a
gateway
admin
you
care
about
what
namespaces
you
trust
route
admins
in,
because
beyond
that,
that's
that's
really.
As
far
as
you
can
go
once
someone
can
create
routes
in
a
namespace,
they
can
do
whatever
they
want
to
connect
to
your
gateway.
A
So
the
namespace
boundary
is
really
the
key
thing
for
gateway,
admins
and
likely
similar
for
route
admins.
But
if
we're,
if
the
primary
concept
here
that
we're
trying
to
switch
is
that
route
admins
are
selecting
up
that
route,
admins
are
defining
what
gateways
they
want
to
connect
to
and
gateway.
Admins
are
primarily
concerned
with
describing
where
they
trust
route
admins.
A
Maybe
I
I
think
this
model
still
works
for
that,
but
there's
a
there's
a
lot
of
possible
configuration
here,
and
maybe
we
don't
need
every
little
bit
of
it,
but
I'm
not
sure
yet,
but
you're
right.
We
need
to
be
very
clear
about
the
use
cases
we
want.
A
A
All
right
well
I'll
this,
this
doc
will
be
visible.
For
you
know
it's
it's
already
gotten
some
good
feedback,
but
any
any
new
comments,
any
thoughts
we
got
all
I'll,
try
and
respond
to
them
on
here
or
on.
I
think
this
issue
is
kind
of
an
umbrella
issue
that
tracks
discussion
as
well,
so
whatever
works.
I
would
appreciate
any
kind
of
feedback
on
this.
A
G
G
So
I
wonder
if
if
we
just
changed
our
mindset
and
said
you
know
we're
not
going
to
have
this
bidirectional
relationship
and
and
routes
just
bind
to
all
gateways,
and
in
doing
so
we
we
look
at
other
existing
apis
for
the
more
security
conscious
use
cases.
So
I'm
thinking
like
the
network
policy
api
is
that
something
that
we
could
possibly
utilize.
C
Yeah,
that's
interesting:
okay,
yeah!
I
was
going
to
say
basically
the
same
thing.
That's
really
interesting
idea
like
if,
because
the
if
you
as
if,
if
our
assumption
is
that
you
know
that
the
user
that
creates
the
gateway
is
more
privileged
like
when
way
back
at
the
start,
we
had
this
idea
that
okay
gateway
is
to
select
routes.
So
there's
a
very
clear,
but
you
know
unidirectional
flow
of
responsibility
and
then
we've
now
got
a
bi-directional
flow,
but
yeah
there's.
C
I
think,
there's
a
lot
there's
precedent
for
extracting
the
policy
out
into
a
separate
object.
So
one
way
could
be
having
a
you
know:
gateways
select
routes,
and
then
you
have
a
separate
route
policy
object
where,
if
you
do,
if
you
are
a
route
owner-
and
you
want
to
say
something
else-
then
you
could
say
it
in
that
separate
object
to
get
your
bi-directional.
A
Yeah-
and
I
I
think
the
unfortunate
part
of
selectors
is
by
definition,
we
end
up
with
some
level
of
bi-directional
agreement,
not
agreement,
but
coordination.
A
So
with
the
selector,
the
resources
you're
selecting
have
to
be
labeled,
you
know
with
with
matching
labels,
and
so,
if
I,
as
a
gateway
admin
say,
I
want
to
select
all
routes
with
app
equals
foo
and
someone
creates
a
new
route
and
happens
to
label
it.
That
way,
then
they're,
basically
just
choosing
to
attach
themselves
to
that
gateway
there's.
A
So
so
you
do
have
the
two
roles
interacting
in
some
way,
and
what
I
think
we're
most
concerned
about
here
is
trying
to
define
the
level
of
trust
involved
and
the
story
within
a
namespace
is
very
straightforward
because
really
within
the
namespace,
you
have
to
assume
that
you
trust
other
operators
within
that
namespace.
If
someone
can
create
a
route
in
the
same
name,
space
as
a
gateway,
they
likely
should
be
able
to
attach
the
two.
A
The
part
that
gets
confusing
is
when
you
cross
that
namespace
boundary
and
that's
where
all
our
kind
of
advanced
bi-directional
logic
really
belongs.
Maybe
there's
a
better
simpler
way
to
do
that,
but
I
I
am
hesitant
to
introduce
too
many
additional
forms
of
config,
crds,
etc.
If
we
don't
have.
A
To
but
with
that
said,
I'm
very
very
interested
like
if,
if
there
are
other
proposals,
I
think
primarily
right
now,
I've
just
written
up
a
doc
and
some
an
issue
and
etc.
But
if
anyone
else
has
has
different
thoughts,
if
you
want
to
add
them
to
the
existing
dot,
create
your
own,
whatever
I'm
very
interested
in
exploring
more
than
just
this,
don't
want
to
have
a
monopoly
on
this
idea
or
concept.
G
G
That's
kind
of
what
I
was
thinking
as
opposed
to
saying,
let's
add
another
crd
to
our
crd
list,
but
I
guess
I'm
thinking
more
of
the
network
policy
api,
but
I
guess
I
don't
know
how
that
would
work,
because
it's
not
like
these
are
two
different
pods
that
are
trying
to
communicate
with
it
with
each
other.
We're
basically
saying
hey
this
route,
which
is
essentially
a
configuration
snippet
being
added
to
a
particular
gateway
right.
E
Yeah,
I
think
that
it
might.
It
would
make
sense
to
me
that
if
you're
going
to
have
something
extra,
it
would
be
a
policy
decision
right.
It's
a
if
you're
going
to
have
something
that
controls
our
relationship.
It
would
need
to
be
a
policy
object
of
some
sort,
but
network
policy
doesn't
seem
like
the
right
one.
You're
right,
yeah.
F
F
But
if
the
number
of
gateway
resources
are
few,
then
it's
almost
like
a
lot
of
your
mapping
is
just
on
the
gateway
itself,
which
isn't
that
much
of
an
issue.
If
there's
not
many
of
them,
that's
kind
of
these,
I
guess
the
assumption
we've
been
going
off
of.
Is
that
there's
not
going
to
be
that
many
gateways,
maybe
one
per
name
space
or
you
know
a
a
handful
per
cluster,
some
kind
of
relationship
like
that,
but
yeah.
I
I
think
it's
interesting
I'd,
be
interested
to
see.
C
So
in
raw
practice
gateways
people
are
going
to
make
gateways.
People
who
are
using
cloud
providers
are
going
to
make
gateways
a
privileged
operation
right
because
a
gateway
is
going
to
bind
he's
going
to
create
some
cloud
provider
resource
which
is
going
to
cost
you
money
so
is
that
is
that
a
correct
assumption.
A
Not
so
I
wouldn't
say
that's,
we
we've
had
a
lot
of
discussion
around
gateway
being
able
to
provision
instances
of
implementations
of
this
api
within
a
namespace
scope.
If
we're
thinking
of
in
cluster
proxies
those
kinds
of
things
and
for
those
use
cases,
I
do
think
we
want
the
ability
to
have
a
namespace
scoped
implementation
of
this
api,
and,
if
that's
the
case,
then
creating
a
gateway
resource
may
not
be
as
constrained.
It
may
be
more
constrained
by
class
or
some
other
thing
with
opa.
As
like,
we
had.
E
Yeah,
I
think
that
there's
two
from
what
I've
seen
so
far,
there's
definitely
two
broad
categories
of
gateways
that
will
be
created.
There's
the
one
that
james
is
talking
about.
That
is
the
please
create
me
and
essentially
an
upstream
load
balancer
or
some
other
sort
of
external
to
the
cluster
thing
and
then
there's
the
ingress
control
style
use
case.
That's
the
please
can
you,
this
gateway
describes
is
like
a
bucket
to
hold
the
config
for
an
ingress
controller
that
requires
some
other
way
to
get
the
traffic
into
the
cluster.
Probably
another
gateway,
yeah.
A
E
For
example,
in
contour's
case
contra
is
an
ingress
controller.
It's
an
in-cluster
proxy.
In
order
to
get
the
traffic
to
the
envoys
that
contour
uses,
you
need
something
else,
that's
something
else
is
either
a
service
or
type
load,
balancer
or
a
a
gateway
of
the
other
of
the
other.
I
don't
use
the
class
but
of
the
other
type,
so
I
think
so
far.
That's
the
main
things.
E
I've
seen
is
two
broad
classes
of
gateways
that
broad
types
of
gateways,
sorry,
that
you
are
sort
of
cloud
load
balancer
for
lack
of
a
better
word
and
in
cluster
proxy,
and
I
think
they
do.
They
are
going
to
have
different,
there's
an
extent
to
which
they
will
have
slightly
different
security
postures,
and
I
would
guess
that
it's
actually
going
to
be
pretty
hard
to
move
around
to
move
gateway
objects
between
classes
that
fulfill
those
different
those
two
different
contracts.
So
you
wouldn't.
E
A
Yeah,
I
think
that's
fair.
I
think.
That's
where
the
you
know
the
seamless
replacement.
The
idea
of
you
could
spin
up
a
new
gateway
of
class
foo
contour
gke,
whatever
it
is
right
and
it
might
have
a
couple
different
settings,
but
it
could
target
all
the
same
routes
and
everything
else,
and
it
could
be
somewhat
seamless
in
nature.
A
But
it's
an
imperfect
thing
for
sure
I
I
think
mark.
One
of
your
key
points
is
is
something
that
we
should
remember
here
that
we're
talking
about
in.
In
most
cases,
a
few
gateways
per
cluster,
or
maybe
10
yeah
like
a
a
relatively
small
amount.
So
we
do
need
to
get
this
configuration
right,
but
we
do
also
need
to
remember
that
it's
it's
something
like
that.
Users
aren't
going
to
be
interacting
with
every
day.
E
I
think
that
makes
sense
to
me
in
the
sense
that
you
we
already
there's
already
the
simplest
possible
api
available.
E
That's
ingress
you're,
like
that's
the
simplest
possible
api
that
could
describe
most
of
the
things
that
we're
talking
about
here,
possibly
service,
the
type
load
balancer
as
well
but
like,
and
I
think
the
thing
that
the
thing
that
we
need
to
keep
in
mind
as
well
is
that
you
know
there's
a
not
insignificant
onboarding
cost
to
people
actually
learning
how
the
gateway
api
works,
and
if
we
want
people
to
pick
this
api
up
and
actually
use
it,
that
cost
should
be.
E
You
know,
there's
going
to
be
a
cost,
but
we
need
to
keep
that
in
mind
as
a
cost
yeah
like.
If
we're
going
to
have
you
yeah,
we've
already
got
four
different
objects
or
something
like
that.
If
we
add
some
policy
objects
on
top
of
that,
you
know,
then
it
it
makes
the
mental
model.
You
have
to
build
up
more
complicated
and
take
you
longer
and
thus
we
either
need
really
really
good
documentation
or
or
we
need
to
make
it
simpler.
E
C
Think
we
agree.
I'd
probably
I
mean
I
kind
of
want
to
quibble
with
that
a
little
bit
in
that.
I
think
the
complexity
lies
in
the
mental
model
and
you
can,
if
you
just
simply
because
if
the
mental
model
is
expressed
in
fields
or
if
it's
expressed
in
cids,
can
change
how
easy
it
is
to
digest.
But
I
don't
know
that
it's,
I
kind
of
wanted
to
push
back
a
little
bit
on
the
idea
that
more
cids
is
intrinsically
more
complex
like
it
can
be.
E
I
mean
the
thing
that
I'm
worried
about
is
that
we
end
up
in
a
situation
like
cert
manager,
where
you
have
you
know
a
certificate
that
creates
a
certificate
request
that
creates
a
certificate
order
that
creates
a
or
something
else.
There's
one
last
one
you,
and
if
you
don't,
if
you
just
care
about
getting
a
certificate
in
the
end,
you
don't
give
you
don't
really
care
about
the
rest
of
that
stuff
and
it
can
be.
E
It
can
be
challenging
to
understand,
what's
going
on
and
to
find
the
right
place
to
look
for
something
when
it's
broken
and
that's
that's
the
thing
that
I'm
worried
about
is
you
know
like
we
can
have
extra
things
that
may
make
it
easier
to
configure
this
to
start
with,
but
then,
when
it
breaks,
how
do
you
find
what
the
problem
is?
Where
do
you?
Where
do
you
go
to
start
and
how
many,
how
many
hoops
do
you
have
to
jump
through
to
get
to
the
thing?
That's
broken.
C
Yeah
and
they're
important
they're,
definitely
like
important
user
experience,
things
to
think
about
yeah.
E
F
Yeah,
I
would
also
say
tobias
towards
the
highest
number
of
users,
but
we
know
the
number
of
http
route
users
is
going
to
be
much
greater
than
the
number
of
users
that
are
interacting
with
gateways
and
so
to
buy
us
towards
their
use
case
and
to
make
to
favor
the
http
route.
Simplicity
over
gateway
simplicity,
because
there's
many
many
more
users
that
are
not
networking
experts,
because
they're
going
to
be
using
routes
over
gateways.
A
Yeah,
I
think
that's
a
good
point,
and
I
do
want
to
close
on
this
pretty
pretty
soon,
because
we
do
have
a
few
other
things
on
the
agenda,
but
but
I
think
that's
a
good
point,
any
anything
we
can
do
to
make
the
http
right.
Well,
the
route
experience
in
general,
more
natural
and
make
more
sense
to
users
is,
I
think,
going
to
be
a
win.
I
I
remember
that
from
tgik
the
gateway
creation
was
straightforward,
but
then,
oh,
how
do
I
create?
A
How
do
I
connect
this
route
to
my
gateway
and
anyways?
I
I
think
there's
there's
plenty
of
room
for
more
discussion
here,
so
I
think
this
translates
well
into
my
next
question,
which
is
how
is
what
is
the
best
way
to
get
feedback
to
provide
feedback
to
continue
this
discussion
online?
A
I
I
have
a
few
ideas.
Obviously
there's
an
oss
issue,
there's
that
doc,
that
anyone
can
comment
on.
We've
used
docs
pretty
heavily
for
this,
and
and
I'm
fine
to
continue
that
if
that
works,
but
I
also
have
started
to
be
thinking
about
what
other
projects
are
doing
with
enhancement
proposals.
A
Obviously
kubernetes
has
their
caps
cluster
ip
cluster
api
has
cep.
I
don't
know
if
that
that's
sep,
I
don't
don't,
actually
know
how
they
pronounce.
That
and
helm
has
their
hips,
but
all
have
a
fairly
similar
structure
and
they're
all
improvement
proposals,
enhancement
proposals,
whatever
you
want
to
call
them.
A
A
I
am
concerned
because
it
adds
overhead,
but
on
the
other
hand,
it
also
adds
some
record
of
why
we
made
the
decisions
we
we
made
and
some
kind
of
permanence
with
those
decisions,
whereas
right
now
our
decisions
are
kind
of
scattered
across
issues
docs
and
other
things.
That
may
not
be
quite
as
easy
to
find
as
entry
enhancement
issues,
whatever
enhancement
docs.
A
Associated
with
the
cap,
so
okay,
so
yeah
there
there's
a
in
kubernetes
there.
Every
cap
has
an
associated
issue,
but
that's
mostly
just
for
tracking.
Usually
what
you'll
see
is
someone
will
create
an
issue
on
k,
slash,
k
upstream,
and
it
may
be
large
enough
in
scope.
That
means
any
kind
of
api
change,
any
kind
of
behavior
change
that
you
know
it's
not
just
a
bug
fix
that
they
say.
A
Oh,
you
should
file
a
cap,
and
the
cap
includes
things
like
rationale
and
user
stories,
sometimes
and
then
key
api
changes
that
you
want
to
propose
with
this
cap,
and
the
cap
also
adds
a
lot
more.
That
I
don't
think
is
relevant
here.
Like
milestones
tracking,
you
know
alpha
beta,
yeah,
graduation,
prp
rs,
all
these
other
things
that
I
think
are
far
too
heavy
for
a
gateway
api,
which
is.
A
Yeah
right,
but
I
also
reference
cluster
api
and
helm,
which
have
lighter
weight
versions
of
those
that
are
more
focused
on
rationale,
and
you
know
alternatives
considered,
which
I
think
could
be
helpful
just
as
you
know,
for
anyone
coming
back
through
the
api,
why?
Why
did
they
do
this?
It
could
be
helpful
to
have
this,
but
I
also
recognize
it's
adding
potentially
adding
a
good
bit
of
overhead.
D
A
A
If
we
had
firm
deadlines
for
releases,
that
would
actually
probably
make
sense,
but
no
what
I,
what
I'm
considering
right
now
is
just
a
way
to
formalize
decisions
and
documents
somewhere
in
between
right
now,
what
we
have,
which
is
a
whole
bunch
of
docs
and
a
whole
bunch
of
issues
and
conversation
that
sometimes
get
gets
disconnected
between
the
two
of
them,
and
maybe
we
could
combine
them
into
something
that
is
like
an
enhancement
proposal.
D
D
E
Yeah,
I've
definitely
found
a
couple
of
times
that
can
be
hard
to
catch
back
up
with
things.
If
you
haven't
been
able
to
look
at
what's
going
on
in
the
repo
for
a
while
feels
like
a
kept
ish
process
would
help
with
you
know,
bringing
yourself
back
up
to
speed
or
people
new
people
being
able
to
come
up
to
speed,
having
to
sort
of
go
hunting
for
google.
Docs
is
kind
of
it's.
It
just
makes
the
the
work
harder
to
catch
up
yeah.
So
I.
F
E
Yeah,
I'm
a
plus
one
on
having
something
like
that,
but
I
I
agree
there
absolutely
is
a
process
overhead
in
doing
it,
and
so
we
shouldn't
do
it
without
a
without
being
confident
that
the
process
overhead
is
going
to
be
worth
it.
You
know
it's
much
harder
to
do
comments
on
a
pr
that
then
has
the
person
go
and
do
a
revision
to
the
pr
and
push
it
back
up
then,
to
you
know,
suggest
changes
on
a
google
doc
can
have
them
accepted.
A
Yeah,
no,
I
yeah
that
that
is
still
a
very
real
pain
point.
Unfortunately,
I
yeah
no
perfect
tool
here.
I
I
think
the
the
real
benefit
of,
even
even
if
things
start
as
docs,
like
even
what
I
was
thinking
for
an
initial
thought
was
translating
docs.
I
have.
I
have
several
design
docs
for
discussion
here.
I
was
thinking
of
translating
them
to
kep
like
prs
and
trying
to
formalize
that
structure,
just
so
that
I
think
more
for
discoverability
and
so
that
they
they
don't
get
lost.
D
A
That's
I
mean
that's
it's,
it's
not
unheard
of
for
upstream
caps
to
start
as
docs
or
email
threads
or
whatever,
and
then
once
there's
consensus
that
that's
translated
into
a
cap
and
the
you
know
final
details
are
worked
out
in
the
cap
and
then
etc.
So
yeah,
maybe
something
like
that
is
what
we
end
up
doing
here.
A
Okay,
well
I'll
keep
on
thinking
about
that.
I
will
at
least
explore
what
a
simpler
approach
could
be
and,
as
we
reach
consensus
on
some
of
these
issues,
I'll
think
about
translating
them
into
a
cap.
I
think
that
would
be
a
good
practice
to
get
into
as
we're
making
our
bigger
v1
alpha
2
changes
here.
A
I
I
wanted
to
highlight
quickly
just
we
harry,
and
I
had
our
kubecon
talk
last
week
and
I
think
it
went
reasonably
well.
It
was
way
too
early
in
the
morning
for
me,
but
we
got
apparently
around
900
people
show
showing
up
and
got
a
lot
of
questions.
A
Harry
actually
got
these
questions
actually
from
our
speaker
from
our
track
moderator,
I
guess
and
anyways.
I
some
of
these
questions
are
interesting.
There's
a
few
requests
for
rate
limiting
a
couple.
A
Other
redirects
were
another
common
feature
request,
a
variety
of
other
things
that
show
the
common
kind
of
questions
we
were
getting
and
some
of
them
were
answered
later
in
the
talk,
but
it
was
still,
I
think,
interesting,
to
see
the
kinds
of
feedback
or
questions
we
got
in
that
talk
and
there's
there's
a
lot
to
get
go
through
so
nothing
groundbreaking
here,
but
just
if
you're
curious,
I
thought
some
of
these
questions
were
interesting
and
the
last
one.
D
A
Yeah,
you
might
want
to
drop
it
somewhere.
I
don't
know
where
it
belongs.
I
mean
really
there's
a
lot
of
these
questions.
Aren't
that
notable,
but
there's
a
few
that
probably
stand
out,
and
maybe
I
should
try
to
summarize
these
in
a
more
meaningful
way
somewhere,
yeah,
okay,
well,
we're
nearly
out
of
time.
I
wanted
to
highlight
there's
a
variety
of
new
issues
and
prs
that
have
come
in
in
the
past
few
days
that
we
just
don't
have
time
to
get
to
today.
A
A
Usually
I'd
spend
more
time
on
it
in
a
meeting
but
just
running
out
of
time,
but
if
you're
interested
it's
closely
related
to
this,
which
tim
was
looking
at
the
api
and
pointed
out
that
hey,
you
should
really
be
following
these
api
conventions
and
not
use
map,
string
string
many
places,
and
it
was
in
both
query
and
header
param
matching.
A
Well,
I
don't
know
why
I
said
header
param,
so
that
is
something
that
that
addresses
so
anyway,
there's
there's
a
lot
of
issues
and
pr's
that
we
just
don't
have
time
to
get
to
today,
but
if
you
have
time
to
review
them
after
this
call,
that
would
be
really
appreciated
and
a
reminder.
This
is
the
beginning
of
our
new
meeting
schedule.