►
Description
Service APIs Bi-Weekly Meeting (APAC Friendly Time) for 20211129
A
A
I
feel
like
those
are
going
to
be
pretty
common
dates
for
others
to
be
unavailable,
so
I'm
recommending
canceling
the
meetings
on
those
days.
I
don't
know
if
anyone
else
has
other
dates.
That
suggest
that
you
know
there
probably
won't
be
many
people.
Those
seem
like
the
most
obvious
ones
to
to
cancel
at
least
anyone
actually
planning
on
being
around
or
would
like
to
meet
on
either
of
those
days.
A
Cool
all
right,
I
I
will
take
silence
as
as
consensus
on
these
then
I'll
go
ahead
and
cancel
these
and
send
a
note
as
well
cool
all
right.
So
the
next
one
is
this
experimental,
crd
and
rewrite
pr
which
apologies.
This
is
absolutely
massive
in
scope,
but
thank
you.
Everyone
who's
taken
the
time
to
review
this.
A
A
A
A
I
is
that
it
would
replace
the
prefix
the
prefix
match,
with
whatever
was
in
the
substitution
and
the
substitution
default
value
was
an
empty
string,
so
by
default.
What
would
happen
is
if
you
had
replace
prefix
match
and
the
prefix
match
was
slash
foo.
That
would
get
replaced
with
nothing.
So
if
your
path
was
slash,
fubar,
it
would
just
be
modified
to
slash
bar
harry
pointed
out.
I
think
it's
a
good
point
is
that
that
may
not
feel
very
intuitive.
That
may
lead
to
surprises.
A
I
haven't
had
a
lot
of
time
to
think
about
it,
but
I
had
enough
time
to
think
to
think
that
I
realized
we
probably
needed
a
bit
more
discussion
on
this
one,
so
yeah.
This
is
just
throwing
this
out
there.
Does
anyone
have
a
an
opinion
on
on
what
we
should
do
here?
Do
you
like
the
idea
of
a
remove
prefix
match
alternative
here,
or
do
you
think
the
existing
replace
mechanics
are
sufficient
with
the
idea
that
replace
with
empty
string
is
effectively
removed?.
B
I
feel
like
replaced
with
empty
string
being
removed,
is
a
common
enough
pattern
in
general
search
and
replace
things
that
doesn't
feel
too
awkward.
In
that
sense,
I
think
harry
has
a
point
that
that
having
the
empty
value
be
meaningful
can
cause
problems
in
cube,
so
maybe
we
would
want
to
consider
do
we
do
we
care
about
the
distinction
between
empty
but
present
and
not
present
at
all
I'd
say
in
this
case?
A
B
I
mean
it
feels
like
it
feels
like
for
ux
you'd
want
to
have
the
distinction
between
set
and
unset
so
that,
if
you
just
don't
set
it
like
it's
weird,
but
if
you
make
a
mistake
and
you
you
know,
then
then
your
stuff
is
being
removed
and
that's
surprising,
like
you
actually
having
it,
that
you
actually
need
to
set
it
and
specifically
set
it
to
yeah
to
empty.
It
feels
like
more
natural,
but
it's
pretty
convoluted
and
at
that
point
it
feels
like.
Maybe
the
extra
type
is
probably
better.
A
Yeah,
I
hate
to
even
suggest
this,
but
it's
almost
like.
If,
if
we
could,
you
know
you
could
use
a
pointer
type
kind
of
thing
without
well,
yeah
pointer
type,
omit
empty
and
then
use
webhook
validation
to
ensure
that
the
value
is
actually
set
and
not
empty,
but
that
that
feels
like
a
real.
You
know
you're
really
stretching
the
bounds
of
this,
but.
C
Are
we
afraid
that
people,
because
it's
not
the
meaning,
is
unambiguous?
In
fact,
if
you
look
at
how
people
use
said,
like
people
do
this,
so
is
it
a
lot
of
because
adding
like
the
optional
type
and
then
now
you
have
like
what,
if
you
had
it,
but
you
optionally
specified
it
and
versus
yeah.
It
feels
like
we're
trying
to
protect
something
that
probably
doesn't
need
the
additional
complexity.
A
A
Obviously
this
is
something
that
made
it
through
the
gap
as
well,
as
is
so
it's
probably
not
too
far
out
there
as
it
is
yeah
I'll
run
with
that.
Okay
I'll
respond
in
here
I
if
anyone
else
wants
to
add
thoughts
too.
This
is
9
45.,
yeah.
Okay,
that's
the
only
thing
I
I'm
working
on
at
resolving
a
couple
more
comments.
I've
resolved
most
of
them
a
bit
earlier
this
afternoon,
but
hopefully
we
can
get
this
one
in
soon.
A
A
D
Sure
yeah,
so
I'm
wrapping
rapidly
typing
here.
So
this
is
not
nearly
complete
as
you'll
see
because
you
don't
have
to
go
very
far
down
to
hit
the
end
of
this,
but
I
wanted
to
start
getting
down
some
of
the
thoughts,
and
so
the
basic
approach
that
I'm
proposing
is
that
a
when
you've
got
a
route
for
say
an
http
route
when
you've
got
your
match
conditions,
and
so
you
say,
you've
got
a
back
end.
Ref
that
that
back
end
ref
could
optionally
be
stay
of
the
name
of
a
service.
D
D
D
D
D
So
you
know
like
an
http
parent
or
a
hp
child
route
and
avoid
the
limitation
of
trying
to
say
that
you
know
you
can
only
do
these
things
in
a
parent
or
only
do
these
things
in
a
child
and
trying
to
keep
relatively
in
think
between
the
two
types
of
you
know,
parent
and
child.
So
you
know,
could
you
how
do
you
if
you
got
like
smi
settings
like
you
know,
just
to
pick
something
you
know
match?
That's
nice
match
such
a
condition
in
a
parent
and
a
child.
D
E
C
Yeah
yeah,
I
do
like
that
exploring
that
avenue
because,
for
example,
kubernetes
federation
is
for
those
of
you
who
still
remember
it
was
an
attempt
to
basically
say
well.
Yeah,
like
the
federated
version,
is
just
the
same
right
and
then
it
turns
out
like
just
applying
that
sort
of
broad
brush
on
everything.
C
A
A
I
I've
really
described
this
as
either
route,
inclusion
or
delegation,
and
I
think
what
you're
describing
is
very
clearly
route
inclusion
and
that's,
or
at
least
what
I've
thought
of
as
route
inclusion,
and
that's
really
just
a
direct
reference
from
a
parent
route
to
a
child
route
and
the
the
delegation
side
might
be
that
a
parent
route
just
says.
I
trust
routes
in
this
name
space
to
attach
to
me
so
the
kind
of
the
loose,
looser
relationship
that
we
have
from
gateway
to
route
kind
of
thing.
A
A
D
B
B
If
say,
the
included
route
has
prefix
rewrites
and
I'm
doing
an
example
here.
How?
What?
How
do
you
make
sure
that
the
prefix
that
the
prefix
route,
the
included
route
rewrites,
matches
the
prefix
that
it
gets
from
the
given
the
fact
that
there's
like
a
prefix
that
you
might
have
a
prefix
rewrite
or
a
prefix
match,
coming
from
the
containing
the
parent
route?
B
B
The
delegation
case
is
more
useful
because,
as
rob
said,
it's
more
flexible
and
one
of
the
biggest
complaints
that
we
have
had
with
http
proxy
in
contour
is
that
it's
not
flexible
enough
that
you
have
to.
That
is
because
there's
a
one-to-one
relationship
between
the
the
parent
and
the
child
and
it's
a
named
relationship.
You
can't
like
there's.
No,
you
can't
sort
of
have
things
sort
of
magically
work
and
that's
one
of
the
things
that
people
definitely
want
about.
That
sort
of
thing
is
some
level
of
magic.
B
How
much
is
the
level
of
magic?
That's
the
really
hard
part
to
define,
but
like
we
need
to
have
something
in
here
that
available
in
the
in
the
eventual
api.
I'm
not
saying
I'm
not
saying
this
isn't
a
good
place
to
start
necessarily,
I'm
saying
we
need
to
have
something
available
in
the
eventual
api
that
handles
the
sort
of
the
self-serve.
B
We
do
that
already
with
the
gateway
with
the
gateway
thing,
but
but
people
want
to
be
able
to
do
that
with
the
route
thing
as
well,
so
that
you
can
say
you,
I
don't
care
about
the
fgn,
but
you
I'll
mount
this
under
whatever
fqdn
I've
got,
but
here's
the
prefix
that
I
want
to
match,
or
something
like
that.
There's
a
few
other
cases
there
as
well.
D
D
So
you
could
have
the
the
ability
to
you
wouldn't
have
to
as
the
owner
of
the
parent
route.
You
wouldn't
necessarily
have
to
define
the
name
of
a
specific
child
route,
but
you
could
delegate
it
to
a
namespace
and
that
that
name
space
a
route
in
that
name
space
would
specify
you
know
its
parent
ref
would
point
to
this.
This
parent
route.
A
A
I
now
I
think
I
may
have
misunderstood
the
other
part
of
what
you're
saying
there,
but
I
think
what
you're
saying
is
the
back
end.
Ref
would
basically
it
could
leave
a
name
off
is
what
you're
saying
so
instead
of
including
a
specific
route
by
name
it
could
just
the
name
would
be
optional
right
and
if
the
name
is
unspecified,
then
what
you're
doing
is
you're
looking
at
the
parent
refs
of
routes
in
that
namespace
and
any
any
route
in
that
namespace.
D
Paste
it
in
right
there
at
the
bottom,
so
this
is
a
direct
cut
and
paste
from
one
of
our
pages
on
our
website,
our
meaning,
the
the
gateway
api
website
and
see
here
how
we're
you
know,
we're
listeners
we're
doing
allowed
routes.
You
know
name
spaces
from
inflector
batch
labels.
I
was
thinking
of
basically
doing
the
same
kind
of
thing
under
the
back
end
ref.
D
A
Okay,
I
see-
I
I
think
you
know
from
my
perspective.
If
we
get
into
this
level
of
complexity,
I
think
what
we're
I
think
we're
talking
about
something
that
is
no
longer
a
back
end
rest
and
I
think
that's
fine,
but
I
think
it
may
it
may
justify
its
own
struct.
Basically,
it's
you
know
it's
basically
an
allowed
route
struck
instead
of
a
back
end,
rest
truck
or
a
delegate
routes,
or
you
know
some
other
kind
of
struct
like
thing.
B
It
feels
like
we
could
almost
lift
the
use,
the
exact
same
struct,
because
it's
going
to
be
doing
exactly
the
same
thing
yeah,
and
I
think
that
that
that
feels
like
a
really
great,
like
isomorphism,
in
the
api
that
that,
if
your
your
gateways
can
allow
routes
to
attach
them,
but
routes
can
allow
routes
to
attach
them
as
well,
yeah
and
yeah.
And
then
and
you
use
exactly
the
same
mechanism
to
do
both
of
those
things.
B
B
The
thing
that
I
think
we
just
need
to
be
careful
about
here
is
that
is
that
is
that
then,
as
part
of
that,
if
we
should,
if
we
choose
to
do
that,
we
we
have
to
be
very
specific
in
defining
what
the
parent-child
relationship
means
and
what
happens
to
the
matches
and
filter
chains
and
stuff
like
that.
Like
and
that's,
I
think,
that's
the
that's
one
of
the
important
things
that
we
found
in
http
proxy
is,
I
mean
we
hdp
proxy
was
a
was
a
like
a
second
stage
design.
B
You
know
it
was
a
reaction
to
we
designed
an
ingress
route
object.
That
was
like
a
itself.
A
reaction
to
ingress
and
one
of
the
things
that
we
did
in
ingress
route
was
that
when
you
do
the
the
parent-child
relationship
you
didn't
have
to
you
the
the
match
criteria
for
the
for
the
routes
didn't
propagate
down
to
the
children.
B
What
that
means
is
that
the
children
need
to
know
where
they
will
be
mounted
in
the
in
the
parent
and
they
need
to
know
like
the
prefix
is
the
best
example
here
you
you
can't
say
you
know
I
want
to
take
all
routes
from
namespace
blog
and
put
them
under
the
prefix
blog
you
you.
What
you
have
to
do
in
that
case
is
you
can
say?
Oh,
I
allow
all
rights
from
routes
from
name
says
blog,
but
then
you
have
to
tell
the
people
in
namespace
blog.
D
D
A
Yeah,
no,
no,
and
and
thanks
for
thanks
for
getting
this
in,
it's
good
to
just
even
get
the
discussion
rolling
here.
I
think
that
the
thing
that's
been
telling
to
me-
and
this
you
know
brief
discussion
we've
had
so
far-
is
that
it
seems
like
there's
pretty
broad
support
for
the
basically
supporting
the
more
complex
option,
which
is
route
delegation
instead
of
just
route
inclusion
right,
and
that
that's
been
helpful
to
hear.
B
I
I
think,
we'll
just
need
to
be
a
question.
Yeah
yeah,
it's
kind
of
been
only
a
few
of
us
talking.
I
would
like
to
throw
the
floor
open
before
we
go
too
far
in
that
to
say
everyone
else,
who's
listening
here,
you
you're
all
a
lot
of
you
are
implementers,
or
does
anyone
have
thoughts
about
you?
The
idea
of
doing
this
delegation
idea
versus
doing
the
inclusion
idea,
the
more
flexible
option.
D
Routes
as
the
the
child
object,
if
you
will
so
that
you
know,
you
know
an
app
team
can
own
their
route
and-
and
you
know,
make
what
you
know
if
they
need
to
change
headers,
because
they
need
to,
you
know,
insert
a
label
for
canary
testing
or
you
know,
blue
green
or
whatever.
They
could
do
that
without
having
to
involve
the
higher
level
admin.
B
A
Yeah,
that's
a
really
good
distinction.
I
would
there's
I
I
I
know
you.
I
know
you
say
that
pretty
clearly
that
route
can
be
a
parent
or
child
or
but
not
both.
But
one
weird
thing
is
for
that
route
in
the
middle
of
a
parent
route,
because
we're
using
parent
refs
that
parent
route
is
still
going
to
be
the
child
of
a
gateway
which
all
makes
sense,
but
we'll
just
have
to
be
like
super
clear
in
in
our
documentation
or
whatever
that
you
can.
D
D
D
B
B
Yeah,
so
I
guess
yeah
again,
this
is
one
of
those
things
where
doing
that
then
means
that
you
can't
have
the
same
child
route
mounted
in
multiple
places
in
under
multiple
conditions
in
the
parent
route.
This
is
what
I
mean
by
this:
to
get
stuff
get
so
fiddly
so
fast,
because
you've
got
to
make
a
lot
of
decisions
very
quickly.
That
then
have
big
flow-on
effects.
B
E
B
A
Yeah,
so
I
wanted
to
pull
this
up
just
so
we're
all
looking
at
the
same
thing
here,
but
the
parent
ref
that
we
have
right
now
on
routes
that
so
far
as
far
as
I
know
only
points
at
gateways.
It
has
everything.
You'd
expect
it's
group
kind,
namespace
and
name,
but
it
also
has
section,
and
that
section
name
is
for
saying
I
want
to
attach
to
this
specific
listener,
so
listener
80.,
I'm
sorry
listener,
you
know
http
or
whatever
the
listener
name
is.
A
I
don't
know
what
I
am
curious
about
is
if
we
need
a
similar
concept
here.
If
there
is
a
route
that
has
say
five
rules
and
you
want
to
attach
to
just
one
of
those,
do
you
need
like
a
should?
We
add
an
entry,
basically
right
here
that
says
route
rule
me
or
yeah.
You
know
that
that's,
and
this
is
probably
getting
too
far
into
the
details,
but
I'm
just
because
routes
have
rules,
and
you
kind
of
have
that
you
know
set
of
multiple
places
you
could
potentially
attach
to.
A
D
A
Now
that
that's
a
good
point,
I
think
it's
good
for
me
to
understand
or
be
helpful
for
me
to
understand
the
common
delegation
use
case
here.
So
my
when
I
think
of
delegation
for
routes,
what
I
think
of
is,
I
want
to
delegate
every
example:
every
request
to
example.com
slash
foo
to
the
foo
namespace
right
and
the
way
I
want
to
do
that
is.
A
If
that
same,
I
guess
well,
let
me
stop
there
and
say:
does:
does
the
route
in
the
food
namespace
need
to
be
aware
of
that
slash
food
prefix,
or
could
it
just
route
regardless
of
prefix
like?
Could
it
would
it
route
on
slash
bar
and
then
the
like
are?
Are
those
prefixes
kind
of
joined
together
or
does
the
route
and
the
food
name
space
need
to
be
aware
of
the
parent
route.
E
E
D
Know
flash
food
slash
bar
you
just
take
off
the
slash
food.
So
if
another
route
is
referencing,
you
know
another
parent
route
is
referencing
that
same
child
route,
but
it's
you
know
slash
mu,
slash
bar
right.
You
know
you
can
do
it
there.
If,
if
you
want
to
do
the
rewriting
at
the
child
route,
you
could
do
it
there
too,
or
instead.
B
A
That's
that's
an
interesting
point,
and
this
is
I
this
comes
right
back
to,
I
think
a
point
nick
had
had
added
earlier
right.
I
think
nikki
had
mentioned
that
you
have
to
be
very
careful
about
what
you
allow
at
multiple
levels
you
know
like
for,
for
example,
you
you
specifically
mentioned
rewriting,
and
I
think
at
least
some
proxy
implementations
are
going
to
be
unable
to
basically
add
a
level
of
rewriting
before
a
level
of
route
be
before
a
secondary
level
of
routing.
Basically
right
like
for
some
implementations.
A
D
Yeah
you'd
have
to
create
your
rules
for
the
for
the
the
proxy
itself.
In
a
way
that
would
you
know,
you'd
have
to
translate
them
from
the
the
parent
and
child
configs
into
a
uniform
config
that
would
handle
the
traffic.
You
know
in
a
single
pass,
yeah
yeah
so
without
question.
This
is
this
model
puts
the
burden
on
the
implementer.
B
Yeah,
I
think
what
I
was
trying
to
say
before
is
that
it
also
puts
the
I
like
this
model
to
be
clear
yeah.
There
is
a
lot
of
work
that
we
will
need
to
do
be
very
specific
about
the
expected
behavior
of
the
api
and
say
that
you,
for
example,
that
maybe
we
want
to
say
you
filters
from
the
parent
and
filters
from
the
child
both
run.
If
the
filters
are
incompatible,
then
the
route
can
be
rejected
or
something
like
that
right,
yeah.
B
I
feel
like
what
we
need
to
do
for
this
is
like
you've
got
the
sort
of
the
base
proposal
here.
Jeff
and
I
think
what
we
need
to
do
is
do
the
base
proposal
and
then
we
need
to
sit
down
with
like
and
be
like.
Here's,
here's
seven
use
cases
or
something
like
that,
like
you're,
doing
a
you're
doing
a
delegated
route,
here's
how
here's,
how
path
rewrite,
can
work?
Here's,
how
adding
headers
here's?
How
header
manipulation
can
work
yeah
and
just
a
few
of
the
different
filtering
options?
B
B
I
think,
having
like
a
bunch
of
a
set
of
like
standard
use
cases
that
we
figure
out
how
to
do
in
each
thing
that
we
talk
about
proposing
and
that
way
you
can
understand
what
the
trade-offs
are
in
under
each
of
those
use
cases,
and
then,
ideally,
you
know
those
use.
Cases
become
test
later
later
on
down
the
track
right.
But
but
those
are
the
use
cases
that
we
use
to
define
how
the
api
fits
together
now
and
that
way
we
can
have
everyone
sort
of
make
sure
that
we
haven't
missed
some
use
cases.
B
I
know
that
there
are
people
with
hp
proxy
who
wanted
to
be
able
to
do
stuff,
like
the
child
route,
contains
the
tls
details
like
which
is
weird
right
like,
but
that's
something
that
people
absolutely
the
people
want
to
be
able
to.
Have
it,
be
that
there's
some
way
for
you
to
supply
the
tls
detail,
all
the
way
back
up
to
the
gateway
and
yeah
people
definitely
want
a
way
to
do
that.
People
want
that
to
be
able
to
do
magic
right,
and
so
we,
you
know,
that's.
D
So
I'll
put
in
in
this
document
I'll
write
up
a
number
of
the
different
use
cases
that
we've
talked
about,
which
you
know
I'm
familiar
with
as
well
and
finish
fleshing
out
the
the
you
know
what
the
proposal
is
and
hopefully
next
week,
if,
if
we
don't
have
anything
else
more
pressing,
we
can
go
over
this
in
in
more
detail
I'll
try
to
get
this.
Let
me
let
my
schedule
here
real
quick.
D
A
B
As
well,
jeff
offers
on
the
table
as
well.
If
you
want
to
do
a
like
a
sidebar,
a
sidebar
zoom,
or
something
like
that
as
you're
writing
to
talk
about
this
stuff,
as
you
as
you
can
no
doubt
tell
like.
I've
also
spent
a
lot
of
time.
Thinking
about
this.
So
if
you
want
to
shortcut
some
rounds
of
feedback
with
a
with
with
a
pairing
or
something
like
that
over
the
document,
then
100
fine
on
that.
D
F
A
A
If
I've
missed
anything
recent
that
we
need
to
discuss-
and
I
think
the
story
is
very
similar
for
pull
requests,
the
one
thing
that
I
think
charisma,
you're
working
on
this
filter
type
consistency-
I
haven't
looked
too
recently,
but
I
know
there
were
some
comments
still
to
be
resolved,
but
it
looks
awfully
close
yep
cool
and
this
one
yeah
we've
already
covered
this
and
shane
you've
got
the
l4
traffic
matching.
I
know
you've
you've
been
out
for
a
bit,
but
I
think
this
is
still
moving.