►
From YouTube: Gateway API BI-Weekly Office Hours
Description
Service APIs BI-Weekly Office Hours
A
We
are
recording
this
is
office
hours
for
september
16..
It
sure
feels
like
we
are
in
the
home
stretch.
Here.
Let's
go
straight
into
the
v1
alpha
1
release
checklist.
I
don't
think
a
ton
has
changed
here.
Other
than
a
lot
of
review
has
happened
on
most
of
the
pr's
in
this
list.
At
this
point,
and
maybe
a
couple
more
things
have
merged
harry,
it
looks
for
like
for
tls.
A
We
also
I've
got
a
back-end
policy.
Pr,
that's
gotten
some
great
feedback.
I
updated
that
yesterday
and
I
think
there
may
be
a
little
bit
more
feedback
left
on
it.
The
biggest
thing
I
know
of
is
we
need
to
figure
out
status
status
on
the
back
end
policy
has
lots
of
different
potential
dimensions
and
yeah.
We
can
talk
about
that
when
we
get
there
yeah
the
conflict
handling
there's
a
few
pr's
here.
A
A
A
I
think
james
is
out
most
this
week,
but
he's
made
some
good
progress
on
conditions
and
status,
and
this
feels
like
a
natural
thing
to
have
closer
to
the
end
of
our
work
anyways
and
with
that
we're
really
getting
it
close
to
the
time
where
we
should
be
talking
about
documentation
and
how
we
can
make
our
docs
better.
So
I
wanted
to
spend
a
little
bit
of
time
discussing
that
today.
A
You
know
our
docs
website
is
a
good
starting
point,
but
there
are
gaping
holes
that
I'm
aware
of
so
as
an
example,
a
user
guide
would
be
great.
We
don't
have
that
right
now.
I
know
there
are
other
things
that
are
missing
here.
Are
for
for
anyone,
cookbook
yeah?
That
seems
like
a
good
one
too,
for
for
anyone
who
has
interacted
with
our
website
recently.
A
I
will
I
will
try
and
make
a
note
to
at
least
create
issues
to
track
this.
It
looks
like
you
know.
The
skeleton
is
there,
but
we
we
have
lots
of
blank
spaces
involved,
yeah
and-
and
the
other
thing
that
I
I
know
I
had
mentioned.
I
was
talking
to
someone
else
about
how
they've
done
docs
well
for
other
projects
and
the
tool
doxy
came
up.
I
don't
know
that
we
need
to
make
that
change
feeling
alpha.
A
So,
who
knows
maybe
there's
room
for
that
in
the
future
as
well,
but
for
now
between
now
and
v1,
alpha
1,
it
seems
like
these
are
the
big
holes
we
need
to
fill
and
and
feel
free
to
add
to
this
list
I'll
revisit
this
after
the
meeting
and
create
some
follow-up
issues
for
these.
Oh,
that
was
cool
as
far
as
the
api
feedback
that
we
got
mostly
from
tim,
but
also
from
dan
in
this
list.
I
think
we've
gotten
a
great
deal
of
this
covered.
A
I
know
rich
took
this
one
on
already
the
defaulting
config
map.
This
is
a
big
one
that
we
have
not
had.
Anyone
take
on
yet
rich
had
mentioned
that
he
might
have
time
to
to
work
on
this.
We
may
also
want
to
split
this
up
depending
on
how
much
time
people
have,
we
have
moved
to
meta,
v1
condition
type.
A
My
guy,
I
think,
you're
on
the
call
this
time
do
you
do
you
have
any
references
for
this
one?
This
was
one
that
I
didn't
have.
A
great
answer
to
tim
had
asked
why
we
were
using
resource
instead
of
kind
for
object,
references-
and
I
I
found
this
this
little
bit
of
a
comment
here,
but
I
I
didn't
know
if
there
was
anything
more
official
as
far
as
guidance
like
because
I'm
so
used
to
seeing
kind.
C
A
Okay,
yeah,
if
you,
if
you
can
link
that
in
this
issue,
that
would
be
awesome.
I
definitely
want
to
follow
api
conventions,
but
I
it's
always
a
little
painful
to
be
the
first
to
follow
a
new
convention
right,
because
everyone
expects
things
to
to
behave
a
certain
way
and
if
we
happen
to
be
the
first
to
do
something
differently
than
that,
we'll
be
the
odd
ones
out
for
a
while,
probably
but
yeah.
If
there's
a
pr
yeah
I'd
love
to
refer
to
that
and
see
the
rationale.
D
C
A
A
A
A
Yeah,
I
I
think
most
of
these
I've
looked
at
and
dealt
with
already
I'll,
create
issues
for
any
additional
ones.
I
find
that
we
haven't
yet
dealt
with,
but
we've
we've
dealt
with
a
large
number
of
a
surprisingly
large
number
of
these
already
okay.
So
pr
on
issue
triage,
I
know
there's
a
lot
to
get
through
and
harry.
It
looks
like
you've
got
one
open
here
for
tls
config.
What
what
do
you
feel
like
is
left
here.
B
E
B
Incorporated
that
change,
where
you
know
like,
if
you
define
tls
certificates
at
the
route
level,
then
you
could
have
conflicts
and
then
I
think
rob
you
commented
where.
Why
should
we?
Why
should
this
behavior
be
implementation
specific
and
I
think
we
can
codify
it?
So
I
think
that
that
change
I
will
I
can
make.
We
have
run
with
kong.
We
have
run
into
an
issue
where,
if
you
prioritize
the
oldest
resource-
and
maybe
the
oldest
resource
is
pointing
to
a
certificate
that
is
out
of
date,
but
a
new
has
a
valid
certificate.
B
A
C
B
A
Yeah,
I
think,
go
ahead.
I
think
all
this
resource
wins
is
probably
the
the
safest
option,
but
it
it
doesn't
hurt,
and
I
think
it's
it's
reasonable
to
to
maybe
add
some
kind
of
note
for
what
my
kaya
suggested
there
as
well.
If
the
controller
does
have
a
way
to
say
validate
a
certificate
in
this
case,
we
can
also
we
can
caveat
that
with
oldest
ballast
valid
resource
wins
so
so
maybe
maybe
the
maybe
the
what
we
say
is
oldest
resource
wins.
A
B
Okay,
so
so
yeah
I'll
take
care
of
that.
That
seems
smaller
one.
If
you
could
go
to
the
diff,
I
think
what
we
have
now.
I
should
have
put
an
example
but
short
on
time,
so
what
we
have
here
in
http
now
it
should
be
in
the
gateway
gateway
types
dot.
Go
should
be
the
first
file
here.
So
what
we
have
here
is
we
have
allow
all
and
deny
all
as
tls
route
overwrite
type,
and
then
we
have
on
line
316.
We
define
tls
overwrite
policy
right
and
it
has
one
straw.
B
One
element
right
now
called
certificate
right.
I
have
not
included
allow
by
on
a
namespace
basis,
as
you
pointed
out,
daniel
to
keep
it
smaller,
but
this
allows
for
you
know,
adding
that
in
future
and
then
we
reference
the
tls
override
policy
struct
inside
our
gateway,
tls
config
structure
right,
so
we
don't
have
a
boolean
anymore
and
we
allow,
for
you,
know,
sort
of
an
enum
in
certificate.
B
B
A
I
guess
one
thought
here:
you
have
a
default
of
denial
here.
I
think
just
the
way,
kube
builder
or
crds
work.
You
may
need
to
have
a
default
at
this
level
as
well,
so
that
if
tls
config
is
specified-
and
I
haven't
specified
anything
related
to
allow
route
override,
I
don't
think
this
default
is
going
to
apply.
B
E
B
F
F
A
B
F
B
D
A
A
F
Yeah
and
it's
something
that
actually
just
very
recently
I
was
messing
around
with
because
yeah
I
was
scratching
my
head
like
okay.
What's
the
right
combination
to
get
the
behavior
that
I
want
and
that's
that's
what
I
found
so
harry.
I
want
to
take
a
look
at
this
pr
in
general,
but
I'll
also
go
ahead
and
put
a
link
to
a
pr
for
this
other
project
that
I
followed
that
approach.
So
you
can
see
what
it
looks
like.
A
B
A
A
A
I
don't
know
it,
it
there's
not
an
obvious
solution
here
I
came
up
with
another
approach
last
night
and
yeah.
This
is
this
is
all
like
tiny
variations
on
the
same
idea,
so
it's
not
anything
dramatically
different,
but
the
idea
is
that
well,
no,
let
me
let
me
back
up
and
go
to
my
comment,
because
that
explains
it
better.
A
A
So
I
thought
about
it
more,
and
one
thing
that
is
true
is
our
back
grants
access
to
status,
resources
separately,
which
could
mean-
and
I
know
it
is-
it-
is
very
messy
to
suggest
relying
on
status
for
information
about
a
resource,
because
status
is
not
something
you
should
be
reading
from.
If
you
are
the
producer
of
that
resource
general,
especially
for
something
security
related.
A
We
could
read
from
gateway
status
to
determine
that,
and
we
could
just
document
that
you
really
should
not
grant
our
back
right
access
to
status
to
users
in
the
namespace
that
works,
but
it's
especially
troublesome,
because
anyone
who
administrates
a
namespace
would
have
access
to
this,
and
if
we're
trying
to
prohibit
people
in
certain
namespaces
from
having
access
to
gateways
of
this
class,
we've
just
allowed
any
namespace
admin
anywhere
to
bypass
this.
So
that's
not
great.
A
My
second
and
proposed
solution
here
is
to
introduce
a
provisioned
gateways
field
on
gateway
class
status,
and
this
would
track,
as
the
name
suggests,
the
gateways
that
have
been
provisioned
using
this
gateway
class.
That's
it
no,
no
additional
status,
no
anything
just
at
one
point.
This
gateway
in
this
namespace
was
provisioned
by
this
gateway
class.
A
That
gives
us
a
lot
of
actually
reasonable
security
benefits.
It
is
something
that
is
tied
to
gateway
class,
so
only
cluster
level
access
is
going
to
be
able
to
modify
it
and
it
bypassing.
This
re
requires
modifying
something
on
gateway
class,
which
is
the
same
exact
place
that
this
field
exists
to
begin
with,
so
it
feels
like
we're
tying
the
security
together
here,
even
if
they're
go
ahead.
A
G
A
Yeah
you're
right,
I
I
had.
I
had
thought
about
that.
Certainly
if
you
have
hundreds
or
thousands
of
of
gateways
in
play
here
that
that
really
could
be
an
issue
of
the
same
class,
I
I
just.
I
wasn't
sure
how
common
gateways
are
really
going
to
be.
That's
certainly
an
issue
for
something
like
routes,
but
we've
we've
already
seen.
Kubernetes
resources
are
capable
of
storing
many.
Thousands
of
you
know
string
pairs
like
this
right.
You
know
endpoints
api,
that
stores
ip
and
port.
G
G
G
A
B
B
B
A
B
C
B
I
see
what
you're
saying
I
think,
that's
that's
possible,
so
we
have
the
any
match
listener
where
you
you
can
skip
specifying
the
virtual
host
at
the
listener
level
inside
the
gateway.
So
if,
if
somebody
wants
to
do
that,
they
can
use
the
current
existing
api
to
actually
do
virtual
hosting
only
at
the
http
route
level
or
trs
route.
B
A
G
A
Okay,
well
yeah
thanks
thanks
to
everyone
for
the
feedback
on
this
specific
api
change.
It
it
certainly
is,
is
not
a
perfect
solution,
but
it
it
seems
like
the
least
bad
thing.
You
know
the
the
progression
of
this
pr
was
okay.
We
need
to.
Can
we
just
enforce
this
on
create?
Well,
maybe
we
can
use
a
web
book
and
then
now
maybe
a
web
hook
isn't
the
best
idea
for
cross
resource
validation
and
then
it
transitioned
to
well.
A
Maybe
controllers
can
maintain
their
own
state
and
figure
it
out
on
their
own,
and
this
is,
I
think,
the
next
natural
evolution
of
that
of.
Maybe
we
can
provide
state
and
gateway
class
itself
that
can
be
used
to
calculate
this.
I'm
hoping
this
might
be
the
final
evolution
here,
but
because
this
has
already
evolved
a
few
times,
I
never
say
never
on
this,
but
really
interested
in
feedback
or
thoughts
on
this.
A
A
I
there
there's
been
some
conversation
back
and
forth
and
I
think
danian
had
some
good
points
of
caution
here
that
maybe
maybe
this
change
was
too
big
to
add
at
this
point
so
damian.
Maybe
if
you
want
to
provide
your
perspective
on
this
and
your
your
hesitancy
around
a
a
change
like
this,
I
don't
know.
F
I
think
it
was
just
general,
you
know
looking
at
some
of
the
feedback
from
harry,
and
maybe
it
was
from
james
to
where
there
were
some
concerns
there,
and
so
I
was
trying
to
look
at
it
like
from
both
perspectives
and
thought
that
okay,
well,
you
know,
maybe
we
could
make
the
change
and
just
move
forward
with.
You
know
only
only
the
same
name
space,
but
you
know
I
had
had
had
a
chance
to
review
the
feedback
in
more
detail
that
harry
provided.
F
F
Okay,
I'm
pretty
sure
this
is
what
you're
talking
about,
but
I
think
it's
good
for
it
to
be
clear,
especially
for
someone
that
knew
that's
gonna
be
reading
it,
and
I
did
notice
in
some
of
the
other
sections
that
you
updated.
You
did
call
out
specific
fields,
so
I
think
that'd
be
helpful
and
then
I
just
didn't
understand.
Why
are
we
doing
a
adding
a
depth
as
part
of
this
pr?
F
A
F
A
Okay,
all
right,
thank
you.
Yeah
yeah,
just
as
as
a
recap
on
this.
Tr
really
is
just
this
kind
of
bi-directional
route.
Selection
of
routes,
routes
can
select.
Gate
can
wipe
that
no
white
list
is
not
the
right
term.
Can
I
can
choose
to
allow
gateways
and
other
namespaces
to
reference
them,
but
by
default
only
only
gateways
within
the
same
name,
space
can
reference
them
with
this
approach.
That's
maybe
the
top
go
ahead.
F
Right
where
I
mean
its
default,
behavior
is
saying:
okay
and
select,
you
know
all
namespaces,
and
so
this
field
is
instead
of
almost
selecting
it's
almost
like
filtering,
but
I'm
like
you
know.
I
could
see
how
that
goes
back
and
forth
and
maybe
that's
just
the
way.
I'm
thinking
of
it,
and
so
I
didn't
add
a
comment
about
the
name
of
the
field.
A
F
If
you
think
about
it,
just
the
defaulting
behavior
of
selectors
of
everything
selected
now
you're
actually
trying
to
filter
out
what
what
you
want.
But
to
your
point
too,
and
that's
kind
of
why
I
was
going
back
and
forth
is
like
you
know,
the
naming
conventions
tend
to
be
selector
so,
but
I
just
wanted
to
share
that.
I
don't
know
if
anyone
else
has
opinions,
but
that
was
just
one
thing
that
came
to.
A
Yeah
I'll
keep
this
in
mind.
I
think
this
may
be
a
follow-up
issue
because
we
have
namespace
selector
in
at
least
one
other
place
right
now,
and
I
and
and
it
it
it
has
a
very
similar,
oh
no
actually
just
kidding
this
is
this
is
something
that
already
existed.
This
was
just
moving
it
around
sorry
yeah.
I.
A
F
You
know
moving
it
to
gateway,
as
you
did
and
as
I
mentioned
in
my
one
comment,
and
it's
almost
like
a
two-way
handshake
between
a
route
and
a
gateway
right
and
so
between
moving
it
to
the
gateway,
the
idea
of
kind
of
having
that
two-way
handshake
and
the
defaults.
All
all
of
those
all
make
sense
to
me.
A
Cool
great
well
yeah,
I
I
had.
I
have
forgotten
how
this
one
works,
and
yes,
that
is
this
is
the
only
place
it's
used
now
that
we've
limited
where
route
namespace
is
actually
exist.
Let
me
yeah.
Let
me
let
me
think
about
this.
I
guess
this
would
also
exist
in
a
gateway
class
for
the
allowed
gateway
namespaces.
F
Well,
yeah,
if
you're
gonna,
if
you're
gonna,
readdress
this
pr
to
update
those
other
comments,
maybe
take
a
little
time.
Think
about
that
and,
like
I
said,
I'm
fine
either
way.
I
was
going
to
comment
on
it,
but
I
didn't
so
by
no
means
you
know.
Am
I
going
to
push
for
using
kind
of
a
filter
terminology,
but
if
it
makes
sense
to
you
and
you
think
it
makes
sense
to
others,
maybe
it's
something
that
we
try.
A
Yeah
I'll
have
to
I'll
spend
some
more
time.
Thinking
about
that,
that's
yeah,
sometimes
sometimes
I
get
so
caught
up,
and
you
know
in
terms
that
I'm
familiar
with
that
yeah,
that's
a
good
thought,
I'll
I'll,
at
least
when
I
do
follow
up
on
this
pr.
I'll
at
least
add
a
comment
describing
my
thoughts
here,
yeah
great
this
conflict
resolution-
pr
is
also,
I
think,
fairly
close.
Now
I
thinks
he
has
mentioned
came
up
with
this
additional
conflict
that
I
have
not
covered
yet
so
I'll.
A
A
This
is
this
is
a
you
know
for
a
while
we
were
going
through
and
we
had
a
lot
of
prs
that,
were
you
know,
right
at
the
beginning
of
their
life
cycle
and
now
we're
down
to
seven
open,
prs
and
increasingly
few
new
ones
need
to
be
made
at
least
to
get
us
to
be
one
alpha
one
so
that
that's
exciting
and
I
mean
there's
lots
of
documentation
and
some
api
changes,
but
I,
I
think
we're
we're
past
the
point
of
huge
groundbreaking
api
changes.
At
least
once
these
go
in.
I
think.
A
A
Yep,
it's
it's
good.
It's
been,
it's
been
a
long
time
coming,
but
yeah
all
right.
So
we've
covered
these
three
back-end
policy
yeah.
I
haven't
gone
back
to
this
one.
Yet
back-end
policy
also
feels
awfully
close
at
this
point.
Let
me
just
before
we
get
into
feedback,
because
there
there
has
been
some
great
feedback
throughout.
A
Let's
just
take
a
quick
refresher
as
to
what
back-end
policy
looks
like
right
now,
there
are
backend
refs
and
there
is
back-end
tls
config
and
that
that
is
the
extent
of
back-end
policy
as
it
exists.
Today
I
did
try
to
based
on
some
great
feedback.
I
did
try
to
better
document
what
a
back
end
is,
but
also
what
kind
of
configuration
may
belong
here
in
the
future.
A
A
A
A
Yeah,
right
and-
and
I
I
feel
I
I've
been
trying
to
think
about
what
might
we
add
here
in
the
future?
That
would
be
invalid,
so
you
know
right
now.
I
can
think
okay,
tls
config
might
be
invalid.
Is
that
going
to
be
invalid
for
a
specific
back
end?
Probably
it's
probably
going
to
be
valid
or
invalid,
and
that's
it
right,
like
I
can't
imagine
it
varying
on
the
back
end.
A
A
That
feels
like
a
very
real
use
case
here,
but
I'm
having
trouble
thinking
of
instances
where
this
is
going
to
be
invalid
for
a
for
one
back
end
and
not
the
other.
So
maybe,
if,
if
anyone
else,
you
know
has
thought
about
this
or
has
ideas
how?
How
do
you
think
we
should
slice
this?
How
how
what
kinds
of
things
do
you
imagine
being
problems
here
that
we
would
want
to
indicate
in
status.
C
A
G
A
G
F
A
A
F
B
B
G
F
C
A
A
A
A
F
It
could
be
helpful
to
have
maybe
just
kind
of
a
higher
level
discussion
in
a
sense
that
it's
like
and
again
this
kind
of
goes
back
to
the
tls
config
I
was
just
talking
about,
but
like
what's
the
line
in
the
sand
where
it's
like.
Okay,
this
is
configured
in
a
route
or
this
is
configured
in
a
back-end
policy.
F
A
Yeah,
that's
a
good
point,
the
distinction
I
the
way.
I
thought
that
the
line
should
be
drawn,
and
there
is,
I
don't
think
any
formal
line
drawn
at
this
point
is
that
back
end
policy
exists
to
well
one
describe
a
backend,
but
also
simplify
multiple
routes,
targeting
a
single,
a
set
of
back
ends
or
a
single
backend
or
whatever.
So,
as
as
an
example
with
tls
config,
if
you
want,
if
you
have
multiple
routes,
targeting
a
service
that
should
use
the
same
client
search
rather
not
re-specify
that
config
in
every
place.
A
A
So
maybe
another
example
of
something
that
pretty
clearly
belongs
on
route,
at
least
to
me.
No
sorry
on
backend
policy
would
be
the
health
checking.
Health
checking
is
very
much
tied
to
the
back
end
and
has
nothing
really
to
do
with
the
route.
It's
the
if
that
line
starts
to
get
a
lot
fuzzier.
When
you
start
talking
about
timeouts
and
retries.
C
Do
we
have
any
specific
use
cases
in
mind
for
retry
and
timeout?
I'm
thinking,
and
the
only
thing
I
can
come
up
with
is
things
like
websockets
or
you
know,
maybe
I
have
a
chat
server
or
something,
and
I
want
to
have
a
high
idle
timeout,
so
you
can
maintain
hold
open
in
the
tunnel,
and
that
sounds
like
it's
very
application
specific,
which
makes
me
think
kind
of
lean
towards
putting
it
on
back-end
policy,
associating
it
more
with
the
application.
F
F
F
And
no,
this
should
be.
This
is
an
issue.
If
we
scroll
down,
is
there
a
link
to
oh
yeah?
I
did
the
k
native
stuff,
that's
kind
of
what
I
was
thinking
you
scroll
up
and
I
link
to
k-nated
keep
going.
Oh
yeah.
I
see
this
one
so
yeah.
If
we
have
other
use
cases,
maybe
describe
them
okay,
but
this
was
the.
This
was
the
use
case
that
I
used
for
the
original
pr,
but
makai
I
do.
F
F
Yeah,
but
I
mean
this
is
going
to
be,
this
is
going
to
be
a
challenge
for
for
users
right,
because
every
time
you
know
a
user
goes
to
create
something
or
update
something
it's
gonna,
be
like
oh
wait.
Do
I
do
this
in
the
route
or
do
I
do
this
in
the
back
end
policy
and
you're
right,
just
see
it
being
a
challenge.
F
A
A
F
A
Great
yeah
I'll
I'll
make
a
note.
I
will
update
this
pr
and
and
add
some
more
details
here,
at
least
of
where
I
view
that
line
and
I'll
keep
on
thinking
about.
You
know
the
potential
value
and
the
potential
complexity.
This
adds
but
yeah
with
that.
I
know
we're
already
over
time,
so
I
don't
want
to
go
any
further
over
time
than
we
are
thanks
so
much
everyone.
This
has
been
incredibly
helpful
and
we'll
talk
to
tomorrow.
Maybe
thanks
rob
have
a.