►
From YouTube: Service APIs Office Hours for 20200902
Description
Service APIs Office Hours for 20200902
A
A
There
has
been
a
ton
of
progress,
usually
I'd
try
and
have
a
more
meaningful
pr
and
issue
triage
section
filled
out,
even
though
it
may
appear
that
there's
not
much
on
the
agenda.
Trust
me
there
is.
We
have
had
by
my
account
around
15
prs,
updated
in
the
past
week
that
have
not
been
merged,
yet
I
know
a
number
have
already
been
merged,
so
I
wanted
to
spend
a
lot
of
time.
Well
really
all
the
time
on
that
today,
but
I
figured
just
as
a
reminder
we
should
run
through
here.
B
A
A
A
A
Thank
you
for
all
your
work
on
that
we
got
the
route
filtering
in
request
viewing.
I
know
I've
reviewed
this
one
I
think.
Oh
I
I
know
I've
looked
at
it.
Apparently
I
didn't
leave
any
comments
yet,
okay,
more
to
cover
today
udp
route.
This
is
lgtm,
but
I
think
it
got
stuck
in
the
endless
endless
path
of
rebasing
all
the
things
I
think
it
needs
another
rebase.
A
A
B
A
A
I
have
updated
this
back
end
policy.
Pr,
I
actually
haven't
respond.
I
need
to
respond
to
the
comments
on
here.
I
I
actually
have
resolved.
All
of
these.
I
just
haven't
had
a
chance
to
like
literally
a
few
minutes
before
this
meeting
and
did
not
get
a
chance
to
respond
to
harry's
excellent
feedback
here.
A
Conflict
handling,
there's
a
a
couple
pr's
in
the
works
here.
I
should
probably
add
one
more
linked
to
this.
Hopefully
we'll
get
a
chance
to
cover
them
and
then
finally,
status
and
conditions.
I
know
james
has
made
some
great
progress
with
this
doc
and
I'm
excited
to
see
it
transition
to
a
pr
and-
or
I
guess
I
guess
it
could
also
expand
scope
a
bit
for
routes
and
gateway
gateway
classes,
but
yeah.
I
think
this
is.
A
This
is
a
great
start
with
this
doc,
so
that
that
is
everything
that
I
am
aware
of.
That
needs
to
get
in
for
a
v1
alpha
one
release.
I
we're
we're
getting
close.
I
think,
and
I'm
especially
happy
to
see
all
the
activity
and
all
the
pr's
coming
in
this
week
and
with
that
said,
I
think
we
should
probably
review
and
review
some
of
them
and
see
if
we
can
unblock
a
number
of
these
pr's.
I
know
there's
there
is
a
lot
to
get
through.
A
I
know
mine
is
the
most
recently
updated.
Let's
start
from
the
bottom,
I
think
james
work
is
going
to
update
or
replace
this
gateway
polarity
work.
I
don't
see
damian
on
this
call,
so
I'll
leave
closing
this
for
a
little
bit.
I
think
we've
already
asked
somebody
may
have
already
asked
if
we
can
close
this.
D
A
D
D
A
B
E
B
F
A
B
G
A
A
Yes,
all
right!
Well,
this
I
mean
I
I
will
make
a
note
too,
to
actually
follow
up
after
the
meeting,
but
I
I'm
not
seeing
anything
I'll
have
to
check,
for
you
know
typos
or
something,
but
the
concept
seems
really
straightforward
to
me.
I
I
don't
really
have
any
hesitation
just
take
a
closer
look
afterwards.
B
E
B
A
B
Yeah,
so
I
think
that's
the
same
comment
that
bowie
had
so
I
could
be
mistaken
here.
So
you
know
feel
free
to
correct
me,
but
I
think
the
previous
prs
was
more
about.
You
know:
here's
a
bunch
of
certificates,
sorry,
the
previous
api
was
here's,
a
bunch
of
certificates
and
the
proxy
or
the
gateway
has
to
ensure
that
the
right
certificate
is
served
for
the
right,
dls
handshake.
B
What
this
change
sort
of
goes
through
is
ensures
that
okay,
here's
my
host
name
and
please
use
this
sort
of
specific
certificate
drive
for
this
hostname.
Now
that
could
be
for
a
wildcard
domain
or
that
could
also
be
for
a
specific
domain.
I
mean
specific
host
name
right
and
this.
What
enables
you
to
do
is
you?
If
you
have
you
know,
certificates
that
are
even
incorrectly
or
badly
named,
you
could
still
use
them.
B
C
B
E
B
B
I
think
this
is
hidden
in
here,
but
tls
config
is
inside
the
listener
element
inside
http
route.
The
listener
is
configured
either,
as
you
know,
a
wildcard
match
on
the
domain,
or
is
it
it's
configured
as
the
exact
match
on
the
domain
and
the
the
matching
of
certificate
follows
the
same
thing
right.
So
if
you
specify
a
wildcard
match
for
a
host
name
in
that
listener,
all
the
wildcard
you
know
subdomains
use
the
same
tls
config,
which
is
the
same
certificate.
D
The
thing
is,
you
don't
need
to
do
so
you
don't
need
to
do
matching
on
anything
in
the
certificate,
because
you
have
the
matching
kind
specified
as
part
of
the
listener,
and
you
have
now.
You
have
one
certificate
ref,
so
you
just
have
it
right.
You
don't
need
to
now
because
of
this
change.
You
don't
need
to
have
specify
any
sort
of
matching
process
through
the
slice
of
certificate,
refs,
correct.
C
D
B
B
C
G
What
about
this
use
case?
So
I
guess
the
use
case
generally
is
like
certificate
expiration
right.
So
if
we
get
a
route
and
we've
got
a
server
certificate
tied
to
that
route,
host
name
it's
going
to
expire
and
if
we
supported
multiple
certificates
as
that
certificate
was
getting
ready
to
expire,
we
could
add
the
the
upcoming
certificate
to
use
so
that
when,
when
it
does
expire,
the
the
new
certificate
can
be
used
from
that
list
of
certificates,
as
opposed
to
just
having
a
single
certificate
tied
to
the
hosting.
B
Yeah,
so,
okay,
that's
interesting,
so
the
way
usually
most
proxies
work
is
they
can
serve
only
one
specific
certificate
at
a
time
for
a
given
sni
right.
Even
if
you
configure
two
certificates-
and
you
know-
maybe
you
can
have
the
intelligence
baked
into
the
proxy
where
it
can
choose
the
right
certificate.
B
B
C
C
Yeah
it's
an
interesting
thing.
It's
like
is
certificate
rotation,
something
that
is
the
future
of
the
distribution
of
certificates,
because,
as
harry
said
at
any
one
time,
there
can
only
be
one
so
people
just
make
a
time
period
of
validity
overlap
and
at
some
point
you're
gonna
have
to
switch.
But
it's
not
the
switching
doesn't
happen
at
the
proxy
layer.
It
actually
happens
when
you're
trying
to
distribute
it.
G
A
B
I
think
other
prs,
you
require
more
feedback,
and
this
like
asynchronous
feedback.
The
one
thing
that
we
can
discuss
rob
is
273,
which
is
probably
pretty
involved
where
we
are
talking
about
it's
a
little
down.
Thank
you,
yeah
yeah.
So,
where
we
are
discussing,
you
know
what
is
the
route?
Sorry,
what
is
an
action
versus
what
is
a
filter
and
this
pr
is
actually
pretty
small
it.
It.
F
B
And
I
think
that
is
all
it
does.
What
conversations
we
are
having
is
like
can
it
makes
that
can?
Does
it
make
sense
for
action
to
not
be
required
right,
and
there
are
definitely
some
cases
where
it
does
not
like
if
there
is
a
filter
which
you
know
performs
a
redirect
or
you
know
which
is
a
permanent
redirect,
maybe
it
does
not
make
sense,
but
then
should
that
like
redirect
be
part
of
the
action,
or
should
it
be
filter
right?
B
So
that's
that's
what
the
confusion
is
rob
has
proposed
something,
and
then
james
also
has
what
james
has
proposed
makes
a
lot
of
sense.
I
think
it
was
discussed
while
I
was
not
present,
but
if
we
sort
of
have
sort
of
a
general
agreement,
I
can
close
this
pr
out
and
you
know,
simplify
our
ghost
structs
to
update
what
james
has
proposed.
A
Yeah
for
context,
what
I'd
originally
proposed
was
that
an
action
was
kind
of
the
terminating
thing
it
was
forward
redirect
or
some
kind
of
extension,
but
I
later
on,
I
think
that
I
think
we
did
discuss.
This
is
a
james
proposal
here,
which
just
simplifies
everything:
it's
either
a
filter
or
a
forward,
and
that's
it
and-
and
I
think
this
is
really
straightforward.
A
D
D
B
C
A
The
way
I
saw
it
when
I
was
proposing
this
there
there
are
some.
You
know.
Filters
generally,
in
my
mind,
were
things
that
modify
an
action
and
actions
or
things
that
were
terminating
terminal,
in
the
sense
that
if,
if
you
had
a
filter
that
was
redirect
to
or
when
a
redirect
happens,
there's
generally
nothing
happening
after
that.
That
is
the
end.
Okay,
that's
an
oversimplification,
but
we'll
just
say
that's
the
end
and
that
you
know
this
forward
needs
to
be
optional.
A
A
E
D
I
think
we
do
need
an
extension
ref
there,
because
this
is
the.
This
is
basically
how
you
specify
the
hop
from
the
proxy
to
the
back
end,
and
that
seems
like
something
where
the
implementations
are
going
to.
It
seems
like
really
something
implementations
are
going
to
extend
like
quality
of
service
or
transport
security,
or
some
some
additional
some
additional
load
balancing
parameters.
B
B
C
B
Like
you're,
not
imagining
it
as
a
replacement,
yeah
yeah,
I
I
imagined
it
as
a
replacement,
and
it
was
like
thinking
more
like
service
level
config
and
the
problems
we're
solving
there.
That's
the
place
where
people
or
users
rather
can
modify
the
behavior
of
communication
between
the
gateway
and
the
next
hop.
A
B
A
A
G
A
A
Yeah
I
yeah
that's
my
this
is
my
only
comment.
I
think
I
think
it's
great.
I
noticed
actually,
as
I
was
doing
a
review
somewhere
else,
that
we
had
something
that
would
have
violated,
I
think,
go
format
or
at
least
go
lint
and
I
thought
well.
We
should
have
verified
catching
that
and
I
and
then
I
saw
this
pr
like
right
after
that.
Oh
okay,
thank
you.
G
A
Okay,
cool
yeah:
it
was
just
a
simple
little
thing
of
we
had
format
and
vet
and
both
make
files
and
yeah
anyway,
cool
okay
covered
this
one
downstream
tls
certificate.
I
think
harry
had
mentioned
that
this
hasn't
gotten
much
feedback,
so
this
is
more
of
a
reminder
that
we
should
provide
feedback,
and
this
I
I
didn't
even
notice
this
pr
come
in.
A
A
This
is
just
a
pure
cleanup
pr.
This
was
based
on
this
was
to
avoid
blocking
a
previous
pr.
I
think
it's
really
straightforward.
It
just
cleans
up
some
some
names
and
I
think
it
also
may
have
fixed
yet
it
does
fix.
This
would
have
been
a
go
format,
yeah
or
maybe
go
lint.
I
don't
you
go
lint
yeah.
We
don't
run
glint,
that's
why,
but
this
is
a
little
typo
and
a
couple
other
things
as
far
as
naming.
So
I
think
this
is
already
lgtm
and
straightforward
yeah.
A
A
A
I
I
thought
why
don't
we
switch
this
around
and
make
the
authorization
happen
on
routes
so
for
a
gateway
to
reference,
a
route
in
a
different
name
space?
The
route
has
to
agree
to
it.
That's
maybe
the
easiest
way
to
describe
this
within
the
same
namespace.
Everything
just
works
by
default,
everyone's
happy
hurrah,
but
across
namespaces,
both
the
gateway
and
route
have
to
agree.
So
there's
some
kind
of
bi-directional
agreement.
I
know
we'd
already
discussed
this
kind
of
bi-directional
route.
A
The
default
implementation
here
is
going
to
be
allow
same
name
space,
so
it
says
gateways
in
the
same
name.
Space
can
use
this
route
and
that's
it.
That's
default
on
same
behavior
as
we
already
have,
but
we
also
have
two
other
ways
that
we
could
do
matching
allow
list
would
say
only
gateways
that
I've
specified
in
this
separate
list
will
be
able
to
use
this
route
or
secondary,
allow
all
which
means-
and
I
I'm
really
hesitant
to
even
add
this
option,
but
it
would
mean
that
any
gateway
anywhere
can
use
this
route.
A
And
it's
fine
that
I
I
don't
know
how
I
feel
about
that.
But
I
imagine
that
there
are
some
use
cases
where
it
could
be
helpful,
so
the
actual
struct
is
really
straightforward.
You
have
allow
and
a
list
of
gateway
references,
so
the
allow
by
default
is
just
going
to
be
same,
the
same
name
space
and
that's
it
every
everything
works
as
it
does.
A
Yeah
that
that
was
the
idea
here.
I
dramatically
decreases
the
blast
radius,
one
of
the
big
problems
with
having
this
kind
of
attribute
on
the
gateway
class
level.
Is
it
dramatically
what
just
had
a
massive
glass
radius,
a
change?
There
could
invalidate
tons
of
routes
for
tons
of
gateways
it
yeah.
It
was
not
great.
A
A
G
D
A
It's
so
because
it's
bi-directional
the
way,
the
way
I
imagine
implementations
are
going
to
do
this
is
first
they
will
select
every
route
that
matches
whatever
the
gateway
route.
Selector
says
it
should
select.
So
that
includes
the
list
of
namespaces.
It
should
look
in
and
well
yeah
and
whatever
labels,
whatever
labels,
it
should
look
for
on
those
routes
and
then
from
there
when
it
gets
that
list
of
routes.
It's
going
to
look
at
this
gateways
attribute
on
each
one
and
say
no.
I
can't
use
this
one.
A
A
A
C
D
A
Yeah
yeah,
so
that
that's
true,
I
I
think
it's
a
it's
a
it's
a
reasonably
safe
compromise,
in
the
sense
that
if
you
have
a
route
owner
and
a
gateway
owner
agreeing
to
something,
it's
probably
a
fairly
safe
thing
to
do
what
the
the
issue
we
had
with
the
gateway.
One
of
the
issues
we
have
of
the
gateway
class
level
authorization
field,
the
allow
route
namespaces
is,
if
you
wanted
different
variations
of
that,
you
actually
had
to
create
an
entirely
new
gateway
class
which
felt,
like
you
know,
maybe
not
ideal.
A
A
D
So
obviously
you
had
previously,
you
know
you
from
the
gateway
class.
You
trusted.
You
specify
that
you
trust
some
namespaces
to
create
gateways,
but
you
scoped,
you
also
scoped
the
routes
so
now
you're
just
you're
delegated
now
the
gateway
class
is
delegating
more
trust
down
to
the
gateways
to
say,
okay,
we
trust
you
to
do
the
right
thing
with
with
routes
in
in
general,.
A
D
D
A
Is
it
I,
I
think
it's
going
to
address
the
critical
ones
you're
right,
that
it
won't
address
all
of
them,
but
I
think
at
least
from
my
perspective,
as
I
was
initially
working
on
the
security
model.
I
one
of
the
big
concerns
was
that
a
gateway
could
reference
any
route
if
it
could
reference
routes
across
namespaces,
it
could
reference
anything
and
there
was
really
almost
no
control
of
that
that
we
had
no
meaningful
authorization.
So
if
you
let
someone
create
a
gateway,
regardless
of
what
namespace
that
gateway
was
in,
it
could
reference.
A
I
I
admit
that
there
there
still
is
you
know
with
this
model
we
we
are
delegating
more
trust
to
admins
of
both
gateways
and
routes,
because
somebody,
you
know
the
you
know,
bowie
mentioned
fat
fingering,
the
the
new
version
of
fat
fingering
or
you
know
whatever
would
be
creating
a
route
and
letting
anything
target
it.
You
know
the
the
allow
all
kind
of
thing
that
that
is
the
new
risk
model
of
somebody
created
a
route
somewhere
and
let
any
gateway
target.
A
You
probably
shouldn't
do
that,
but
if
you
did,
that
is
that
is
a
real
risk
here,
but
the
beyond
that.
The
only
other
way
to
allow
a
gateway
to
reference
a
route
is
act
outside
outside
of
the
same
name.
Space
is
to
actually
list
that
gateway
as
a
reference,
and
that
feels
pretty
safe
and
very
clearly
intentional.
A
I
didn't
want
to
require
that
for
everything,
because
that
that
felt,
like
a
you,
know,
a
lot
of
overhead
to
always
have
to
reference
the
gateway,
especially
in
the
same
name
space,
but
I
think
for
multi-name
space
references.
We
want
it
to
be
very
clear
that
this
route
is
being
referenced
by
this
gateway
way
over
here.
A
D
D
A
A
A
It
updates
parameters
ref
there
for,
for
the
longest
time
we
had
a
problem
in
the
spec
that
said
that
inferred
that
the
local
object,
reference
that
is
parameters
ref
on
gateway
class
should
reference
anything
in
any
namespace,
but
we
didn't
actually
have
a
way
to
specify
namespace,
and
so
the
godoc
did
not
match
up
with
what
was
actually
possible,
and
so
my
initial,
my
initial
pr,
was
actually
the
complete
opposite
of
this
and
I'll
bring
that
up.
Just
for
a
bit
of
context.
A
A
But
before
I
went
any
further
with
this,
I
took
this
to
sig
network,
the
broader
community,
because,
as
you're
aware
gateway
class
is
entirely
parallel
to
the
ingress
class
resource
that
exists
in
the
ingress
api
and
we
also
intentionally
opted
not
to
add
a
namespace
reference
there
and
the
rationale
at
that
point
had
been.
We
should
be
referencing
crds.
We
want
the
crd
validation,
we
want.
You
know,
there's
very
minimal
advantage
over
referencing,
say:
namespace
scope,
config
map
over
just
annotations.
A
The
overwhelming
response
that
I
got
was
that
we
don't
want
to
do
this
for
ingress
class
and
given
that
we
didn't
want
to
do
this
for
ingress
class,
it's
very
hard
to
argue
that
we
should
do
it
here.
It
seems
like
if
we
want
to
do
it
here.
We
need
to
convince
the
broader
sig
network
community
that
it
should
be
done
elsewhere.
A
A
A
A
Okay,
definitely
leave
some
comments
on
this
pr
it.
It
does
seem
like
a
relatively
straightforward
pr.
It
just
happens
to
have
a
lot
of
history
behind
it
that
this
pr
on
its
own
may
not
show.
So
I
wanted
to
provide
a
little
bit
more
background.
I
have
linked
to
it
further
down
here,
but
yeah
I
I
will
leave.
I
will
leave
this
this
pr,
as
is,
if
anyone
has
more
thoughts,
feel
free
to
to
add
a
comment.
There.
A
Okay,
I
see
our
pull
request.
Number
is
going
down.
We
must
be
getting
some
prs
in
oh
yeah,
the
ones
that
okay
cool,
the
other
ones,
I
think,
are
all
actually
fairly
straightforward.
I
think
this
is
worth
discussing
as
a
broader
group.
It
feels
weird
to
me,
but
I
was
generally
fine
with
it
at
the
end.
A
A
A
A
A
We
we
are
quickly
running
into
this.
I
I
don't
want
to
call
it
a
problem,
but
it
is
a
an
issue
that
will
become
more
common
as
we
introduce
more
route
types.
It
means
you
know,
for
the
sake
of
consistency,
we'll
be
changing
the
same
field
multiple
times
across
multiple
routes,
not
the
end
of
the
world,
but
it
is
just
something
we'll
be
doing
more
of
all
right.
I
think.
Let
me
double
check
here,
damian's
pr.
A
We
briefly
discussed
to
install
the
make
target
yeah,
let's
yeah,
let's,
let's
cover
my
my
back
in
policy
thing
here,
real
quick,
so
I
got
some
great
feedback
from
harry
on
this
one.
We've
already
talked
about
back-end
policy
and
I've
dramatically
simplified
it.
It
is
just
tls,
config
harry
pointed
out
that
it
made
no
sense
to
use
the
same
tls
config
type
here,
because
we're
talking
about
basically
client.
A
A
A
Well,
okay,
so
the
argument
is
like
say,
nginx
or
or
something
like
that
it
provides.
I
think
they
call
it
a
trusted
certificate
or
something
like
that.
But
an
envoy
has
a
similar
concept
and
the
idea
is
that,
if
you're
using
a
self-signed
cert
or
something
like
that,
you
can
provide
your
kind
of
custom
ca
here
for
validation.
D
D
C
D
D
D
So
I
think
there's
kind
of
consensus
across
the
ingress
community
that,
in
a
secret
ca.crt,
can
be
used
to
store
a
a
ca
bundle,
but
there's
not
consensus
around
which
certificate
that
ca
bundle
corresponds
to
whether
it's
the
ca
bundle
of
the
peer
you're
validating
or
this
or
the
ca
bundle
of
the
certificate.
That's
in
the
same
secret.
A
D
Yeah,
I
guess
this
ties
into.
I
know
micah
described
how
openshift
deals
with
tla
secrets,
specifically
too,
so
you
can
kind
of
have
least
privileged
ingressors
that
don't
need
to
be
able
to
have
access
to
all
secrets.
But
I
think
that
feels
like
that.
Specifying
that
feels
like
a
larger
post,
be
one
alpha.
One
task.