►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210127
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
All
right,
we're
recording
this
is
january,
27
already
and
the
service
apis
meeting.
I
have
a
few
things
happened
the
past
week.
That
would
be
good
to
talk
about.
I
don't
see
bowie
here
yet
so
I'm
going
to
hold
off
on
his
items
for
a
little
bit,
I'm
assuming
he'll
show
up
and
so
we'll
move
on
to
the
timeline
for
a
v0.2
release.
A
Someone
had
requests.
I
think
this
is
someone
from
the
k-native
community
had
requested
that
we
get
a
release
out
or
at
least
provide
some
guidance
on
when
another
release
would
be
incoming.
I
know
we
made
some
validation
updates
and
improvements
specifically
for
them
and
yeah.
I
think
I
think
we've
definitely
intended
to
have
a
v0.2
release.
A
A
I
know
we'd
originally
discussed
sometime
in
january,
even
releasing
odot
2.,
that's
not
going
to
happen,
but
I
would
be
open
to
a
0.2
at
some
point
in
the
next
few
weeks
I
I
took
a
look
at
the
changes
since
1.0
1.0,
our
first
final
v1,
alpha
1
release
and
there's
some
fixes
for
default
values
for
validation
and
for
conditions
status.
Essentially,
that's
that's
all
that
I
can
kind
of
summarize
in
here.
A
I
don't
know
if
I'm
missing
anything,
so
I
don't
think
an
0.2
release
is
going
to
be
a
huge
huge
set
of
changes,
but
I
think
it
is
still
valuable
to
get
those
various
fixes
tied
to
a
specific
release
version.
Does
anyone
have
any
any
guidance
or
thoughts
around
a
0.2
release
timeline
here.
A
All
right,
well,
I
think
I'm
leaning
towards
sometime
early
in
february
for
anyone
who's,
also
working
on
the
kubernetes
release
cycle.
A
I
think
it's
february,
9,
there's
an
enhancements
freeze,
so
I'd
rather
stay
away
from
that,
because
I
know
a
lot
of
people
are
also
working
on
the
enhancements
for
the
cycle,
but
I
would
say
either
slightly
before
or
slightly
after
that,
the
first
half
of
february
at
least
it
would
be
good
to
get
a
0.2
release
out
any
any
hesitation
about
that
timeline.
A
All
right,
I'm
going
to
run
with
it
cool
the
other
one
that
I
wanted
to
cover
real
quick
is
a
follow
up
on
the
webhook
pr.
I
see
that
harry
is
here,
and
I
think
you
and
I
had
slightly
different
understandings
on
and-
and
I
trust
yours
more-
I
should
say
on
what
we
intended
for
filters
here
and
specifically,
if
we
intended
to
allow
multiple
filters
of
the
same
type
to
exist
in
the
same
route.
Rule
maybe
explain
how
you
envision
multiple
filters
of
the
same
type
being
used.
B
Yes,
so
can
you
hear
me
yeah?
Okay,
so
we
have
filters
of
primarily
two
types
right.
One
are
entry
filters
and
one
are
external
right
and
then
in
the
entry
filters
we
have
two
con
conformance
levels
right.
We
have
one
core
and
one
extended.
B
So
the
behavior
of
core
and
conformance
filters
is,
you
know,
defined,
is
concretely
defined.
So
we
we
have
stayed
away
from
you
know.
You
know,
introducing
like
multiple
filters
of
the
same
kind
should
not
be
allowed.
So
that's
so,
for
example,
if
we
have
a
it's
a
request,
header
injector
or
I
forget
the
name
of
the
filter
but
modifier
yeah,
request,
modifier
or
filter
header.
B
Yeah
header
mode,
we
vla
we,
we
are
asking
users
to
use
that
filter
only
once
whenever
there
is
a
whenever
there
is
a
you
know
on
on
a
specific
rule
of
the
route
right,
so
yeah
you,
you
use
that
one
once
my
point
here
is
more
about.
Like
you
know,
okay,
we
can
specify
that
behavior
but
for
custom
filters,
which
is
sort
of
a
a
huge
extension
point.
B
We
should
allow
for
multiple
custom
filters.
The
reason
for
that
is,
let's
say
any
implementer
decides
to
implement
custom
filters
using
you
know
a
set
of
crds,
or
maybe
a
generic
crd.
Now
that
user
should
be
able
to
specify
that
filter
multiple
times
right.
So
so
that's
like
because.
B
Know
how
the
end,
how
how
custom
filters
will
behave
right?
We
are
not
defining
that
behavior.
So
that's
why
I
think
it's
best
to
stay
away
from
limiting
the
number
of
instances
of
custom
filters,
because
that
is
anyways
implementation,
specific.
A
A
I
I
I
can
see
how
you
might
want
to
reuse
that,
so
I
think
I
think
what
you're
suggesting
here,
if
I'm
understanding
correctly,
is
that
we
should
scope
this
web
book
validation
to
only
validate
core
filters
that
we're
aware
of
and
that
we
know
we
don't
want
more
than
one
of.
B
A
C
A
Yeah,
I
think
that
seems
reasonable
yeah.
That's
a
compelling
enough
use
case
that
I
I
don't
think
we
want
to
prevent
it
any
any
other
thoughts
on
this
front.
A
All
right,
I'll
I'll,
follow
up
with
this
after
I'll
leave
this
tab
open
I'll,
follow
up
after
to
just
describe
what
we
said
here,
but
I
I
think
that
I
think
that
makes
sense.
A
Let
me
let
me
get
into
this
gateway
service,
apis
renaming,
I
don't
know
so,
but
we
started
this
conversation.
It
looks
like
a
couple
days
ago.
A
I
should
we
change
the
name
of
this
repo
to
align
with
the
pre
primary
resource
name,
so
bowie
mentioned
it
below,
but
apparently,
when
this
repo
was
created,
the
idea
was
let's.
This
is
a
set
of
apis
that
are
going
to
iterate
on
kubernetes
services,
expand,
you
know,
etc
right,
and
so
it
made
sense
now
that
we
have
a
concrete
resource
name
that
we've
voted
on
and
seem
to
have
some
kind
of
consensus
around
service.
A
Apis
almost
seems
wrong,
because
this
is
this
is
an
api
that
has
no
resource
in
it
called
service
itself
right.
So
this
somehow
feels
like.
Maybe
we
should
consider
renaming
the
project
to
reflect
the
resources
that
are
within
it
anytime.
We
reading
a
project,
it
is
a
lot
of
work
and
we
should
not
do
it
lightly,
because
it's
also
a
lot
of
you
know
requires
community
to
adjust
and
understand.
Oh
this
project
that
I
knew
was
this
is
now
this,
so
I
tried
to
get.
A
I
tried
to
ping
some
other
maintainers
on
this
as
well.
I
don't
know
that
looks
like
damian
also
has
just
responded.
Let's
just
have
an
open
discussion
here.
Maybe
bowie.
Do
you
want
to
provide
a
little
bit
more
background
too
on
the
the
idea
behind
a
potential
name,
change.
D
Oh,
this
was
just
some
feedback
that
people
got
a
bit
confused
because,
while
the
project
is
named
service,
apis
most
people
ended
up,
calling
the
thing
gateway
and
it
became
for
some
people
were
saying
it's
a
discoverability
problem
that
they
couldn't
find.
It.
A
Yeah,
that
makes
sense.
I
think
I
think,
that's
a
compelling
reason
that,
as
people
start
to
use
this
api
more,
the
traditional
search
would
just
be
oh,
google,
kubernetes
gateway
or
search
for
a
kubernetes
gateway
right,
and
if
this
is,
if
this
is
called
service,
apis
that
could
be
confusing.
Potentially
I
don't
know
danny.
E
Yeah,
I
mean,
I
think
it
goes
to
your
earlier
point.
Is
you
know
it's
a
pain
in
the
butt
to
do
a
name
changes.
I
think
we
need
to
have
real,
solid
evidence
to
cause
the
name
change.
So
now
you
give
the
example
like
discoverability,
so
I
just
went
and
said.
Okay,
let
me
go
to
google
and
do
a
search
for
kubernetes
gateway
class,
and
I
mean
it's
all
service
api,
stuff,
yeah,
paypal,
spec,
kubernetes
service.
I
mean,
let
me
try
gateway,
2
and.
E
Yeah,
so
when
we
go
to,
we
do
a
kubernetes
gateway
search,
that's
where
we
get
into
what
we
would
expect
since
gateway
was
taken
by
what
is
it
by
istio,
a
lot
of
istio
that
shows
up
and
then
kubernetes
ingress.
E
A
G
Yeah
I'll
mention
a
couple
things,
so
I
I
personally
think
that
it
is
about
the
marketability
of
the
project
service.
Apis
is
such
a
generic
term.
I
mean
if
you
search
service
apis,
so
many
things
are,
you
know,
use
some
combination
of
those
terms
that
it's
it
it
it's
hard
to
be
concrete
about
what
that
really
references,
because
it's
so
generic
and
also
the
plural
aspect.
It
seems,
like
you,
know,
different
people
calling
service
apis
the
service
api
service.
You
know
service
dash
api.
G
It
doesn't
feel
as
concrete
as
a
marketable
name
for
the
project
as
something
like
gateway,
which
is
a
bit
more
of
a
concrete
name,
and
so
I
I
think
that's
that's
kind
of
my
perspective
on
it,
which
I
think
is
important
for
the
project,
because
it
is
something
that
requires
consensus
and
awareness
about
the
project
for
it
to
succeed
as
a
standard.
G
A
Yeah,
I
think
that's
a
really
good
point,
and
I
would
I
would
add
that
the
pluralization
is
something
we
we
have
certainly
already
struggled
with
when
we're
writing
about
service
apis
and
because
there's
already
a
service
resource
in
kubernetes
upstream,
we
can't
just
say
service
api.
It
like
that
would
not
work.
So
we
can't
simply
describe
this
project
as
service
api
or
the
service
api.
A
So
I
think
I
think
that
connection
to
the
service
resource
had
some
confusion
here
that,
like
mark
said
we
we
are
really
early
on
in
this
project,
at
least
as
far
as
broader
awareness
goes,
and
if
we're
going
to
make
a
change
now,
it
will
primarily
affect
us
and
basically
the
the
group
that
is
building
either
the
project
or
building
on
the
project,
but
not
necessarily
people
that
are
actually
using
the
project
yet
because
I
don't
think
they're,
that's
a
large
group.
A
So
if
we
are
ever
going
to
change
this
name,
this
is
a
good
opportunity
or
at
least
bad
opportunity.
But
I,
but
I
will
certainly
say
this.
This
would
be
a
lot
of
work
and
I
agree
with
damian.
We
should
not
do
it
lightly.
B
So
boy,
when
we
initially
named
it
service
apis,
it
was
it
was
with
a
vision.
It
seems
from
a
comment
that
it
was
about.
You
know
iteration
of
kubernetes
services,
and
we
have
discussed
that
in
passing
that
you
know
in
future.
Maybe
gateway
is
like
our
gateway,
api
or
service
apis.
Whatever
you
call,
it
now
can
be
used
to
do
that
right.
So
are
we
narrowing
down
the
scope
of
the
project
to
be
an
iteration
of
ingress,
which
is
what
it
is
today
and
then
not
be
concerned
about
iteration
of
services
in
future.
D
B
D
Yeah,
I
think
so.
I
think
that
we
already
have
with
the
sort
of
like
the
back-end
config
and
talking
about
l4.
D
I
don't
think
that
aspect
of
it
we're
we're
seeing
it
changing.
I
think
this
is
mostly
like
if
I
type
this
into
like
a
web
search,
what's
going
to
help
us
find
the
project
and
also
from
a
project
naming
perspective,
because
we
have
two
distinct
names
right
now
and
the
desire
would
just
be
to
have
one.
G
Like
I
do
you
see,
I
do
see
a
point
that
if,
if
there
were
to
be,
I
mean
basically
the
way
we're
you
know
going
about.
This
is
okay.
Gateway
is
the
top
of
the
tree
of
this
resource
tree,
and
so
that
should
be
the
name
right.
And
so
I
do
see
a
concern
if
there
were
ever
another
top
level
resource
type
that
existed
that
this,
you
know
that
http
routes
and
other
routes
would
use.
G
A
A
Yeah,
that's
that's
a
good
point
and
I
I
think
you
know
I
kind
of
alluded
to
this
here-
that
we
seem
as
a
community
to
be
pretty
happy
with
the
gateway
name
and
it's
hard
for
me
to
imagine
another
top
level
resource
that,
I
know
never
say
never,
but
gateway
does
seem
like
it
is
the
fundamental
component
of
this
api.
A
If,
if
we
were
uncertain,
we
could
try
and
use
some
variation
of
routing
and
whatever,
but
again
that
that
would
also
potentially
be
difficult
to
to
find
so
for
if
we're
trying
to
increase
discoverability,
I
think
the
gateway
name
is
is
likely
both
the
easiest
to
find
and
also
the
most
marketable
or
easiest
to
reference
in
doc,
docs
and
whatever
else
it
might
be.
D
A
Yeah,
I
mean
that's
a
good
point
it
it
certainly.
A
I
think
the
primary
desire
here
is
to
focus
on
discoverability
and
marketability,
I
suppose,
of
this
of
this
project,
and
that
does
not
necessarily
require
changing
the
actual
url
involved
here,
the
actual
github
project
name,
I
I
feel
like
if
we,
if
we
change
the
project
name
without
changing
the
repo
name,
we
would
regret
it
at
some
point
in
the
future,
but
I
recognize
that
the
vast
majority
of
work
here
is
changing
the
repo
name,
not
the
project
name.
B
I
think
if
we
do
decide
to
rename,
we
should
go
all
in
and
have
a
note
that
this
project
was
previously
named
service
apis,
because
if
we
are
not
consistent,
I
think
it
will
cause
a
significant
amount
of
more
confusion
with
newer
users
and
that's
support
overhead
that
I
think
we
should
avoid
right
now,
like
we
have
to
pay
that
cost
now
or
we'll
have
to
pay
that
you
know
confusion
declaring
out
the
confusion
cost
later.
A
G
No
one
is
thinking
of
the
term
service,
apis
and
they're
kind
of
referring
it
to
us
as
the
gateway
and
that's
just
kind
of
something
I've
noticed.
So
I
do
feel
like
when
you
end
up
using
it.
You
don't
really
service
apis
doesn't
really
appear
in
any
place
of
the
usage
except
you
know.
Obviously
you
refer
to
a
service.
B
Yeah
I
mean
I
completely
agree
with
that:
I'm
not
against
renaming
I'm
just
more
concerned
with
the
mechanics
of
it
right
like
so
so
that
logic
completely
adds
up
and
even
in
passing
people
I
have
mentioned
it
as
gateway
api.
So
yeah,
I'm
I'm
just
my
point
is
no.
If
we
rename
just
let's
just
do
it
completely.
D
Okay,
I
think,
let's
follow
up
on
the
thread.
It
sounds
like
most,
people
are
in
favor
of
doing
the
rename
and
the
time
to
rename
is
now.
I
think
like,
for
example,
java
used
to
be
called
oak,
and
if
they
like
named
themselves
oak,
they
would
have
saved
like
20
of
the
size
of
every
java
executable
but
anyways,
like
that's
a
anecdote
about
naming
and
when
to
do
it.
A
Yeah,
no,
that
makes
sense
it
seems
like
this
would
be
good
to
also
get
some
feedback
from
the
broader
sig
network
community
as
well,
and
maybe
if
we
were
to
move
forward
with
a
rename
on
this,
we
could
try
to
have
it
in
place
in
time
for
our
0.2.0
release
so
that
it
is
easy
to
target.
A
Okay,
well,
let's,
let's
leave
this
thread
going
for
maybe
a
week
or
so
I
I
think,
there's
at
least
a
reasonable
amount
of
support,
but
I
I
don't
know
that
we've
completely
reached.
A
E
On
sid
network
mailer
and
get
some
feedback
just
to
make
sure
that
there's
no
one
against
it
or
I
guess
to
rob's
point
to
the
other
option-
would
be
just
discussing
it
over
the
sig
network
call.
A
I
think
I
think
both
make
sense.
Yeah
yeah
might
as
well
send
something
out
on
on
mailer
as
well
just
to
get
the
broadest
audience
possible,
never
want
any
kind
of
rename
to
come
as
a
surprise.
A
All
right,
cool,
yeah
and
feel
free
to
follow
up
here
on
mailing
list
or
yeah
next
week
as
well,
all
right
bo.
You
also
added
one
and
as
soon
as
I
saw
this
on
the
agenda,
I
I
was
like
oh
man,
I
because
I
I
went
ahead,
I
think
end
of
last
year
and
I
got
links
to
kind
of
things
to
track
implementations
of
a
variety
like
everyone,
I
know,
is
currently
working
on
an
implementation
of
service
apis,
and
I
think
I
have
reasonably
good
links
for
everyone
at
this
point.
A
A
E
A
Yeah
yeah
now
that's
completely
fine,
I
think.
Even
if
we
can
just
link
to,
I
think
you
had
an
issue
kind
of
tracking
your
progress
towards
an
implementation.
A
D
Yeah,
especially
contour,
you
guys
have
public
issue
tracking
that
should
suffice.
For
now,
we
just
make
it
clear
what
the
status
is.
H
A
That
makes
sense,
I
think,
that's
where,
where
a
lot
of
us
are
right
now
cool
all
right,
I
I
will
follow
up
I'll,
probably
get
a
pr
out
soon.
That
includes
either
links
to
tracking
issues
or
links
to
demos
for
the
ones
that
actually
have
something
in
progress.
Well,
that
that
can
be
used
right
now
and
we
can
go
from
there
but
yeah.
I
completely
agree
we
should
have
an
implementation
page
up.
I
lost
track
of
this
one.
A
All
right,
I
think
I've
made
it
through.
We've
made
it
through
the
first
few
here.
Let
me
I
did
want
to
add
a
little
bit
of
time.
Oh
that's
handy
or
whatever
I
I
did
want
to
spend
a
little
bit
of
time
discussing
this
gateway
route
binding
thing
again.
We
actually
did
end
up
merging
this
pr
from
mark.
Thank
you
for
mark
has
made
some
incredible
improvements
to
our
documentation.
So
thank
you,
but
we
ended
up
merging
this
after
some
consensus.
A
In
the
comments
about
how
we
should
describe
the
relationship
between
a
gateway
and
routes
and
what
pattern
we
should,
what
pattern
we
should
recommend
here,
and
I
think
I
think
what
you've
described
here
is
completely
reasonable
here,
mark
it,
it
makes
sense
it's
it's
basically
describing
a
type
of
gateway.
So
in
this
case
a
prod
web
gateway
is
the
route
selector,
that's
being
used,
the
label
that's
being
used,
and
then
you
would
add
that
label
on
the
route
itself.
A
I
that
is
one
of
many
patterns
that
are
possible.
Obviously,
but
as
I
as
we
were
digging
through
this
conversation
and
trying
to
understand
exactly
how
this
relationship
works,
it
got
me
wondering
kind
of
more
broadly
if
if
there
are
still
flaws
in
our
route
selection
and
if
we,
if
we
need
to
revisit
any
part
of
this
and
and
to
be
clear,
this
is
very
early
in
my
thought
process
and
I
don't
have
a
solution.
A
I
just
wanted
to
get
other
people
thinking
about
it
and
see
if
anyone
else
had
had
been
thinking
about
the
same
flaws.
I
had
and
had
already
thought
of
solutions
or
ways
to
tackle
this,
but
one
one
of
the
most
fundamental
things
that
I
think
is
is
challenging
here.
Is
that
a
and
we
we
have
discussed
this,
but
a
route
owner
is
fundamentally
in
control
of
what
gateway
it
is
bound
to,
and
we
try
to
make
the
relationship
look
the
other
way,
but
the
route
owner
is
the
one
that
controls
the
labels
on
the
route.
A
G
I,
after
thinking
about
this
quite
a
bit,
I
do
feel
like
that.
Maybe
users
go
into
two
camps
and
I'm
really
interested
to
hear
what
other
people
think
that,
like
either
the
route,
basically,
the
platform
administrator
presents
a
couple
of
options
to
service
owners
and
say
here's
what
you
can
use
and
route
owners
make
the
decision
they're
the
ones
that
make
the
decision
which
gateways
they're
bound
to
or
it's
the
other
way
around,
where
the
platform
minister
wants
them
to
have
no
awareness
of
how
it's
exposed
and
they
perform
the
mappings
of
routes.
G
D
Have
like
I
mean
I
thought
this.
This
came
up
in
the
design.
We
it's
a
handshake,
so
it
supports
both
use
cases.
A
It
it
does
theoretically
support
both,
but
the
gateway
owner
has
pretty
limited
control
it
it's
somewhat
a
handshake,
but
only
so
much
a
handshake.
As
you
know,
the
route
can
basically
change
almost
all
of
the
variables.
The
only
thing
the
gateway
can
really
restrict
is
what
namespaces
it's
alexa
routes
from,
but
that's
the
extent
of
its
control.
D
G
Well,
so
one
example
is
like:
if
the
service
owner
needs
to
control
low
level,
I
don't
know
path
like
which
path
things
are
routed
to
and
stuff
like
that.
But
basically
the
platform
administrator
needs
to
determine
how
that
routes
actually
exposed
on
which
listener
and
things
like
that
and
there's
no
way
to
I
mean
you:
can
it's
kind
of
difficult
to
separate
those
two,
if
you're
doing
it
by
label
base,
because
the
route
owner
can
change
the
label
and
influence
which
gateway
they're
exposed
on
there's
no
way
to
concretely
and
totally
separated
those
two.
G
Unless
you
basically
say:
okay,
it's
basically
like
a
map
of
gateway
per
namespace,
which
is
a
totally
suitable
way.
But
I
don't
know
this.
That's
where
I
want
to
get
feedback.
A
Yeah,
I
guess
I
guess
I'm
trying
to
contrast
this
to
you
know
originally
one
of
the
proposals
we
had
and
to
be
clear,
I'm
not
suggesting
we
go
back
to
this,
but
one
of
the
original
proposals
we
had
was
a
list
of
route
references
inside
gateway
and
what
that,
what
that
did
give
you,
which
we
don't
have
right
now,
is
a
way
for
the
gateway
admin
to
in
a
very
fine-grained
way.
To
say
these
are
the
routes
I'm
going
to
select
and
nothing
else
and
they
route
owners
yeah.
D
A
That
that's
fair
but
yeah,
then
at
that
point
you
can
change
the
route
owner
can
change
the
service.
The
route
is
referencing,
yeah
yeah
that
so
so
I
guess
I
guess
the
the
real
answer
is
that
there's
a
limited
amount
of
product
protection
anything
can
give
you
at
this
point
you
you
basically
have
to
trust
a
namespace,
but.
D
A
D
A
Controlling
yourself,
I,
I
guess
I
guess
the
the
path
I
was
going
down
is:
is
our
selection
model
kind
of
more
confusing
than
it
needs
to
be
if
the
route
owner
is
ultimately,
what
has
control
and
should
the
route
just
choose
the
gateway
or
gateways
it
wants
to
be
connected
to.
D
D
And
then
the
other
way
was
that
yeah,
like
I,
I
have
a
bunch
of
gateways.
I
just
want
to
automatically
enroll
namespaces.
E
Maybe
it's
just
the
naming
that's
confusing,
because
I've
always
thought
of
like
the
route
binding
is
more
of
a
filter
than
selection
right
and
we,
and
so,
if
we
think
of
it
as
a
filter,
it's
like
a
way
for
the
gateway
to
filter
all
these
different
routes
that
may
be
out
there
and
our
default
filter
says:
hey
we're
going
to
filter
out
all
routes
except
the
routes
that
are
in
you
know
my
name
space
as
the
gateway
right,
and
so
maybe
I
don't
know
if
it
helps
with
this
use
case,
but
maybe
it's
we
need
to
think
about
the
naming
and
consider
this
actually
being
a
filter
as
opposed
to
a
selector.
E
D
I
don't
yeah
because
they
they're
basically
predicates
it's
like
does
it
belong
to
this
set
of
things
and
that's
basically
what
it
does.
A
Yeah,
I
I
don't
know
what
the
answer
is
here,
but
I
think
this
is
one
of
the
most
confusing
parts
of
our
api
still
and
although,
although
it's
powerful,
I
just
want
to
make
sure
we
thought
through
any
potential
way,
we
could
simplify
or
make
this
easier
for
users
to
understand
it.
It
sounds
like
some
of
the
first
little
bits
of
feedback
we've
gotten
is,
you
know
around
the
gateway
route
relationship
which
is
kind
of
a
key
part
to
this
api
I,
and
that
it
can
be
confusing.
D
E
E
Right-
and
I
know
I
mean
we
selected
or
we
consolidated
on
selectors,
because
that's
the
kubernetes
way
of
making
that
that
association
right
I
mean
we
originally
were
talking
about.
You
know
list
of
routes.
Maybe
we
could
use
a
list
of
namespaces
we're
all
routes
in
those
namespaces.
But
again,
that's
seems
like
that's
not
the
way
that
kubernetes
does
things
so.
G
I
think
I
think
this
goes
back
to
what
you
said
earlier,
daniel,
where
it
is
actually
more
about
kind
of
the
example
that
we're
using
in
the
label
selector,
whereas
you
know,
do
route
owners.
Think
of
this
as
like
they
are
putting
in
attributes
of
the
gateway
to
determine
where
it
gets
exposed
or
they
putting
in
attributes
of
their
app
in
that
label
like
did
they
put
their
app
name
and
that
label
or
some
attribute
of
their
app.
G
E
E
E
A
This
is
this
doc.
Is
the
closest
we've
come
to
providing
a
recommendation
here,
and
it
is
entirely.
There
was
some
discussion
in
the
comments
about
different
ways.
We
could
do
this,
whether
we
wanted
to
describe
characteristics
of
an
app
or
an
environment
or
a
whatever
in
this
case.
A
The
solution
that
mark
suggested
here,
I
I
think
is,
is
a
good
balance,
but
it
is
one
of
several
ways
to
do
this
and
it's
basically,
you
select
based
on
a
an
infrastructure,
family
or
specific
gateway,
name,
depending
on
your
perspective,
of
what
this
means.
G
Yeah,
I
know
this
is
really
just
about
convention
and
I
think
convention
here
is
important,
because
it
is
one
of
the
most
confusing
and
fundamental
part
of
the
api
is
kind
of
like
you
know,
most
services
use
app
as
a
key
for
selection
of
pods,
and
so
this
is
a
similar
decision
here.
It's
just
kind
of
what
keys
we
end
up
using
customers
are
our
users
are
feel
free
to
choose
their
own,
but
the
more
that
we
kind
of
converge
on
a
convention.
I
think
the
easier
this
api
will
be
to
understand.
D
It
it,
it
does
seem
like
it's
more
centered
on
the
contract
between
the
gateway
and
the
user,
the
consumer
right,
because
for
for
the
most
part,
I
would
imagine
lots
of
people
wouldn't
even
put
the
selector
there.
They
would
just
have
like
a
list
of
namespaces
to
come
from
and
then
you'd
have
to
put
a
selector
there.
Only
if
you're
offering
multiple
different
kinds
of
gateways
and
there
you
sort
of
people
want
to
distinguish
which
particular
ones
they
want
to
be
exposed
on.
D
D
A
Well,
I
think
that
I
think
that
depends.
I
mean
I
think
it's.
It's
certainly
possible
that
multiple
multiple
gateways
could
be
provisioned
or
or
at
least
could
select
routes
in
the
same
name
space.
A
A
D
Yeah,
it
seems
like
if,
since
routes
have
the
ability
to
choose
which
gateway
it
will
be
exposed
on
that
that
selector
for
the
specific
resource
is
less
useful.
A
So
if
you,
if
you
say
that,
maybe
at
some
point
down
the
road
we
want
to
require
a
selector
to
be
non-empty,
or
at
least
change
the
empty
behavior
to
not
select
anything,
then
that
the
selector
here
has
much
more
meaning
and.
D
Yeah
yeah:
that's
like
a
policy
thing,
but
if
you,
if
you
set
it
to
empty,
doesn't
that
just
mean
it's
useless
for
that
namespace.
A
No,
I'm
not
talking
about
namespace,
so
yeah,
that's
correct!
Namespace
is
not
a
selector
necessarily
there's
from
all
from
none
from
same
name,
space
kind
of
thing.
D
Yeah
so
wait
rob
this
selector
is
on
name
spaces.
Isn't
it
not
it's
not
on
the
route?
Are
we
getting
confused.
A
Okay,
so
looking
at
the
example
I
have
here,
there
are
there's
a
selector
for
routes
and
then
there's
an
option
to
say
namespaces
from
all,
or
I
think
it's
from
selector
it
might
be
from
list.
I
forget
which
we,
which
we
did
here.
Oh.
A
So
there
are
two
two
core
options
here
and
basically
to
understand
what
route
is
being
selected.
You
have
to
look
at
the
namespace
selector
or
from
statement
the
route
selector,
and
then
you
have
to
look
at
the
route
and
you
have
to
look
at
what
the
route
is,
allowing
itself
to
be
selected
by
so
there's
kind
of
three
variables
and
admittedly
you
don't
necessarily
have
to
change
any
of
them,
but
because
there's
so
much
going
on
it
can
get
pretty
overwhelming
and
confusing.
D
One
suggestion
is,
if
we
feel
like
this
is
going
to
be
something
that
is
targeted
for
removal
like
we
could
give
the
basic
use
case
and
omit
this
as
the
recommendation
and
see
how
far
people
are
able
to
get,
because
you
could
still
do
the
the
route
chooses
which
gateways
it
was
exported
on
use
case.
A
Just
throw
it
in
here,
so
that's
exactly
market
mark,
and
I
had
a
discussion
around
this.
I
I
can't
remember
the
context.
Maybe
it
was
an
issue
somewhere.
I
regardlessly.
A
If
you
use
the
route
to
to
be
the
primary
mechanism
for
gateway
selection
right
now,
the
route
is
tied
to
a
you
know:
the
route
allows
for
a
gateway
reference
of
only
allow
these
specific
gateways
to
use
this
this
route.
So
that's
a
way
you
could
accomplish
that
the
problem
is
it
really
prohibits
seamless
gateway,
replacement,
part
of
our
model,
as
I
understand
it
is
we
want
to.
A
D
The
primary
basic
way
that
you
set
this
up
is
that
from
the
gateway
you
control,
which
namespaces
have
access
to
it
and
then
from
the
route
you
can
pick
which
specific
gateways
you
want
to
use,
and
then
there
is
this
additional,
like
advanced
use
case,
where
you're
thinking
of
basically
being
able
to
like
cut
over
a
gateway,
and
then
in
that
case
you
need
a
level
of
indirection,
which
is
this
label
selection.
D
A
Yeah,
so
the
route
you
can
do
either
let
every
gateway
use
me.
Let
any
gateway
in
the
same
name,
space
select
me
or
let
this
specific
list
of
gateways
select
me
yeah.
D
A
D
D
Basic
it
shouldn't
be
like
the
most
maximumly
like
complicated
thing
that
we
can
set
up.
A
All
right,
well
yeah.
I
think
I
think,
there's
plenty
of
discussion
to
have
here,
especially
I'm
interested
in
feedback
from
others.
If,
if
they
start,
if
you
you
see
anyone
who's
interacting
with
this
api
in
any
way
or
just
reading
through
it
for
the
first
time,
if
there's
confusion
around
these
concepts,
it'd
be
great
to
understand
where
it
is,
and
you
know
where
our
room
for
improvement
is
because
I
I
do
really
want
to
get
this
gateway
route
relationship
right.
A
I
think
this
is
a
really
core
principle
of
our
api
and
right
now
it
feels
like
it
may
be
more
complicated
than
it
needs
to
be,
and
maybe
that's
just
how
we're
communicating
it
kind
of
like
what
what
you're
saying,
but
we
like
if
we
just
provide
the
simple
examples
that
could
help.
D
Yeah,
I
think,
like
just
leave
selector
out
of
the
most
basic
description
of
this,
and
then
we
can
work
through
the
complicated
use
cases
where
that
thing
is
relevant.
E
A
Okay,
well
cool!
Thank
you
to
everyone
for
talking
through
this.
If
you
have
any
comments,
I
don't
know
if
there's
an
issue
tracking
this,
but
definitely
interested
more
feedback
on
this
specific
relationship
and
if
there's
room
for
improvement
of
either
documentation
or
just
the
the
functionality
itself.
A
All
right,
I
we
don't
have
much
time,
but
I
think
there's
a
little
bit
to
go
through
for
prs.
I
think
I've
covered
at
least
the
most
recent
issues.
I
don't
know
that
we
got
time
to
discuss
this
one.
Yet
are
we
all
right
with
basically
merging
custom
and
implementation
specific
into
a
single,
a
single
support,
yeah.
D
C
C
A
A
A
Mike,
I
think
the
way
you
were
differentiating
between
these
two
custom
and
implementation
specific
were
both
largely
you
know,
custom
things
that
would
have
different
behavior.
The
difference
would
be
that
custom
would
not
not
necessarily
be
supported
by
every
implementation.
D
C
Yeah,
that's
kind
of
what
I
meant.
Maybe
this
isn't
the
best
example
that
I
was
thinking
about
pathmatch
type
and
the
details
of
regular
expressions.
We
didn't,
I
don't
think
we
specified
exactly
what
syntax
you
use,
so
the
the
syntax
for
your
regular
expression
is
kind
of
implementation,
specific,
that's
kind
of
a
bad
example,
though,
because
I
see
we
also
have
a
match
type.
That's
called
implementation,
specific,
which
that's,
I
think.
Maybe
that
should
be
called
custom.
C
A
A
Yeah
I
this
this
needs
a
little
bit
more
thought.
So
this
is
issue
530.
I
know
we're
over
time.
I
don't
want
to
keep
people
any
longer,
but
if,
if
we
can
follow
up
here
with
some
additional
conversation
because
initially
we
were
moving
towards-
I
think
in
this
conversation
just
trying
to
merge
these
concepts,
but
it
does
sound
like
there's
sufficient
differentiation
that
we
may
need
so
some
more
thought
here.
A
A
Thanks
appreciate
it
all
right:
well,
we
are
past
time.
Thank
you.
Everyone
for
great
feedback
here
and
we'll
talk
to
you
next
week
have
a
great
one.