►
From YouTube: Service APIs Office Hours for 20200819
Description
Service APIs Office Hours for 20200819
A
We
are
recording
welcome
to
service
apis
office
hours
for
august.
19.
looks
like
we've
got
lots
to
go
through,
but
because
we
are
still
so
close
to
a
v1
alpha
one.
I
want
to
just
take
a
quick
reminder
at
where
we
are
and
how
close
we
are
tls
config,
I
think
harry
you're,
making
some
great
progress
there
more
to
talk
about
on
our
agenda
advanced
routing
again.
A
I
think
I
think
we're
getting
pretty
close
on
that
filtering
pr.
I
service
level
config.
I
have
some
updates
today
on
this
front
and
I'd
really
love
some
feedback
here.
Conflict
handling,
I
think,
we're
in
a
reasonably
good
place.
There
is
at
least
one
pr.
We
can
talk
about
for
more
detail
today
and
I
think
this
status
and
conditions
will
be
closer
to
the
end
of
this
release
cycle,
but
I
think
we're
at
an
all
right
place
again.
A
With
that
said,
harry
had
the
great
idea
to
go
back
through
and
look
at
some
old
pr's.
That
really
could
use
some
triaging
and,
I
think,
you've
sorted
by
the
least
recently
updated
pr
which
is
great,
which
happens
to
belong
to
me.
This
was,
as
we
all
know,
ended
up
being
a
very
controversial
one.
At
the
time
it
was
a
pr
before
api.
A
The
discussion
probably
should
have
continued
on
at
an
issue
for
a
bit
longer.
At
the
end,
I
think
we
reached
consensus
here
on
exactly
what
gateway
class
meant.
My
question
on
this
pr
is
not
so
much
the
decision.
I
think
we're
all
on
board
with
the
decision
here.
My
question
is:
if
we
think
we
want
a
design
decisions.
Dock
like
this
is
it.
Is
it
worth
documenting
these
kinds
of
decisions
in
a
separate
page
on
our
docs
website,
or
is
there
a
better
way
to
do
this?
B
B
A
D
Well,
while
we're
waiting
for
bowie,
I
guess
the
question
that
I'd
have
for
the
community
is:
how
are
other
design
decisions
recorded
or
are
designed
decisions
recorded
for
other
projects?
Yeah?
Normally,
you
see
design
decisions,
as
you
know,
a
design
dock
that
gets
merged
into
the
repo
and
that
becomes
like
okay,
the
project
decided
I'm
doing.
A
D
B
E
B
D
And
issues
that
are
tagged
right,
what
is
like
kind
enhancement
or
something
like
that
I
mean:
does
it?
Is
there
some
way
that
we
can
leverage
that
to
be
able
to
say?
Okay,
we
cut
b1
alpha
one,
you
know
for
for
all
the
enhancements,
here's
you
know,
here's
a
link
and
it
links
to
all
those
pr's
or
all
the
issues
that
have
kind.
D
D
A
I
think
part
of
my
motivation
for
this
back
in
the
day,
and
this
feels
like
forever
ago
now
was
that
it
was.
It
was
hard
for
a
newcomer
to
the
project
to
understand
why
resources
were
the
way
they
were,
and
I'm
thinking
that
maybe
this
could
be
accomplished
just
with
a
this
specific
example
could
be
accomplished
just
with
a
much
shorter
note
on
gateway
class
itself
in
the
reference
docs,
or
not
reference
docs
and
somewhere
in
docs,
that
talks
about
gateway
class,
but
it
doesn't
need
a
whole
section
to
its
own.
A
D
B
A
A
H
A
D
G
D
G
It
keeps
getting
pushed
out,
I'm
I'm
hoping
to
do
it
today
and
tomorrow.
I
think
the
way
that
I'm
looking
at,
I
think.
What's
probably,
I
might
end
up
just
suggesting
that
we
leave
things
as
it
is
and
not
reverse
the
polarity,
because
the
upstream
api
machinery
or
cigar
discussion
seems
to
have
died
down.
G
Yeah
they're,
all
all
the
conditions
we
have
are
error
conditions.
So
generally,
if
you
see
an
error,
it's
it's
going
to
be
a
problem.
It's
going
to
be
a
problem,
so
that's
why
I
need
to.
I
want
to
go
back
and
refresh
my
memory
on
your
proposal
and
just
so
because
it's
been
a
while.
I
just
want
to
make
sure
that
I
I'm
trying
to
understand
what
you
mean
and
all
the
and
that
we're
capturing
everything.
D
D
I
believe
it
goes
beyond
just
the
scope
of
this
pr
right.
Is
it
not
only
how
we
want
to
reflect
the
polarity
of
the
status
conditions,
but
is
it
also
kind
of
going
through
the
different
resources
and
making
sure
that
we
at
least
have
like
a
reasonable
level
of
status
conditions
or
maybe
yeah?
Let's
throw
that
to
the
side?
I
I
don't
mean
to.
I
know
you
want
to
do
this
triage,
so
so
anyways.
H
D
A
A
H
A
B
A
D
A
E
A
Harry
james,
whoever
else,
if,
if
this
is
going
to
be
an
undue
burden
on
your
implementation,
to
try
and
keep
all
these
routes
up
to
date
with
which
which
gateway
is
currently
processing
them,
it
seems
like
it
would
be
great
for
user
experience,
I'm
just
not
sure
how
painful
it
would
be
to
actually
implement
and
and
to
clarify.
This
is
the
idea
of
setting
it
on
a
route
which
gateway
or
gateways
are
currently
processing
that
route
or
connected
to
that.
A
A
A
D
A
A
A
I
G
G
A
Yeah
I
I
know
we
have
no
plans
on
having
a
core
implementation,
but
I
I
know
the
the
one
thing
that
the
one
area
this
came
up
is
one
of
my
prs,
where
it
could
potentially
be
helpful
to
have
a
shared
controller
code
logic,
something
like
that.
That
was
responsible
for
marking
gateways
that
had
that
had
tried
to
use
a
gateway
class
in
an
invalid
namespace
in
a
namespace
that
was
not
allowed,
and
so
it
may
be
in
the
same
vein
as
a
web
hook.
A
G
A
A
B
G
I
A
A
Cool
okay,
we'll
move
on
quickly
here
to
a
service
level,
config
follow-up,
and
this
one
is
I
I
had
tried
to
add
some
some
basic
proposal
here
as
a
very
rough
starting
point.
I
I
will
so
there
were
a
bunch
of
proposals
below.
I
think
they
were
all
valuable,
but
I
wanted
to
just
throw
one
on
top,
so
we
could
focus
on
one
and
critique
it,
and
and
and
really
were
that
there
are
a
few
different
components
here
to
this
proposal,
summary
whatever,
whatever
we
want
to
call
it.
A
One
of
the
big
questions
we
want
to
answer
is
what
which
of
these
things
belong
in
v1,
alpha,
1
and
which
of
them
belong
later.
You
know,
there's
a
lot
of
different
things
we
could
potentially
cover
in
this
kind
of
resource
or
resources
have
have.
I
suggested
the
right
ones
for
v1
alpha
1
versus
later.
I
don't.
I
don't
think
it's
practical
to
try
and
get
every
bit
of
this
into
v1
alpha
1,
but
just
you
know
what
makes
sense
here.
A
A
It
seems
like
it
may
be
helpful
to
not
just
be
able
to
reference
a
service,
but
maybe
a
service
import,
and
maybe
you
know
our
routes
can
reference
things
that
aren't
services.
So
maybe
there
is
some
other
kind
of
resource
we
haven't
thought
of,
yet
that
we
would.
We
would
want
a
back-end
policy
to
like
this
to
apply
to.
A
A
A
But
let's,
let's
say
we
call
this
service
back-end
policy.
It
can
target
a
service,
and
so
this
is.
This
is
not
something
like
I
loved.
Initially,
I
really
liked
any
of
the
other
alternatives
that
could
ensure
we
wouldn't
have
any
conflicts.
You'd
be
kind
of
one-to-one
mapping
where
you
know
that
whatever
this
policy
is
is
going
to
be
unique
to
a
service.
A
You
know
the
same
that
the
same
tls
config
from
elsewhere
in
our
service
apis
types,
and
I
don't-
I
don't-
think
the
multiple
certificate
references
really
make
sense
here
I
was
just
thinking
it
could
be
helpful
to
use
the
same
consistent,
tls
config
type,
but
maybe
I
need
to
rethink
this
entirely
as
far
as
how
we
would
connect
from
gateway
to
backend.
But
this
is
this
is
what
this
tls
config
is
dictating
the
connection
from
gateway
to
backend.
A
A
A
B
I
think
for
sure
tls
needs
to
be
in
there,
the
other
ones,
probably
even
if
one
of
them
make
it.
It's
a
good
thing
to
demonstrate
to
people
how
to
use
it.
If
it's
easy
like,
if
there's
no,
not
a
lot
of
discussion,
you
know
you
can
have
all
of
them.
The
other
one
I
was
thinking
of,
was
health
check
and
that
one
requires
just
probably
a
bit
more
discussion
as
to
its
meaning
for
some
infrastructures.
A
A
A
Well,
cool,
I
I
am
taking
silence
as
indicating
that
everything
is
perfect,
which
I
like
and
then
the
the
next
thing
that
I
included
here
is
more
just
about
the
spec
itself.
I
I
think
timeouts
to
me
seems
relatively
straightforward.
I
know
there
had
been
some
mentions
of
differentiating
between
read,
write
time
out,
but
it
seems
like
not
many
implementations
support
that
differentiation.
A
A
A
G
D
G
A
My
hope
is
that,
with
something
like
this
back-end
policy,
this
is
more
of
an
advanced
configuration
and
not
so,
and
not
something
like
that.
The
more
simple
use
cases
will
require.
So
you
know
our
simple
use
case
still
really
is
gateway
and
route,
and
this
is
more
of
a
additional
configuration.
If
you
wanted.
A
A
Policy
config
type
things
like
I
imagine
we're
going
to
be
able
to
cover
the
vast
majority
of
shared
common
config
at
this
level,
but
there
may
be
additional
service
level
config
that
needs
to
be
tied
to
a
service
or
similar
resource,
and
we
could
at
least
recommend
using
this
same
kind
of
pattern
if
other
implementations
want
to
add
more
more
configuration
now
that
only
that
only
increases
the
crd
explosion.
Admittedly,.
A
A
A
A
A
Cool,
I
will
follow
up
with
this
one
cool,
okay.
So
well,
let
me
let
me
skip
down
to
the
last
one
real
quick,
just
as
a
heads
up,
we
have
new
maintainers
joining
and
the
terms
in
terms
of
harry
and
james
just
need
to
get
an
approval
from.
I
think
a
sig
lead
so
casey
in
this
case,
but
yeah
thanks
thanks
to
james
and
harry,
for
signing
up
and
being
part
of
this
and
yeah
anyways.
A
I
don't
think
a
lot
of
them
that
I
would
like
to
talk
about,
are
actually
made
by
harry,
so
I'll
leave
those
for
tomorrow,
but
one
that
I
wanted
to
one
that
I'm
quite
familiar
with,
and
I
think
would
be
good
to
have
a
in-person
discussion
around
would
be
the
auth
fields,
which
I
think
is
the
one.
I
closed
cool,
that's.
That
was
very
cool
of
me.
A
A
A
You
know
you,
may
you
know
that
there
are
significantly
large
potential
forms
that
ways
this
can
break
and
it
would
be
harder
to
recover
from
whereas
routes
changing
is
pretty
quick
to
recover
from,
I
think,
for
most
implementations,
so
that
was
that
was
the
motivation
for
moving
this
from
something
that
changes
immediately
and
retroactively
to
something
that
only
applies
to
new
gateways
as
they're
created.
So
this
becomes
more
of
a
validation
concept
here
and
harry
and
james
have
both
had
a
great
feedback
here
and
I'll
jump
down
to
the
bottom.
A
A
I
should
should
process
it,
and
the
last
one
is
where
we've
had
all
our
additional
discussion
and
that's
if
a
condition
on
gateway
is
still
relevant
here,
you
know,
is:
is
there
any
value
in
a
in
adding
a
condition
on
a
gateway
to
indicate
that
this
is
this
gateway
is
not
in
a
allowed
namespace?
It's
it's
not
where
it
should
be.
My
my
concern
with
any
kind
of
condition
like.
C
B
A
A
The
controller
has
no
way
of
setting
that
condition,
so
that
is
not
relevant
the
other,
and
this
is
where
that
discussion
came
up.
We
could
have
some
kind
of
shared
controller
implementation
that
was
responsible
for
setting
status
fields
such
as
this.
The
problem
is,
I
can't
think
of
any
other
use
case
other
than
this
one
condition,
and
this
condition
is
relatively
useless.
I
think
because
it
says
the
forbidden
namespace
for
class
is
sure
you
you
shouldn't
be
here,
but
at
the
same
time
everything
is
still
working.
A
It's
saying
this
gateway
shouldn't
be
in
this
name
space,
but
don't
worry
because
everything
will
still
work
the
way
it
it
already
is.
So
at
that
point
it
seems
like
the
condition,
isn't
really
providing
any
value
like
you
shouldn't
do
this,
but
don't
you
know
it's
still,
it's
still
all
working.
So
what
I
think
might
be
a
more
valuable
approach
here
is
to
consider
adding
a
new
condition
that
indicates
which
controller
is
actually
implementing
the
gateway
and,
if
that
remains
nil,
if
no
controller
ever
claims
a
gateway.
A
Space,
okay!
Well,
if,
if
anyone
has
has
time
to
be
part
of
this
discussion,
that
would
be
awesome,
I
will
unclose
this
pr
and
close
the
correct
one
after
this
meeting.
I
think
that's
about
all
we
have
to
cover
today
every
other
open
pr
that
that
I
would
cover
is
oh
actually
james.
We
haven't,
we
haven't
gone
through
this
one.
Yet
are
you?
Are
you
blocked
on
anything
from
as
far
as
review
on
this.
G
E
A
G
E
A
G
Okay,
yeah,
it's
easy!
Okay,
I
just
got
lazy.
One
issue
that
I
noticed
with
this
with
the
docs
is
the
documentation.
The
api.
Docs
generator
doesn't
deal
with
any
sort
of
pre-formatting,
so
things
that
work
things
that
look
alright
in
the
godoc
actually
get
munged.
And
if
you
look
at
the
api
docs,
where
we
have
yaml
examples
and
everything
they're
really
really
bad,
what
the
doc
generator
does.
Is
it
strips
all
the
left
most
white
space,
even
in
pre-former
pre-formatted
areas?
Oh
no,
so
I
don't
have
a
good
solution
to
that.