►
From YouTube: Gateway APIs Meeting (APAC Friendly Time) 20210809
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
carry
on
sorry,
I
guess
recording.
B
To
start
this
yeah
so
last
week
I
spoke
to
celeste
horgan
from
one
of
the
tech
writers
from
the
cncf.
She
did
a
great
review
of
contours
docs
and
the
cncf
are
sort
of
spinning
up
a
docs
review
process
and
I
sort
of
pinged
her
and
said:
hey.
Is
there
something
like
that
for
communities
that
that
we
could
do
she
said
I
don't
know
I'll
check
with
sig
docs
like
she
said?
B
Oh,
I
can
do
a
cncf
one,
but
I
don't
know
if
sing
dogs
will
want
me
to
do
that,
but
they
were
like
that's
fine,
so
she
is
going
to
have
a
look
over
or
someone
who
she
gets
to
do
it.
She
will
organize
someone
having
a
look
over
our
docs
and
sort
of
a
a
you
know
technical,
but
I
don't
know
anything
about
this
specific
thing
reader.
What
do
they?
You
know?
What
do
they
think
about
our
docs?
B
I
mean
I
think,
as
of
today,
the
experience
is
woeful
if
you
are
technical,
but
I
don't
know
very
much
about
what
we're
trying
to
achieve
with
go
api.
So,
like
rob
said,
I'm
gonna
spend
some
time
this
week.
Rob
if
you
pick
me
that
name
of
that
plugin
I'll,
have
a
look
and
see
if
there's
anything,
I
can
do
quickly
to
do
that
I'll
have
to
play
with
it
yeah.
B
So
I
think
and
I'll
see,
if
I
can
do
some
docs
updates
some
since
I'm
looking
at
the
docs
and
I'm
thinking
about
being
one
off
or
two
anyway
I'll
see.
If
I
can
push
in
any
updates,
I
think
that
the
biggest
update
is
going
to
be
the
the
route
attachment
one
once
we
get
that
pr
merged
in
is
to
do
a
doc's
update
to
handle
that
one,
because
that's
completely
different
to
what
it
was.
A
Yeah
yeah
that
so
that
that
pr
like
I've,
just
I
haven't
gotten
into
docs
yet,
but
even
just
examples,
it's
changing
a
lot,
that's
going
to
be
our
most
our
biggest
one
to
document
and
everything
yeah
but
yeah.
That's
that
sounds
really
really
great.
I'm
excited
to
have
more
docs
reviews
and
more
more
work
on
docs,
because,
like
woeful,
I
think
is
where
you
used
is
yeah
very
good,
accurate,
I
would
say
so.
A
Yeah
that's
got
to
be
our
focus
for
the
next
couple
weeks,
at
least
to
try
and
get
them
up
to
date
and
reasonable,
and
really,
I
think
you
know
what
what
has
naturally
happened
is
when
we've
merged
v1
alpha
2prs
in
we've,
either
missed
documentation
or
just
kind
of
added
it
here
and
there,
and
it
may
not
have
made
sense
where
we
added
it
like.
We
don't
have
a
a
a
reasonable
structure
anymore.
B
Yeah,
so
I
think
the
that's
one
of
the
things
that
I'm
hoping
that
celeste
reviewed.
She
did
a
lot
of
talking
for
contour
about
our
information
architecture
and
suggestions
for
ways
in
which
we
could
approach
that.
So
I'm
not
going
to
spend
a
lot
of
time
worrying
about
the
information
architecture.
Yet
until
I
get
someone
who
knows
what
they're
doing
to
suggest
some
things:
perfect,
yeah,
yeah
and
the
but
yeah,
I
will
try
and
make
sure
that
the
pages
we
have
are.
B
You
know
either
correct
themselves
or
have
an
issue
open
to
correct
them,
or
something
like
that,
so
that
yeah,
if
I
can't
get
to
all
the
things
myself,
that
we
at
least
have
a
burn
down
list
for
for
the
doc
strangers.
A
Yeah
great
well,
thanks
for
setting
that
up
yeah,
no
problem
cool
all
right.
Well,
let
me
let
me
keep
on
moving
here,
but
I
think
this
I
think,
we're
in
pretty
good
shape.
I
I'm
hopeful
that
we
can
get
this
in
and
ready
for
review
this
week
with
all
these
pr's
in.
But
of
course,
it'll
just
take
that
kind
of
continued
effort
on
the
review
front,
but
at
least
the
pr's
exist
or
almost
exist
so
cool
the
the
next
one.
A
I
I
don't
so
let
me
just
say
I
don't
I
don't
think,
there's
a
whole
lot
of
prior
art
here
or
any
prior
art
here,
but
if
anyone
has
suggestions
for
the
review
process
and
how
we
make
that
work
currently,
my
working
theory
is
some
kind
of
pr.
That's
based
on
master.
That
goes
into
some
kind
of
new
branch
that
doesn't
have
v1
alpha
2
in
it.
A
Yet
is
approximately
what
I'm
what
makes
the
most
sense,
but
if
anyone
is
more
familiar
with
this
or
has
ideas
on
how
we
can
make
api
review
relatively
easy
for
the
cygnet
reviewers,
I
am
very
interested
in
ideas,
options
whatever,
but.
C
A
I
think
it's
going
to
be
hard
to
find
time
where
everyone
overlaps,
but
I
was
planning
on
reaching
out
to
them
with
on
slack
and
seeing
if
that
would
be
helpful,
and
maybe
it's
a
couple
one-off
meetings.
If
timing
doesn't
work
for
all
of
them,
I
I
don't
know,
but
I'm
I'm
very
people
with
that
three.
A
C
C
C
A
D
A
B
All
right
yeah,
I
feel
like
with
respect
to
the
power
thing
the
like.
It
feels
like
they're,
going
to
need
to
be
reviewing
pretty
much
the
whole
like
the
whole
set
of
apis
go
files
and
the
the
docs
that
we
have
both
there
and
in
like
on
the
website
so
like
it
feels
almost
like.
You
could
just
be
like
here's,
the
v1
alpha,
2
branch
off
you
go
or
something
like
that.
Like.
A
Yeah
yeah,
no,
I
almost
thought
about
that,
but
it
feels
like
we
need
to
have
some
kind
of
mechanism
for
comments
and
back
and
forth
and
and
updates
and
and
that
kind
of
thing
which
pr
is
probably
the
easiest
yeah
yeah.
But
you
know,
as
a
pr
is
going
to
get
overloaded.
You
know
we
have
gaps
that
have
hundreds
of
comments
or
over
a
hundred.
I
imagine
this
will
get
more
than
that.
A
I
don't
know
we'll
see,
but
as
a
starting
point
I
mean
we've
never
done
this
before
it
seems
like
a
reasonable
start
and
if
we
need
better
we'll
figure
it
out,
I
guess
but
cool
all
right.
The
the
very
last
thing.
Well,
no,
not
the
very
last
thing,
but
the
thing
that
I
wanted
to
highlight
is
something
that
we
talked
about
in
doc
form
last
week.
A
I
the
reason
I'm
bringing
this
up
in
this
context
is,
from
my
perspective,
v.
One
alpha
two
is
potentially
our
last
alpha
release.
We-
I
don't
know
that
for
sure,
but
I
want
to
at
least
give
us
the
chance
for
it
to
be
our
last
alpha
release.
I
would
love
to
be
able
to
go
to
beta
from
v1
alpha
2.,
so
that
means
at
a
minimum.
We
can't
remove
things
we
can.
We
can
do
things
to
convert,
we
can
whatever,
but
if
there's
anything
we're
uncertain
about,
we
should
try
and
remove
it
now.
A
Well,
we
can
have-
and
we
have
this
opportunity
to
make
a
truly
breaking
change.
Now.
We
can
make
other
changes.
We
can
do
things
that
are
convertible,
but
I
don't
know
that
there's
much
precedence
for
like
completely
removing
something
on
the
way
to
beta.
Maybe
there
is,
I
don't
know,
but
I
wanted
to
at
least
explore
that.
A
A
A
B
A
Yeah
and
and
I'll
admit
that
that
you
know
it
may
be
too
optimistic
whatever,
but
I
I
don't
want
to
leave
anything
off
the
table
like
if
there's
something
we're
uncertain
about
I'd
rather
not
include.
It
then
include
it
and
then
wish
we'd
taken
this
opportunity
to
remove
it.
That
I'd
say
that's
my
my
primary
thinking
here
and
so
this
this
gap
is
really
tiny
and
well.
A
The
consequences
are
larger,
but
the
actual
api
changes
are
tiny.
The
api
change
is
really
just
remove.
Tl
like
dls
cert,
ref
from
route
and
add
a
namespace
field
to
the
cert
ref
on
gateway.
A
B
I
can't
remember
if
we
do
or
not,
we
definitely
were
planning
to
okay,
exactly
how
it
works
is
complicated,
really
yeah.
A
Yeah
and
and
that's
what
it
was
so
one
of
the
things
that
actually
is
in
the
v1
alpha
2
milestone
was
a
pr
that
I
had
started
with,
which
was
trying
to
clarify
the
documentation
and
clarify
how
it
worked,
and
that
kind
of
got
hung
up
and,
as
I
was
writing
it
out
it
just
it
felt
increasingly
confusing
and
and
prone
to
something
that
would
cause
issues,
confusion
and
many
conflicts,
and-
and
it
felt
like
something
that
we
could
potentially
solve,
just
with
the
direct
ref
from
gateway
and
maybe
automation,
if
necessary,
and
that
that's
where
this
gap
came
from
right,
it
was
just
can,
can
we
accomplish
many
of
the
same
things
without
the
same
confusion
without
the
same
room
for
conflicts,
etc?
A
That
that's
the
fundamental
thinking
here,
but
I
wanted
to
get
some
broader
feedback
and
it,
I
don't
think,
there's
anything
particularly
new
in
this
gap
that
wasn't
already
in
the
doc
but
yeah.
What
are
people
thinking
about
this
idea?.
B
B
You
know
I
want
to
be
able
to
supply
some
tls
details
and
I
want
them
to
be
you
to
be
wired
up
for
me
and
I
don't
want
to
have
to
edit
the
gateway
to
do
that
and
that's
the
those
are
the
two
key
things
that
that
the
app
developer
owns
the
tls
details
and
that
they
don't
want
to
have
to
give
gateway
edit
access
to
app
developers
to
enable
them
to
put
that
on
the
on
the
gateway.
B
I
mean
they
don't
want
to
have
to
have
coordination
between
the
gateway
owner
and
the
route
owner
to
say
it's,
this
specific
secret
or
something
like
that
right,
like
they
want
to
just
be
able
to
have
some
way
in
which
you
can
do
this.
The
problem
is
right,
the
more
magic
you
make
it
the
easier
it
is
to
for
people
to
accidentally
blow
things
up
or
to
expose
services
they
shouldn't
or
that's.
B
What's
especially
when
you
start
going
across
namespace
so
yeah,
I
will
have
a
I'll
have
a
look
over
that,
but
that's
definitely
the
use
case
that
I
that
I
think
I
certainly
expected
the
http
route
pls
support
to
before
is
for
people
to
be
able
to
for
app
developers
be
able
to
say
you
know
I've
done
my
own
work
to
I've
got
my
own
tls
key
pair
that
I
want
to
that.
B
I
want
to
secure
this
specific
service
with,
and
you
I
mean
obviously
that's
going
to
include
the
hostname
most
of
the
time,
but
maybe
not
always
like
that's
the
problem.
Is
people
want
to
be
really
magic
without
having
to
worry
too
much
about
the
implementation
details
which
puts
the
implementation
complexity
involved
squarely
on
the
implement
like
on
the
actual
gateway
implementers.
A
Yeah
yeah,
that
that
makes
sense-
and
I
guess
something
you
know
coming
from
from
my
perspective-
or
this
is
really
more
of
a
question:
how
common
is
it
for
app
developers
to
be
providing
their
own
certs
versus
using
something
like
cert
manager
or
some
other
kind
of
form
of
generated
cert
for
their
dev
domain
or
whatever
other
domain
they're
they're,
interacting
with?
Is
that
a
pretty
common
feature
request.
B
I
certainly
haven't
had
that
exact.
It's
feature
request,
but
so
we've
got
a
really
old
issue
in
contour
which-
and
I
remember
this
title
because
you
know
every
time
I
look
at
it
it.
You
know
stabs
me
in
the
eye.
Is
it
something
like
hdb
proxy?
B
Designing,
creates
bad
life
cycle
management
or
something
like
that
and
their
complaint
is
basically
that,
because
we
have
this
mandated
thing
where
there's
a
root:
hp
proxy,
that's
owned
by
the
person
who
owns
domain
and
then
child
hp
proxies
have
to
be
put
in
single,
like
combined
references
by
name
from
the
person
who
owns
that
root
history
proxy,
then
it
means
that
the
people
who
are
downstream
of
that
have
to
either
have
added
access
to
the
top
level
one
or
there
needs
to
be
a
strong
level
of
coordination
between
the
two
things.
B
You
know,
and
I
was
like
well
that's
why
we
actually
designed
patient
proxy
specifically
to
force
that
strong
level
of
of
coordination
between
the
two
between
the
two
actors,
you
know
and
that
that
api
is
specifically
designed
to
to
make
you
do
that,
and
so,
like
yo
yeah,
I
was
kind
of
annoyed
at
the
guy
who
loved
it
to
be
honest
but
like,
but
the
point
is
that
people
definitely
want
there
to
be
a
more
magic
way.
That's
definitely
that's
more
akin
to
what
you
can
do
to
the
sorts
of
crazy
shenanigans.
B
E
B
Yeah
they'll
reference
the
same
tls
or
something
like
that.
Like
that's
the
sort
of
thing
people
just
I
don't
want
to
have
to
think
about
this.
You've
got
to
make
this
problem
go
away
for
me
and
then
the
fact
that
they
don't
want
to
have
to
think
about.
It
means
a
lot
of
the
time
they
haven't
thought
about
the
weird
edge
cases
that
you're
going
to
come
up
with
once
people
start
claiming
different
domain
names
on
different
certs
or
something
like
that.
C
Yeah,
I
think,
like
the
question
we
were
asking
with
this
is:
does
that
magic
need
to
live
here
or
is
it?
Could
it
be
governed
by
a
separate
system
where
it
is
fairly
well
factored
out?
For
example,
the
magic
could
involve
less
encrypt
could
involve
some
kind
of
facilitation
of
like
handing
out
certificates
to
people,
but
it
it
sounded
complicated
and
factored
out
enough
that
it
may
make
sense
to
live
kind
of
side
on
the
side
of
this,
but
not
directly
inside
here.
A
Yeah-
and
I
I
think
one
I
I'd
echo-
those
concerns,
I
think
one
of
my
concerns
is-
and
this
came
from
writing-
that
pr
that
was
trying
to
explain
this
is:
is
that
the
trust
model
here
that
a
route
and
namespace
a
can
somehow
affect
a
route
and
name
space,
b
or
c?
Basically,
when
a
route
trusts
a
gateway,
it
trusts
all
the
other
routes
that
gateway
trusts
specifically
for
servants,
and
so
there's
kind
of
this.
A
If
this,
if
this
gateway
trust
routes
and
these
three
name
spaces,
I
as
a
route
owner-
need
to
know
that
and
also
trust
those
same
namespaces
which
maybe
that's
okay,
but
it
it
gave
me
some
some
room
for
consideration
that
maybe
this
is
something
I
don't.
I
don't
know
what
it
is
yet,
but
maybe
there's
some
vulnerability
lurking
here
that
we
haven't
completely
understood.
Yet
I
don't
know.
E
So
I
I
kind
of
think
I
think
that
the
proposal
here
definitely
prevents
or
removes
any
support
for
the
kind
of
workflow
that
nick
was
just
describing.
E
I
think
the
simplification
is
a
good
thing
and
I'd
argue
that
maybe
it's
even
good
from
like
a
conceptual
point
of
view,
because
we're
saying
okay,
this
is
the
thing.
Here's
one
thing
which
gateway
api
does
and
if
you
want
higher
level
stuff,
then
you
should
build,
highlight
build
something
higher
level
on
it
and
I,
I
kind
of
think,
that's
okay.
C
Yeah,
I
think
the
important
thing
rob
I
haven't
read
your
gap,
but
it
wasn't.
It's
like
it
doesn't
remove
the
fact
that
you
could
build
the
infrastructure.
It's
more
like
you
need
to
describe
it
in
such
a
complete
detail
at
this
layer,
which
I
think
is
an
interesting
distinction.
We
should
make
like
nothing
will
prevent
awesome,
cert
thing
from
being
built
on
top
of
it
versus
that
the
fact
that
awesome,
cert
thing
needs
to
actually
exist
inside
here.
A
That's
it
I
mean
when,
when
I
was
again
when
I
was
trying
to
document
the
existing
state,
it
became
clear
that
it
was
one
confusing
but
two,
that
the
entire
purpose
of
cert
on
route
was
just
as
a
shortcut
to
attach
that
cert
to
the
listener
and
the
idea
that
people
could
attach
multiple
certs,
conflicting
certs,
etc.
That
way
involved
a
lot
of
potential
for
conflicts
and
additional
bits
of
status.
A
We
might
need-
and
it's
really
just
a
shortcut
mechanism-
it's
it's
not
really
anything
that
it
feels
like
there's
a
better
way
to
accomplish
that
shortcut
without
messing
up
or
confusing
the
api.
But
that's
my
own
bias
here.
I
think
there
are
a
few
others
that
we're
trying
to
say
something:
yeah
go
ahead
mike.
F
A
I
think
it's
the
idea
that
someone
can
choose
to
specify
a
cert
for
your
host
name,
and
that
is
what
you're
stuck
with
essentially
and
and
it's
not
a
gateway
owner.
It's
another
route
owner
in
another
name,
space
and
they're
they're,
specifying
a
cert
on
your
behalf
that
you
may
not
like.
I
mean
that
that's
kind
of
a
dumb
I
don't
know,
but
just
that
that
unexpected
mechanism
feels
like
it's
right
for
unexpected
things
to
happen.
I
don't
know
what
they
are.
I
can't
I
I'm
unsure.
F
That's
the
certificate
you
use
if
that
route
is
used
and
the
route
is
going
to
be
selected
based
on
things
like
host
name
and
possibly
other
rules.
Path
may
be,
assuming
that
your
angus
controller
is
terminating
tls
and
can
look
at
the
past,
the
host
header
and
the
the
path
in
the
request.
I
guess
like.
B
Yeah,
I
think
the
problem
is
the
problem.
Is
that
when
you
do
the
like,
when
you
do
the
dance
right,
if
you've
got
multiple
certs,
that
all
want
to
want
to
talk
for
the
same
host
name,
if
they're
not
exactly
the
same,
then
like
you
have
a
problem
because,
like
at
the
tls
negotiation
point
which
one
do
you
use
like,
you
don't
have
enough
information
at
the
tls
negotiation
point
to
know.
B
If
there
are
two
conflicting
routes
that
both
specify
search
for
hostname.com
or
whatever,
then
you
have
you
don't
have
all
you
have
at
that
point
is
the
s9
while
the
tls
negotiation
is
finishing
and
that's
if
you're
terminating,
and
so
the
only
thing
that
you
can
use
to
choose
which
which
certificate
to
have?
Is
that's
nice?
That's
literally
what
it's
for.
So
you
can't.
B
If
you,
if
you
allow
people
to
specify
their
own
search
for
for
a
host
name,
you
the
thing.
You've
got
a
thing
you
have
to
handle.
As
part
of
that
is
what
happens
if
someone
has
a
con?
Is
someone
if
there's
a
conflict,
and
how
do
you
tell
that?
There's
a
conflict
right
like
that
means
that,
basically,
your
ingress
controller
will
have
to
go
in
decode.
B
The
cert
check
that
you
know
check,
subject,
alternate
names
or
cns
to
check
that
the
the
host
and
the
host
name
that
it
says
it's
for
is
what
it's
actually
for
and
stuff
like
that,
which
is
super
like
quite
complicated
right
like
you,
don't
want
to
do
that
if
you
don't
have
to.
A
F
A
You
have
something
very
similar
in
openshift,
but
I
think
you
have
a
few
more
validation
bits
of
validation
that
help
make
it
more
manageable.
For
your
use
case,
the
yeah,
I
think
the
yeah
go
ahead.
F
Well,
there
are
two
things:
one
you
mentioned
or
nick
mentioned
validating
certificates.
We
actually
do
validate
certificates
in
our
ingress
controller
and
we'll
complain.
If
you
give
us
well
something
invalid.
The
other
thing
is
I
I
think
I
see
what
you're
saying
if
you
have
two
routes,
are
you
saying
if
you
have
two
routes
with
the
same
host
name
and
say
they
match
on
different
paths
and
each
route
specifies
their
certificate?
You
need
to
know
which
certificate
to
use
to
terminate
tls
so
that
you
can
then
do
the
path
match.
B
So
you
can
route
and
stuff
like
that,
but
that
doesn't
change
the
fact
that
at
the
tls
negotiation
point,
the
only
information
that
a
implementation
that's
terminating
tls
has
is
the
tls
details
like
the
s
and
I
plus
the
plus
the
cypher,
suites
and
stuff.
Like
that,
that's
all
it
has,
and
you
know
stuff,
that's
in
the
search,
obviously
cns
and
sans
and
stuff
like
that.
But
that's
that's
it
that's
all.
B
It's
got
yeah
until
it's
finished
that
and
then
it
can
look
at
the
and
then
it
can
look
at
the
the
the
route
of
the
path
and
headers
and
stuff
like
that.
But
it
can't
do
that
until
the
tls
is
finished,
and
so
you
have
no
way
to
pick
which
cert
it's
going
to
be
based
on.
If
the
certs
are
different,
based
on
things
that
are
not
the
sni
and
like
ca
and
stuff
like
that,
then
then
it's
not
gonna,
you
can't
you
can't
use
it
as
discriminator.
B
You
just
don't
have
enough
information
and
so
and
the
the
thing
the
thing
that
arises,
then
this
is
one
of
the
reasons
we
haven't
done.
Any
contour
is,
if
you
have
you
know
it's
kind
of.
I
think
we
kind
of
intended
that,
if
you're
going
to
do
this,
the
the
way
that
you're
going
to
practically
use,
it
is
there'll,
be
a
wild
card
cert
on
the
on
the
gateway,
and
then
you
can
supply
a
more
specific
cert
on
a
route.
B
B
You
know
and
have
blogged.com
as
a
separate
cert
that
comes
in
on
a
route
instead
of
on
the
gateway,
and
that's
because
you
don't
want
to
give
people
with
you
don't
want
to
give
people
with
for
people
with
route
access
access
to
edit
the
gateway
to
put
the
cert
on
the
gateway,
and
but
I
think
the
bowie's
point
is
fair,
that
you,
you
don't
have
to
give
them
access
to
that.
B
C
C
It
was
it
wasn't
clear,
100
clear
that
let's
say
we
put
it
in
the
route
that
that
is
an
appropriate
place
for
all
use
cases.
I
think
that's
what
like
one
of
the
biggest
concerns
would
be
is
that
if
you
put
in
the
route,
you
kind
of
lock
people
into
a
certain
way,
for
example
to
for
people
to
represent
that
they
want
a
certificate
added
to
the
gateway
and
then
a
certain
way
to
enforce
and
kind
of
grant
that
permission,
and
it
felt
like
at
least
with
certificates.
C
A
lot
of
the
infrastructures
are
fairly
complex
in
terms
of
how
permissions
would
be
mapped
and
so
forth,
like
there's
even
some
degree
of
organizational
structure,
that's
built
into
it.
Maybe
everyone
has
access
to
certificates.
Maybe
the
groups
are
different,
so
the
kind
of
the
difficulty
is
that
if
we
put
it
into
the
api
now
we
might
have,
we
might
be
basically
mandating
a
certain
way
of
doing
things
which
may
not
make
sense
in
the
broader
context
like.
C
I
know
that
there
was
a
lot
of
discussion
about
like
oh
well,
what
if
we
have
some
resources
to
represent
like
who
owns
what
host
names
and
so
on
and
so
forth.
But
that's
like
a
very
complicated
thing,
because
that,
in
some
ways
or
maps
are
like
organizational
structures
which
may
not
be
so
nice
as
to
how
kubernetes
resources
are
parceled
out.
C
So
in
that
light,
though,
like
makaya,
it
is,
we
should
write
down
the
use
case
and
understand
that
it
is
possible
to
layer
it
on
top
and
kind
of
what
a
system.
Maybe
we
could
have
a
generic
mechanism
that
fits
this
use
case,
but
doesn't
necessarily
need
to
kind
of
go
inside
the
current
route
data
structure.
C
C
Some
reasonable
path
versus
just
like
hey
like
this,
is
something
that
we
fill
in
sort
of
like
exercise
left
for
reader.
A
Yeah
I
sketched
that
out
in
in
this
gap.
I
I
this
is
not
a
a
great
deal
of
detail
here,
but
I
I
tried
to
explain
what
a
controller
might
look
like
that.
Does
this
and-
and
I
think
it's
actually
a
pretty
compelling-
you
know
use
case
for
a
controller
right.
We
have.
We
have
great
examples
already
of
controllers
that
automate
cert
attachment
right.
It's
it's
not
a
new
concept
in
kubernetes,
and
I
think
it
would
allow
a
more
natural
way
to
represent
this
of
if
that
controller
could
be
configured
with
something.
A
A
The
one
part
is
removing
the
cert
ref
from
routes,
but
the
other
part
is
allowing
cross
name,
space
refs
from
gateway,
so
that
allows
for
that
ability
to
attach
a
certificate
from
an
app
namespace
to
a
gateway
and
potentially
others.
But
I
think
that
is
actually
a
fairly
powerful
thing
that
does
enable
all
this
kind
of
automation
in
what
I
think
would
be
a
better
end
state
personally.
B
F
B
Yeah,
okay,
so
yeah,
I
you
know,
obviously,
because
we've
got
requests
for
contour
for
the
same
thing,
I'm
gonna
need
to
think
about
it
too,
and
so
yeah
you
and
I
can
catch
up
about
this
offline,
maybe
mclaren
and
talk
about
it.
A
bit
more
I'll.
Have
a
look
at
this
gap,
rob
and
see.
If
I
can,
it
makes
sense
to
me
that
that
the
hot
I
mean
it
could
be
that
the
high
level
controller
is
part
of
the
implementation
of
an
ingress
controller
right
like
it.
B
A
A
Yeah,
I
think
this
was
one
of
their
points
of
confusion,
of
how
or
if
they
should
support
certs
on
routes
yeah,
but
we
I
I
agree,
we
sh.
We
should
try
and
make
sure
this
is
all
coherent
and,
and
it
makes
sense
with
the
assert
manager
and
any
other
kinds
of
automation.
A
Yeah.
You
know
my
my
preference
right
now
is
is
obviously
to
try
not
to
include
it
in
v1,
alpha
2.,
but
this
is
admittedly,
a
small
enough
change
that
maybe
we
don't
need
to
block
api
review
on
this
specific
thing,
but
you
know
I
would
love
to
you
know,
have
those
discussions
and
make
sure
that
we
can
get
we.
B
Yeah,
I
think,
looking
just
I
just
spent
a
little
bit
a
second
reading,
the
previous
comments,
and
I
think-
and
I
think
one
of
the
key
part
is
as
rob
said,
that
in
this
one
the
other
thing
that's
important
here
is:
is
that
we've
got
there?
Is
a
mechanism
here
to
do
the
cross
name,
stress
refs
and
have
the
refs
be
allowed
or
disallowed.
You
know
and
that's
the
reference
policy.
I
like
that.
B
The
idea
here
is
to
take
the
reference
policy
thing
that
we're
using
for
services
right
now
and
to
apply
it
to
secrets
for
for
this,
for
this
use
case
yeah.
B
So
like
yeah
again,
the
thing
is
that
the
secret
can
live
in
a
namespace,
a
separate
namespace
that
people
don't
have
access
to
that
can
have
reference
policies
that
say
what
gateways
it's
allowed
to
be
used
in,
and
so
you
can
have
it
leaving
the
namespace
where
your
route
says
that
and
a
reference
policy
that
says
this
can
be
used
in
a
gateway
in
this
specific
gateway
and
so
that
you
know
that,
then,
is
a
mechanism
that
that
a
high
level
controller
can
use
to
actually
pull
the
certs
in
and
there's
there's
a
there's.
B
All
that
also
means
that
there's
there's
a
point
at
which
the
gate,
the
controller,
that's
handling.
This
can
reject
the
thing
at
some
point
and
there's
a
place
where
you
can
surface
that
information
and
that's
the
reference
policy.
You
can
say
I
can't
you
know
this
reference
policy
is
allowed,
you
know,
but
but
I
can't,
but
you
can't
do
it
for
other
reasons,
or
something
like
that.
So
there's
there's
a
status
point
where
you
can
get
information
about.
What's
going
on,
yeah.
F
So
the
idea
of
having
giving
the
ingress
controller
or
the
gateway
controller,
implementation
gateway,
api
implementation,
access
to
all
secrets
in
the
cluster
makes
me
nervous
and
right.
You
can't
specify
a
reference
policy,
but
what
enforces
reference
policy?
Isn't
that
the
same
thing
to
which
you
gave
access
to
all
the
secrets
in
the
cluster.
A
Yeah
so
yeah
you're
completely
right,
and
so
it
depends
on
your
security
model.
It
depends
on
what
you're
comfortable
with
it
is
entirely
valid
that
we
want
this
to
be
a
different
component
altogether,
right
that
we
want
this
to
be
a
controller
that
watches
certs
and
watches
secrets
in
a
specified
set
of
namespaces
and
then
attaches
them
to
gateways
and
potentially
other
namespaces.
A
If
you
want
to
limit
or
reduce
your
your
risk
and
similarly
you
could
deploy
a
you
know,
a
gateway
controller
implementation
that
only
had
access
to
a
subset
of
namespaces
or
secrets
in
a
subset
of
namespaces,
but
I
think
we
have
the
same
same
access
concerns,
if
not
more,
when
it
comes
to
attaching
secrets
to
routes
right.
A
You
know
in
that
world
a
you
know,
a
a
gateway
implementation
is
going
to
have
to
be
able
to
read
all
secrets
in
any
in
any
name
space
it
supports
routes
which
is
also
a
pretty
elevated
access.
A
A
F
That's
a
good
point,
and
that's
actually
that
reminds
me
that
we
did
talk
a
lot
about
that
in
the
issue
that
harry
linked
issue
103,
where
we
talked
about
trusting
the
ingress
controller,
to
read
all
secrets
in
the
cluster,
and
we
actually
discussed
some
ideas
similar
to
well
cert
manager
and
similar
to
a
controller
like
we're
talking
about
now
to
copy
that
would
potentially
copy
secrets.
B
More
yeah,
so
I
think
I
it
feels
to
me
like
the
thing
we
all
got
to
do
is
go
away
and
read
the
gap
and
have
a
think
about
it
and
comment
on
it
and
try
and
pull
pull
back
these
other
things
like
what's
g,
what's
sir
manager
doing
with
gateway
support,
you
know
and
how
and
how
you?
B
How
does
this
more
dynamic
use
case
work
in
a
world
where,
where
it's
got
to
be
the
gateway,
you
know,
and
maybe
it's
maybe
it's
as
simple
as
that,
you
know,
like
you
say
that
the
get
as
it
stands
has
has
a
suggestion
for
how
you
could
do
this.
Maybe
we
just
need
to
say
like
if
you
want
to
do
this
use
case,
it's
not
that
you
can't
do
it
with
it.
B
You
can
do
it
with
the
api,
it's
just
that
you
need
to
build
another
another
controller
on
top
to
do
the
to
do
it
safely
and
if
you're
not
willing
to
build
that
other
controller.
On
top
you,
probably
whatever
you
build,
is
probably
not
going
to
be
as
safe
as
you
think
it
is.
A
Yeah,
I
I
agree
with
all
that,
and
actually
now
that
you
mentioned
cert
manager,
specifically,
we
should
I
I
can
ping
the
cert
manager
maintainers
that
have
been
working
on
the
gateway
implementation.
I
would
it
would
be
good
to
get
their
feedback
on
this
as
well,
since
they're
very
familiar
with
this
whole
area.
A
Definitely
yeah
cool,
okay!
Well.
Thank
you.
Thanks
for
the
great
discussion
on
this
just
would
appreciate
any
any
feedback.
Any
comments
on
this
I'd
I'd
love
to
make
a
decision
on
this
this
week,
if
at
all
possible,
because
you
know
I'd
love
to
have
you
know,
I
I
recognize
we
can
start
the
cygnet
review
without
this
specific
thing-
solidified,
but
I'd
love
to
get
it
in
one
way
or
another
sometime
soon,
so
that
we
we
don't
delay
v1
alpha
2.,
so
yeah
just
interested
in
your
thoughts.
A
I
I
think
this
discussion
has
been
very
helpful
and
I'll
leave
it
there.
This
is
pull
request
749
if
anyone's
looking
for
it.
A
I
think
the
only
other
thing
I
had
on
the
agenda
was
issue
triage
or
pr
and
issue
triage.
Before
we
go
there
was
there
anything
specific
that
anyone
wanted
to
bring
up
any
issues,
anything
that
any
concerns
about
v1
alpha,
2
anything
else.
We
want
to
get
in
or
haven't
gotten
in.
A
I'll
take
silence
as
great
okay,
so
I
don't
think
there's
that
much
that
we
really
need
to
get
into
for
pr
and
issue
triage
today.
I
think
we
maybe
should
take
our
win
and
and
go
with
it.
There's
oh
wait
harry
you,
you
did
a
version
selection,
pr
already,
okay,
never
mind!
I
no
idea
this.
This
happened,
but
thanks
harry
it's,
he
looks
like
he
he's
already
dropped
off
but
glad
this
works.
A
Maybe
I
don't
have
any
any
pr's
that
I'm
aware
of
that
need
attention
right
now
there
there
is
an
interesting
discussion
on
this
one
that
could
use
more
eyes,
but
I
don't
think
it's
a
blocker
to
view
on
alpha
2.
C
A
It
is,
it
is
very
easy,
and
hopefully
we
can
catch
that
in
pr
reviews.
But
yes,
it
is
very
easy
to
make
that
mistake.
So
yeah
the
the.
A
I
I
think
it's
going
to
be
increasingly
easy,
and
I
think
this
has
to
be
part
of
our
versioning
story,
but
I
think
our
versioning
story
as
a
whole
is
going
to
change,
as
we
have
docs
for
two
versions
that
we
want
to
show.
At
the
same
time.
You
know
we
want
to
be
able
to
switch
between
them,
and
so,
as
that
changes
we'll
need
something
to
either
label
or
I
don't
know-
I
don't
know
how
to
surface
that.
But
yeah
it'd
be
good
too.
A
To
make
it
clear,
it's
not
that
changes
to
v1
alpha
docs
aren't
valid.
We
just
need
to
be
clear
that
they
usually
aren't
desired.
A
A
A
A
B
We
are
gonna
have
to
do
like
performance
profiles
anyway,
you
know,
you
know
you
say
an
ingress
controller
is
a
thing
that
has
core
support
for
gateway,
gateway,
class
and
http
route,
with
extended
support
for
tls
route,
a
you
and
a
gateway,
a
load
balancer
with
gateway
support
is
one
that
has
core
support
for
tcp
route
and
udp
udp
route
with
extended
support
for
http
route
and
tls
route,
or
something
like
that,
like
you
know,
is
going
to
be
different
classes
of
thing
that
you're
not
no
matter
what
you're
not
going
to
be
able
to
just
move
conf
like
move
routes
between
an
ingress
controller
and
a
yeah
and
a
load
balancer
seamlessly,
no
matter
what
we
do,
because
they're
different
things.
A
So
I
don't
know
just
if
you
have
any
thoughts
of
how
we
can
accomplish
this.
I
think
nick
used,
the
the
keywords
here,
I
think
a
conformance
profile
is
something
that
we're
going
to
need.
I've
been
thinking
about
that
in
the
context
of
conformance
tests
as
well,
how
we
actually
structure
those
and
how
we,
you
know,
tag
them.
You
know
it
does.
A
This
implementation
support
this
resource,
this
feature
this
etc
and
yeah,
but
but
I
think,
there's
going
to
be
some
very
common
threads
and
this
pr
represents
what
I
think
is
by
far
the
most
common
one
of
ingress
type
controller
yeah.
So
no
need
to
spend
too
long
on
this
one,
but
this
is
752.
If
you
have
any
thoughts
on
this
but
yeah,
I
think
that's
all
I
had
for
today.
If
anyone
else
wants
to
add
anything
to
the
agenda
feel
free,
but
otherwise
I
guess
we
can
have
a
minute
or
two
back.