►
Description
Service APIs Bi-Weekly Meeting (APAC Friendly Time) for 20211220
A
All
right
again,
this
is
gateway
api
meeting
for
december
20.,
a
fairly
light
agenda
today,
but
most
noteworthy
is
the
next
two
meetings
are
cancelled
due
to
the
holidays
and
we'll
get
back
on
january
10..
So
I
enjoy
your
time
off
for
anyone
who's
taking
some
time
off
and
yeah.
This
is
our
our
last
meeting
of
2021..
A
So
with
that,
I
there's
a
brief
update
on
the
0.4
release
last
meeting,
I
discussed
a
potential
patch
because
there
were
a
couple
issues
in
the
v1
alpha
2
api
that
we
wanted
to
fix.
A
As
I
was
getting
ready
to
push
that
release
out.
I
realized
there
was
one
more
that
was
just
kind
of
sitting
and
waiting,
and
that's
this
fix
from
steve,
where
he
pointed
out
that
there
are
there's
at
least
one
use
case
where
having
a
wild
card
in
a
hosting
yeah.
It's
a
redirect
to
a
wild
card
does
not
make
any
sense,
so
he
cleaned
up
the
validation
on
that.
A
I
think
there's
one
comment
outstanding
on
this
pr,
but
I
figured
this
would
be
good
to
include
in
that
release
as
well
so
yeah
anyway.
That's
that's
why
I'm
holding
off
on
the
odot
4.1
release.
I
does
that
make
sense.
Anyone
rather
not
include
this
specific
fix
in
that
release.
A
Cool
all
right,
I
will
keep
on
going,
then.
The
next
item
is
probably
a
little
bit
more
contentious
and
that's
coming
back
to
this
port
matching
support.
A
I
think
I'm
the
only
one
who's
commented
yet
well
myself
and
ciao
so
far,
but
I
wonder
if
anyone
else
has
some
like
higher
level
thoughts
on
the
idea
of
adding
port
in
this
context
and
for
for
anyone
not
paying
attention
the
the
idea
here
is
to
add
port
to
parent
ref
in
for
route
based
port
matching
or
for
gateway
attachment,
depending
on
your
perspective,.
B
Rob
is
there
any
update
from
the
last
time
we
discussed
this
like
yeah.
A
Yeah
yeah,
that's
so
I
know
challenge
pushed
a
number
of
comments
here
and
updated
the
gap,
for
I
think
everything
I
hope
I'm
not
missing
anything
that
we
discussed,
but
there
is
a
fairly
large
update
questions
we
discussed
it
last
week.
Yeah.
I
think
I
think
the
biggest
question
that
was
left
open
is
one
that
I
tried
to
address
here
and
that's
just
is
this
really
enough?
Are
we
going
to
want
to
add
more
things
to
parent
ref?
B
Okay,
yeah,
I
mean
so
there
were
like
two
ways
of
framing
it.
One
was
like:
are
we
going
to
add
more
and
why
can't
we
use
section
name
instead
of
port,
that.
C
B
A
Thanks
yeah-
and
I
know
I
know,
chow-
did
cover
the
section
name
versus
port
fairly.
Well
now
I
know
that
was
one
of
his
updates.
I
so
hopefully,
hopefully
that's
that.
That
section
is
a
little
bit
more
sensible
now
or
more
detailed,
the
other
area
yeah.
I
agree
it's
just
kind
of
will.
We
ever
expand
this
and
if
so,
what
would
that
look
like?
I
think,
that's
covered
a
little
bit
in
the
gap,
our
pr
here,
but
I
just
added
my
own
thoughts
as
well.
A
Since
it's
you
know
it's
one
of
those
things
we're
trying
to
predict
the
future
and
potential
use
cases
we
might
have.
I'm
I'm
not
really.
You
know
I've
been
trying
to
think
of
any
and
I'm
not
really
aware
of
any
the
the
label.
Selector,
I
know,
has
come
up
before
jsonpath
for
all
its.
You
know,
you
could
do
a
lot
with
that,
but
again
it's
just
trying
to
come
up
with
a
concrete
use
use
case
for
it.
A
I
I
don't
know
so
it's
a
little
hard
to
predict
the
future
with
these
apis.
But
my
personal
take
is
that
this
doesn't
prevent
expansion
from
happening
it.
Just
we
should
be
aware
of
any,
and
you
know
any
short-term
things
that
we
might
want
to
add,
and
I
can't
think
of
any.
A
But
yeah
thanks
for
adding
that
to
your
backlog
and
but
does
anyone
else
have
a
perspective
or
thought
on
this
concept
here.
C
I
I'm
just
curious
the
parent
breath
if
the
parent
arrived
in
this
case
in
the
child's
particular
case,
if
that's
still
pointing
to
gateway
gateway
or
it's
pointing
to
some
other
object.
A
Yeah,
that's
a
that's
a
good
question,
so
I
there's
really
two
potential
use
cases.
This
gap
proposes,
as
I
understand
it,
one
is
for
the
most
traditional
approach
which
would
be,
for
you
know,
gateway
to
route
relationship
which
basically
says
hey.
I
want
to
attach
to
this
gateway
on
port
80..
That
would
be
how
you
would
interpret
this.
A
On
the
other
hand,
what
I
where
chad
is
coming
from
is
is
working
on
a
mesh
implementation
of
this
api
and
I
think,
he's
most
interested
in
the
other
side
of
this,
where
their
parent
resource
is
something
that
represents
a
mesh,
I'm
not
exactly
specific
sure
the
specifics,
but
I
think
it's
a
mesh
custom
resource
that
is
the
parent
of
their
routes,
and
so
this
is
basically
saying
hey.
I
want
to
attach
to
this
specific
mesh
on
port
80
or
443
or
whatever
port
it
might
be.
A
D
But
I
think
the
one
thing
I'd
say
is
for
the
route
inclusion
delegation
proposal,
where,
with
what
we
talked
about,
was
having
the
child
routes,
their
parent
ref
would
be
the
parent
route
that
they're
being
included
from
that's
another
way.
We
were
looking
at
using
the
the
parent
ref.
D
I
don't
I
haven't,
had
a
chance
to
look
at
this
pr,
I'm
not
sure
I'm
just
I'm
just
I'm
just
kind
of
commenting
towards
or
providing
that
in
sort
of
your
comment
about
the
you
know.
Are
there
going
to
be
other
things
that
we
want
to
include
in
paragraph
in
the
future.
A
Yeah,
that's
that's
a
good
point.
I
I
think
parent
ref
was
in
intentionally
left
a
little
bit
open,
so
we
could
have
these
kind
of
more
expansive
use,
uses
of
parent
ref.
Unfortunately
jeff.
A
The
the
use
case
you
called
out
is
an
important
one,
because
parent
ref
for
route,
inclusion
or
delegation,
or
whatever
we
end
up,
calling
that
if
we
use
that
approach,
it
means
that
both
section
name
and
port
become
meaningless
in
that
particular
well,
as
far
as
I
can
tell,
they
would
become
meaningless
when
route
is
apparent,
because
there's
not
a
clear
what
is
section
name,
you
know
what
it
what
is
poor
when
you're
attaching
to
a
parent
route
right,
I
think,
that's,
probably
acceptable.
A
All
right
well
I'll,
leave
this
one
as
is,
but
again,
if
you
have
time
over,
I
know
it's
holidays
or
whatever.
So
I
don't
don't
work
extra
for
this,
but
if
you
have
extra
time
in
your
work
day,
I
would
would
love
some
more
feedback
or
thoughts
on
this
one.
A
I'd
love
to
to
get
this
one
through
to
this
upcoming
release,
if
possible,
but
or
or
not,
not
necessarily
get
it
I
mean
getting,
it
would
be
great,
but
I
just
like
to
get
consensus
one
way
or
the
other
on
this
one
all
right.
The
next
one
is
conformance
test.
A
This
is
really
really
early.
I'm
trying
to
be
careful
with
how
I
phrase
this
is.
This
is
very
much
work
in
progress
draft.
You
know
all
the
things
I
wanted
to
file
this
pr
early
enough
just
in
the
process
because,
anytime,
you
try
and
add
an
initial
structure
for
conformance
tests.
A
I
you
know
there
will
be
plenty
of
opinions
on
how
to
structure
things
on
how
to
approach
different
aspects
of
it,
and
so
you
know
we
have
a
gap
that
get
provided
a
baseline,
that
this
follows,
but
the
guest,
the
gap
left
lots
of
details
unanswered
for
sure,
and
so
this
tries
to
fill
in
a
little
bit
more
of
the
details
and
structure
you
know
to
sketch
something
out.
It
does
overlap
a
little
bit
with
the
ingress
controller,
conformance
helpers
and
logic
where
it
can.
A
But
a
lot
of
this
is
you
know
new
or
different.
I
guess
you
could
say
the
the
thing
I
want
to
I
want
to
highlight
here
is:
don't
there's
a
lot
of
messy
code
in
here?
A
A
Do
the
structs,
most
specifically
the
conformance
test,
struct,
makes
sense
and
then,
though,
the
way
I've
kind
of
I've
added
some
really
basic
docs
around
this,
do
those
make
sense
and
really
not
even
you
know,
I'm
sure
there
are
typos
and
whatever
in
the
docs,
but
that
does
the
direction
I'm
going
with
the
dots
and
with
the
proposed
flow.
I'm
working
on
here
actually
makes
sense,
so
those
are
kind
of
like
the
the
higher
level
kind
of
feedback.
That
would
be
really
helpful
at
this
stage.
A
With
that,
let
me
get
into
the
the
basics
of
it
hi.
This
is
really
all
that
it
takes
to
run
conformance
tests
in
this
world.
So
one
there's
a
conformance
test
suite
that
you
can
set
up
without
too
much
effort
and
you
can
get
it.
You
can
pass
a
set
of
tests
for
it
to
run
based
on
I'm
thinking,
I'll,
probably
split,
or
we
should
probably
split
conformance
tests
into
different
packages.
A
You
can
run
some
conformance
tests,
so
this
is
very
much
with
the
the
use
case
and
thought
process
in
mind
that
as
much
as
we
want
people
to
use
our
cli,
we
also
want
these
tests
to
be
something
that
we
can
integrate
into
our
own
dev
workflows.
So
this
is
something
that
I've
been
trying
to
test
out
with
our
own
gk
implementation
of
this
api.
A
Just
to
see,
if
hey,
can
we
run
these
tests
regularly
in
our
own
test
suite?
Can
we
integrate
whatever
structure
we
have
here
and
that
that
that
really
is
the
idea
with
how
these
are
structured
so
that
they
can
easily
be
integrated
into
other
workflows?
Hopefully
so
that
that's
the
gist
of
this?
This
is
using
the
controller
runtime
client,
which
I
sounds
like
almost
everyone
is
using
already
so
shouldn't
be
too
surprising.
A
There
I've
already
described
in
a
previous
meeting
this
kind
of
idea
of
a
base
yaml
for
conformance
that
basically
describes
a
set
of
resources
that
we
can
structure
tests
around.
This
includes
namespaces
some
gateways
which
could
be
pre-provisioned
I'll
get
into
that
later,
and
a
variety
of
other
things
that
just
kind
of
make
for
a
nice
environment
when
so
you
so
every
test
definition
doesn't
need
to
redefine
the
pods
the
service,
the
everything
else
around
it
just
there.
There's
kind
of
this
shared
understanding
environment
of
tests.
A
Yeah
I've
talked
a
lot
already.
Are
there
any
questions
before
I
keep
on
going
here,
any
any
questions
or
thoughts
on
the
basic
structure.
So
far
I
like
what
I'm
saying
right
here:
yeah,
that's
awesome,
so
yeah
I'll
keep
on
running
through
this
again
there's.
I
think
this
base
is
basically
three
namespaces.
Each
include
a
service,
a
deployment,
a
I
mean
nothing
too
crazy.
A
These
are
using
echo
server,
so
we
can
parse
the
results
that
actually
matches
with
the
same
thing
that
ingress
controller
conformance
is
using
so
again,
there's
some
overlap
through
here
and
then
you're
also
going
to
see
our
manifest
for
a
individual
test
case.
This
is
one
that
I'm
not
thrilled
about.
A
I
tried
to
do
some
in
inline
yaml
and
it
technically
worked,
but
trying
to
do
inline
yaml
inside
go
is
awfully
messy
and
gross
so
yeah,
whatever
the
corresponding
test
that
goes
with
this
yamo
is
defined
with
this
conformance
test,
truck
suite
or
test
definition
right,
so
you've
got
a
short
name,
a
description,
a
set
of
manifested
to
apply
and
then
a
test
function.
A
So
the
key
thing
about
this
test
function
is:
it
doesn't
need
to
worry
about
actually
applying
this
or
cleaning
anything
up
this
you
know
if
this
is
wrapped
already
by
a
function
that
applies
and
cleans
up
anything
defined
in
here
automatically,
and
then
you
just
have
access
to
a
client
and
test
framework,
and
you
can
write
whatever
you
want
in
here.
It's
pretty
straightforward.
There
should
be
not
much
in
the
way
of
surprises,
but
this
is.
This
is
really
one
of
the
areas.
A
I
wanted
some
some
focus
and
feedback
not
again
not
on
the
specifics
of
this
test
case
there's.
This
is
just
a
nonsense
test
case.
I
I
have
a
controller
name
hard
coded
in
here
right
now,
because
I
haven't
anyway,
there's
still
work
to
do
here,
but
with
that
said,
the
idea
that
this
is
kind
of
the
api
and
structure
that
we're
working
with
and
looking
towards
for
defining
tests.
A
Yeah.
That's
that's
really
it
there's
this
is
this
matches
again
the
gap
description
for
for
what
we're
defining
here?
So
I
hoping
this
won't
be
too
surprising,
but
again
it
is
kind
of
what
I
kind
of
a
baseline
that
I'd
like
to
structure
other
tests
with
if
it
makes
sense
any
thoughts
concerns
around
this.
B
Pretty
feature-packed
start,
I
think
we
should
try
to
get
like.
We
should
try
to
write
more
tests
around
it
and
gain
feedback
from
that
cycle
rather
than
yeah
thinking
too
much
about,
like
you,
know,
sort
of
thinking
like
it's
very
hard
to
predict
how
these
things
go.
B
A
Yep
yeah,
exactly
that
that's
yeah,
you
got
exactly
and
that's
you
describe
exactly
that.
The
challenge
I've
been
having
so
far
is
at
some
point.
We
just
need
to
have
tests.
We
just
need
to
say
this
is
good
enough.
A
You
know,
I
think
800
some
lines
of
code
and
and
I'm
trying
not
to
I'm
trying
not
to
balloon
that
out
too
much
further
than
it
already
is.
But
again
it's
it's
just
trying
to
to
find
that
that
right
balance,
but
I'm
I'm
thinking
this
is
around
the
scope,
I'm
going
to
try
and
keep
this
at,
maybe
add
one
more
test
definition
just
so
we
can
see
some
variety
and
actually
complete
this
one,
even
but
again
yeah.
I
appreciate
that.
B
B
A
B
A
So
yeah
thank
you
that
that
is
a
great
transition
to
my,
I
think,
kind
of
the
the
last
and
and
most
poorly
defined
aspect
of
this
yet
and
we'll
get
here.
Eventually,
I
have
this
http
round
tripper
that
interface.
That
is
not
too
different
from
what
is
it.
It
has
a
lot
of
overlap
with
what
is
an
ingress
controller
conformance
again,
the
the
details
of
this
interface
need
work,
but
the
idea
is
clear
that
I
want
the
thing:
that's
making
hp
requests
to
be
something
that
can
be
overwritten.
A
That's
that's
very
important
for
us
if
we're
trying
to
integrate
these
tests
in
gke,
because
we
want
to
be
able
to
make
requests
to
say
an
I'll
be
and
not
necessarily
be
running
the
test
in
the
same
place
that
you
can
make
requests
from
as
a
rough
example,
but
I
imagine
this
kind
of
idea
of
overriding
an
http
client
could
be
potentially
useful.
More
broadly
with
that
said,
I
will
ship
with
the
default
one
that
tess
would
use
by
default
again
that
the
idea
is
fairly
straightforward.
That
you'd
have
a
request.
A
Well,
yeah
you!
It
would
basically
take
a
request
as
pram
and
then
return
captured,
request
response
and
an
error
where
the
error
is
specifically
some
kind
of
unexpected
error,
making
the
request
itself,
not
a
http
error
code
or
something
like
that
yeah.
So
this
this
needs
a
lot
more
work,
but
this
is
kind
of
maybe
the
most
unique
or
you
know
something
that
didn't
come
out
of
the
gap.
A
This
is
just
something
that
came
out
of
at
working
through
this
and
trying
to
figure
out
how
we
could
integrate
this
throughout
different
test
frameworks.
It
seemed
like
it
would
be
a
useful
thing
to
be
able
to
override,
in
certain
cases
yeah,
but,
but
that
that
very
much
is
something
like
I
I
forget
exactly
how
I
integrated
it
right
now.
I
think
it's
something
that
I
connected
to
the
test
suite.
A
I
can
probably
do
that
to
the
test
definition
as
well,
though
those
details
are,
are
less
critical.
In
my
perspective,
the
biggest
thing
is,
I
think
anyone
who's
using
these
tests
will
be
just
passing
in
this
and
then
not
really
caring.
You
know
once
they
have
the
suite,
they
can
run
whatever
and
they're
done,
and
they
don't
have
to
interact
with
anything
below
that
that
stage,
but
yeah
that
that's
what
I'm
thinking
there.
I
I
don't
know
what
what
do
you
think
is
this
something
that
would
be
useful
to
anyone
else.
B
I
think
so
it
will
be
useful
to
us
shane,
it's
not
on
the
call
but
yeah
it
would
have
been
okay.
A
A
There's
there's
those
areas
that
I'm
trying
to
work
through,
most
notably
the
http
interface
and
just
finishing
out
some
test
definitions,
but
comments
on
structure
on
any
of
any
of
these
areas
would
be
really
appreciated
and
I'll
keep
on
pushing
updates
to
this
pr,
as
I
go
yeah
cool
any
any
last
thoughts
or
comments
before
I
move
on.
A
All
right,
I
think,
we're
on
to
the
last
one
then-
and
this
is
the
only
one
I
added
to
pr
and
issue
triage
for
the
day.
Let
me
know
if
I
missed
anything
else.
I
think
this
is
a
good
point
that
our
docs
are
confusing
here.
A
We've
kind
of
left
this
open
that
says:
hey,
you
can
re-encrypt
traffic
when
it's
coming
from
for
the
basically
connection
from
gateway
to
back
end
using
http
router
tls
route,
but
we
have
not
provided
any
standard
way
to
re-encrypt
that
traffic
we've
just
said
it
can
be
done,
and
here
you
I
think
you
were
the
one
who
commented
most
recently
on
this.
A
I
think
correct
me
if
I'm
wrong,
but
I
think
you're
hoping
that
we
can
add
this
kind
of
capability
to
the
api
directly
and
not
just
say
well
technically,
it
can
be
done,
but
you
need
some
kind
of
custom.
Something
to
do.
It
depends
on
your
implementation.
B
Yeah,
I
think
this
I
mean
I
had
sort
of
mistakenly
assumed
that
something
like
this
existed
now
upstream.
Tls
is
something
like
not
everybody
uses
it,
but
it's
a
fairly
mature
and
fairly
standardized
like
solution,
so
we
should
like.
Maybe
we
didn't,
like
I'm
clanking
on,
why
we
didn't
do
it,
but
we
can
say
this,
but
we
should
like.
I
don't
see
implementers
using
it
still,
but
we
should
standardize
it
and
we
we
definitely
should
at
least
communicate
that
hey.
A
Yeah
that
that
makes
sense
that
that
lines
up
with
what
I
was
thinking,
I
I
wanted
to
clarify
you
mentioned
something
about
you
know
we
should
have
a
concrete
plan
before
we
get
to
beta
for
this.
What
what
do
you
do?
You
mean
plan?
Isn't
just
we
should
have
a
proposal
or
gap,
but
not
necessarily
implemented
before
we
get
to
beta.
That
would.
B
Be
that
would
be
a
pretty
ideal
case,
I'm
not
sure
if
you'll
be
able
to
get
to
it,
but
at
least
have
like
verbal
discussion
say
this
could
be
implemented
in
these.
These
fashions
and
people
are
like
yeah.
This
makes
sense,
and
you
know
something
like
that.
Rather
than
issued,
we
didn't
take
this
into
account
and
you
know
I
mean
I
don't
think
it
will
be
causing
a
like
a
big
change,
but
mostly
people
are
in
agreement
rather
than
you
know,
being
surprised
later
on.
A
Yeah,
that
makes
a
lot
of
sense,
so
it
seems
like
what
we
need
here
are
two
things
one.
We
need
someone
to
volunteer
to
just
update
the
docs
to
describe
to
clarify
that
this
can
be
done,
but
we
don't
have
a
standard
way
to
do
this
yet
and
second
somebody.
You
know
this
is
a
larger
process,
but
somebody
to
actually
propose
how
we
could
do
this
in
a
standardized
way.
A
Yeah
cool
all
right.
Well,
if
anyone
wants
to
volunteer
to
take
on
either
of
those,
I
would
would
love
some
help
on
this
one,
especially
the
docs
update.
If
anyone
or
if
anyone
has
any
any
interest
in
leading
a
gap,
this
could
be
a
good
one
to
to
work
on
as
well
so
either
either
you
can
volunteer
now
or
volunteer
on
the
bug
afterwards.
This
is
9
68.
A
A
All
right,
well,
hey!
Thank
you!
Everyone
have
a
great
rest
of
your
year
and
we'll
talk
to
you
in
the
new
year
have
a
great
one.