►
From YouTube: Gateway API Office Hours 20200909
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
september
9.
It
is
office
hours
for
service
apis,
big,
thank
you
to
everyone
who
who
keeps
on
showing
up.
I
know
two
meetings
a
week
an
hour,
each
basically
and
many
many
hours
in
between
working
on
this.
I
appreciate
all
the
all
the
contributions
for
from
everyone.
A
I
feel
like
we
really
are,
in
the
final
stretch,
at
least,
towards
an
api
that
people
can
use
with.
That
said,
let's
go
through
this
alpha
checklist.
I
actually,
I
ran
out
of
time
to
update
it
completely,
but
we
got
a
ton
of
things
in
over
the
past
week.
I'm
really
excited
about
that
lots
and
lots
going
on
at
long
last.
The
s
I
and
mode
pr
is
merged
harry.
I
was
gonna.
Ask
you
about
tls
route.
Do
you
think
this
should
be
part
of
the
one
alpha
one.
B
I
I
mean
I
have
a
hard
time
deciding,
but
I
think
people
have
asked
for
that
functionality,
so
we
couldn't,
we
could
keep
it
out
as
well.
I
mean
that's
that
it's
it's
an
independent
pr
from
the
other
two
right
so,
but
but
I
think
it
should
be
close
with
the
review.
So,
okay
yeah,
I
I
I'm
fine,
either
ways
personally.
A
Okay,
yeah,
that
makes
sense.
That
seems
that
seems
like
a
reasonable
stretch
goal.
If
nothing
else,
thanks
thanks
for
the
work
on
that
one,
I
think
we'll
have
time
to
look
at
it
today,
the
tls
on
route,
this
that
seems
fairly
straightforward.
C
A
Great
route
filter
is
merged.
Request
mirror,
I
think,
is
awfully
close.
We'll
get
a
chance
to
look
at
that
today.
Udp
route
is
in
hurrah.
I
guess
I
can
move
that
to
completed.
Oh
well
back
in
policy.
The
pr
still
exists.
It
does
still
need
a
bit
of
review.
A
It
is
really
tiny
at
this
point
like
every
time
I
I
make
a
change
to
it.
I
make
it
a
bit
smaller
it
seems
like,
but
that
is
where
it
is
right
now
I
you
can
see
where
I
I
dropped
off
here,
there's
one
more
pr
that
I
was
going
to
add
that
covers
conflict
handling,
and
then
I
think
once
the
so.
I
have
three
pr's
open
related
to
this.
A
I
think
once
they're
in
maybe
conflict
handling
will
be
complete
enough
for
v1
alpha
one,
but
I'm
open
to
feedback
or
other
things
that
we
might
want
to
cover
here
and
then
finally,
for
cleaning
up
stats
and
conditions
again.
I
I
ran
out
of
time
to
add
things
to
this
list,
but
james
has
at
least
two
new
prs
in
this
space,
and
I
think
we
may
have
some
time
to
look
at
them
today
as
well,
and
then
somebody
added
this
one,
which
is
good.
Yes,
we
should
have
it
yeah.
A
E
That
could
be
kind
of
like
our
last
little
check
mark
is
make
sure
that
the
all
the
install
and
example
stuff
works.
And
then
maybe,
if
we
don't
have
a
an
issue
for
it
is
maybe,
after
the
release,
we
look
at
doing
ci
for
it.
A
Yeah
yep,
that
makes
sense
cool,
okay,
well,
yeah.
I
mean,
I
think,
we're
we're
at
a
decent
spot.
I
I
guess
the
the
other
one
is.
There
are
significant
holes
in
our
documentation
right
now,
and
so
again
this
feels
like
kind
of
a
final
step,
but
also
an
important
one,
to
make
sure
that
this
is
all
presentable
and
understandable.
A
Cool
all
right
well
without
further
ado,
let's
get
into
pr
and
issue
triage.
There
is
a
lot
going
on
yeah.
This
is
this
is
going
by
most
recently
updated.
No
most
yes,
most
recently
updated.
Is
this
right,
yeah?
Okay,
whether
or
not
that's,
correct
or
not?
I
think
we'll
have
time
to
get
through
a
lot
of
these
pr's
today
I
harry
any
any
thoughts.
It
looks
like
this.
One
was
recently
updated,
yeah.
B
I
just
added
a
comment.
I
think
james
asked
a
question,
so
the
plan
here
is
to
I
think
we
already
discussed
this
a
couple
of
times.
I
just
haven't
had
time
to
get
around
to
it.
If
you
scroll
up
a
little
bit,
the
plan
is
to
replace.
C
C
E
B
Time
off
so
yeah
I'll
get
to
this.
Definitely
this
week,
yes,
okay,
great.
A
A
Yeah
and
actually
yeah,
maybe
it
may
well
prioritize
pr
some
hair
because
I
know
you've
got
to
drop
a
little
early.
I'm
assuming
that's
the
case.
Yeah.
A
So
the
next
one
is
request
mirroring
I
feel
like
this
is
awfully
close
at
this
point.
There's
a
bit
of
feedback.
You
created
a
follow-up
issue
for
this
one,
and
I
think
john
yeah
john
created
a
follow-up
issue
for
this
one.
So
for
those
without
context,
I
had
suggested
that
the
names
here
were
not
particularly
consistent.
A
Well,
they
were
consistent,
but
they
were
confusing,
like
request,
header
and
request
mirror
feel
like
very
consistent
names
that
mean
very
different
things
where
one
is
about
modifying
headers
and
one
is
about
mirroring
a
request.
A
Maybe
that
is
similar.
I
don't
know,
but
I
thought
there
was
room
to
make
the
names
a
little
bit
better.
Harry
has
filed
a
follow-up
for
this
one
and
then
the
other
question
came
from
john,
and
this
was
about
mirroring
and
specifically
for
istio's
use
case.
Their
mirroring
implementation
allows
for
mirroring
a
percentage
of
traffic,
and
it
was
more
of
a
generic
question
of.
Is
there
a
way
to
extend
these
kind
of
filters,
or
do
they
really
just
have
to
create
their
own?
A
And
at
this
point
I
think
the
answer
was
that
for
now,
core
filters
will
be
things
that
can
be
broadly
supported,
and
if
we
need
things
beyond
that,
then
you
for
now
the
best
approach
is
a
a
custom
extension,
at
least
for
v1
alpha
one
I
looked
around
and
all
I
could
find
is
you
know,
istio
and
of
course,
envoy
behind
the
scenes
supports
this,
but
I
can't
find
many
common
implementations
of
this,
so
at
least
for
now
I
seems
like
something
like
we
can
punt
a
little
bit
so
with
that
said,
I
think
that's
all
feedback
resolved
on
this
pr.
B
A
A
A
C
B
C
Yeah,
I'm
good
with
any
kind
of
consistent
pattern.
I
think
that
initially
the
tls
in
foo
pattern
seems
a
bit
weird,
but
it's
actually
kind
of
I
thought
about
it
for
a
bit
and
I
think
it's
pretty
clear.
So
I
really
like
how
clear
it
is,
but
it'd
be
great
just
to
so
instead
of
having
like
two
less
config
and
then
all
the
other
ones,
you
just
have
them
all
as
following
the
same
convention
everywhere,.
A
A
Something
like
that,
you
tls
in
route
config,
that's
what
it
is,
so
you
have
tls
in
gateway,
config,
tls
and
backend
config.
I
I
don't
care
too
much,
I
just
as
long
as
it's
consistent
and
as
long
as
these
all
live
in
the
same
place.
I'm
I'm
okay
with
that.
It's
it's
not
like
our
users
are
going
to
be
interacting.
Well,
I
guess,
implement
implementations
will
be
interacting
with
these
types,
but
as
long
as
our
field,
names
make
sense
and
as
long
as
our
type
names
are
consistent,
I
think
that's
good.
B
C
B
B
C
In
yammel,
because
I
just
feel
like
in
in
the
yaml
allowed
in
route
requires
extra
knowledge
to
read
it's
not
it's.
It's
not
just
immediately
obvious
what
what
it
seems
to
be
doing.
So
it's
not
that
big
a
deal.
I
think
in
the
context
of
this
pr
we
can.
You
know
we
can
come
back
and
tweak
the
name,
but
I
wonder
if
there's
sort
of
a
more
evocative
name
that
we
could
choose.
B
C
C
A
Yeah,
so
I
thank
you
for
bringing
this
up
because
I
the
first
time
I
read
through
this
pr,
I
had
that
not
the
exact
same
thought,
but
I
was
thinking
man
that
there's
there
should
be
a
better
term
here,
but
I
don't
know
what
it
is
and
every
term
I
thought
of
was
you
know,
like
five
words
long
it.
You
know,
it's
very.
You
know
hard
to
get
a
concise
name
here.
I
another
thing
I'm
thinking
of
as
we're.
A
You
know
as
as
we're
looking
at
it
now,
something
like
allow
route
override
or
something
like
that,
but
it
seems
like
what
we're
trying
to
describe
here
is
allowing
the
right
route
to
override
these
default
settings,
or
something
like
that-
I
I
don't
know
but
yeah
any
any
ideas
for
better
names
are
entirely
welcome
here
totally.
Yes,
I
have
no
opinions
on
this
and
this.
C
C
B
A
Yeah
I
mean,
if
that's
tough,
because
we
don't
know
what
we
might
have
at
route
level
in
the
future,
because
you
know
if
it
is
really
just
certificates.
I
think
there's
a
strong
argument
to
be
made
for
the
suggestions
that
james
james
has
here
of
allow
route
certificates
or
import
route
certificates.
H
A
A
And
can
we
get
in
trouble
via
merge?
That's
a
good
question.
E
A
E
A
B
B
B
E
A
Okay,
well,
this
seems
like
a
great
opportunity
to
suggest
names
here
and
bowie
is
just
about
a
couple
more
comments
from
bowie
here.
If
the
top
level
has
star.food.com
and
the
rev
has
r.foo.com
I'm
assuming
these
are.
This
is
related
to
hostname,
to
certificates.
B
B
B
B
E
Yeah
to
me
it's
like,
if
we,
if
we're
struggling,
finding
a
name,
it
must
feel
like.
Do
we
need
to
step
back
and
say?
Is
this?
Is
this
the
right
approach?
I
mean
what,
if
we
kind
of
flipped
the
solution
upside
down
and
said,
okay,
well,
could
we
tag
a
a
certificate
on
the
gateway
as
a
default
certificate
so
that
you
know
if,
if
the
certs
at
the
route
level.
E
A
I
think
that
I
think
that's
similar.
It
is
different,
but
we
still
wouldn't
need
to.
A
D
All
right,
so
that's
why
I
was
chatting.
I
guess
my
comment
was
like:
do
we
need
to
support
overrides,
or
can
we
have
yeah?
I
guess
it's
going
to
be
hard
because
you,
if
you
wanted
to
do
an
override,
you
would
have
a
listener
block
that
has
all
hosts
with
a
certificate
there
and
then
your
route
would
have
the
specific
certificates
I'm
just
thinking
like.
Can
we
make
those
merge
logic
easier
if
we
impose
more
restrictions.
B
B
B
Then
you
have
undefined
behavior,
essentially
right,
but
if
you
define
one
at
the
gateway
and
you
define
at
the
route
the
route
one
takes
precedence.
If
you
do
define
one
at,
if
you
don't
define
it
through
the
gate
gateway
and
you
define
it
route,
then
again
it's
the
route
and
you
don't
define
a
drought,
then
the
gateway
one
takes
place.
I
think
I.
D
The
other
thing
is
in
the
hp
route,
okay
and
then
what
would
let's
say
you
would
define
a
certificate
route?
Is
it
a
natural
thing
that
the
host
name
at
the
http
route
will
line
up
with
the
certificate?
I'm
just
thinking
in
terms
of
like
configuring?
D
Let's
say
I
like
hand
translated
this
to
some
proxy
config
like
is
there?
Is
it
when
we
get
into
trouble
in
translating
certain
things
that
you
can
do
at
the
right
level?
Like
what
kind
of
restrictions
will
we
have
to
impose
to
make
sure
that
we
don't
end
up
with
strange
configs
so,
like
let's
say,
the
hostname
match
doesn't
match
the
way
the
certificate
matching
happens,
and
then
how
do
you
like
mine,
goes
up.
D
B
I
see
I
see
I
see
yeah,
so
I
think
the
way
in
the
entire
api,
wherever
we
define
tls,
we
have
made
a
decision
to
be
explicit
about
how
which
sni
to
bind
or
which
wildcard
sni
to
bind
to
which
certificate
right
and
that's
evident
inside
the
listener
inside
gateway
and
the
same
applies
in
the
route
as
well.
Right,
so
proxies
are
not
supposed
to
infer
the
sni
based
on
the
sans
or
you
know,
cns
inside
the
certificate
itself
right.
B
So
here,
like
you,
can
see
in
the
http
route,
you
have
the
host
name
array,
which
is
an
array
and
which
you
have
a
the
config
right.
So
on
line
15
or
line
60,
you
have
host
names
in
line
69.
You
have
dls
in
route
config.
So
whatever
configuration
you
define,
that
applies
to
the
host
names.
You
are
defined
in
that
route
right
and
the
same
is
in
the
in
the
gateway.
So
you
should
have
a
consistent
matching.
B
You
definitely
can
have
collisions
if
you
define
things
in
the
route
right,
and
that
is
something
the
user
has
to
take
care
of.
You
know
this
is
essentially
a
use
case
where
you
know
you're,
spinning
up
services
which
are
on
separate
domains
right.
If
you
have
just
a
single
wildcard
certificate,
our
guidance
should
be
that
just
define
it
at
the
gateway
layer
and
call
it
a
day
right
like
you,
don't
really
need
the
complexity
of
defining
tls
and
route.
At
that
point,.
A
A
All
right
great
feedback
on
this
one.
What
what
do
we
need
next
on
this
harry?
Do
you
have
enough
feedback
to
go
forward
to
make
any
changes,
or
could
you
use
some
help
with
a
bit
more
feedback
or
naming
advice
or
structure.
B
B
D
B
I
think
we
do
clarify
that.
That
is
not
valid.
I
will
take
a
note
to
make
sure
that
we
do
clarify
that
the
gateway
has
to
provide
like
a
fallback
certificate.
I
think.
F
E
B
Yeah
yeah,
so
I
think
I
have
necessary
feedback
here
thanks
daniel,
so
I'll
make
sure
that
language
is
updated
to
include
that
gateway
must
have
a
certificate,
even
if
allowed
is
allowed
in
route
is
set
to
true
and
and
a
certificate.
Ref
at
the
route
level
takes
precedence,
so
I
I'll
go
through
it
and
make
sure
that
we
have
the
necessary
language
in
there.
A
All
right,
we've
got
a
lot
more
to
get
through
here.
I
guess
we
can
start
moving
back
up
james.
You,
you
made
a
pr
recently
to
standardize
on
route
status
fields.
A
Do
you
want
to
provide
any
additional
backup
this?
This
scene
is
pretty
straightforward,
you're
just
merging
the
status
for
http
route
and
tcp
route
at
this
point?
Is
that
correct.
C
Yeah,
I
think
this
was
something
that
occurred
to
me
when
I
was
looking
at
harry's
tls
route,
and
I
realized
that
the
conditions
and
this
this
the
status
that
mica
did
for
http
route
makes
sense
for
for
everything,
and
I
think
that
for
any
kind
of
route,
knowing
that
it's
been
accepted
by
a
specific
gateways
is
the
status
that
we
want
to
expose.
So
we
can
make
that
common
and
yeah
for
some
kinds
of
routes.
C
We
might
also
want
to
have
additional
status,
but
I
think
for
the
v1
just
having
that
common,
your
your
route
got
admitted
somewhere
is
generally
what
we
should
do.
A
Yeah,
that
makes
sense-
and
this
does
also
feel
like
a
a
place
where
the
you
know
like,
as
we
were
discussing
earlier,
that
mirroring
condition,
where
a
condition
that
that
mirror
a
mirroring
config
is
invalid,
may
only
be
true
for
one
controller,
that
was,
that
is
referencing
a
route
where
multiple
controllers
may
be
interacting
with
the
route
at
the
same
time,
and
so
having
status,
be
per
gateway,
as
this
proposes
allows
us
to
have
additional
conditions
beyond
just
admitted
here
was
this.
Was
that
your
intention.
C
B
H
A
Great,
the
extra
point
I
was
going
to
have
here
is,
you
know
already,
since,
probably
since
you
created
this
pr,
we
now
have
udp
route
merged
in
potentially
in
the
next
week
or,
however
long
we'll
have
tls
route
merged
in
so
we
are
starting
to
multiply
the
number
of
routes
we
have
to
deal
with.
So
we
have
to
start
thinking
about
what
we
can
safely
share
between
them
and
also
how
we
can
extend
any
shared
type.
A
So
as
an
example
for
these
kind
of
conditions,
would
it
be
safe
to
say
that
they
will
all
have
the
same
shared
set
of
conditions
but
say
http
route
may
have
a
way
of
adding
additional
conditions
that
only
apply
to
http
route
or
tls
route,
or
whatever
it
happens
to
be.
I
don't
know,
have
you
have
you
thought
about
how
that
might
work.
C
So
I
think
that's
that's
possible.
I
was
more
imagining
it
that
you
know
http
route
and
other
things
would
have
additional
status
fields
and
that
wouldn't
necessarily
be
conditions,
but
I
think,
as
we
get
more
different
route
types,
it's
important
to
consolidate
them
the
apis
across
them,
so
that
they're
predictable.
So
you
know,
I
think,
it's
way
easier
to
have
six
different
route
types
which
are
which
all
brought
which
are
which
all
conform
to
the
same
patterns
and
yeah
structure
than
it
is
to
have
six
different
ones
that
are
completely
different.
A
A
Great
yeah,
this
this
seems
pretty
straightforward
to
me.
I
didn't
really
have
much
noise
comments
other
than
this
one.
C
Yeah
so,
depending
on
the
order
of
which
things
land
I'll
rebase
it
on
the
other,
so
that
the
route
condition
will
become
a
generic
meta,
v1
condition
yeah
that's
going
to
erase
the
type
of
the
type
field,
so
you
won't
so
type
then
wouldn't
be
route
condition
type.
It
would
just
be
string
yeah.
A
Yeah,
that
makes
sense,
and
just
for
the
sake
of
consistency,
we'll
skip
on
down
to
that
one,
because
it
seems
closely
related.
This
is
based
on
tim's
feedback.
So
thanks
for
getting
getting
something
in
that
he'd
suggested
and-
and
you
may
have
already
been
thinking
about
separately
as
well-
I'm
not
sure
but
yeah
just
switching
over
to
the
shared
condition
type,
which
apparently
is
the
standard
we're
supposed
to
be
using
everywhere.
C
Yeah,
just
one
thing
again,
just
to
re-emphasize
the
point
that
we're
tight
we're
going
to
be
making
the
switch
erases
the
type
of
the
type
field
so
instead
of
having
listener
condition,
type,
which
is
a
strongly
typed
type
field
in
the
condition
it's
just
string.
So
there's
a
little
bit
less
typing
a
little
bit
less.
You
know
static,
typing
assistance
to
the
implementer,
but
there's
also
a
little
bit
more
freedom
to
add
your
own
implementation,
specific
conditions.
A
Yeah,
that
makes
sense,
and-
and
on
that
note
for
the
time
being,
you're
going
to
stick
with
you're
going
to
still
define
these
types
even,
but
just
just
so
it's
clear
what
what
each
potential
condition
type
is
for.
I
guess
what
resource
it's
for.
C
B
C
In
one
pr,
but
I
think
that
it's
useful
to
keep
the
tight,
I
think
that
in
general
it
will
be
useful
to
preserve
the
typing
on
those
things,
because
it
just
uses
the
type
system
to
give
a
little
bit
of
enforcement
and
guidance
to
to
the
classification
right.
So
we,
when
we,
we
discussed
the
document
before
and
we're
still
going
to
have
this
kind
of
classification
of
where
you
should
use
types
where
you
should
use
condition
types
with
different
class
types.
C
This
these
kind
of
these
sort
of
conditions
go
with
the
gateway,
these
header
conditions
go
with
routes
and
so
on
and
just
trying
to
use
and
this
using
what
typing
system
facilities
we
have
to
kind
of
collect.
Those,
I
think,
is
probably
help
a
bit
more
helpful
than
just
depending
on
the
naming
convention.
A
Great
any
any
hesitance
to
get
this
one
in
I.
I
think
this
is
quite.
A
Straightforward
yeah
this
this
is
an
unfortunate
side
effect.
Some
new
and
indirect
requires
but
yeah.
Maybe
we're
just
not
updating
this
enough.
A
A
All
right
we'll
keep
on
moving
then
another
couple
from
harry.
A
Down
the
list
and
I'll
come
back
to
this
guidance
on
conflict
resolution.
This
is
a
new
pr
for
this
week.
I
created
this
yesterday.
A
I
I
think
it's
relatively
straightforward,
though
I
have
not
responded
to
james
feedback,
yet
I
will
get
to
that
soon.
Thank
you.
Thank
you
for
reviewing
this
just
as
a
high
level.
I,
the
scope
of
this
pr,
was
to
add
some
guidance,
add
the
guiding
principles
to
the
documentation
covering
conflict
resolution
and
to
say
you
know
if
we
have
not
covered
a
conflict
in
the
docs
for
a
specific
type.
A
I
re
use
these
principles
to
resolve
any
conflicts
and
then,
beyond
that,
I
added
three
or
four
different
resolutions
to
conflicts
inside
the
godoc
for
relevant
types
and
and
suggested
validation
as
well.
So
this
is,
I
think,
a
relatively
small
pr,
but
I
do
need
to
work
on
some
of
the
wording
for
sure
yeah
thanks.
I
do
need
a
new
line.
A
This
one
yeah
well
yeah
I'll,
respond
to
some
of
this
feedback
in
here,
but
thank
you
so
much
for
the
feedback
and
if
anyone
else
is
interested
in
conflict
resolution,
any
feedback
is
appreciated,
but
all
I
think
that's
straightforward
enough,
so
I'll
just
keep
on
moving
on
this
one
keep
on
going
back
down.
This
is
one
that
has
been
brought
up
before.
A
I
think
it.
I
think
everything
is
resolved,
there's
not
much
in
the
way
of
comments
or
feedback
on
this
one.
Yet
at
this
point
it
just
needs
an
lgtm
from
someone.
A
A
So
in
that
sense,
I
think
of
this
more
of
a
a
bug
fix
a
documentation
fix
then
an
actual
change
in
behavior
yeah.
So
if
anyone
has
time
to
to
take
a
look
at
this,
it's
a
pretty
small
pr,
yeah.
A
And
we'll
keep
on
going.
I
think
I'd
really
really
like
to
get
some
of
these
older
prs
in
so
I've
got
this
one,
which
is
allowed
gateway,
namespaces
and
basically
changing
it
to
suggest
that
it
should
be
done
on
create
only
so
again.
This
is
removing
this
condition
and
as
saying
that
this
will
instead
be
validated
entirely
by
entirely
by
a
validating
web
hook.
A
So
that
seems
straightforward
to
me.
It
definitely
gets
rid
of
some
potential
conflicts
and
some
potential
large
blast
radius
changes.
A
The
longest
discussion
on
here
is
a
thread
between
harry
and
I,
and
I
think
I
think
the
conclusion
is
that
we
can
track
this
as
a
separate
issue,
but
there
was
a
suggestion
that
maybe
we
should
still
have
a
condition
here,
a
condition
to
indicate
that
a
gateway
is
in
an
invalid
class
in
an
invalid
namespace.
So
as
an
example,
a
gateway
somehow
got
created,
the
webhook
validation
failed
or
that
the
name
slate
allowed
namespaces
changed.
A
I
don't
know
something
like
that,
and
it
is
a
gateway,
is
in
the
name
space
that
it
shouldn't
be
in
or
that
is
not
allowed
by
that
gateway
class.
And
this
condition
still
wouldn't
prevent
the
controller
from
actually
implementing
the
gateway.
It
would
just
be
more
of
a
warning,
and
my
hesitancy
with
this
condition
is
that
it's
it's
something
that
can't
be
consistently
applied,
because
we
don't
know
that
every
controller
is
going
to
be
able
to
see
every
namespace.
A
Able
to
meaningfully
say
that
a
gateway
exists
in
an
invalid
namespace
for
a
class
so
based
based
on
that.
I
was
hesitant
to
do
this,
but
either
way
I
think
we
can.
We
can
handle
that
in
a
separate
issue
and
if
we
do
push
that
off
to
a
separate
issue,
this
becomes
an
absolutely
tiny
pr.
So
again,
this
one
just
needs
a
tiny
bit
of
feedback.
C
H
A
Thanks
sounds
good.
Thank
you.
This
is
another
one
by
me
and
this
is
adding
gateway
selection
to
routes,
and
this
is,
I
think,
we
covered
this
in
more
detail
last
week
and
if
anyone
has
had
more
time
to
think
about
it
and
potential
ramifications,
the
entire
idea
is
to
flip
everything
on
its
head.
A
Remove
this
whole
concept
of
allowed
route,
name,
spaces
from
gateway
class
and
instead
allow
routes
to
specify
which
gateways
can
select
them.
So
it
still
requires
two
different
personas
for
gateways
and
routes
to
be
able
to
reference
each
other
multi-name
space
across
namespaces,
but
in
this
case
it
pushes
those
personas
down.
So
it's
basically
route
owner
and
gateway
owner
that
need
to
agree
instead
of
gateway
and
gateway
class
owner.
A
A
I
don't
know
this.
One
again
is
really
just
needing
some
review.
I
don't
you
know.
I
know
we've
talked
through
this
one
already.
I
don't
think
there's
too
much
more.
I
have
to
add
today
other
than
that,
if
you
have
some
time
to
take
a
look
at
it,
that
would
be
very
much
appreciated.
A
Any
any
last
words
on
this
one,
any
any
reasons
that
we
might
want
to
be
hesitant
here,
any
things
we
should
look
out
for.
A
Cool
all
right,
I
will
keep
on
moving
down
back
in
policy.
This
one
did
have
some
meaningful
changes
over
the
last
week,
so
I'll
get
into
them
a
little
bit.
Thank
you
to
everyone
for
the
feedback
on
this
pr
back
in
policy
like
I've
said
every
every
time
I
change
it.
It
gets
smaller.
A
So
you
know
that's
that's
where
we
are.
I
looked.
I
looked
around
the
community
for
use
of
tls
certificates
after
I
think
it
was
some
feedback
from
james,
and
he
had
mentioned
you
know
previously.
I
had
two
separate
references
here.
I
had
one
for
a
ca
bundle
and
one
for
the
certificate,
and
you
know
james
had
mentioned
well.
You
could
combine
those
all
into
a
single
tls
secret
with
kubernetes.
A
I
think
that's
a
reasonable
place
to
start
at
least
the
key
is
that
we
need
to
agree
on
the
key.
Ca
bundle
should
be
specified
under
so
in
this
case,
it
may
optionally
include
a
certificate
authority,
bundle
under
a
ca,
dot,
cert
key
data
field.
Whatever
this
matches,
I
can't
see
too
many
providers
that
are
doing
this
right
now,
but
nginx
ingress
is
a
notable
one
that
does
support
this
methodology.
A
A
I
think
that
is
simple
in
terms
of
less
secrets
to
manage.
It
is
unfortunate
if
you
want
to
you,
know,
use
the
same.
Ca
bundle
a
ton
of
different
times,
and
you
then
have
to
embed
it
in
each
one
of
your
secrets.
I
can
see
that
getting
potentially
annoying
in
this
use
case,
but
yeah
this.
This
does
seem
like
a
simple
approach
and
it-
and
I
think,
a
compelling
reason
to
start
here
is
it
doesn't
preclude.
C
I
have
I
have
thoughts
so
originally,
when
I
was
talking
about
the
ca
cert.
I
was
looking
at
it
from
the
perspective
of
you,
have
a
certificate,
a
key
and
a
ca
bundle,
and
you
want
to
put
them
all
on
the
same
secret
and
the
ca
bundle
is
the
one
for
the
certificate
that
you
have
in
the
secret,
so
they
all
match.
C
I
only
found
out.
I
only
found
out
about
how
nginx
ingress.
B
C
The
ca
cert
data
field
when
I
tried
to
kind
of
standardize
upstream
and
honestly,
I
am
not
a
fan.
C
The
problem,
I
think
I
see
with
the
way
internetx
does
it
is
that
you
have
a
single
secret
with
two
completely
different
disjoint
things
in
it
right,
so
you
have
a
single
secret,
which
has
your
client
certificate
in
your
client
certificate
and
your
key
and
someone
else's
ca
bundle
yeah.
So
you
take
two
things
which
are
completely
independent,
completely
separate
and
have
no
relationship,
and
then
you
stuff
them
into
the
same
secret
and
stuffing
them
with
the
same
secret.
C
A
That's
makes
sense,
yeah,
no,
that's
fair
yeah,
I
mean
I,
as
I
read
through
nginx
implementation.
It
did
seem.
I
I
agree
with
how
you
were
describing
this,
as
you
know,
shoving
in
two
things
that
aren't
entirely
related.
I
mean
they're
they're,
both
used
for
a
similar
purpose
of
client,
tls
kind
of
you
know,
but
but
yes,
it's
not
an
obvious
relationship,
and
if
you-
and
if
you
just
saw
these,
you
know
certs
and
ca-
bundle
hanging
out
together
in
a
secret,
you
might
think
they
were
more
closely
related
than
than
they
are.
A
C
A
I
I
think,
the
way
I'm
understanding.
That,
then,
is
that
it
may
be
better
to
go
back
to
take
one
step
back
and
have
a
ca.
Cert
wrap
a
ca
bundle,
ref
and
a
client
certificate
ref
and
just
kind
of
keep
them
separate.
C
Yeah,
I
think,
for
for
ca,
bundles,
I
would
support,
I
think
it.
I
think,
standardizing
the
ca
cert
to
store
a
ca
certificate
bundle
in
a
kind
of
abstract
sense,
and
I
think
I
think
that
makes
sense.
I
think
that
you
know
if
now,
if
this
api
can
standardize
that
key,
then
I
think
that's
good
for
for
the
ecosystem,
but
I
think
it's
in
specifically
sorry
here
in
in
the
backend
tls
config.
I
think
we
should
distinguish
between
the
certificate.
C
The
client
certificate
that
you're
presenting
and
the
policy
in
which,
which
you're
using
to
validate
the
peer
that
you're
connecting
to
yeah.
A
That's
fair
yeah,
now
any
any
other
thoughts
on
this
one.
Anyone
else
have
the
same
kind
of
hesitation
here
between
shoving
everything
into
a
single
tls
secret.
A
Yeah
yeah;
okay,
that
that.
C
Far
as
as
far
as
peer
validation
policy
goes,
I
think
there's
a
number
of
things
that
you
might
want
to
validate
you.
I
mean
there's,
obviously
the
ca,
but
the
ca
roots.
There's
also
you
know
hosts
you
will
see
usually
validate
some
sort
of
host
name.
You
can
have
certificate
validity.
You
know
that
I
only
want
to
connect
to
things
which
are
valid
for.
E
G
A
I
had
thought
of
it:
it
being
a
another
object:
ref
a
separate
object,
ref
for
to
reference,
aca
bundle.
C
A
I
that's
that's
a
good
question.
I
know
if
you're
going
to
make
it
a
kubernetes,
tls
secret,
it
needs
to
have
the
tls
cert
and
tls
key
fields.
So
I
would
I
guess
it
would
have
to
not
be
this
secret
type
and
just
have
this
specific
key
in
it,
but
I
I'm
not
sure
how
broadly
that
supported.
H
A
C
You
know,
there's
a
large
proportion
of
users
who
are
going
to
be
using
things
like
cert
manager
to
generate.
B
C
So
I
think
I
agree
that
conflict
supporting
a
conflict
map
makes
sense
for
some
implementations,
but
there's
also
this
wider
ecosystem,
like
what
is
everybody
else?
What
is
what
all
these
other
tools
do,
because
we
all
have
to
kind
of
agree
on
where
we're
storing
things.
C
Thinking
back,
I'm
not
sure
I
had
a
point,
but
I
should
have.
Maybe
my
point
is
that
we
should
strongly
in
this
api.
We
should
strongly
define
what
the
formats
of
all
these
things
are
and
give
the
ecosystem
something
to
coalesce
around.
C
C
E
Okay,
I'm
telling
you
because
I
understand
where
makai
is
coming
from,
there's
nothing
secret
with
the
certificate,
but
on
the
other
hand,
I
know
that
you
know
what
rob
was
saying
is
like
anything
at
all.
Security
related
seems
to
you
know
lean
towards
using
a
secret.
So
that's
why
I
was
curious
if
assert
managers
a
big
common
integration,
if
we
should
choose
one
or
the
other
based
on
ease
of
integration,.
C
G
C
Yeah,
what
it
typically
does
is
when
it
generates
a
secret.
It
will
put
some
of
the
let's
talk
about
this
the
other
days.
It
puts
some
of
the
chain
in
the
tls.cert
key,
but
I
think
it
puts
the
root
of
the
ca
bundle
in
the
ca.cert
data
field
in
the
secret.
C
C
As
far
as
I
know,
it
never
puts
anything
in
config
maps
today,
but,
like
you
say,
I
don't
think
that
there's
any
I
mean
I
think
I
agree
that
ca,
bundles,
aren't
secrets
sort
of
by
definition.
A
Okay,
yeah,
that's
that's
helpful,
I'll
I'll,
be
sure
to
follow
up
with
this
one.
It
seems
like
there's
broad
consensus
to
split
this
out
and
I
should
take
a
bit
of
a
survey
around
the
community
again
just
to
see
how
broadly
certificates
well
ca
starts.
Ca,
bundles
are
supported
and
what
kind
of
resources
they're
most
commonly
stored
in
and
and
if,
if
it
is
secrets,
maybe
I'll
at
least
default
to
referencing
a
secret
here
and
yeah.
A
Maybe
there's
maybe
there's
a
place
for
describing
how
we
could
reference
this,
and
I
couldn't
no.
I
I
think
we
should.
We
should
suggest
they
should
be
in
one
kind
of
resource
and
and
go
with
that
so
yeah
I'll
follow
up
on
this
one.
Thanks
for
the
great
feedback
here
and
I'm
also
as
I'm
looking
at
this
and
realizing,
I
haven't,
removed
all
the
prototypes.
Yet
so
at
least
one
more.
E
Yeah,
I
pop
that
in
a
comment.
Thank
you.
The
pr
also
another
comment,
but
I'm
still
gonna
go
through
and
review
appreciate
it
more
comfortable.
A
A
A
All
right
well
yeah.
I
guess
we
are
over
time,
but
thank
you
to
everyone
for
the
great
feedback.
I
think
we're
making
great
progress
here
and
yeah
I'll
follow
up
on
this
pr
shortly.
Thanks.