►
Description
Service APIs Bi-Weekly Meeting (APAC Friendly Time) For 20210414
A
B
Yeah,
I
know
we
went
through
this
process
with
previous
releases,
especially
trying
to
get
v1.
Alpha
went
out
the
door
of
just
saying
all
right,
let's,
let's
set
a
specific
time
and
then
start
going
through
the
milestone
issues
and
tagging
kind
of
prioritizing,
and
the
reason
for
that
is
we
in
the
contour
community,
as
you
know,
been
on
the
implementation
journey
and
we've
been
using
zero,
two
zero
and
kinda
at
the
point
where
it's
like.
A
A
A
Yeah,
that's
a
great
goal
as
well
and-
and
I
should
say
like
my
idea
with
this
release-
is
really
to
try
one
to
clean
up
a
few
more
things.
Whatever
we
whatever
is
possible
to
clean
up
before
we
start
working
towards
v1,
alpha
2,
but
also
to
potentially
add
a
few
more
features.
Well,
we
can
still
experiment
in
v
v1
alpha
1,
because
we
can
still
add
things
here
and
potentially
change
them
in
v1,
alpha
2.
But
this
gives
us
a
little
bit
of
a
window
to
experiment
with,
say
something
like
timeouts.
A
B
A
Great
all
right,
so
this
one,
let's,
let's
start
at
the
top
this
is,
I
have
a
follow-up
for
this
later
on,
but
maybe
I'll
just
skip
ahead
to
it.
This
is
a
nice
to
have
in
my
mind,
this
is
a
way
to
dramatically
improve
ux
by
providing
some
kind
of
insight
or
visibility
here
this
this
overlaps
a
lot
with
the
concept
of
either
fixing
this
upstream
or
adding
some
kind
of
cube,
cuddle
plug-in,
either
of
which
are
valid,
and
I
wanted
to
I'll
just
briefly
skip
ahead
here.
A
A
The
really
annoying
problem
with
this
is
that
this
is
implemented
by
api
server,
not
a
cube
cuddle,
so
it's
not
like
you
can
tell
your
users
well
I'll,
just
use!
You
know
the
latest
coupe
cuddle,
because
that's
not
going
to
solve
it.
You
really
need
the
latest
version
of
kubernetes,
which
is
going
to
be
a
hard
sell.
A
So
I
I
do
want
to
make
this
fix
it's
going
to
make
life
easier
for
crds
for
years
to
come,
but
unfortunately
it
doesn't
solve
our
short-term
issue
here.
So
these
are
related,
but
this
is
not
a
complete
solution
for
this
yeah,
so
I
I
think
this
is
still
a
nice
to
have,
but
I'm
interested
in
others
feedback
here.
C
Yeah,
I
think
the
I
mean
yeah.
This
is
one
of
the
things
that
came
up
when
I
was
going
through
the
status,
the
status
user
journeys
thing
that
I
had
up
next,
that
yeah
having
something
like
this
would
be
good.
I
think,
in
the
absence
of
we
could
possibly
look
at
doing
a
plug-in
as
well.
Maybe
that
would
be
a
good
way
to
give
something
to
people
easier,
that
I
agree
that
we
should
try
and
push
this
upstream,
but
maybe
a
plug-in
might
be
quicker
in
the
short
term.
A
C
A
But
yeah
yeah,
I
know
I
I
absolutely
agree.
I
think
this.
I
think
we
could
build
some
really
cool
stuff
around
this
I
mean
my
my
head
kept
on
going
a
bit
past
them
thinking.
Well,
you
know.
If
I
really
want
this,
I
want
some
kind
of
like
graph.
You
know
some
kind
of
tree
diagram
to
show
the
relationships
here
and
but
you
know
you
can
only
go
so
far,
but
I
agree
there's
a
lot
of
a
lot
of
room
for
some
powerful
visualizations.
A
C
D
A
So,
just
to
maybe
ask
some
of
the
others
here:
how
do
we
feel
about
a
bring
a
plug-in
into
a
coop
cuddle
plug-in
into
the
scope
of
this
project?
Like
obviously
any
one
of
us
could
build
our
own
unofficial,
cube,
cuddle,
plug-in
and
just
say
hey.
This
is
a
thing
you
can
use
and
there's
not
really
any
kind
of
long-term
support
guarantees
with
that
or
we
could
try
and
bring
this
in
scope
for
this
project
and
make
it
kind
of
a
core
idea
of
how
you
interact
with
these
apis.
E
I
worry
about
the
user
penetration
of
something
like
that.
Like
I,
I
use
one
or
two
coupe
cuddle
plug-ins.
I
should
use
more,
but
I'm
just
too
lazy
to
go,
look
them
up
or
install
them
or
my
you
know.
Security
systems
on
my
machine
make
it
hard
to
download
new
plugins,
like.
I
think
that
you
just
get
not
that
high
of
a
penetration
amongst
users,
like
maybe
like
how
many
do
you
think,
will
hit
of
the
average
gateway
user
like
10
percent
five.
You
know
25
like
at
that
point.
E
I
don't
know
if
it
starts
to
become
worth
it.
I
think
if
we
see
a
bunch
more
of
these
workflows,
where
it's
like,
we
wanna
display
some
status,
that's
very
important
that
we
cannot
do
otherwise,
then
I
think
it
becomes
more
relevant,
but
I'm
not
sure
if
we
have
enough
of
these
yet
to
really
warrant
trying
to
support.
But
that's
my
opinion
happy
to
see
if
anyone
else
feels
differently.
B
I
agree
with
you
mark
and
I'd
also
say
like
I
know,
because
I'm
so
heads
down
in
the
implementation
side
of
things.
I
I
just
don't
have
the
same
bandwidth
that
that
I
did
before
the
implementation.
So
you
know
and
then
near
term.
It
would
be
it's
tough,
because
a
lot
of
the
folks
on
the
call
are
handling
the
implementation
side
to
add
even
more
to
the
scope
of
what
the
project
consists
of.
C
Yeah,
even
as
someone
who
supports
the
idea
of
just
having
a
plugin,
it
feels
like
it
feels
like
one
of
us.
Just
you
know,
making
a
making
something
quickly
now
would
be
a
better
sort
of
proof
of
concept,
and
then
we
talk,
and
then
we
decide
later
on
how
useful
it
is
and
whether
it's
worth
bringing
in.
A
Yeah,
I
agree
with
that.
I
think
this
is
a
a
great
starting
point
where
someone
anyone
who
who
feels
like
building
a
plug-in
for
this
can
and-
and
I
think
that
could
improve
experience
a
lot
and
if
it
does,
we
can
talk
about
pulling
it
into
the
scope
of
this.
But
yeah
like
like
people
are
saying
you
know
we're.
We've
got
a
lot
going
on,
but
I
think
this
is
going
to
come
back
up
pretty
quickly
with
what
you
mentioned,
nick
your
dock,
that
we'll
get
it
to.
A
I
think
the
next
item
shows
a
lot
of
the
limitations
right
now
of
the
ux
of
using
gateway,
so
so
this
will
return,
but
to
just
to
make
sure
we
don't
spend
all
our
time
on
this
one.
Let
me
just
how
do
we
want
to
prioritize
these?
Last
time
we
used
the
priority
labels
and
we,
I
think
this
is
going
to
be
an
important
long
term.
I
think
that's
what
we'll
call
a
nice
to
have.
A
A
A
A
A
A
F
B
A
It
is
okay,
it
is
yeah
and-
and
my
idea
now
is
to
maybe
we
can
try
and
fill
out
back-end
policy
a
little
bit
even
with
the
idea
that
it
could
shift
to
service
policy
or
something
that
can
be
tied
to
different
levels
of
the
stack.
But
if
we
have
the
idea
of
a
resource
that
can
be
attached
to
route
or
back
end
as
an
example,
then
that
feels
like
an
appropriate
place
for
that
and
so
and
I
don't
want
to
go
too
off
track
here.
A
D
A
Yeah
my
my
take
on
this
is
long
term
means
it's
nice
to
have
an
o3o,
but
does
not
matter
at
all.
If
it
gets
in
soon
is
something
like
we
should
prioritize
and
try
to
get
in
for
o3o,
but
if
it
doesn't
work,
okay
and
critical
urgent
is
something
like
we
should
block
0301
if
we
don't
get
it
in
yeah
great
cool
health
check
per
service.
A
I
also
have
a
follow-up
coming
for
this.
It
looks
like
there's.
This
feels
like
a
relatively
portable
feature
and
we'll
get
into
that
later,
but
this
this
feels
very
similar
in
concept
to
timeout.
It's
a
nice
to
have
I
I
guess:
timeout
is
potentially
more
portable
than
this,
but
we'll
get
there
later.
But
to
me
this
is
somewhere
between
soon
and
long
term.
Anyone
feel
like
being
a
tie,
breaker
pushing
it
one
direction
or
the
other.
B
E
E
So
I
I
do
think
this
is
important
and
soon
and
and
the
service
policy
like
there's
it's
such
a
big
topic
and
it
can
go
so
many
ways
and
and
nick
I
really
appreciate
your
feedback
so
far
on
it.
I
don't
know
how
long
that
will
take
to
close.
To
be
honest,
so
I'm
just
worried
about
blocking
on
service
policy
for
too
long
while
we
try
to
figure
that
out
and
then
blocking
features
that
I
think
are
probably
important
in
the
short
term.
C
D
C
To
v1
alpha
2.
we're
better
off
just
cutting,
even
if
it's,
even
if
it's
not
a
full
cid,
but
just
like
some
extra
structs
or
something
like
that
to
be
like
we're
going
to
have.
We
have
a
structure
you
reuse
at
different
places,
that's
better
than
than
jumping
through
the
you
know
head.
Let's
make
a
whole
extra
cr.
I
say
a
d
thing.
If
you
just
have
the
same
struct,
then
it's
pretty
easy
to
change
that
into
a
crd
later.
B
B
We
intend
on
doing
that
and
so
yeah
it
would
be
nice
to
have
these
features
the
last
one,
the
connection
timeouts
and
the
health
checking
in
and
when
we've
discussed
service
policy,
it
almost
seems
like
it
could
be
an
iteration
of
the
back
end
policy,
so
maybe
moving
forward
with
the
timeouts
and
the
health
checking.
It
would
make
sense
to
move
forward
with
adding
this
functionality
to
the
back
end
policy.
B
C
Yep
we
have
a
little
bit
of
prior
in
contour
as
well,
because
in
http
proxy
we
have.
We
have
a
very
a
set
of
different
policy
objects
that
have
that
control
settings
like
this,
so
we
actually
have
a
timeout
policy,
a
load,
balancer
policy
yeah.
These
are
all
structs,
not
full
objects,
and
so-
and
they
there's
a
few
cases
in
which
we
use
those
trucks
at
different
points
in
the
in
the
cid
crd
hierarchy.
A
A
A
F
B
Few
days
old
right,
you
know
right
we've,
this
kind
of
goes
back
to
back
in
policy.
What
I
could
potentially
do
here
or
harry,
if
you
want
to
jump
in
you
know
to
nick's
point,
is:
do
we
have
a
retry
policy
struct
within
the
back
end
policy,
where
we
can
go
ahead
and
expose
different
retry
attributes.
D
A
I
agree
with
all
that,
and
I
I
spend
some
time
looking
at
the
portability
of
these
different
features,
like
what
implementations
actually
support
these
concepts
and
of
what
I
found.
Health
checks
and
reit
and
timeouts
seem
to
at
least
a
generic
request.
Timeout
seemed
to
be
the
most
broadly
supported
and
the
request
retry
seemed
to
be
slightly
less
supported
across
implementations,
so
that
would
lead
me
to
prioritize
prioritize
this
a
little
bit
below
the
other
two,
but
I
agree
that
it
fits
in
and
is
related
very
closely
to
the
other
ones.
C
C
I
was
just
gonna
say:
yeah
100,
agree
about
with
your
so
now
hurry
about
timeouts
having
edge
cases.
I
know
that
when
I
first
started
trying
to
understand
the
envoy
timeouts
it
was,
it
did
not
work
how
I
expect
so.
I
think
when
we
do
the
timeouts,
you
need
to
be
really
careful
about
defining
what
each
timeout
is.
Sorry,
that's
a
bit
of
a
tangent.
A
A
F
A
A
A
A
A
Okay,
yes,
this
could
be
good
to
get
in
so
the
the
idea
that
it
can
be
hard
to
clean
up
after
yourself,
if
you
don't
have
some
additional
information
about
what
controller
put
a
gateway
in
in
status
to
begin
with,
and
so
adding
controller
name
to
that
reference.
This.
This
feels
really
small
in
scope
and
could
potentially
help
implementations
work
play
nicely
together.
A
A
B
A
Yeah
I
figured
I
I
don't
want
to
be
too
optimistic.
I
thought
about
that
as
well
and
if
we
get
to
that
point,
that's
great,
but
I
like
the
idea
of
having
one
last
community
meeting
where
we
can
just
pick
through
the
last
little
bits
of
issues
for
the
release
and
then
have
a
day
to
you
know
get
those
in.
It
gives
us
just
that
last
little
bit
of
wiggle
room.
B
A
A
All
right:
well,
we
can.
We
can
come
back
to
that,
but
yeah
leave
it
open
any.
I
think
anyone
who's
listed
in
the
owner's
file
is
welcome
to
take
this
release
on,
but
I
think
you
do
need
to
have
that
level
of
access
to
release
cool
all
right,
nick,
take
it
away.
This
was
a
great
doc.
I
read
through
all
of
it
and
had
more
thoughts.
I
didn't
get
turned
into
comments
yet,
but
maybe
if
you
want
to
run
through
some
of
the
highlights
here,.
C
Yeah,
so
the
reason
I
wrote
this
was
that
I
was
starting
to
do
some
stuff
with
figuring
out
how
what
what
status
updates
contour
would
be
doing
on
routes,
and
I
just
got
like
oh
there's
only
the
admitted
condition
right
now,
there's
a
lot
of
information
on
listener.
I
was
like
well
how
would
actually
that
that
would
even
work
if
you're
the
different
personas
like
what
does
it
look
like
to
actually
consume
the
status
of
this,
and
then
I
realized
that
no
one
had
done
that.
C
C
That's
supposed
to
be
relevant
to
me,
I
think
in
the
current
rbc
and
roles
design,
it's
made
pretty
clear
that
the
that
anybody
who
uses
this
api
should
have
read
access
to
to
everything
to
all
the
different
types
of
object.
You,
and
so
that's
kind
of
you
know
it's
not
that
you
can't
look
at
the
objects
it's
like.
C
C
I
think
the
first
one
that
you
commented
on
rob
it
was
important,
but
I
think
we
have
an
answer
there
now
that
I
think
well,
you-
and
I
agreed
at
least
that
we
should
recommend
that
when
you,
when
you
are
installing
a
controller
it
should,
it
should
come
with
the
ammos
or
install
a
gateway
class
for
you
that
you
that
describes
gateways
that
it
will
set
up
for
you.
There
should
be
something
that
indicates
you
should
you
it
should
be
included,
or
at
least
have
directions
and
so
yeah.
C
So
I'm
not
sure
how
deep
you
want
me
to
go.
I
don't
want
to
go
through
every
question.
I'd
encourage
everyone
to
have
a
read
of
this,
but
like
one
of
the
big,
the
the
two,
a
couple
of
really
big
things
that
I
thought
are
is
really
important
is
that
there
should
be.
I
think
the
thing
that's
really
important
is
that
we
address
some
way
for
the
controller
that
is
implementing
a
gateway
class
should
have
a
way
to
say
here's
the
things
I
support.
C
I
think
it
should
probably
be
on
the
gateway
class.
I
think
mark
you
opened
an
issue
about
this.
I
think
that
there's
another
comment
about
that
on
there
this
and
there
should
be
a
couple.
There
was
a
couple
of
other
sort
of
extra
bits
of
info
that
came
up
and
then
the
second
one
that's
further
down
is
that
yeah.
I
think
we
need
a
little
bit
more
info
on
routes
like
in
the
status
on
routes,
but
mark
did
you
wanna
jump
in.
E
I
was
I
I
there's
so
many
like,
so
I'm
going
through
right
now
in
terms
of
like
our
cloud
load
balancers
and
what
they
support
in
the
gateway
classes,
and
so
we
we
end
up
having
basically
like
a
spreadsheet,
that
is,
the
gateway
api
spec
within
each
every
cell
is
kind
of
like
do
we
support
it
if
we
do
support
it?
What
like?
What
do
we
support
like,
for
instance,
like
what
ports
we
support?
We
only
support
three
ports
on
our
external
load,
balancer
and
so
in
the
ports
field
of
that
sheet.
E
It's
kind
of
like
that,
and
so
this
this
is
kind
of
becoming
our
way
of
expressing
through
the
gateway
class.
I
don't
know
you
know,
maybe
that's
a
separate
tool
that
does
that,
because
there's
so
because
it's
you,
you
basically
have
to
print
out
the
entire
surface
area
of
the
api
to
show
every
field
that
might
be
supported,
which
I
think
would
be
complex
to
support
on
the
gateway
class
resource
itself.
E
C
Yeah,
I
mean
one
of
the
things
that
I
was
thinking
was
that
and
is
that
it
feels
like
it
would
be
useful
to
me
at
the
very
least,
to
have
something
that
can
indicate
to
you
what
sort
of
controller
it
is
you
know
is
it
does
it
run
like
an
ingress
controller
where
it
runs
in
cluster
and
to
an
extent
it's
up.
You
there's
something
else
that
that
figures
out
how
to
get
the
traffic
to
the
cluster.
That's
you
know
for
contour,
that's
what
we
do
right
now.
C
Balancer,
that's
creating
an
infrastructure
like
upstream
for
you
that
will
handle
the
the
you're
actually
getting
the
traffic
to
the
into
the
cluster
yeah
so
like
that
feels
like
a
really
key
distinction
in
what
a
gateway
controller
could
do,
and
the
other
thing
that
feels
like
a
really
important
bit
of
information
is
what
types
of
routes
do
you
support.
I
know
that
further
down
rob
raised
the
good
point
that
for
a
gateway,
it's
pretty
easy
to
check
what
types
of
gateways
you
can
bind.
C
C
It's
actually
under
application
developer.
You
know
what
how
do
I
know
what
what
kind
of
routes
can
I
use
with
a
particular
gateway
that
one
there's
a
kind
field
in
the
in
the
route
binding
selector?
So
that's
the
way
that
you
can
tell,
but
if
you're
creating
a
gateway,
if
you're
a
cluster
operator
who's
creating
a
gateway?
How
do
you
know
what
kinds
you
can
put
in
that
thing?
C
Without
I
mean
right
now,
you've
got
to
go
and
look
up
the
the
implementation
documentation
for
the
controller
that
you're
using
feels
like
that
would
be
a
nice
reasonably
easy
thing
to
put
into
a
status
of
a
getaway
class.
That
would
then
mean
that
this
whole
thing
is
discoverable
without
having
to
go
out
to
look
at
external
documentation.
A
Yeah,
I
I
agree.
I
think
I
agree
with
what
both
you
and
mark
said
here
like
we
can't.
We
can't
include
every
specific
detail
of
you
know
what
an
implementation
may
or
may
not
support,
but
the
high
level
things
of
what
protocols
does
this
you
know?
Is
it
l4
l7?
Are
there
specific
extra
ones
that
the
specific
implementation
supports?
Let's
say
grpc?
Maybe
not
everyone
supports
that,
etc
and
and
build
on
that.
I
think
those
kind
of
high
level
things
will
get
us
a
long
ways.
A
I
created
an
issue
that
suggested
we
should.
We
could
have
a
description.
You
know
just
a
a
string
field
that
describes
a
gateway
or
a
gateway
class
specifically,
but
it
may.
It
may
also
help
to
have
a
few
fields
like
this
that
describe
capabilities
like
you're
described
like
you're,
suggesting,
like
the
probably
the
protocols,
the
port
type,
the
route
types
and
like
you're,
like
you're,
describing
how
it's
how
it's
deployed
like
is
this
cloud
load.
Balancers.
C
Yep
and
the
other
thing
that
I
think
that
really
gives
us
is,
it
gives
us
a
way
to
sort
of
define
for
lack
of
a
better
word
conformance
profiles,
that's
different
to
the
support
profiles
that
we're
talking
about
with
core
extended
implementation
specific.
This
is
like
because
I
think,
in
terms
of
testing,
to
see
if
a
thing
fulfills
the
api
contract
and
in
a
portable
way
requires
information
about
how
it
what
what
parts
that
api
contractor
fulfills.
So
you,
an
ingress
controller,
is
not
going
to
be
able
to
do.
C
Therefore,
or
something
like
that
right,
like
you
know,
there
needs
to
be
a
way
to.
If
we
want
to
be
able
to
have
automated
conformance
testing,
then
there
needs
to
be
a
way
for
you
to
know
what,
in
an
automated
way
in
a
machine-readable
way,
what
what
the
particular
controller
does
yeah
so
that
way,
if
we,
if
we
define
it
there,
that
gives
us
a
really
easy
clean
place
to
say
you
know
an
ingress,
the
ingress
controller
conformance
profile.
C
Again,
I
don't
know
if
that's
the
right
words
to
use,
but
the
ingress
can
an
ingress
controller
needs
to
support
at
a
minimum
layer.
Seven-
and
you
know
http
and
https,
or
something
like
that.
Right,
like
you
know,
there's
some
set
of
features
that
say
this
is
a.
This
is
an
you,
an
in-class
to
ingress
controller
and
then
that
way
later
on,
when
we,
when
we
are
able
to
define
a
standard
set
of
tests,
that
you
need
to
meet
to
meet
that
thing,
then
then
we
can
start
being
able
to
issue
like
conformance
seals.
E
D
C
D
A
Yeah
now
I
I
agree
with
that
and
I'd
thanks
again
for
writing
this
there.
I
recommend
everyone
take
some
time
to
read
through
it
add
comments
whatever.
I
think
a
number
of
these
items
are
going
to
have
to
turn
into
follow-up
issues
or
pr's,
because
these
are
these
are
lots
of
a
lot
room
for
improvement
throughout.
I
think
is
you
know.
This
is
a
great
way
to
show
what
is
currently
lacking
in
in
our
ux,
and
you
know,
when
you
get
so
focused
on
implementation,
it
can
be
easy
to
miss.
C
Yes,
yeah,
I
think
one
of
the
things
I
wanted
to
avoid
and
like
I
don't
want
to
like
throw
stones,
but
I
know
that
the
first
time
that
I
tried
to
understand
the
sir
manager's
set
of
cds.
I
found
the
the
sort
of
the
the
cookie
following-
not
great
that
was
a
long
time
ago.
So
I'm
pretty
sure
they
fixed
it
quite
a
bit
by
now.
But
you
know
that
was
that
was
sort
of
my
canonical
example
of
like.
C
A
Yeah,
I
agree,
and
I
think
we
we
talked
about
prioritizing,
adding
new
features.
I
I
think
you
know,
like
health
checks,
et
cetera
timeouts.
I
think
this
is
another
area
we
should
prioritize,
as
I
think
damian
mentioned,
we're
awfully
close
to
kubecon,
there's
going
to
be
a
lot
more
discussion
and
likely
usage
of
gateway
api
around
that
time,
whether
it's
kubecon
talks
or
articles
blog
posts,
whatever
that
are
coming
out
soon.
C
A
C
C
I
don't
think
it
really
matters
what
we
pick
as
long
as
we
pick
something
and
write
it
down
and
be
like
this
is
what
they're
for-
and
this
is
what
they're
intended
for
you
know
being
my
understanding
was
http
routers
for
when
you
effectively
when
you
terminate
tls
tls
route
is
for
when
you
aren't
terminating
it,
but
you
care
about
the
s
I
and
tcp
routers
when
you're
just
forwarding
ports
through-
maybe
that's
tls,
maybe
it's
but
we
need.
I
think
that
needs
to
be
written
down.
A
D
Unless
and
it's
another
action
item
there
is
to,
we
need
to
have
a
and
you
can
assign
that
tracking
issue
to
me
is
we
need
to
define
which
protocol
and
which
route
type
are
supported
in
the
core
api
right,
like
that's,
that's
like
we
need
to
figure
out,
like
you
know
like
you,
can't
have
a
tls
termination
and
have
a
t
like
you
cannot
not
terminate
tls
and
still
have
like
tcp
routing
or
something
like
that.
That's
a
bad
example,
but
something
along.
A
Cool
okay
I'll,
create
that
issue,
and
thanks
for
volunteering
to
follow
up
harry
the
next
one,
I
had
a
dock
associated
with
this
too,
but
I
I
was
you
know,
related
to
v1
alpha
one
well,
v,
o
dot
3.0.
I
tried
and
probably
failed
here
to
get
a
picture
of
what
was
truly
portable
across
different
implementations
that
are
already
working
with
this
api,
and
I
I
found
the
timeouts
and
feel
free
to
correct
me.
I
this
is
from
an
outside
in
perspective.
A
A
But
there
did
seem
to
be
a
fair
amount
of
support
for
a
core
set
of
features.
Here,
timeout
felt
almost
hilarious
to
me.
You
can
see
you
can
see
the
kind
of
the
the
different
underlying
implementations
here
coming
through
and
and
again
I
probably
got
things
wrong
here,
but
it
seems
like
you
could
potentially
map
a
generic
timeout
to
you
know
a
request
timeout
for
a
number
of
implementations
and
maybe
map
that,
to
you
know
both
write
and
read
timeout
where
they're
split
out.
A
C
The
request
timeout,
so
you
want
to
so
when
we're
defining
these
things.
You
need
to
be
really
clear
that
this
is
from
the
perspective
of
the
client
right
like
this
is
the
overall
timeout
from
the
respective
of
the
client
or
whatever,
like
it
doesn't
matter
as
long
as
you're.
But
you
have
to
be
extremely
specific
because,
like
yes,
I
I
never
enjoy
you
know
connection
idol.
Timeouts
can
have
there's
a
few
of
them,
because
it's
the
connection
from
the
client
to
the
envoy
and
the
envoy
to
the
back
end
and
those
are
different.
C
Timeouts
there
are
you
connect
timeouts
from
envoy
to
the
back
end.
There's
you
there's
a
whole
bunch
of
them
and
because
there's
like
four
there's
actually
like
four
different
edges,
where
you
can
mess
with
timeouts
and
a
couple
of
ones
where
the
timeout
is
calculated
on,
like
the
entire
time
from
when
the
request
is
sent
to
the
back
end
to
when
the
request
to
the
back
end
is
closed
and
there's
a
whole
bunch
of
other
ones
like
that,
where
you
like.
A
D
Yeah
I
mean
there
are
so
many
times
that
I
will
actually
have
to
go
back
and
just
make
sure
that
read
timeout
and
client
request
timeouts
are
same
and
we
need
to
define
like
client
request.
Timeout
is,
I
guess
you
make
an
http
request
and
then
wait
for
a
response
is
like,
and
then
it's
like
the
beginning
of
the
response
or
the
end
of
the
response.
So
so
details
will
matter
a
little
bit
there.
I
think.
D
Exactly
so
so
that's
that's.
Why,
like
it
gets
a
little
complicated,
but
I
think
at
least
client
request.
Timeout
is
something
we
can
support.
Maybe
it's
a
bad
way
to
name
properties
right
and
kong.
It's
deriving
that
from
engine
x.
So
that's
another
layer
that
we
have
to
deal
with,
but
that's
hong
kong.
C
Yeah,
like
I
feel,
like
the
the
like
the
key
part,
there
is
basically
you're
gonna
need
on
the
page
where
you
talk
about
timeouts
you're
gonna
need
like
a
diagram.
That's
like
yo.
He
is
here's
the
lifetime
of
a
hp
request.
You
know
going
through
a
proxy
and
here's
what
this
timeout
covers,
yeah,
so
that
then
you
can
turn
it
into
whatever
your
underlying
proxy
actually
needs.
A
Yeah,
I
think,
looking
at
what's
possible
here,
there's
really
only
one
that
is,
you
know
portable
across
more
than
a
couple
implementations
as
far
as
I
can
tell,
but
maybe
maybe
that's
me
lacking
some
creativity
here.
I
think.
Obviously,
the
underlying
implementation
of
you
know
shared
underlying
implementation,
means
more
as
possible
than
is
currently
exposed
on
a
number
of
these.
C
D
D
One
thing
that
gets
me
thinking
is
since
we
are
like
maintainers
and
we
get
confused
about
these
things.
Maybe
there
is
that
there
will
be
always
requests
to.
You
know
make
timeouts
configurable
at
you
know
fine
grained
levels,
but
maybe
we
should
think
about
how
about
you
know
having
timeouts
configured
more
granularly
like
at
a
gateway
level,
and
you
know
only
have
like
exceptions
to
configure
some
timeouts
at
lower
levels.
How
do
we
decide
that?
C
A
100
agree:
we've
had
quite
a
few
requests
coming
to
contour
where
people
are
like.
Oh
you.
I
need
to
change
the
connect
timeout
and
then,
when
we
drill
down
into
it,
it's
like.
Oh
no,
you
actually
need
to
change.
The
client
request.
Dyno
you
know,
but
because
that's
because
the
particular
timeout
that's
relevant
in
a
particular
case
is
completely
impenetrable.
C
Absolutely
though,
the
the
reason
that
people
want
to
tune
these
so
much
is
because
I
think
I've
said
this
before
in
a
different
way.
The
proxy
is
the
place
where
you
get
to
fix
things
that
are
that
that
people
can't
change,
because
you
legacy
apps
or
some
other
reason.
The
proxy
is
the
place
like
the
ingress
is
the
place
where
you
can
fix
that.
A
Yeah
for
sure
I
I
know
we're
we're
at
times,
so
I
just
if
anyone
sees
something
on
this
list-
that's
wrong
or
if
they
see
you
know
common
ground
where
we
could
potentially
provide
a
little
bit
more
portability,
definitely
feel
free
to
add
content
here
or
also
want
to
transition
this
kind
of
content
back
to
an
issue.
So
we
can
get
this
discussion
going
on
github
as
well
with
that
said,
there's
a
few
things
in
pr
and
issue
triage
that
I
think
we
just
don't
have
time
for
today.
E
A
Great
and
let's
see
what
else
is
here,
yeah
a
couple:
small
things:
more
discussion
on
service
policy,
some
new
additions,
just
if
you
have
some
time
some
bandwidth
for
reviews
or
to
continue
discussions
on
issues,
there's
plenty
of
activity
and
yeah.
But
I
think
that's
all
the
time
we
have
for
today.
So
I
let's,
let's
call
it
at
that.