►
Description
Service APIs Bi-Weekly Meeting (APAC Friendly Time) for 20211206
A
All
right
welcome
to
gateway
api
meeting
for
december
6..
We
are
recording
and
we've
got
lots
to
get
through
today.
Let
me
start
off
just
with
a
final
follow-up
on
gap735,
a
huge
thanks
to
shane
for
following
through
on
this
one,
and
I
I
think
we
are
awfully
close
to
the
finish
line
on
this.
A
I
this
is
again
about
basically
address
matching
source
and
destination
address
matching
for
tcp
and
udp
route
shane.
I
want
to
make
sure
I
got
this
right.
I
know
you
had
just
recently
pushed
an
update
for
proxy
protocol.
If
I'm
remembering
correctly,
you
basically
said
that
proxy
protocol
is
not
considered
for
address
matching.
Is
that
correct,
harry.
A
B
Must
be
considered,
his
suggestion
was
that
it
may
become
difficult
to
go
the
other
way
more
so
than
like,
basically
to
start
without
it
and
to
get
to
it
would
be
more
difficult
than
to
remove
it.
If
we
felt
we
needed
to
at
some
point
in
a
later
iteration.
B
B
A
B
A
B
A
Yeah,
so
there's
this
longer
one
about
named
address
and
I
think
harry
this
is
waiting
for
a
follow-up
from
you
on
this
one.
But
it
is
really
just
trying
to
see
if
named
address
is
a
blocker
right
now
or
if
it's
acceptable
enough
to
just
kind
of
move
forward
with.
C
Yeah
so
yeah
I
mean
I'm
fine
with
it.
It's
just
pretty
unusable,
in
my
opinion,
without
a
prefix
named
address
will
mean
is
something
different
for
everybody.
So
that's
also
fine
like
if
you
know
implementer
like
it's
a
bit
it
the
user.
Experience
could
be
better,
but
I
certainly
don't
want
to
block
this
pr
on
that.
It's
a
bigger,
much
bigger
issue.
B
Yeah,
I
would
also
throw
out,
like
I
get
where
you're
coming
from,
but
I
would
also
throw
out
like
we
still
got
a
little
bit
of
time
if
this
merges
it's
still
provisional
so
like
I
would
definitely.
I
know,
howard
john's
got
something
he's
planning
to
add
the
port
stuff
to
this
like
right
away,
potentially-
or
at
least
he
he
mentioned
doing
so
so
it
doesn't
necessarily
mean
it's
set
in
stone.
If
we
do
that,
even
if
we
merge.
A
Yeah,
I
agree
with
that
and
I
think
harry.
I
also
agree
with
what
you're
saying
that
you
know
named
address
as
a
as
a
type
is,
is
rather
imprecise,
because
it
does
mean
something
different
for
every
implementation,
but
I,
I
also
think
it's
almost
a
little
too
late
to
fix
that
mistake,
because
we
we've
already
shipped
named
address
with
gateway,
and
so,
if
you
have
two
different
ways
to
represent
a
named
address,
then
whatever.
B
My
thinking
goes
in
a
slightly
different
direction
than
what
you
said
rob
not
that
we
should
probably
fix
holistically
rather
than
like
try
to
do
it
in
microcosms
like
this
is
one
place
where
we
could.
We
are
already
using
it.
Maybe
we
need
to
before
we
go
to
beta,
say:
okay,
we're
using
this
in
two
different
places.
Does
it
still
make
sense.
D
C
A
That's
that's
a
good
idea,
because
I
I
did
like
what
nick
had
proposed
further
down
of
kind
of
the
vendor
prefixed
value
for
yeah.
D
A
I
just
wrote
perfect
well
well,
maybe
what
we
should
do,
then
is
is
merge.
This
like,
as,
as
we've
already
said,
it's
provisional.
I
think
we
all
agree
with
99
of
the
content
in
here
and
then
create
a
follow-up
issue
to
track
an
alternative
way
to
represent
named
address
both
here
and
on
gateway
itself,
because
I
think
gateway
the
resource,
because
I
I
think
there
is
room
for
something
better.
Like
a
vendor
prefixed
name,
there.
A
That's
yeah.
That's
a
good
point.
I
hadn't
really
thought
about
yeah.
I
I'm
thinking
I'm
thinking
very
I'm
biased
towards
the
perspective
where
they're
one
the
same,
the
implementer
and
the
provider
of
the
named
address,
but
obviously
that's
not
always
going
to
be
the
case.
Yeah
very
good
distinction
there,
cool,
okay!
Shane!
Do
you
want
to
create
that
follow-up
issue,
sure
cool,
awesome
and
I'll
I'll
make
sure
to
go
through
this
one
more
time?
I
know
there's
already
one
lgtm
on
this,
so
maybe
we
just
need
an
approve.
B
A
Cool
all
right.
Well,
it
sounds
like
this
one's
about
good
to
go
here,
so
I'll
make
sure
to
run
through
it
and
add
an
lgtm
or
approve,
and
if
someone
else
can
do
that
as
well,
that'll
be
great
and
I
think
shane
you're
following
a
file
up
issue,
a
follow-up
issue
for
this
one
cool
great
thanks.
Next
one
to
cover
is
a
conformance
update.
This
is
a
relatively
small
thing,
but
I
just
wanted
I
put
in
a
fair
amount
of
time
working
on
conformance
tests,
but
I
didn't
even
have
enough
to.
A
I
didn't,
feel
comfortable
doing
the
work
in
progress
pr
for
this
yet,
but
I
just
wanted
to
share
an
update
of
my
general
thoughts.
One
of
the
things
that
I've
worked
on
is:
is
this
kind
of
a
base,
a
set
of
basically
an
environment
that
conformance
tests
can
run
in?
I
think
right
now
it
can
contains
three
gateways,
three
namespaces,
a
variety
of
that
I
think
the
same
number
of
back-end
services
deployments,
etc.
A
A
A
Is
that
as
much
as
I
want
this
to
be
exposed
as
a
cli,
I
also
would
love
to
get
this
to
a
place
where
you
can
import
these
tests
and
kind
of
integrate
them
with
your
own
test
suite
that
includes,
you
know,
maybe
some
kind
of
hp
request
interface,
if
you're,
if
you're
working
in
a
different
environment
where
that
doesn't
necessarily
make
sense
or
where
the
vanilla
net
hp
requests,
aren't
going
to
make
sense,
you
want
to
override
some
part
of
that
anyway.
A
These
are,
these
are
all
just
fairly
high
level
ideas
right
now.
I
just
I
really
do
hope
to
get
a
pr
out
this
week,
but
yeah.
These
are
my
high
level
thoughts.
What
I've
been
working
on
for
conformance
and
yeah.
If
you
have
ideas,
if
you
have
suggestions
on
more
details,
more
more
ideas
on
how
to
structure
this
or
you
know,
requests
for
how
this
could
better
integrate
with
workflows.
You
know
whatever.
A
D
It
looks
good
to
me:
have
you
considered
using
one
of
the
echo
server
things
instead
of
sub
hostname,
so
you
get
all
the
headers
and
all
that
sort
of
stuff
as
well.
That
will
let
us
test
yeah,
you
know,
did
the
headers
yeah
if
a
header
adding.
A
Yeah,
that's
that's
a
good
point.
Yeah!
Let
me
let
me
work
on
a
better
base
image
than
just
serve
hostname.
That's
a
good
point!
Oh
cool!
All
right!
The
next
thing
I
wanted
to
cover
it.
Well,
actually
I
don't
jeff,
I
don't
think
you're
on
this
call,
so
I
don't
think
there's
much
to
say
on
route
inclusion
delegation.
I
know
he's
been
working
on
this
stock
and
proposal
there.
There
is
more
here
now,
but
I
don't
see
him
on
the
call.
So
we'll
just
leave
this
for
next
week.
A
Okay,
that's
fine!
I
next
up
is
pr
on
issue
triage
in
no
particular
order.
One
of
the
ones
I
wanted
to
get
to.
I
think
john
had
raised
this
idea.
I
don't.
I
also
don't
see
him
on
the
call
right
now,
but
that's
fine.
I
I'm
at
least
familiar
with
the
idea
here
so
john
had
proposed
adding
port
matching
and
routes.
This
is
really
a
follow-up.
I
think
this
issue
yeah.
A
This
issue
refers
to
gap
735,
which
originally
included
port
matching,
but
was
you
know,
left
out
because
it
was
confusing
for
good
reason,
but
this
kind
of
separates
that
out
and
tries
to
explore
port
matching
on
its
own
and
it's
you
know,
usefulness
or
not.
A
A
John,
you
know,
understandably,
is
coming
at
this
from
a
mesh
perspective,
and
so
he's
looking,
you
know
so
you
know
and
then
basically
the
idea
is,
as
I
understand,
their
implementation.
They
are
using
parent
ref
to
attach
a
route
to
a
mesh
right,
and
so,
if
you
attach
a
wrap
to
a
mesh,
you
could
also
basically
say
I
want
to
attach
to
this
mesh
on
port
80,
which
is
not
that
different
from
saying
I
want
to
attach
to
this
gateway
on
port
80
or
443.
A
It's
a
little
weird,
but
it
does
seem
at
least
workable.
So
this
this
is
a
proposal
or
feature
request.
Yeah
feature
request
from
john:
he
had
specified,
you
know,
suggested
a
few
different
options,
one
adding
it
to
just
the
match
itself
on
each
route
type,
the
other.
You
know
that
that
is
what
we
explored
in
735
and,
I
think,
ended
up
going
away
from
the
other.
One
was
a
section
name,
you
know
you
could
reuse
section
name
to
be.
A
You
know
a
reference
of
a
port
with
just
use
a
string
as
a
port
and
it
kind
of
works,
but
it's
kind
of
gross
and
then
the
final
idea
is.
Could
we
just
add
a
port
field
to
paragraph-
and
this
is
I
want
to
attach
to
this
port
on
my
parent
yeah?
Not
my
parent
resource
that
feels
like
it
is
generally
applica,
roughly
applicable
to
both
use
cases.
It
seems
primarily
useful
for
mesh,
but
at
least
understandable
for
ingress,
but
I'm
interested
in
what
others
are
thinking.
D
Here
I
think
I
agree
that
it
makes
sense
that
the
port,
the
third
one
kind
of
makes
sense,
but
it
it
would
be
a
little
funky
with
route
with
router
route
conclusion
with
jeff's
proposal.
Basically,
what
is
the?
What
is
the
port
field
on
apparent
ref?
That
points
to
a
route
mean
I
mean
we
can
just
say
it
doesn't
mean
it'll
be
ignored,
but
yeah,
which
is
probably
fine.
It's
probably
not
enough
for
a
reason,
but
that's
the
only
other
thing
I
can
think
of
that
would
be
a
problem.
A
Yeah
and
I
think
right
now
well,
I
think
section
name
on
parent
route.
References
to
parent
routes
is
also
undefined,
like
I
don't
think
we
have
a
route
rule
name
we
may
we
may
need
that.
We
probably
will
need
that
for
route
inclusion,
so
you
can
at
least
see
where
section
name
could
be
useful
for
route
to
route
references.
D
Yeah
yeah,
I
think
that's
that
should
definitely
be
part
of
both
of
these
proposals
to
find,
if
we're
going
to
add
that
new
field,
we
just
got
to
think
about
it
and
define
it
and
say:
what's
up
yeah
yeah,
I
think
it's
fine
for
things
for
things
to
say,
especially
if
the
field
is
optional,
which
this
would
be
that
you
know
when
this
refers
to
x.
It
must
be
ignored.
A
E
Hi
rob
rahul
here
hey,
so
this
is
my
first
time
here
to
this
meeting
one
I
mean
my
preference
is
of
course
the
first
idea
here
it
seems
like
the
simplest,
having
abstraction
levels
with
section
names
or
other
references
seems
more
complicated.
Furthermore,
for
a
lot
of
the
mesh
use
cases,
but
especially
given
that
this
is
probably
be
an
optional
field,.
A
Yeah
that
that
makes
sense,
I
think,
that's
most
similar
to
what
we'd
originally
described
in
735.
If
shane,
you
can
correct
me
if
I'm
wrong,
but
I
think
that's
kind
of
where
it
would
basically
what
you'd
added
in
in
here
was
port
matching
on
in
tcp
route,
udp
route,
etc.
Right
say
it
one
more
time,
you
so
sorry,
the
original,
like
way
back
in
the
day,
the
original
gap,
735
included,
port
matching
and
that
port
matching
was
on
like
inside
the
match
of
tcp
route
and
udp
route
right.
D
A
Yeah
yeah,
that's
fine.
I
shouldn't
shouldn't
dig
too
far
into
this.
I
you
know
I.
I
agree
that
if
you're
you
know
from
from
a
mesh
perspective,
including
including
this
directly
in
the
match,
is
is
great,
but
then
I
think
where
we
got
stuck-
and
this
is
me
just
trying
to
remember
which
could
be
wrong,
but
I
think
where
we
got
stuck
on
this
is
that
it
it
became
a
field
that
either
didn't
have
a
meaning
for
ingress
or
had
a
confusing
meeting
for
ingress.
A
I
and
and
both
of
those
were
unfortunate,
but
maybe
there's
maybe
there's
a
path
forward
here.
A
Yeah
yeah,
I
think
thanks
for
the
feedback
ripple,
we
should.
We
should
really
just,
I
think,
continue
the
discussion
on
this
issue
for
for
the
next
little
bit,
if
you
have
any
thoughts
or
feedback
on
this
idea-
and
I
do
want
to
move
on
from
this-
I
think,
but
it's
it's
good
to
get
that
feedback
and
to
get
the
preference
here
for.
D
Yeah,
I
would
just
say
I'd
love
to
hear
I'd,
love,
to
hear
more
of
use,
cases
and
stuff
like
that
on
this
issue.
So
sorry,
very
else
please
go
okay,.
C
A
Yeah
cool,
okay-
I
I
just
noticed
in
chat,
I'm
just
catching
up
in
chat,
there's
a
question
from
lewin
about
what
happens
if
it
is
not
specified
for
a
mesh
use
case.
That's
a
good
question.
I
think
that
would
have
to
depend
on
mesh
implementations
right
now.
The
and-
and
I
think
istio
is
the
main
one.
I'm
aware
of
as
well
as
I
think
traffic
director
is
working
on
something
here,
but
I
I
don't
know
I
mesh
is
relatively
underspecified
right
now,
I'm
like!
Yes,
I'm
not
sure
what
that
would
mean.
A
I
I
my
guess
is
that
it
means
listen
on
all
ports,
but
again,
I'm
not
sure
and
then
rahul
you're
saying
you
cannot
match
a
lot
of
tcp
traffic
for
mesh,
so
my
sequel,
traffic,
etc.
Okay,
okay,
yeah
and
feel
free
to
add
comments
here
or
if
you
want
to
add
any
additional
discussion,
we've
got
a
couple
minutes.
Otherwise
I
can
move
on.
B
A
Got
it
and
I
I
figured
as
much
I
for
a
sec,
I
saw
you
were
unmuted
and
thought:
oh,
maybe
he's
just
thinking
for
a
second
and
then
yeah.
I
figured
when
it
went
that
long
yeah
well
glad
to
have
you
back.
I
think
we've
got
enough
here
too,
and
basically
the
default.
The
action
I'm
from
this
is
just
continue.
The
discussion
in
here.
I
think
this
requires
some
more
thought
and
I
think
it
might
have
been
harry
to
mention
that
this
is.
I
can't
you
know,
opening
a
can
of
worms.
A
So
hopefully
we
can.
Hopefully
it's
not
too
big
of
a.
I
can't,
but
yeah
cool
all
right.
Let's
keep
on
moving,
then
this
one's
a
smaller
one,
steve.
I
don't
see
you
on
the
call,
but
I
chat.
I
chatted
with
steve
a
bit
this
morning
about
generated
types.
I
introduced
this
bug
when
I
moved
everything
into
experimental
and
stable
crds.
A
A
It
looks
like
steve.
Has
volunteered
to
look
into
this
more
there's
a
deep
copy
gen?
That
is
probably
all
we
need
here,
but
anyway,
steve
is
looking
at
this
one.
If
anyone
is
super
familiar
though,
and
wants
to
help
out,
always
welcome
the
next
one
or
sorry
go
ahead,
I
think
nick
you're
about.
D
D
I'm
really
glad
I'm
glad
to
pick
that
one
up
he's
yes,
because
yeah
he's
he's
he's
looking
at
fixing
up
the
whole
thing:
the
wild
card,
the
first
name
thing
yeah,.
A
Yeah
yeah
and
actually
that's
let
me
just
jump
right
into
this
one
then,
because
that
is
also
where
this
came
from
the
wild
card
hosting
thing.
This
seems
like
a
really
sensible
change.
Steve
is
running
into
some
trouble
with
cla
verification.
I
don't
know
what's
going
on
there,
but
the
actual
pr
to
me
seems
reasonable.
A
James,
no
james
is
not
on
this
call,
but
I
I
still
have
a
strong
preference
towards
these
types.
These
custom
types
that
we're
using
everywhere
as
opposed
to
a
string,
but
I
don't
know-
I'm
also
not
implementing
this
api
so
for
someone
who's
actually
implementing
this
api
are
all
these
custom
type
names,
just
a
pain
to
work
with.
D
I
you
know,
I
haven't
heard
anything
like,
I
haven't
been
doing
the
pr's
for
contour,
but
I
know
that
steve
chris
and
steve
sloka
have
been
doing
them
and
you
know
neither
of
them
have
been
complaining
about
it
at
all.
I
feel
like
the
big
advantage
it
gives
us
having
to
be
typed
is
that
is
that
it
lets,
gives
you
two
advantages.
D
The
the
type
itself
holds
the
crd
validation,
so
there's
only
one
place
where
you
need
to
set
the
validation
stream
for
this
further
for
the
type
and
then
you
also
get
the
type
safety.
A
Yeah
yeah,
I
I'd
agree
with
that.
I
think
it's
it's
highly
worthwhile
I'll.
Add
a
comment
to
that
effect.
The
the
actual
pr
itself
seems
pretty
straightforward.
I
I'm
not
sure
where
this
falls
in
our
release
pattern.
We've
left
room
open
in
our
versioning
guidelines
to
basically
release
bug
fixes
to
our
validation.
A
A
D
D
A
D
A
Okay-
and
the
very
last
thing
on
the
agenda
today
is
charisma.
I
think
this
is
your
pr.
I
noticed
you
had
updated
it
just
before
this
meeting
and
I
hadn't
gotten
a
chance
to
take
a
look
yeah.
What
what
do
you
need
from
us
on
this.
F
So
right
now
I
think
I
didn't
commit
a
ghost
home.
So
that's
why
it's
breaking,
but
I'm
not
sure
how
to
complete
that
and
what
I
did
was
I
kind
of
move
around
the
tests,
so
that
tells
that
the
back
end
ref
test
and
the
other
tests
I
just
may
want,
because
they
were
testing
the
same
thing.
A
F
Okay,
yeah
yeah,
and
it
puts
it,
puts
the
logic
in
this
validate
around
spec.
Okay.
That
way,
we
can
range
over
the
rules.
A
Okay,
cool
yeah!
Let
me
let
me
take
another
look
at
this.
I
know
I'm
not
the
only
one
who's
been
reviewing
this
but
yeah.
Thank
you
again
for
for
taking
this
one
on
yep
cool
all
right,
so
this
just
needs
another
round
of
review.
It
look,
it
sounds
like
and
it's
otherwise
pretty
close
cool
all
right.
Well,
that's!
I
think.
That's
all
we
have
on
the
agenda
today.
If
I
missed
any
issues
or
prs,
let
me
know
we
have
time
to
cover
them.
A
Otherwise
we
probably
have
some
time
we
can
get
back
good
to
me
all
right.