►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210913
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
All
right,
this
is
the
gateway
api
meeting
for
september
13..
We've
got
lots
on
the
agenda
all
added
by
me
at
this
point,
but
anyone
can
feel
free
to
add
their
own
content
if
they
want
to.
I.
The
first
thing
I
have
on
my
mind
is
I
wonder
if
anyone
wants
to
lead
the
community
meeting
on
september
20th,
so
the
same
meeting
a
week
from
today,
I'm
going
to
be
out
actually
visiting
family
in
canada.
A
A
Tim
had
been
reviewing
another
cap,
as
he
was
doing
our
review,
and
that
cap
also
would
benefit
from
this
kind
of
cross
namespace
reference
that
we're
allowing
with
reference
policy
and
you've
already
seen
if
you've
been
looking
through
our
sig
network
review
feedback
that
hey
it'd
be
really
cool.
If
we
could
make
this
more
generic
and
useful
to
more
than
just
gateway.
Api,
so
seems
like
reference
policy
is
at
least
somewhat
popular
in
concept,
and
it
seems
worthy
of
a
discussion
at
sega.
A
A
I
chimed
in
here
and
tim
had
mentioned
the
connection
to
reference
policy
as
well,
so
feel
free
to
comment
on
this
cup
as
well,
but
because
there's
this
kind
of
two
apis
coming
together
that
have
potential
across
cigs
to
make
use
of
a
resource
like
this.
It
may
make
sense
to
see
what
is
out
there.
I
sent
out
an
email.
A
Anyone
who's
on
sig
off
mailing
list
would
already
have
seen
this
but
sent
out
an
email
today
to
sigoth
just
to
start
the
conversation-
and
I
have
something
on
the
agenda
for
this
coming
wednesday
to
discuss.
When
does
reference
policy
make
sense
and
two,
if
it
makes
sense,
should
we
look
at
some
kind
of
more
generic
placement
gateway
api
for
it
to
belong
so
yeah
that
that's
this
discussion?
A
C
A
Yeah
I
I
agree-
this
is
probably
not
something
that
we
can
block
on.
I
completely
agree
with
that,
but
I
do
want
to
at
least
make
sure
that
we've
done
our
due
diligence.
I
I
think
a
good
sign
would
be
that
sigot
says
hey.
This
is
a
good
idea
we
should
pursue
it
further,
like
part
of
this
is
also
getting
a
review
from
sigoth
on
this
api
that
is,
network
related,
but
really
closer
to
authorization
anyways,
so
looping
them
in
just
to
review.
D
A
Yeah
no,
I
agree
with
that
one
of
the
things
I
I
had
a
brief
discussion
with
him
about
this
on
friday
after
well
as
he
was
reviewing
the
last
chunk
of
gateway
api
and
one
of
the
things
that
came
out
of
that
discussion
is
maybe
reference.
Policy
is
something
that
does
have
to
move
to
resource
instead
of
kind
references
which
that
makes
things
a
little
messy.
A
But
if
we're
trying
to
turn
reference
policy
into
a
more
generic
thing,
we
can't
necessarily
guarantee
that
every
implementation
of
reference
policy
is
going
to
understand
the
kind
of
resource
mapping.
This
is
that's,
that's
tangential,
but
that's
the
kind
of
change
that
could
come
before
we
release
v1
alpha
2,
depending
on
broader
feedback.
I
don't
know.
D
D
A
A
This
is
by
no
means
approved
or
final
in
any,
in
any
sense
of
the
word,
I'm
just
trying
to
a
lot
of
our
discussions.
A
lot
of
what
we've
been
working
towards
now
is:
how
can
we
better
prepare
ourselves
to
build
a
backwards
compatible
api?
So
how
can
we
remove?
How
can
we
limit
the
kinds
of
breaking
changes
we'll
make
in
the
future
and
make
this
truly
backwards
compatible?
We
haven't
really
talked
about
what
that
means,
and
I
have
just
sketched
out
some
thoughts
that
may
or
may
not
make
sense.
I
can.
A
A
C
A
Yeah,
that's
that's
a
good,
so
I
I
I've
just
been.
I
I
had
some
thoughts
that
I
tried
to
run
by
daniel
smith
and
and
jordan
about
just
what
is
really
possible
here.
Compared
to
upstream
and
I've
I've
been
guilty
of
trying
to
think
of
crds
as
hey.
We
can
create
the
upstream
api
experience,
but
that
is
not
weak
because,
as
you
said,
bowie
it
is
pretty
well
def.
A
Well,
I
don't
know
well
defined,
but
there
are
pretty
clear
patterns
that
we
follow
there
and
that's
because
we're
trying
to
basically
keep
api
server
and
controllers,
specifically
controller
manager
in
sync-
and
you
have
these
compatibility
guarantees
and
all
this
stuff
with
crds,
it's
a
little
more
a
little
more
loose
in
the
sense
that
we
we
don't
have
all
these
components
all
tightly
controlled
in
the
same
system.
We
we
don't
have
quite
the
same
guarantees
that
we
can
even
offer
if
we
wanted
to,
and
our
validation
capabilities
are
also
significantly
weaker.
A
D
Yeah,
I
see
what
you're
saying,
but
I
feel
like
the
the
sort
of
end
point
of
that.
Is
that
the
you?
Why
have
the
validation
at
all?
Like
you
know,
if
you
can't
rely
on
the
validation
to
screen
out
incorrect,
correct
values,
then
then
you're
going
to
what
you're
going
to
have
to
do
as
a
controller
writer
is
just
to
do
the
same
check
that
you
would
do
in
the
validation
anyway.
A
I
I
think,
that's
the
conclusion.
I've
come
to
as
I've
been
as
I've
been
trying
to
process
this
and
trying
to
understand
how
we
could
loosen
validation
like
one.
You
know
to
to
go
back
to
something
that
we've
dug
into
quite
a
bit
is
port.
You
know,
should
it
be
optional
or
not,
and
half
of
that
is
deciding?
A
D
I
I
hear
what
you're
saying,
and
I
think
it
doesn't
make
sense
to
sort
of
have
the
rule
be
that
the
the
the
cid
validation
is
for
users
yeah.
That
makes
sense,
but
like
the
it
feels
like.
The
validation
is
just
as
much
part
of
the
api
as
anything
and
that
the
same
rules
should
apply
to
the
validation
as
to
adding
changing
or
removing
fields.
C
I
think
rob
we
might
want
to
take
this
to
a
dock,
because
this
one,
the
subtlety
here,
is
that
what
we
want
to
do
is
create
a
ecosystem
in
which
the
controllers
might
get
a
little
skew
of
each
other.
Let's
say
you
have
one
user's
cluster:
the
infrastructure
provider
is
going
to
be
installing
the
crds,
and
then
they
may
be
using.
C
You
know
something
that
they
installed
themselves
like
nginx
or
contour,
or
what
have
you
and
what
we
want
to
do
is
make
sure
that
everyone's
implementation
meets
some
certain
criteria,
such
that
even
slight
skews
will
not
just
cause
things
to
majorly
blow
up,
and
one
of
these
things
is
that
is
if
the
web
hook
is
slightly
off,
that
it's
not
the
case
that,
like
an
entire
set
of
infrastructure,
just
stops
working
all
together.
It's
I
think
at
the
outset
my
general
sense
is
in
the
beginning.
Actually,
this
stuff.
C
This
will
be
not
as
much
of
a
problem,
because
there's
basically
just
one
version
of
the
api
lying
around.
This
will
become
a
problem
like
two
years
right,
whereas
people
get
stuck
on
software,
some
people
refuse
to
upgrade
because
things
are
still
working
and
and
kind
of
we
have
more
skew
in
terms
of
versions.
A
Yeah
yeah,
I
agree,
there's
a
good
bit
of
nuance
here
and
certainly
for
those
major
changes
like
dropping.
You
know
make
required
field
becoming
optional,
or
something
like
that.
That
does
seem
like
something
that
likely
requires
an
api
rev,
a
new
api
version.
I
think
I'll
need
to
double
check
that
at
least
in
upstream
but
yeah.
This
is
a
complex
topic.
I
just
want
to
get
thinking
about
it
now
because
it
it
has
to
guide
our
decisions
around
what
you
know
v1
alpha
2.
A
Is
this
release
that
we're
really
trying
to
keep
everything
about
compatibility
in
mind
and
just
having
this
discussion
now
and
you
know
going
forward
in
a
doc
about
what
that
looks
like
what
what
we're
committing
to
and
what
we
want.
Implementations
to
you
know
be
able
to
handle
right,
because
we
know
there's
going
to
be
skew
in
clusters,
and
we
know
our
implementations
of
this
api
will
at
least
be
able
to
handle
some
amount
of
sku.
A
A
A
One
of
the
bits
of
confusion
here
is
on
what
wild
car,
what
what
wild
card
domains
actually
match.
My
understanding
from
looking
at
envoy
docks
is
that
a
wild
card
domain
and
they're
in
virtual
host
matches
n
labels.
There's
no
restriction
on
the
number
of
labels
that
can
be
matched
is.
Does
that
sound
accurate
or
did
I
miss
something.
F
A
D
F
D
G
D
E
Is
given
given
a
host
name,
given
your
host
name,
how
do
you
choose
a
certificate
right
and
when
you're
choosing
and
if
you
have
a
wild
card
certificate
in
your
certificate
store
you,
the
star
is
only
allowed
to
match
one
dns
label
right?
That's
the
thing
that
you
know.
I
think
that,
ultimately,
all
this
stuff
has
to
align
to.
A
Yeah,
so
I
I
think,
there's
there's
a
few
things
at
play
there
and
I
agree
that
the
implementations
can
and
should
choose
certificates
that
way
for
sure,
but
I
think
and
harry
you
can.
You
can
remind
me
if,
if
my,
if
I'm
remembering
this
conversation
incorrectly,
but
my
my
example
here
is
basically
saying
that
star.example.com
could
potentially
be
used,
at
least
by
some
implementations,
on
a
gateway
to
match
both.
You
know
basically,
two
levels,
deep
of
subdomains,
so
store.staging
and
app.staging.example.com.
C
D
G
A
C
G
Yeah,
okay
yeah.
It
feels
almost
like
fundamentally
there's
kind
of
two
different
ways
to
routing
out
an
ingress
like
one
is
what
I
think
the
spec
is
supposed
to
be
in
that
you
match
the
s.
I
you
say
this
is
my
certificate
for
that
s.
I,
and
then
these
are
the
routes
for
that
s,
and
I,
the
other
that
I've
seen
is
kind
of
here's,
a
big
bundle
of
certificates,
and
I
just
want
to
match
anything.
I'm
going
to
automatically
you
know.
F
G
G
G
G
H
H
I
expect
that
to
be
picked
up
picked
up,
but
what
about
bar.food.example.com?
According
to
click?
Imagine
there
is
no
tls
in
the
world.
In
that
case
our
spec
says
that
you
cannot
have
two
level
of
nesting
like
just
plain
http
matching.
Where
is
everybody's
understanding
on
that
topic,
and
then
we
can
dive
into
sni.
D
Dns
label.
Yes,
the
the
spec
currently
explicitly
says
that
the
that
the
only
valid
that
star
is
is
only
valid
for
one
label
in
the
host
name
field
between
the
listener
and
the
routes.
So,
if
you
have
star
in
one
field,
it
can
match
one
label
in
the
other
one
or
one
star,
so
you
can't
it
won't.
Do
it
shouldn't
do
multiple
and
you
I'm
you
if
envoy,
if
that's
not
the
behavior,
that
envoy
has,
I
can't
remember
if
it
is
or
not.
D
G
B
D
Yeah,
I
think
that
john's
point
was
fair,
that
that
you
can,
on
the
ingestion
like
that,
that
you
can
say
that
if
the
single
label
doesn't
match
between
a
gateway
listener
and
a
gateway
route,
then
the
route
should
then
the
route
must
be
rejected.
Right,
that's
what
the
spec
says,
but
like
that
yeah
and
then
but
then
what
happens
is
for
envoy
once
that
actually
gets
rendered
out
to
config.
D
If
a
thing
comes
in
for
abc
example.com,
then
then
it'll
get
routed
right,
but
that's
the
way
that
envoy
works
right
like
so
there's
a
there's,
a
weirdness
in
the
behavior
there,
because
of
the
way
that
it
does
string
matching
and
that's
a
that's
a
greedy
glob.
It's
not
it's
not
like
a
single
label
blob,
but
the
I
don't
think
that
we
should
change
the
way
that
the
the
gateway
and
the
listener
first
name
need
to
agree
for
the
gateway.
D
D
And
so
like,
I
think
it's
fair
for
envoy
implementations
to
say
if
you
were
doing
a
wild
card,
a
wild
card
cert
and
a
wild
card
route,
then
there's
this
weirdness
that
will
come
up
like
it's
a
pretty
specific
thing.
You
should
you
be
doing
like
I'd.
Argue
you
probably
really
shouldn't
be
doing
double
wildcard.
That's
weird!
You
know,
but
if
you
do
then,
yes,
there's
this
witness
and
that's
one
of
the
things
that
you
know.
D
You've
got
the
sni
in
that's
in
the
actual
certificate,
the
hostname
that's
on
the
listener
on
the
gateway
and
the
hostname,
that's
on
the
route,
and
if
you
can
have
multiple
levels,
if
the
glob
is
greedy
on
any
of
those,
then
you
get
a
combinatorial
explosion
of
things
that
it
could
possibly
be
and
having
it
be,
a
single
label
makes
the
makes
the
whole
the
way
that
the
the
three
things
interact.
Much
easier
to
understand.
E
D
I
think
that
yeah
and
like-
and
you
know
one
of
the
things
that
I
remember
we
found
when
we
were
implementing
ingressv1,
which
had
a
similar
thing,
was
that
there
are.
There
are
a
lot
of
educators
around
like
what
happens.
If
you
have,
you
know
a
wild
card
on
one
side,
but
not
on
the
other.
You
know
what
happens
if
you
have
a
cert,
that's
not
a
wild
card
or
a
router
diesel
car.
You
know,
or
vice
versa.
D
If
the
wild
cards
don't
match
up,
there's
a
bunch
of
things
that
you
need
to
that.
We
need
to
be
clear
about
the
behavior
for
for
when
we
had
this
and
yeah,
and
I
think
I
haven't
I
thought
I
had
commented
on
this
pr,
but
obviously
I
haven't
sorry
yeah,
but
so
I
think
that's
the.
If
I
would
to
summarize
the
feedback
that
I
will.
F
D
A
C
A
Yeah,
because
you
can
solve
a
lot
by
just
not
attaching
the
route
if
you
have
a
route
for
a.b.example.com
and
you
just
don't
attach
to
the
gateway
because
it
doesn't
match
those
dynamics
like
it
doesn't
match.
Star.Example.Com
from
the
api
perspective,
you've
solved
at
least
some
of
your
problem.
That
way,
not
all
of
it,
but.
E
A
Yeah
for
sure
I
I
just
think
we
need
to
be
cognizant
that
there
are
some
and
some
implementations
out
there
that
are
not
going
to
be
able
to
restrict
that
wild
card
matching.
So
that's
my
perspective.
At
least,
it
feels
like
at
least
mentioning
in
the
spec
that
not
every
implementation
is
capable
of
this
behavior.
A
A
A
That
was
really
asking:
do
we
need
spec
and
status
for
reference
policy?
I
don't
have
a
good
answer
to
that.
I
his
suggestion
was
that
if
you
don't
think
you'll
ever
need
status,
you
probably
don't
need
the
distinction
between
spec
and
status.
I'm
unsure
can.
Can
anyone
think
of
a
compelling
use
case
for
status
here.
G
C
A
That
is
responsible
for
reading
from
or
implementing
based
on
this
reference
policy
so
populating
that
status
gets
into
this
kind
of
messy
thing
where
you'd
need.
You
know
like
controller
name
or
some
concept
of
that,
which
we
we
have
some
precedent
for,
but
it's
yeah,
I
don't
know
I
I
don't
know
how
I
feel
about
that.
C
E
A
Yeah,
that
would
be
a
good.
I
yeah
that'd,
be
a
good
follow-up.
I
should
ask
in
their
slack
channel
just
to
be
sure
I
don't
have
a
lot
of
experience
there.
It
does
seem
like
what
others
are
saying,
that
the
safest
thing
is
to
leave
spec
and
status
in
place
unless
we're
completely
sure
that
we'll
never
need
status
and
it
seems
like
status,
is
unlikely,
but
not
impossible.
D
A
A
If,
if
you
want
to
comment
on
this
one,
it's
the
last
comment
in
here
would
be
good
to
get
a
different
perspectives
on
this
one
cool
all
right,
the
next
one
potential
for
wasting
some
time
on
this
one,
but
I
had
been
discussing.
I
see
yeah
marks
on
this
call
discussing
naming
with
mark
and
and
ways
we
can
simplify
the
routes
section
in
a
listener.
A
He
had.
He
and
shane
had
done
some
great
docs
improvements
around
cross,
namespace
routing,
but
as
part
of
that,
looking
at
the
examples
they
may
have
been
at
least
slightly
more
confusing
than
I
would
have
hoped,
and
by
no
fault
of
the
examples
themselves,
just
the
the
wording,
the
whatever
one
suggestion
mark
had
was
hey.
Could
we
maybe
rename
allowed
routes
to
route
constraints?
A
G
Yeah
I
this
is
like
a
very,
very
weak
hesitation,
but
it
just
seems
like
constraints-
I
don't
know
I've
been
native
english
speakers,
so
it's
not
a
huge
deal
for
me,
but
for
someone,
that's
not
like
it's
kind
of
a
word
that
I
haven't
seen
in
the
api
before
it's
kind
of
long
kind
of
hard.
To
spell
this
is
like
a
very
vague
concern,
but
if
we
could
make
it
slightly
simpler,
I'd
be
happier,
but
I
also
don't
have
any
better
suggestions
really.
So
I'm
fine
with
this.
If
there's
no
better.
F
A
Yeah
so
more
context
on
this
is
this
was
just
routes.
The
name
was
just
routes
and
sig
network
review.
I
think
it
was
dan
had
mentioned.
Hey
routes
does
not
seem
appropriate
anymore,
because
this
isn't
a
list
of
routes.
This
isn't
a
selector.
This
is
really
just
what
kind
of
routes
you
accept,
and
so
this
is.
This
is
more
a
limitation
on
the
kinds
of
routes.
I
think.
A
A
I
Yeah
I
mean
the
original
proposal
I
think
came
up
because
we're
in
the
docs
we
were,
we
were
trying
to
give
it
a
generic
term
for
it,
and
we
actually
called
it
selection
constraints,
which
I
think
would
be
way
too
long
for
this
yeah.
Also,
I
wanted
to
ask:
was
there
ever
thought
weren't
there
originally
thoughts
of
gateways,
selecting
things
other
than
routes
like
is,
it
does
should
routes
even
appear
in
the
name
or
this
is
this?
Is
that
making
it
way
too?
Generic
for
this
purpose.
A
B
A
F
A
A
I
I
agree
that
if
it's,
if
it's
not,
if
there's
no
selector
inside
of
it,
I
I
I
am
very
hesitant
to
include
selector
in
the
name
of
the
field
yeah.
My
my
has
my
my
hunch
here
is
just
to
leave
this
as
is,
but
if
anyone
has
any
alternatives
or
wants
to
push
for
anything
else,
definitely
add
it
here
or
in
another
issue.
A
A
A
That's
my
understanding
right
now
of
the
current
state
of
review.
I
review
has
two
parts,
though,
of
course
there's
the
feedback
and
there's
the
actual
responding
to
that
feedback.
This
is
the
pr
that
has
the
latest
bit
of
feedback.
I
come
combined
with
harry.
I
think
we
respond
to
almost
everything
in
here
the
one
that
I
have
not
addressed
yet
is
this
the
one
that
we
just
talked
about
today,
which
is
back
in
status,
but
we're
we're
awfully
close
on
this
front?
I
think
I
look
back
to
the
previous
pr.
A
It's
absolutely
massive.
I
I
know
that
susan
has
one
pr
that
she's
working
on
that's,
I
think,
almost
like
probably
95
done
as
far
as
web
hook.
Validation,
there's
some
feedback
on
that
one.
I
think
that's
the
the
last
missing
piece
of
that
original
api
review
pr,
but
I
very
well
could
have
missed
something.
There's
there's
a
lot
of
comments
there.
A
D
That
that
covers
my
question
was
just
you
know
what
else
we
need
to
do
to
have
the
formal
part
done
so
that
we
can
be
like
okay,
we
tick
that
box.
Now,
all
we've
got
is
actually
close
out.
The
you
know
all
the
actions
that
we're
finishing
you
know.
So
we
can
then
put
all
of
the
stuff
that
we
need
to
finish
into
a
milestone
and
call
that
okay,
when
that's
done.
A
A
There
there,
the
discussion
around
whether
port
should
be
optional
or
not
ended
up
being
more
complicated
than
I
expected,
and
that
has
led
me
to
this
discussion
about
really
this
our
api
compatibility,
because
if
we
have
a
strong
story
for
how
we
can
make
a
field
optional
in
the
future,
it
doesn't
really
matter
if
we
make
port
optional
now,
but
if,
on
the
other
hand,
the
outcome
of
this
is
it's
a
real
pain
to
make
a
field
optional
in
the
future,
we
really
need
to
address
port
optionality
now
that
this
is.
This
is
my
perspective.
A
So
although
this
feels
a
little
tangential,
that's
kind
of
at
least
part
of
why
I've
been
digging
into
what
does
compatibility
look
like
what
what,
as
we
release
v1
alpha
2?
What
are
we
actually
committing
to
because
that
drives
some
of
our
other
decisions
around
this
release?
In
my
mind,
james
you've
got
a
hand.
E
A
This
is,
this
is
kind
of
all
going
back
to
that
skew
and
what
we
want
to
require
implementations
to
support
and
the
the
alternative
is
that
every
every
implementation
handles
you
know.
Any
required
field
has
a
an
empty
check,
a
nil
check,
whatever
it
is
for
that
type
and
can
handle
that,
which
is
also
not
great
so
that
that's,
I
think,.
A
D
G
But
then
it's
kind
of
a
problem
like
the
issue
is
that
the
only
reason
I
would
do
something
with
it
if
it's
zero
is
if
I
knew
that
it
was
optional
at
which
one
I
would
just
update
my
code.
But
the
problem
is
that
I
wrote
this
code
a
year
ago
and
now
the
specs
changed,
because
users
are
running
the
old
version.
So
I
can't
exactly,
I
think.
G
D
G
G
Like
almost
every
every
required
value
like,
if
you
get
an
object
that
you
don't
think
is
valid,
then
it's
you
would
treat
as
an
error,
even
if
it's
not
possible
to
get
that
through
crd
validation,
but
because
the
series
validation
can
change
in
the
future
right.
So
that's
a
zero
port,
maybe
a
protocol.
You
don't
understand
that
was
newly
added
something
like
that.
A
A
A
Okay,
now
that's
fine,
so
yeah.
My
my
original
question
here
was
about
rc2
timeline
and
what
seems
reasonable.
I
the
way
I
look
at
rc2
is
we're
so
close
to
v1
alpha
2
being
ready.
We
should
save
rc2
until
it
is
what
we
think
is
v1
alpha
2
right
like
there
should
be
next
to
zero
difference
between
rc2
and
our
final
v1.
Alpha
2
release.
In
my
mind,.
A
Yeah
that
that
could
be
that
we
had
a
view
we
had
an
rc2
before.
Why
not
have
another
one?
No,
that's
not
a
valid
answer.
I
my
concern
is
that
if
it
gives
us
one
more
chance
to
get
some
feedback
on
a
release
before
we
flip
that,
hopefully
identical
release
to
an
actual
api
version,
but
I
I'm
not
completely
convinced
it's
necessary
either.
So
I
yeah.
C
B
D
A
A
F
A
A
A
A
We'll
just
we'll
aim
for
that
and
we'll
see
what
happens
but
I'll,
try
and
just
throw
some
dates
on
milestone
and
actually
add
issue
well
add
prs
that
should
be
in
the
milestone
to
the
milestone:
yeah.
Okay,
that's
all
I
had.
Is
there
anything
else?
We
should
cover
real
quickly,
any
anyone
that
needs
a
pr
review
or
issue
discussed.