►
Description
Service APIs Bi-Weekly Meeting (APAC Friendly Time) 20210324
A
All
right
we're
recording
this
is
the
gateway
api
meeting
for
march
24th,
and
we
have
a
couple
things
to
get
through.
But
if
anything
wants
to
add
anything
to
the
agenda
feel
free.
The
first
thing
I
wanted
to
cover
is
yesterday.
I
finally
went
ahead
and
made
a
milestone
for
v0.3.0
in
previous
meetings.
A
Anyone
can
feel
free
to
correct
me
on
this,
but
I
think
it
makes
sense
to
go
ahead
and
add
whatever
we
want
to
do.
Do
this.
One
kind
of
last
additive
cleanup
release
get
a
few
things
out
of
the
way
before
we
start
shifting
towards
v1
alpha
2,
because
once
we
do,
I
want
to
make
sure
that
you
know
everything
we
do
is
focused
on
v1,
alpha
2
and
when
we
start
making
breaking
changes,
we
don't
have
to
also
be
focused
on
all
the
little
bits
of
v1
alpha.
A
One
cleanup
we
want
to
do
so
with
that.
I
added
a
whole
bunch
of
things
to
the
v0.3.0
milestone.
My
logic
here
was
really
kind
of
simple,
in
the
sense
that
anything
that
was
relatively
recent
or
useful
that
I
thought
was
purely
additive
things
that
additive
or
cleanup
improvements
in
some
way
can
fit
into
v0.3.0
in
from
my
perspective,
and
then
anything
that's
breaking
or
in
any
way
going
to
change
experience,
we
should
hold
off
to
lv1
alpha
2..
A
A
A
We
have
not
for
v1
alpha
2,
yet
yeah
yeah,
so
the
the
last
the
last
time
this
came
up.
The
idea
was
that
we'll
do
a
final
v1
alpha
1
release
that
would
be
v
0.3.0
and
then
we'll
shift
we'll
add
v1
alpha
2
to
the
main
branch,
and
at
that
point
we
can
also
start
finding
ways
to
differentiate
docs
between
v1,
alpha
2
and
v1
alpha
1..
Maybe
that
just
is
a
separate
directory.
We
freeze
docks
for
v1
alpha
1,
throw
it
in
a
separate.
A
B
A
Oh
yeah
for
sure,
yeah
and
and
the
scope
of
v0.3.0
is
anti-
is
still
entirely
v1
alpha
one,
so
anything
that
we
get
in
here,
especially
if
the
docs
changes
is
a
single
version,
and
you
know
it
targets
everything.
Once
we
release
v0.3.0,
we
we
have
to
start
thinking
about
where
doc
updates
apply
and
if
you
need
to
cherry
pick,
you
know
or
whatever
doc,
updates
back
to
a
v1
alpha
1
docs
site.
A
But
yeah
my
goal
here
and-
and
anyone
feel
free
to
correct
me
or
you
know,
say
we
should
do
something
else,
but
my
goal
here
is
to
really
try
and
get
as
much
as
we
possibly
can
into
the
api
in
the
next
month.
There
there
are
a
few
things
that
we've
kind
of
just
left
sitting
for
a
while,
and
I
think
it
would
be
good
to
have
some
kind
of
starting
point.
The
advantage
of
getting
this
interview
on
alpha
one
as
opposed
to
waiting
and
trying
to
throw
it
into
v1.
A
Alpha
two
is:
it
gives
us
a
little
bit
of
time,
not
a
ton,
but
it
gives
us
some
time
for
implementations
to
test
out
a
feature,
get
feedback
on
it,
and
if
we
determine
that
hey
this,
this
field,
this
configuration
this
way
we
design
the
api
doesn't
quite
make
sense.
We
have
that
short
window
to
make
a
change
to
what
whatever
we
added
here
in
v1
alpha
2..
So
I
I
think
the
the
idea
is.
A
We
should
try
and
get
something
like
in
for
a
lot
of
these
different
areas
and
then
leave
open
the
possibility
of
changing
or
improving.
In
v1,
alpha
2.,
but
that's
again
just
my
perspective
on
this.
Does
anyone
else
have
thoughts,
ideas
on
on
this
release
process?
Does
it
make
sense
to
try
and
shove
all
these
things
in
to
v1
alpha
2
at
v1,
alpha
1,
as
this
kind
of
intermediate
final
release.
A
A
Yeah
and
that
that's
part
of
this,
I
do
want
to
go
through
this
list
and
make
sure
what
we
have
in
here
makes
sense,
or
it
doesn't
make
sense.
We
can
bump
it
or
potentially
we're
missing
things
that
need
to
be
in
here
and
if
we're
missing
things
that
really
should
be
prioritized,
I
want
to
make
sure
that
those
are
accounted
for.
A
So
that's
what
I
wanted
to
spend
the
majority
of
the
meeting
on
is
just
here's.
What
I
think
could
fit
in
vo.3.0,
but
as
we
go
through
these,
if
there's
things
that
are
obviously
missing
or
things
that
just
don't
make
sense,
be
good
to
know
and
also,
if
you,
if
you
have
capacity
or
know
someone
who
does,
this
is
also
a
call
for
help,
because
we've
got
lots,
lots
and
lots
to
do
here.
So
if
you
have.
A
B
A
Yeah
well
actually
yeah
that,
yes,
I
I
mostly
agree
with
that.
But
yeah,
it's
it's
an
open-ended
dock
issue,
but
I
I
have
a
pretty
clear
idea
of
what
I
want
to
do
with
that,
so,
okay,
yeah,
yeah,
okay,
so
we'll
just
start
from
the
top.
This
is
one
that
this
again
is
not
a
critical
thing,
but
it's
one
that
john
pointed
out
that
I
didn't
even
I
didn't
even
realize
this
was
a
thing.
It's
very
cool.
A
I
have
a
pr
that
fixes
this
or
adds
this
it
allows.
If
you
add
a
category
to
your
crd,
you
can
coop
cuddle
get
gateway
api.
It's
the
category
that
I
chose.
I
will
return
all
resources
in
that
category,
so
you
can
see
if
you
apply
all
our
examples.
You've
got
udp
route,
gateway,
class
gateway,
tcp
route
and
http
route,
all
output
in
the
same
way,
which
feels
quite
handy
a
really
tiny
change,
but
seems
like
a
good
win
so
that
one's
already
on
its
way
category
and
age
columns.
A
A
We
don't
need
them
anymore,
they're,
just
they
do
an
extra
redirect
which
doesn't
help
anyone.
So
this
removes
all
those
references
again.
Just
reviews
on
these
would
be
really
handy.
I
think
they're
pretty
straightforward
damian.
This
is
your
pr
update,
docs
for
fields
of
type
local
object
reference,
it's
generally
good
to
go.
A
A
A
A
A
A
A
B
So
that's
why,
if
that's
extended,
I
think,
like
yeah,
we
should
clarify
this
in
the
docs.
In
my
mind,
implementation
specific
is
a
field
that
we
say
the
behavior
of
this
feature
this.
So
we
have
a
feature
which
could
be
an
extended,
for
example,
regex,
but
there
is
a
tiny
part
of
it.
That's
we're
just
saying
that
that's
going
to
be
implementation
specific,
but
if
you
support
it
aside
from
that
piece
of
it,
it
should
always
behave
the
same,
whereas
custom
is
like
we
say
nothing
about
it.
B
D
Yeah
and
keep
in
mind,
it's
really
important
to
note
this
is
implementation,
specific
meaning
if
you
use
it
today
and
it
works,
and
then
you
use
it
somewhere
else
and
it
works.
Maybe
maybe
it's
implemented,
but
it
will
have
something
different
behavior
on
this
other
implementation.
So
it's
critical
to
call
that
aspect
of
it
out.
B
Yeah
my
custom,
I
think,
is,
is
like
a
broader
thing.
That's
on
a
feature
basis,
so
the
distinction
would
be
because
we
don't
want
to
have,
for
example,
just
to
throw
out
at
regex
into
custom,
because
there
is
a
uniform
way
that
we're
going
to
do
it.
But
there
is
this
one
aspect
that
will,
you
know
require
a
little
bit
more
attention.
B
B
Now
the
core
must
be
fully
specified.
The
extended
also
must
be
fully
specified.
Actually
I
take
that
back.
That's.
I
think
I
find
the
implementation
specific
to
be
like
cross-cutting
across
stuff,
although
I
think
we
should,
as
a
general
rule,
make
or
not
have
implementation
specific
things.
So
basically,
we're
left
with
it's
extended,
which
means
that
you
have
a
choice
of
implementing
the
feature,
but
the
api
knobs
that
you
use
to
actuate.
B
It
are
portable
if
that
feature
is
supported,
and
then
within
that
there
may
be
some
situations
just
based
on
reality
that
we
can't
it's
still
a
very,
very
useful
feature.
But
you
know
there
are
some
pieces
of
that
surface
area
that
we
simply
just
can't
mandate
down
to
the
last
sort
of
precise
behavior,
in
which
case
we
can
use
implementation
specific
to
say,
hey.
I
know
that
this
is
not
perfect.
B
A
A
B
A
A
A
I
guess
is
the
way
to
say
it,
and
a
really
simple
change,
in
my
opinion,
is
just
to
make
the
structure
of
this
match
the
structure
of
our
navigation,
because,
right
now
you
you
know,
as
as
our
docs
grow.
This
is
just
going
to
become
more
and
more
unmaintainable,
and
so
sooner
than
later,
updating
the
structure
here
to
update
our
navigation
seems
like
it
would
be
a
good
win.
A
A
A
All
right
load,
balancer
source
ranges.
This
was
one
that
came
up
from
a
while
ago
and
it's,
I
think,
a
fairly
good
point
in
the
sense
that
I
again
I
don't
know
how.
Broadly
this
is
going
to
be
supported.
Maybe
this
has
to
be
an
extended
field,
but
this
is
something
that
we
could
really
copy
from
the
service
api
upstream
with
potentially
limited
changes,
and
it
does
seem
like
a
valuable
kind
of
config.
A
B
B
Yeah
we
should
evaluate
a
couple
external
traffic
policy,
low
balancer
source
ranges
and
see,
if
there's
some
more
organized
way
to
do
it.
We
probably
would
want
to
if
at
all
avoid
the
situation
where
we
we
simply
just
ended
up
with
like
everything
again
on
gateway,
and
then
it
became
kind
of
a
puzzle
to
understand.
A
B
Put
those
together
as
a
discussion
topic
to
figure
out
what
is
like
the
appropriate
way
to
treat
these
in
a
more
like
up
one
level
versus
one
at
a
time,
because
I
think
one
at
a
time
like
I
guess
you
could
add
it
it.
It
feels
like
like
each
addition
that
just
makes
it
more
and
more
complicated,
just
slowly.
A
Yeah
you're
right.
I
think
these
are
both
kind
of
not
high
priority
items,
but
we
do
need
to
have
a
compelling
answer
for
why
we
choose
to
port
things
from
service
api
up
these.
So
I
I
get
the
hesitation
I
get.
You
know
service.
The
the
service
resource
in
upstream
has
become
very
bloated,
but
one
could
argue
that
that's
it's
also
trying
to
do
a
lot
more
things
than
gateway
is
trying
to
do
at
least
the
gateway
resource,
so
maybe
but
but
yeah
this.
This
is
a
slippery
slope.
B
E
B
E
B
A
How
yeah,
yeah
and
and
the
other
side
of
this
is
we,
you
know,
I
guess
I
guess
it'd
be
helpful
to
run
through
some
issues
upstream
for
external
traffic
policy,
load,
balancer
source
ranges
and
see
if
there's
common
confusion.
If
there's
room
for
improvement
on
on
these
fields,
there's
feature
requests
related
to
them
that
you
know
the
current
structure
just
does
not
support,
but
I
you
know
I
don't.
I
don't
know
that
it's
worth
just
renaming
something
or
changing
it
slightly.
B
B
A
Yeah
that
makes
sense
the
next
one
I
have
in
here
is
a
relatively
old
one
yeah.
This
goes
back
back
in
time.
Two
two
digit
issue
number
add
timeouts
to
destination
connection
details.
This
was
at
least
partially
addressed
well
dating
you
have
a
an
open
pr
that
covers
some
form
of
timeout
and
retries.
A
I,
this
is
an
area
that
I
know
we've
kind
of
punted
for
a
while,
but
I'd
like
to
revisit
timeout
configuration
as
well
as
I
thought
I
had
retries
on
here.
Yeah
request,
retry.
I
guess
this
is
your
pr
that
I
added
in
here.
I
think
I
know
there's
a
lot
of
different
ways
to
configure
timeouts,
and
so
this
could
potentially
turn
into
bike
shedding.
Where
we're
just.
You
know
talking
about
every
different
way.
A
We
can
configure
this,
but
I
think
especially
because
we're
still
in
v1
alpha
one
it's
worth
trying
to
add
something.
It
doesn't
need
to
cover
every
possible
use
case,
but
if
we
have
something
like
as
a
starting
point,
I
think
that
will
help
so
yeah
this.
This
has
been
an
issue
for
a
long
time,
something
like
that.
We
knew
we
wanted
in
this
api.
We
just
need
to
take
some
time,
work
out
a
proposal
and
and
try
and
get
try
and
get
it
in.
A
All
right,
the
the
next
one
is
health
checking,
also
going
back
to
the
same
general
era
found
a
year
ago
and
also
agree
that
this
is
a
a
high
priority
item.
Health
check
behavior
is
partic
particularly
helpful
when
you
have
multiple
routes
pointing
to
the
same
service
like.
I
think
I
think
this
is
a
good
win.
I
am
interested
if
there's
anyone
who's,
also
really
wanting
to
push
on
health
check
or
or
has
strong
feelings
about
what
health
check
configuration
could
look
like.
We
have.
A
E
Here
we
have
some
of
this
in
contour,
you
know
where
you
can
define
active
health
checks
against
endpoints.
Look
at
the
question.
A
lot,
though,
is:
what
do
you
need
it
with
kubernetes,
because
you
could
do
the
internal
service
health
checks
that
way,
but
some
of
the
things
contour
was
used
for
in
the
past
was
for
non
kubernetes
endpoints.
So
that
was
why
we
kind
of
added
it.
You
know
the
health
check
like
vms
and
stuff
that
makes
sense.
A
Yeah
that
that
that
does
make
a
lot
of
sense
and
we
have
some
gk
specific
limitations
or
features.
I
guess
that
that
make
it
more
beneficial
to
have
custom
health
check
config
as
well,
so
so
yeah.
This
is
probably
not
something
that's
going
to
be
used
by
everyone
or
every
use
case,
but
I
think
it's
certainly
a
good
win
to
have
in
place
yeah.
Be
it
be
interesting
to
look
it's
good
to
know
that
contour
is
doing
some
custom
health
checking
as
well.
A
A
A
I
think
my
default
backend
idea
is
not
a
great
one,
but
maybe
just
the
back
end
ref
that
I
proposed
here.
We
we
discussed
this
in
a
meeting.
Probably
I
don't
know
a
couple
months
ago,
yeah
january,
I
think
it's
a
relatively
straightforward
idea,
but
I
just
I
want
to
revisit
this,
and
I
want
to
try
and
push
to
get
this
in
again.
A
My
my
goal
here
is
to
try
to
take
some
of
these
discussions
that
we've
kind
of
just
let
sit
for
a
while
and
revisit
them
and
push
to
get
something
again
in
the
next
month,
if
at
all
possible,
just
try
and
expand
out.
We
have.
We
we've
had
a
lot
of
good
ideas
that
have
kind
of
gotten
stuck
in
proposal
phase,
and
plenty
of
these
proposals
are
good.
That
just
haven't
turned
into
an
implementation
and
that's
really
what
I'm
trying
to
focus
on
and
prioritize
in
the
next
month.
A
If
someone
is
interested
in
volunteering
to
work
on
one
of
these
or
lead
the
development
just
assign
yourself
to
the
issue-
and
we
can
help
out
as
far
as
review
working
through
concepts,
ideas
whatever
but
it'd
be
great
to
great
to
see
some
new
contributors
here
and
existing
ones
to
just
take
on
some
of
these
individual
issues
and
then
the
last
one
query
param
matching.
I
think
this
is
one
that's
also
stuck
around
for
a
while.
There
does
seem
to
be
some
community
support
for
this.
A
A
A
B
A
A
We
have
all
these
little
details
that
we've
been
talking
about
for
a
while
that
we
just
have
not
added
implementations
for
so
we
have
this
opportunity
to
get
new
features
in
get
some
basic
feedback
and
still
potentially
break
or
break
that
initial
implementation
in
a
v1
alpha,
2
release
so
I'd.
You
know
I'd
like
to
take
this
opportunity
to
expand
the
capabilities
as
much
as
reasonably
possible,
but
I
I
absolutely
agree.
This
is
probably
larger
in
scope
than
we'll
be
able
to
accomplish,
but
let's
see
what
we
can
get.
A
In
all
right,
I
will
keep
on
moving
then
there's
a
few
pr's
to
run
through
and
some
issue
triage
as
well
yeah.
Let
me
let
me
hold
off
on
this
one.
This
is
one
that
I've
been
pretty
interested
in
for
a
while
and
we
spent
a
bunch
of
time
on
it
last
week.
So
I'll
come
back
to
it.
If
we
have
time
john,
you
raised
an
issue
that
I
think
deserves
some
broader
conversation
here:
route
status
when
multiple
controllers
are
involved.
A
F
So
if
I
see
that
there's
gateway
a
b
c
d,
but
I
only
know
about
a
and
b
I
have
no
way
of
knowing
if
I
should
be
cleaning
up
c
d
or
if
that's
because
someone
else
is
owning
c
d.
So,
like
you
mentioned,
we
need
something.
I
don't
know
what's
normal
for
this
on
things
that
have
kind
of
a
shared
status,
but
it
seems
like
we
need,
like
a
controller
reference
or
something,
I'm
not
sure
that
how
this
was
best
solved.
But
it
seems
like
right
now
it's
hard
to
implement.
A
B
A
A
F
A
F
F
B
So
the
the
thing
is,
you
probably
aren't
a
necessity,
use
a
finalizer
or
analyzer
equivalent
if
you're
keeping
the
state
somewhere
else,
because,
like
you're
a
bad
citizen,
I
guess,
if
you
just
kind
of
abandon
things
and
then
the
other
issue
that
this
would
bring
up,
is
that
who
is
responsible
for
deleting
the
orphan
ones
like?
How
do
you
know
that
you
should
delete
it
or
someone
else
should
delete
it
or
everyone
should
delete
it
and
then
that
it's
it's.
B
D
F
F
F
B
A
A
B
A
Yeah,
even
as
someone
let's,
let's
say,
someone
is
trying
to
manually
clean
up
and
they
say:
hey,
I
don't
have
this
controller
anymore.
Is
it
safe
to
remove
these
items
and
a
visual
check
says
yes,
this
these
two
gateways
were
tied
to
the
specific
controller
that
you
don't
have
anymore.
I
mean
this
is
this
is
a
real
edge
case,
I'll
say
that,
but
it
feels
like
it.
It's
a
very
minimal
edition
that
adds
some
potential
reliability
and
capability.
D
It
kind
of
seems
to
me
like
there
should
be
a
gateway
class
controller
that
cleans
up
any
gateway,
entries
and
routes
where
those
gateways
no
longer
exist,
and
if
an
implementation
does
need
to
do
cleanup
work,
then
it
can
add
a
finalizer.
Otherwise,
though
it
does
seem
like,
maybe
there
should
be
a
higher
level
control.
I.
F
Don't
think
we
can
assume
that
there's
any
one
person
that
can
read
all
the
gateways
and
do
such
a
high
level
cleanup,
at
least
for
us.
We
allow
like
multiple
config
sources.
You
know
multi-cluster,
you
know
file
configs,
so
it's
it
seems
tricky
to
expect
that
one
controller
can
see
everything,
especially
once
you
go
to
like
considerations,
etc.
B
B
A
A
So
one
of
the
things
we
we've
said
so
far
is
that
users
of
this
api
can
provide
or
implement
custom
route
types.
I
don't
think,
we've
explored
this.
I
don't
think
this
is
very
likely,
but
maybe
some
implementation
in
the
future
wants
to
implement
a
custom
gateway
type
that
would
be
very
difficult
to
support
by
some
generic
controller
cleaning.
Up
again,
I
hate
to
even
suggest
that
that
could
happen,
but
you
know
worst
case.
A
A
A
Conditions
for
back-end
policy-
this
is
another
one
that
came
up
relatively
recently.
Yeah
the
back-end
policy
is
difficult
and
we
have
not
had
a
good
this.
This
feels
related
to
what
you
were,
what
we
were
just
discussing
discussing
on
the
other
one,
that
if
we
want
to
have
meaningful
conditions
on
a
back
end
policy,
those
conditions
need
some
kind
of
ownership,
some
kind
of
clear
understanding
of
which
controller
dropped
that
condition
there
and
so
far
our
answer
has
been
well.
Instead
of
that,
just
put
your
conditions
on
the
route
or
gateway.
A
A
A
A
The
new
ones
this
week
are
actually,
I
think,
for
me,
this
is
a
really
annoying
one
mark's
feedback
that
we
really
should
have
gateways
bound
to
coupe.
Cuddle
output,
like
showing
in
coop
cuddle
output
for
routes
made
a
lot
of
sense
to
me,
but
it's
really
annoying
to
implement.
I
spent
some
time
I
worked
through
this
with
some
folks
from
api
machinery
to
make
sure
this
is
actually
truly
not
possible
any
other
way
and
unfortunately
it
looks
like
we
are
stuck
with
a
new
api
field.
A
But
yes,
I
tried
all
the
various
things,
but
if
you
dig
into
the
kubernetes
code
implementing
this
it
just
doesn't,
it
has
the
most
basic
implementation
of
matching
that
exists,
and
so
it
only
supports
the
most
basic
json
path,
implementation,
and
that
is
intentional
for
now,
but
anyways
yeah,
so
that
that's
that
issue.
I
would
appreciate
some
feedback
or
some
ideas
here.
A
F
A
There
are
a
few
things
it,
unfortunately,
the
additional
printer
columns-
implementation,
as
I
understand
it
actually
is
api-
is
driven
by
api
server
so
like
as
a
without
getting
too
far
into
this.
If
you
were
to
use
coupe
cuddle
and
specify
additional
columns
or
a
json
path,
advanced
json
paths
work
perfectly.
It's
this
specific
component,
which
is
the
additional
printer
columns,
that's
implemented
by
api
server.
A
That
has
the
much
stricter
limitations
on
what
it
will
send
back
and
so
kubecuttle
itself
has
support
for
lots
of
things,
but
unfortunately,
because
this
would
be
an
api
server
edition,
it
would
be
a
while
there's
one
pr
that
was
open
for
around
a
year
and
eventually
closed
because
it
rotted
that
somewhat
helped
here,
but
even
still
that
was
not
perfect,
so
yeah.
I.