►
From YouTube: Gateway API Bi-Weekly Office Hours for 20201028
Description
Service APIs Bi-Weekly Office Hours for 20201028
A
All
right,
hey
everyone,
it
is
october
28th,
and
this
is
service
api's
office
hours.
As
always,
we
are
recording
and
we've
got
lots
and
lots
to
get
to
it.
It's
been
a
productive
week,
it
seems
and
right
off
the
bat
damian
has
a
great
question
here
of
you
know
my
my
interpretation
is,
if
you
know,
as
we're
looking
through
v,
one
alpha
one
milestone
if
there's
things
that
we
can
potentially
prioritize
and
and
maybe
more
specifically,
if
we
can
set
a
firm
release
date
and
stick
to
it.
A
So
my
interpretation
interpretation
of
this
question
dating
you
feel
free
to
correct
me,
is
that
we
should
have
a
a
firm
release
date
whatever.
That
is
that
that
we
agreed
to
and
then
we
would
have
a
very
small
number
of
issues
that
could
block
that
release
if
they
were
not
resolved,
but
otherwise
we
would
release
on
that
date,
or
I
I
don't
know,
is
that
kind
of
what
you
were
thinking.
A
B
My
thinking
is
is
like
you
know:
if
we
need
to
build
in
a
little
buffer
but
yeah,
I
think
it's.
I
think
it's
really
important
that
we
set
a
date
and
we
commit
to
that
date
as
part
of
that
yeah.
You
know,
maybe
it
makes
sense
to
go
through
what
we
have
tagged
for
v1
alpha
one
assign
some
priorities
to
things,
just
to
make
sure
that
hey
we're
going
to
try
to
get
everything
we
can
in,
but
let's
at
least
make
sure
we're
focusing
on
the
priorities
for
b1
alpha.
One.
A
A
I'd
say
that
we
have
a
lot
of
these
covered
thanks
to
harry's
work
on
both
getting
started
and
tls,
but
we
could
use
more
yeah.
I
don't
know
I'm
just
I'm
just
trying
to
process
this
through,
as
as
I'm
you
know,
looking
through
these
issues
right
now,
it
seems
like
we
have
a
number
of
open
issues
that
feel
too
broad.
This
one
is
nearly
nearly
done
just
I
think
james.
You
just
need
to
oh
james,
isn't
on
this
call.
C
A
A
I
have
I
have
started
on
it,
but
I
would
be
open
to
you
know
making
this
less
of
a
blocker
on
v1
alpha
when
actually
getting
released,
just
as
long
as
there's,
because,
right
now
what
the
documentation
says
is
you
know
we
don't
support
this
in
the
api.
You
may
want
to
use
your
policy
agent
of
choice
to
implement
this
instead,
but
we
haven't
provided
any
examples
of
how
they
might
do
that
it
would
be
nice
to
have,
but
I
don't
think
it's
required.
B
There's
a
lot
of
noise
here
right,
16,
whatever
issues,
but
we've
got
whatever
number
that's
priority
high
and
let's
look
at
those
and
really
kind
of
I'll
kind
of
go
through
them
with
a
fine-tooth
comb
to
say,
okay,
which
of
these
high
priorities
are
really
you
know,
a
kind
of
a
release.
Blocker,
I
don't
know
that's.
That
was
my
train
of
thought.
I
don't
know
what
everyone
else
thinks.
A
A
A
B
A
A
C
A
A
Yeah
so
this
this
came
from
the
the
pre-alpha
review
and
we
do
not
have
a
way
right
now
to
just
match
everything
or
we.
We
have
not
made
it
clear,
especially
on
tcp
route
and
udp
route
like
if
there
are
no
matches
what
happens,
and
so
the
easiest
way
to
do
this
is
to
specify
that
if
no
matches
are
specified,
all
requests
should
match.
A
C
Yeah,
I
think
we
should.
We
should
add
this
and
we
win
alphabet
so
that
yeah
yeah.
I
think
let's
do
this,
so
users
can
at
least
you
know
properly.
Actually
we
can
have
a
concrete
example
of
how
to
use
this
crd
right
like
right
now
in
the
current
form,
I
don't
think
you
can
even
have
like
a
good
concrete
example.
A
A
C
A
B
E
E
B
B
Really
quick
too,
while
we're
here,
let's
look
at
these
and
I
wonder,
and
maybe
like
do
we
need
to
have
all
these
boxes
checked
to
say
we're.
You
know
we're
unblocked
right.
So
maybe
let's
just
talk,
really
quick
and
maybe
put
an
asterisk
next
to
the
ones
that
we
feel
like
are
must
haves
or
any
of
them
must
haves.
A
B
B
A
B
B
B
I'm
sorry
rob.
I
went
through
kind
of
the
list
just
the
other
week
and
I
I
found
myself
like
okay,
should
I
work
on
this
or
not
because,
like
there's
an
assignee
on
there,
and-
and
I
guess
I
don't
know-
if
maybe
I'm
missing
something,
but
I
tend
to
if
someone's
assigned
to
something
it's
like
okay,
I'm
just
kind
of
reluctant
to
work
on
it.
A
E
C
B
And
since
harry
and
bowie
are
on
the
call
like,
if
you
guys
are
gonna
work
on
this,
do
do
me
a
favor
and
just
maybe
make
a
note
to
say:
okay,
here's
the
checkbox,
I'm
gonna
work
on.
So
if
someone
does
come
to
this
issue,
maybe
even
myself
and
it's
like
oh
okay,
I'll
work
on
the
fourth
check
box,
since
you
guys
are
working
on.
You
know
one
and
two.
A
A
C
I
think
we
can
it's
an
alpha.
I
think
we
can
you
leave
it
out,
like,
like
people
generally
understand
what
is
the
I
don't
know.
This
is
an
implicit
understanding
where
you
know
how
path
and
headers
are
matched
their
priority,
but
I
would
say
important
soon
here:
okay,
that
works,
but
I
mean
if
you
ship,
v1
alpha
one
without
this
item.
I
think
that's
fine
yeah.
A
A
Yeah
yeah,
I
I
spent
some
time
looking
at
this.
I
know
I
volunteered
myself
for
this.
I
think
there's
a
bit
more.
That
can
be
said
based
on
this
discussion,
just
to
kind
of
answer
some
of
the
questions
that
came
up
here,
but
I
don't
think
it's
critical
for
our
documentation
like
if
you
really
want
to
dig
you
can
find
it,
but
it
it's
it's
hard
to
fit
in.
I
spent
a
little
bit
of
time
looking
at
how
I
would
add
this
and.
A
C
A
B
A
Yeah
yeah,
that's
yeah!
Absolutely
let
me
first
run
through.
I
wanted
to
get
through
a
couple
other
things.
First,
do
we
want
to
release?
Well,
the
the
release
candidate
discussion
will
be
a
good
way.
To
conclude
this,
I
think
once
we
have
an
idea
of
where
the
prs
are
headed,
I
wanted
to
just
briefly
run
through
this.
A
This
is
not
v1
alpha
one,
so
I
don't
want
to
waste
much
time
on
it.
I
just
want
to
raise
your
attention.
We
we
had
some
interesting
names
come
in.
That's
all
I'll
say
here.
I
don't.
I
think
I
want
to
leave
this
and
let
it
run
for
another
week
or
so
see.
If
we
get
any
more
interesting
names,
I
don't
I
I
don't
want
well,
no
that
this
this
name
definitely
came
from
tim
kind
of
like
vortex.
A
A
C
A
That's
exactly
it
yeah,
I
don't
know
you
know
we'll
have
some
more
time
to
talk
about
if,
if
any
of
these
actually
seem
better
than
gateway
and
and
rule
out
any
that,
definitely
we
don't
want
to
go
forward
with,
but
yeah.
I
don't
want
to
spend
too
much
time
here,
just
a
reminder
that
it
exists
and
if
you
have
any
ideas
or
want
to
share
it
with
anyone
who
might
by
all
means.
A
And
then
the
next
one
I
just
so.
This
is
something
that
we
said
was
long
term
or
soon,
but
not
something
that
is
blocking
v1l
following
release.
So
I
also
don't
want
to
spend
much
time
on
this,
but
I
just
wanted
to
let
you
know
that
this
seems
to
work
and
I've
started
some
kind
of
discussion.
I
guess
with
the
opa
maintainers
to
see
if
this
kind
of
thing
fits
in
their
gateway,
gatekeeper,
library
and
oh,
I
need
to
update
the
github
issue
to
for
service
apis
naming.
A
Thank
you,
bowie
yeah,
okay,
so
I
again,
I
don't
want
to
spend
too
much
time
here,
because
we
have
a
lot
of
prs
that
are
very
worthwhile,
but
if
you're
interested
in
rego
or
very
likely
better
at
it
than
me,
this
is
my
first
time
writing
any
reggoe
and
it's
rather
messy
definitely
feel
free
to
give
some
feedback
or
yeah
try
it
out
and
yeah.
Let's
with
that,
let's
run
back
to
the
v1
alpha
1
milestone
and
specifically
pick
prs
that
are
associated
with
this.
A
A
A
Cool
okay,
yes!
Well,
if
we
had
had
this
earlier,
we
would
have
caught
these.
This
is
definitely
something
that
that
I
let
through
so
I'll
fix
I'll
fix
the
examples
in
this
pr,
but
for
anyone
who,
what
who
missed
it
there
is
well,
there
soon
will
be
a
fix
to
this.
That
verifies
examples
with
kind
okay.
What
else
should
I
go
through
future
proofing?
Protocol
type?
I
think
this
one
is
super
close
as
well.
A
A
Yeah
yeah,
so
I
I
just
wanted
somebody
else
to
add
the
final
lgtm
on
this.
It's
it
got
to
a
really
tiny
point.
It's
really
just
here
are
our
core
protocols.
You
can
specify
any
one
of
these
and,
if
you
don't
use
them,
I
just
use
a
domain
prefix
on
any
protocol.
You
you
use
beyond
that.
This
is
similar
to
app
protocol,
except
it
does
not
limit
or
suggest
that
you
know
a
a
large
list
of
you
know.
A
B
B
Yeah
and
so
for
both
the
ip
address
type
or
the
named
address
type.
You
know
if
you
specify
either
or-
and
it's
not
supported
right-
I
mean
you
could
essentially
do
the
same
for
both
right.
I
specify
some
address
that
the
controller
says
no.
This
is
not
like
an
address
range.
I
support,
for
example
or
or
the
I
think
the
core
of
the
issue
is,
with
the
named
address
type
that
I
updated
the
godox.
B
A
B
D
D
A
So
I
don't
forget
it,
I
would
assign
myself
or
cc
myself,
but
I'm
already
there
so
yeah
cool
and
the
I'm
just
running
through
these.
This
is
done.
Protocol
type
we've
gone
through
this
harry
has
added
a
great
pr
around
documenting
the
release
process.
I
think
this
is
worth
talking
through
a
little
bit
this.
This
came
from
an
issue
where
john
howard
had
pointed
out
that
using
non-semver
tags
for
releases
really
does
not
work
well
with
gomod.
A
So
if
you're
trying
to
import
this
with
our
initial
prerelease
tag,
it
does
not
play
nicely.
So
the
idea
is
going
forward.
We
use
v0.1.0,
at
least
for
the
v1
alpha
1
release
and
continue
through
there
and
harry
you've
documented
a
few
different
things
here,
including
basically
new
minor
release
versions
for
new
alpha
or
beta
apis,
and
then,
when
we
go
ga
we
go
to
v1.o,
which
to
me
all
makes
sense.
You've.
Also
maybe
the
most
controversial
thing
in
here.
A
A
A
C
Right
so
this
is
while
using
if
you
want
to
change
like
specify
the
protocol,
the
gateway
in
the
upstream
service.
What
protocol
the
gateway
should
you
know
initiate
the
connection
on?
There
is
no
way
in
the
api
to
define
that
we
can
use
the
app
protocol
field,
but
that's
only
available
in
1.18
and
higher.
C
So
this
is
sort
of
a
stop
stopgap
solution
where
we
introduce
a
you
know,
an
annotation
on
the
service
resource,
which
would
be
the
networking
dot
x,
dash,
keras,
dot,
io,
slash
app
protocol,
and
then
you
can
define
the
protocol
to
use
for
each
specific
board
right.
So
so
the
idea
here
is
to
give
a
solution
that
works
for
116
117,
and
you
know
by
the
time
this
api
actually
gets
some
good
adoption.
C
My
my
current
thought
is:
maybe
1.18
will
be
already
you
know,
mainstream
and
that
most
of
our
users
will
come
from
there
right,
and
so
we
can
release
this
even
alpha
one
with
this
annotation
in
there.
But
you
know
we
discourage
the
use
of
the
annotation
in
newer
versions
of
cube
so
yeah
that
that's
what
this
pr
does.
I
think
there's
been
some
good
feedback
and
from
rob,
but
the
you
know.
Maybe
this
annotation
could
be
a
field
on
backend
policy,
or
maybe
this
annotation
should
actually
be
in
the
backend
policy
resource.
C
A
A
I
think
an
annotation
is
probably
a
reasonable
thing
to
put
directly
on
the
back
end
itself
in
this
case
the
service,
and
that
same
pattern
could,
in
the
future,
apply
to
other
resources
that
were
referenced.
That
may
not
be
service
if
they
need
some
concept
like
app
protocol,
because
yeah
annotation
can
be
anywhere.
C
Then
it's
probably
a
good
sign
that
maybe
you
know
we
should
include
that
inside
somewhere
in
our
api
right
and
like
like
that's
just
a
signal
and
then
we
can
sit
down
and
think
you
know
maybe
back
in
policy.
Maybe
there
could
be
multiple
options
at
that
point.
So
so
that's
like
that's
why
we
we
shouldn't
encourage
if
we
encourage
and
using
this
annotation
a
lot.
I
think
it's
going
to
the
similar
route
of
you
know
ingress
class
annotation
right
so,
but
yeah
any
any
of
structured
information
inside
annotation
is
complicated.
As
you
know,.
A
A
C
A
C
A
A
C
B
B
Yeah,
if
you
go
to
the
top
descriptions
empty,
no
link
to
a
an
issue
or
anything
like
that
harry.
Do
you
mind,
maybe
just
giving
a
little
background
there
to
make
it
easier
for
someone
to
jump
in
and
kind
of
be
brought
up
to
speed,
and
if
we
don't
have
an
issue
defined
for
this,
then
yeah
something's,
missing
yeah.
A
A
I
think
we'd
we've
discussed
this
briefly
in
the
past.
The
idea
that
both
well
okay-
let
me
let
me
give
the
background
right
now
of
these
two
things
just
don't
match
on
gateway,
we
support
domain
exact
any
as
hostname
match
types
and
on
http
route.
We
had
this
kind
of
wild
card
matching
and
based
on
that
and
based
on
another
issue
where
that
was
very
related,
where
we
had,
you
know
no
good
default
here
of
a
match
type
of
when
hostname
isn't
even
used
it.
A
I
think
it
would
get
more
confusing
to
try
and
bring
this
syntax
down
to
http
route,
the
enum
based
syntax,
and
I
also
struggled
to
find
a
way
that
we
would
expand
the
types
of
matching.
So
we
had
domain
any
and
exact
and
all
of
those
felt
like
they
could
be
expressed
with
this
kind
of
wild
card
matching,
and
I
couldn't
think
of
any
more
advanced
use
cases
than
that.
But
I
know
I
know
that's
a
dangerous
thing
to
say.
A
So
yeah,
I
think
I
think
this
approach
is
reasonably
straightforward,
but
it
does
represent
a
relatively
significant
change
here.
So
if
anyone
has
time
to
take
a
look,
I
know
I've
gotten
some
great
feedback
from
james
and
harry
on
this
one.
I
think
all
the
feedback
that
I've
gotten
so
far
has
been
resolved.
A
So
if
anyone
can
take
one
more
look,
maybe
while
we
have
this
pr
open
does
this?
Does
this
approach
feel
wrong
like
the
wrong
direction
to
take
to
anyone?
Just
you
know
you
don't
have
to
comment
on
the
entirety
of
the
pr
and
its
accuracy
or
whatever,
but
just
this
general
direction
does
it
does
it
seem.
A
A
That's
that's
what
happens
when
you
have
a
pr
that
I
guess
fixes
to
all
right.
So
that
means
that,
through
this
meeting,
we've
managed
to
triage
all
the
ones
that
do
not
have
prs
associated
with
them
and,
I
think,
make
decent
progress
on
the
existing
pr's
and
the
ones
that
might
be
a
little
stuck
have
people
that
have
volunteered
to
follow
up
and
continue
reviewing
on
this
one.
A
A
A
A
A
B
I
guess
I
have
a
couple
questions
that
I
feel
like
will.
Help
with
the
decision
is,
is
one
is
how
much
effort
was
it
rob
the
cutter
release
candidate
and
then,
I
think
part
of
it
too
is
like
how
how
far
away
do
we
think
we
are
from
the
one
alpha
one
I
mean
if
we're
talking
a
week
or
two
the
way
alpha
one
doesn't
necessarily
make
sense,
especially
if
there
was
a
fair
bit
of
work
that
it
took
to
make
the
release
candidate
happen.
A
So,
there's
almost
no
time
so
the
initial
release
candidate
was
just
about
you
know
establishing
consensus
that
it
was
time
the
actual
complexity
was
limited.
To
writing
this
release.
Note
the
next
rc
is
going
to
be
most
complex
because
we
have
committed
to
updating
a
change
log
for
every
additional
release,
but
with
that
said
anything
any
effort
we
spend
on
a
change
log
for
rc2.
A
A
I
I
know
I've
been
overly
optimistic
before
as
far
as
timeline
on
release
cadence,
it
does
feel
like
we
have
a
pretty
concrete
list
of
to
do's,
but
even
still,
I
think,
we're
probably
two
weeks,
maybe
one
week,
but
let's
say
two
weeks
from
a
final
release
here
and
given
that
maybe
there
is
room
for
one
more
rc
it
does.
You
know
we
had
51
commits.
I
think
I
counted
three
or
four
api
changes.
At
least
that
could
be
worth
a
another
rc.
B
A
A
B
Yeah
from
my
standpoint,
it's
showing
progress
and
that
we're
taking
a
structured
approach
to
making
that
progress
and
so
yeah.
I,
like
the
release
candidate,
there's
been
as
we
saw
enough
of
api
changes
to
warrant
the
release
candidate.
In
my
opinion-
and
you
know,
rob
as
you
mentioned
is
like
that
change
log
is
we're.
Gonna
have
to
deal
with
that,
no
matter
what
so
we
might
as
well
fight
that
bullet.
B
It
would
be
nice
at
some
point,
maybe
not
for
that
initial
pr,
but
to
to
somehow
document.
You
know
what
is
being
done
here,
rob
so
that
you
know
we
kind
of
share
that
burden
yeah.
You
don't
have
to
always
be
responsible
for
this,
but
maybe
since
you've
taken
this
on,
is
it's
something
that
you
could
add
to
harry's
document
to
to
help
others
follow
that
process.
A
E
B
B
B
E
E
A
Yeah
cluster
api
seems
to
be
consistently
be
the
standard
that
we
can
reference
but
again
they're
a
little
bit
different
as
that,
as
they
have
a
significant
amount
of
implementation
built
in
associated
with
api.
Whereas
we
are
just
an
api
at
this
point,
and
even
if
you
know
the
only
other
thing
we'd
have
is
a
web
hook
in
here,
which
would
make
sense
to
version
along
with
the
api.
A
E
B
A
A
Yes,
yeah
that
that
seems
approximately
right.
I
I'm
not
quite
ready
to
commit
to
a
date
yet,
but
I
think
that's
a
good
one
to
pencil
in.
I
think
you
know
we
meet
really
quickly
for
anyone
who
happens
to
be
around
in
the
mornings
a
lot
tomorrow.
I
think
it's
a
morning
meeting
tomorrow.
I've
lost
track
whenever
we
meet
tomorrow.
I'd
like
to
finalize
that
date
as
well.