►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20201008
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
Welcome
to
service
apis
meeting
for
october
8.,
thanks
to
everyone
for
showing
up,
we've
got
a
release
candidate
that
went
out
yesterday
and
some
great
questions
around
it.
So
yesterday
we
got
james
pr
in
thanks
for
the
quick
reviews
around
that,
and
I
I
tried
to
release
this
with
some
kind
of
note
that
you
know
this
was
still
a
work
in
progress,
but
I
you
know,
I
I
think
any
any
maintainer
can
change
right
at
this
as
as
they
see
fit.
I
don't
imagine
you
know
this.
A
This
project
has
mostly
flown
under
the
radar,
so
I
can't
imagine
this
getting
much
pickup
beyond
people
who
might
be
interested
in
implementing
this
api,
but
james
added
some
great
questions
to
the
agenda
that
I
think,
would
be
good
to
cover,
including
what
the
commitment
is
around
the
rc
one
and
if
we're
going
to
make
any
changes
or
especially
breaking
changes
for
rc2,
and
you
know
how
we
how
we
transition
from
rc
to
a
full
release.
A
A
A
I
to
me,
I
think,
that's
still
acceptable,
but
I'm
I'm
open
to
what
others
think
that
that
had
been
my
perspective
on
what
an
art
release
candidate
is
especially
a
release
candidate
for
a
initial
alpha
of
an
api,
but
I
am
very
open
to
what
others
think.
C
So
can
you
hear
me
yeah
cool?
Let's
give
you
a
little
bit
of
background
here.
I
didn't
really
read
the
little
release
note
too
closely,
and
so
I
posted
the
link
around
internally
and
I'm
like
yay.
We
have
a
release,
we
have
a
release
and
my
assumption
was
that
it
was
the
v1
alpha
one
release
and
then
I
got
questions
about.
What's
a
release.
C
C
C
A
Yeah,
that's
fair.
We
we
didn't
document
it
very
well
I
or
or
at
all,
and-
and
so
I
I
should.
I
should
probably
add
that
if
nowhere
else
to
the
release
note
itself
here,
my
idea
was
that
this
is,
you
know
again
kind
of
close
enough.
A
That
implementations
could
start
working
against
this
api,
with
the
understanding
that
things
can
and
will
still
change,
at
least
slightly
between
now
and
a
v1
alpha
1
release,
but
that
I
think
bowie
added
in
chat,
hopefully
no
new
features
and
no
major
restructuring,
which
I,
I
think
that's
kind
of
the
balance
I
had
envisioned
here.
You
know
our
whole.
A
Our
whole
project
here
is
an
api,
so
it's
kind
of
difficult
to
do
a
pre-release
that
doesn't
allow
for
changes
in
the
api
itself,
but
I
I
would
hope
and
think
that
those
should
be
minor
in
scope.
A
A
C
I
think
we
had
this
discussion
on
on
previous
calls
where
people
are
interested
in
implementing
v1
alpha
one,
but
also
we're
worried
about
the
stability
of
the
api,
so
that
releasing
an
rc1
which
isn't
you
know,
uniquely
identified
by
a
api
version,
seems
like
we
have
that
same
problem.
C
Do
people
think
that's
a
problem,
or
is
it
just
we'll
just
commit
to
making
the
on
the
wire
api
compatible
for
all
the
rc
series.
D
C
Well,
I
guess
that's
my
question
because
you
know
if
someone
implements
v1
alpha,
1
rc1
and
then
we
change
a
bunch
of
stuff
and
then
you're
running
a
cluster
with
v1
alpha
1
rc2.
C
What
do
they
do?
Do
they?
Are
we
going
to
be
careful
about
changes
so
that
they
they
can
gracefully
work
with
that?
Or
would
they
just
be
broken.
D
Yeah,
I
guess
they're
pointing
out
the
weaknesses
of
this
rc
thing.
I
was
just
using
it
as
like
sort
of
like
a
kick
for
ourselves
to
get
it
into
a
shape
where
we
can
cut
the
alpha
and.
D
Alpha
points
where
we
can
basically
say
from
now
on
we're
basically
trying
to
stabilize
it
to
be
towards
the
alpha.
Maybe
we
could
have
used
a
different
word
as
rc,
although
that's
the
one
that
came
to
mind,
because
it
is
technically
a
candidate
for
a
release
and
we're
general
work
towards
stabilizing
james.
Do
you
do
you
have
users
who
are
consuming
it
and
want
to
just
be
pinning
to
rc1.
C
We
have
we
have
an
internal
project
which
is
kind
of
tracking
it.
So
I
think
that
if
we
kind
of
clarified
what
we
mean
by
rc
along
the
lines
that
you
just
described,
I
think
that
would
be
pretty
helpful
for
them,
because
I
think
I
think
what
we
mean
by
rc
is
it's
in
a
state
that
implementers
that
we
feel
implementers
can
start
tackling
it,
but
no
one
should
yet
ship
a
product
until
the
final
v1
alpha
one
release
is
that
yeah?
That's
right!
Yeah.
A
C
Okay,
that
makes
sense
I'll
just
add
a
sentence
to
the
release,
notes
just
to
clarify
and.
A
Great
sounds
good
yeah
thanks
thanks
for
calling
that
out,
I
know
there.
There
was
definitely
some
reasonable
confusion
around
around
what
an
rc
should
mean
here,
but
yeah
cool
and-
and
hopefully
you
know-
I
think
another.
While
we're
talking
about
release
candidates,
we
should
talk
about
maybe
what
kind
of
sequence,
what
kind
of
how
often
we
want
to
release
an
rc
and
and
how
quickly
we
might
achieve
alpha,
because
you
know
like
well
not
not
to
skip
too
far
ahead.
A
A
I
I
had
thought
that
it
might
be
good
to
release
to
plan
on
releasing
another
rc
in
somewhere
between
10
days
and
a
week
from
our
and
two
weeks,
so
between
10
and
14
days
from
our
first
rc
and
then,
if
we
are
reasonably
happy
with
that,
rc
proceed
to
a
v1
alpha,
1
release
very
shortly
after
that
I
don't
know
if
that's
a
reasonable
timeline
to
to
everyone
else.
I
know
we
still
do
have
a
number
of
issues
here,
but
the
list
is
certainly
dwindling.
A
So
so,
and
and
just
probably
sounds
good
to
me-
cool
great,
thank
you
and-
and
I
think
the
the
follow
up
to
that
is
james
question
here
of
what's
this,
what
how
do
we
define
when
we
graduate
from
an
rc
to
a
full
release?
A
I
am
hopeful
that
our
next
rc
can
be
generally
api
complete
and
you
know
maybe
we
can
let
that
soak
for
just
a
few
days
give
people
a
chance
to
play
with
it
poke
at
it
make
sure
we
haven't
missed
things
and
then
graduate
to
v1
alpha
one
from
there
that
that
had
been
my
perspective
on
this.
I
you
know,
I
know
I've.
I've
had
other
months
in
mind
before,
but
it
sure
it
sure
does
feel
possible
that
we
could
actually
get
something
out
in
october.
A
And
so,
if
you
say
we,
we
get
another
rc
out,
not
this
following
week,
but
early
and
the
week
after
that,
and
then
an
alpha
shortly
after
that
that
hopefully
would
have
no
changes
in
between
the
final
rc
and
an
alpha.
A
Maybe
that's
a
reasonable
timeline
here.
I
don't
know.
A
I'm
going
to
take
the
the
lack
of
of
feedback,
as
everyone
agrees
fully
with
me,
so
yes,
thanks,
bowie,
and
so
with
that
I
think
we're
set
on
rc
and
potential
timeline
here.
A
If
anyone
else
wants
to
push
for
something
different,
definitely
let
me
know
put
it
in
slack
or
zoom
or
wherever
with
that
said,
let's
take
a
little
bit
of
time
and
go
through
this
milestone.
I
know
I've.
I
know
harry
has
volunteered
to
take
this
one
on.
D
A
A
A
Okay,
great
faqs
is
anyone
interested
in
taking
this
one.
C
A
A
E
I
I'd
be
happy
to
look
at
it.
I
guess
I
was
just
not
okay
just
been
reading
it
there.
I
wasn't
sure
where
it
was,
but
I
can
follow
up
with
ariel
find
two
to
find
out
so.
A
I
I
forget
your
is
this:
this
is
there,
it
is.
A
My
typing
skills
get
immeasurably
worse
when
I'm
screen
sharing
something
about
it
all
right.
The
standardized,
selector
fields
and
the
api
is
also
a
good
one
that
yeah
harry
has
harry.
Has
volunteered
for
a
lot
of
these
I'm
going
to.
I
know.
I'd
also
been
involved.
I've
been
involved
in
a
lot
of
these
selectors
too.
So
I'm
going
to
help
out
with
this
one.
A
Type
aliases
resolve
too
aggressively
in
the
generated
documentation.
I
remember
this.
We
have
a
few
less
type
aliases
now,
but
I
think
we
still
have
this
problem
right.
James.
C
Yeah,
I
think
so,
but
I'm
not
sure
that
there's.
B
B
C
A
I'm
going
to,
I
know
this
is
a
potential
solution.
I
don't
know
if
it's
going
to
make
a
difference,
but
if
anyone
wants
to
volunteer
to
try
it
out
and
see,
if
it
does,
it
could
be
worthwhile.
D
C
Yeah
there's
another
related
there's
another
related
issue
with
documentation
that
I
think
gabe
put.
B
C
Pr
in
for
which
is
that
the
documentation
generator
doesn't
do
anything
with
named
constants,
which
is
kind
of
unfortunate,
because
we
have
a
bunch
of
places
where
we
have
these.
We
use
the
you
know,
ghost
string,
enum
pattern
and
we
attach
documentation
to
certain
constants,
which
is
useful,
but
you
can't
get
it
from.
C
A
Either
yeah
that
that
is
frustrating
and
I'll
just
we
don't
have
that
many
pr,
so
I'll,
just
pull
that
one
up
real
quick!
This
is
one
that
I
think
you
had
pointed
out.
The
same
documentation
appears
below
here,
but
it's
not
obvious
because
yeah
it
it
this.
C
Just
get
ignored,
yeah,
it's
I'll,
probably
look
at
it,
maybe
today,
but
it's
possible
that
in
the
code
templating
the
constant
values
are
like
available
somewhere,
but
I
don't
think.
A
C
A
You
would,
you
would
hope
so
because
we
use
these
all
over
the
place,
but
I
don't
actually
know
I
I
spend
all
my
time
just
looking
straight
at
the
go
types
which
is.
A
Yeah,
that's
a
good
question:
okay,
yeah
I'll
leave
that
for
now
then,
and
we're
on
to
gateway
and
gateway
class
relationship.
I
think
this
is
changed
to
a
kind
documentation.
A
I've
added
this
to
v1
alpha
one
milestone.
It
would
be
good
to
clarify.
We've
had
a
lot
of
discussions
about
the
difference
between
gateway
and
gateway
class.
Does
anyone
feel
especially
qualified
to
answer
this
in
the
form
of
documentation.
C
A
Okay,
well
I'll
I'll.
Take
this
one
and
ccu,
I
I've
written
at
least
some
things
around
this
and
been
involved
in
some
of
the
discussion.
I
don't
know
that
my
first
attempt
at
differentiating
this
will
be
perfect,
but
I
can
give
it
a
first
go.
A
A
This
would
involve
a
transition
from
route
name
space.
This
is
the
time.
E
A
Yeah,
so
this
is,
you
know:
we
have
routes,
dot,
route,
name,
spaces
and
routes,
dot,
route
selector,
and
it
could
be
argued
that
this
is
just
too
repetitive
and
we
could
get
rid
of
the
route
prefix
here.
I
think
that's
probably
a
reasonable
thing
to
do
here,
so
I've
kind
of
suggested.
What
that
might
look
like
this
one
gets
a
little
funky.
A
Does
anyone
would
does
anyone
not
like
this
idea?
Would
anyone
prefer
we
just
don't
touch
this
and
leave
it,
as
is.
A
Okay,
I
I'm
going
to
assign
this
to
myself
then
and
I'll
I'll,
do
a
pr
and
feel
free
to
to
comment
or
leave
feedback
that
maybe
we
shouldn't
take
this
on,
but
it
seems
like
a
pretty
straightforward.
A
B
Yeah
so
currently
in
http
route,
we
have
a
path-based
matching
and
header
based
matching
and
then
an
extension
point
in
tcp,
tls
and
udp
routes.
We
only
have
an
extension
ref
now
the
point
like
when
I
was
actually
using
the
extension
ref.
No,
it
turns
out
so
you
can
define
a
route
and
then
the
matching
criteria
has
to
live
in
a
different
crd
right.
B
So
is
that
something
that
we
want
to
support
in
the
api?
Or
do
we
recommend
authors
create,
like
you
know,
http
router?
You
know
x
route
like
apis
under
this
which
are
very
similar
in
structure
and
behavior
as
in
service
apis,
so
so
that
that
was
my
conundrum.
So
that's
why
I
opened
this
up
like
having
matching
logic
outside
throughout
crd.
B
A
B
Yeah
I
mean
I'm
questioning
all
the
routes,
not
just
http
route,
because,
okay,
I
think
we
should
have
uniformity,
but
you
know
routes
like
tcp
route.
If
you
don't
have
any
match
criteria
right
now
and
if
you
remove
the
extension
reflect,
the
only
way
you
can
do
routing
is
like
send
all
the
traffic
to
from
one
listener,
to
run.
A
Yeah,
okay,
I
the
the
thing
that
I
I've
struggled
with
this
as
I
thought
about
it
is
it's
hard
to
remove
it
from
the
other
routes
and
if
we
can't
remove
it
from
the
other
routes,
it
almost
feels
like
it's
easier
to
leave
it
on
http
route.
Just
because,
just
for
the
sake
of
consistency,
I
I
with
that
said.
I
don't
feel
very
strongly
here.
I
cannot
come
up
with
a
great
example
of
an
extension
point
for
matching
in
an
hd
route
that
we
don't
already
handle.
D
Baby,
can
you
harry?
Can
you
put
some
examples
there
as
to
both
sides?
The
thing
is
like:
if
you
want
to
implement
your
own
hp
route,
that
might
be
a
pretty
complicated
thing
to
get
right.
So
if
we
were
to
recommend
that
that's
how
people
extend
that,
we
need
to
make
it
easy
or
not.
It's
just
like
a
really
difficult
thing.
B
No,
I
was
just
going
to
confirm
yeah.
That
was
the
other
side
of
it
where
you
know
adding
a
new
resources,
pretty
complicated
like
in
you
know,
hazards
life
cycle
and
then
there's
like
so
many
things
to
take
care
of.
So
so
I
think
if,
if.
C
The
working
group
says
you
should
extend
things
with
your
own
routes.
People
are
going
to
run
with
that
right,
we'll
get
there'll,
be
a
ingress
engine
x,
route
type
there'll
be
a
contour,
http
proxy
route
type
there'll
be
a
lot
of
fram.
I
think
the
result
of
that
will
be
that
there's
a
lot
of
fragmentation
which
isn't
necessarily
you
know.
A
bad
thing
like
fragmentation
within
the
umbrella
of
gateway,
is
still
an
improvement
over
fragmentation
without.
D
Supporting
immediately
having
people
create
their
own
specific
routing,
crds
like
a
copy
of
http.
That
feels
like
it's
gonna,
run
into
problems,
pretty
quickly
for
just
users
to
understand
and
for
to
match
behaviors.
But.
D
A
I
think
that
is
this.
The
idea
to
add
custom
routes
is
is
a
really
cool
part
of
this
api,
but
it
is
also
kind
of
that
steep
cliff
you
you
describe
like
it
is
a
a
dangerous
thing
to
become
too
common
you,
you
really
don't
want
you
know
like,
or
at
least
I
don't
think
we
want
to
start
out
with
every
implementation
having
all
their
own
custom
rounds
right.
A
You
know,
then,
then
you,
you
lose
the
portability,
and
I-
and
I
I
know
like
just
you
know-
we're
probably
not
going
to
start
that
way,
but
I
would
I
would
lean
towards
starting
with
more
exception
points
on
resources,
so
there's
at
least
a
way
to
extend.
A
B
Yeah
that
that
makes
sense-
and
I
agree
you
know
that-
gives
at
least
a
point
of
experimentation
and
feedback.
So
so
let
me
go
ahead
and
I'll
add
some
try
to
add
some
documentation
around
it
as
to
you
know
how
why
and
how
an
extension
point
should
be
used
is
very
important
for
us
to
document.
B
A
Okay
sounds
good,
and
I
I
like
I
like
james's
comment
here
that
you
know
this.
This
is
something
that
could
be
a
very
standardized
extension
point
of.
I
just
want
to
match
all
git
requests
like
that.
That
seems
like
a
great
way
to
experiment
with
what
could
start
as
extended
functionality
and
maybe
eventually
becomes
core.
A
B
A
Okay,
cool,
if
if
anyone
feels
underwater
with
something
that
I
have
assigned
to
them
or
cc'd,
just
ping
me,
and
I
can
help
find
someone
else
or
take
it
on
myself
yeah,
but
that
I
think
that
means
everything
that
we
are
trying
to
get
into
v1
alpha
1
is
assigned
and
accounted
for
and
feels
like
we're
getting
close,
wow
cool
all
right
with
that
said,
I
wanted
to
follow
up,
but
a
lot
of
people
on
this
call
were
also
at
office
hours
yesterday
and
we've
kind
of
been
working
through
this
document
of
different
approaches
we
could
take
to
restricting.
A
Creation,
you
know
specifically
gateway
creation
by
gateway
class.
The
old
story
of
I've
got
an
external
load,
balancer
gateway
class,
and
I
would
rather
not
expose
that
to
every
single
name
space
in
my
cluster.
I'd
rather
just
have
a
sunset,
and
so
we
discussed
briefly
the
a
few
different
approaches,
one
being
the
approach
that
we
currently
have
and
slight
variations
on
that
using
either
a
selector
or
list,
but
something
that
is
an
attribute
or
field
on
gateway
class
itself
to
control
this.
A
A
I've
run
this
by
a
few
people
from
a
few
different
cities.
Just
to
you
know,
spread
the
net
wide.
I
also
you
know
send
this
out
to
the
sig
network
mailing
list
to
see
if
we
could
get
as
much
feedback
as
we
possibly
could
on
this
resource.
Quotas
came
up
because
that's
two
things
that
are
very
relevant
to
this
use
case
already
use
quota,
so
the
way
that
you
restrict
service
type
load
balancer
is
with
quota
and
the
way
that
storage
class
solved.
A
Limiting
you
know
how
a
specific
storage
class
could
use
a
could,
use,
you
know
be
used
in
a
namespace
was
also
quota.
So
this
is
an
example
of
how
you
would
you
know,
limit
the
number
of
load
balancers
or
limit
the
amount
of
storage
for
a
given
storage
class
in
a
namespace.
A
The
advantage
here
is
that
there's
prior
art
and
it's
very
relevant
to
what
we're
doing
the
disadvantage
is
that
of
the
use
cases
that
have
used
this.
The
you
know
at
least
talking
with
saad
from
sig
sergeant.
This
does
not
seem
like
a
popular
approach.
A
One
of
the
downsides
of
this
is
that
it
is
allowing
everything
by
default,
and
you
need
to
create
an
entry,
a
quota
entry
in
every
single
namespace
to
explicitly
deny
you
know
the
use
of
a
storage
class
and
that
obviously
scales
as
you
as
anyone
creates
a
new
namespace.
You
have
to
make
sure
this
quota
exists
here,
or
else
they
can
use
whatever
storage
class
or
gateway
class
they
want.
A
A
A
Option
number
four
can
and
feel
free
to
interrupt
me
at
any
point.
If
you
have
feedback
thoughts,
the
fourth
option
here
came
with
the
gateway
class
grant,
and
this
one
is
a
suggestion
that
I
think
tim
had
and
the
idea
is
well.
Why
can't
we
just
you
know
we
we
want
something
like
our
back.
We
need
some
kind
of
model
like
this.
That's
going
to
scale
across
all
different
kinds
of
class
resource.
B
A
A
A
And
finally,
the
the
last
idea
here
is
to
say
that
we're
not
going
to
solve
this
yet
essentially
that
that's
maybe
too
strong
of
a
summary
here,
but
to
say
you
know,
this
is
out
of
scope
for
our
v1
alpha
1
api.
We
want
to
promote
this
concept,
an
idea
and
instead
we'll
provide
examples
of
how
users
could
enforce
this
themselves
with,
as
you
know,
opa
templates
policy,
config,
etc.
A
If
they
happen
to
be
using
a
policy
agent,
we
can
provide
examples
of
how
they
could
achieve
this
kind
of
policy
without
actually
making
it
core
inside
our
api,
yet
because
we're
not
quite
sure
what
it
should
look
like
inside
our
api
or
if
it
should
live
inside
our
api
at
all
yeah
that
those
those
are
the
vast
array
of
options
presented.
A
I
do
not
love
any
of
them,
but
I
have,
as
time
has
gone
on
I've.
I've
gradually
started
to
shift
towards
this
last
option
of
you
know
basically
punting
on
this
a
little
bit
and
and
providing
a
way
that
is
out
of
tree
at
least
initially
and
continuing
to
work
on
a
more
standardized
approach
that
is
going
to
work
for
not
just
us
but
other
class
resources
as
well.
A
A
So
that's
where
we
are
in
this
one
I
am
increasingly
unsure
of
where
we
should
go.
But,
given
you
know
this
paralysis
of
choice,
I
am
rather
more
hesitant
to
push
an
idea
that
is
wholeheartedly
wrong
than
to
punt
on
it
and
provide
this
kind
of
half
answer
and
the
v1
alpha.
One
release
of
you
can
use
this
other
option
to
enforce
this.
A
Instead,
I
don't
know,
but
I
know
I
know-
we've
already
gone
over
time
here,
so
I
don't
want
to
take
up
too
much
more
of
of
everyone's
time,
but
I'll
give
just
a
minute
or
two.
If
anyone
has
a
preference
here
of
these
potential
approaches
or
some
other
approach,
we
might
not
have
thought
of.
D
Sounds
good
yup,
let's
yeah,
since
this
is
like
a
generic
problem,
probably
end
up
talking
to
it
through
it
with
a
bunch
of
cigs,
so
yeah
adding
our
own
thing,
probably
isn't
super
wise
at
this
point.
A
Yeah
it
was
this.
It
goes
back
to
a
comment
that
antoine
had
at
the
the
beginning.
Here
that
was,
you
know,
basically
we're
if
we
try
and
cram
this
into
gateway
class,
we're
we're
confusing
the
purpose
of
gateway
class,
and
I
know
we've
had
similar
comments
internally,
as
I
initially
proposed,
adding
this
to
gateway
class,
that
this
is
kind
of
confusing
what
gateway
class
is
for
mudding
the
waters.
A
So
I
unfortunately
have
come
to
agree
that
this
may
not
be
something
we
should
solve
at
least
not
in
the
way
that
is
currently
implemented.
So
I
I
can.
I
can
take
this
one
on
to
to
both
remove
it
and
and
potentially
come
up
with
some
suggestions
for
a
opa
or
policy
agent
based
approach
to
this.
In
the
meantime,
not
to
say
we
won't
eventually
solve
this
inside
our
api.
D
Okay,
cool
yeah,
unfortunately,
opa
is
not
like
the
most
easy
to
explain
and
you
don't
give
the
users
many
guardrails.
That's
definitely
something
that
I
think
generally.
We
need
to
kind
of
solve
because
I
think
the
use
case
is
quite
compelling.
D
A
C
Yeah,
I
think
the
benefit
so
one
of
the
things
that
gatekeeper
seems
to
have
done
well.
Is
you
it's
possible
for
a
project
to
ship
with
paramount
parameterized
policies?
C
So
we
as
a
project,
can
say
here's
a
bunch
of
gatekeeper
policies
that
you
can
use
and
we've
done
the
rego
implementation
for
you
and
you
can
and
then
operators
can
just
you
know,
select
those
and
parameterize
them.
So
it
takes
a
lot
of
the
rego
pain
out
of
developing
these
things.
A
A
Cool
all
right.
Well,
I
think
we're
over
time,
but
thank
you,
everyone
for
for
the
great
feedback
here
and
we'll
talk
to
you
all
next.