►
From YouTube: Service APIs Meeting (APAC Friendly Time) 20210629
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
we're
recording
this
is
the
gateway
api
meeting
for
june
29,
and
I
think
we
have
a
pretty
light
attendance
today.
A
So
I
think
the
answer
here
is
going
to
be
that
most
people
I'm
seeing
on
this
call,
could
probably
attend
or
have
attended
the
later
afternoon-
well,
pacific
afternoon
time
meeting
time,
so
we've
been
alternating
between
a
europe-friendly
time
zone
and
a
more
apac
friendly
time
zone,
and
it
seems
like
we're
getting
better
attendance
for
the
afternoon
meetings
for
the
apac
time
zone,
so
I'm
leaning
towards
switching
all
meetings
to
this
later
time
of
the
people
that
have
attended
this
meeting.
Is
there
anyone
that
couldn't
make
the
later
meeting
time.
A
A
On
that
note,
the
next
meeting,
at
least
at
google-
and
I
think
at
many
american
companies
is
a-
is
a
holiday,
so
I'm
leaning
towards
canceling
it.
I
think
the
attendance
will
be
pretty
low.
A
I
think
we'd
be
on
pace
for
a
july
five,
which
is
is
obviously
not
the
fourth,
but
I
think
the
fourth
got
extended
and
and
basically
most
companies
are
giving
the
fifth.
So,
given
that
I'm
playing,
I
think
we
should
just
cancel
the
next
meeting.
Would
anyone
be
around
if
we
did
have
a
meeting?
A
Nope
okay
sounds
good
I'll
plan
on
canceling
that
one
then
cool
all
right.
So
a
lot
of
this
discussion
today
I
wanted
to
go
through
a
doc
I'd
put
together.
Many
of
you
were
probably
at
the
meeting
nick
led
last
week.
Unfortunately,
I
missed
that,
but
I
did
watch
the
recording
and
I
chatted
with
him
after
about
selection
policy
and
just
to
jog
your
memory.
This
is
the
idea
of
selection
policy
was.
A
Can
we
take
these
concepts
of
you
know,
cross
namespace,
selection
and
bump
it
out
to
another
resource,
and
he
he
had
a
good
example.
I
think
we've
gone
back
and
forth
between
reference
policy
or
selection
policy-
I'm
not
very
opinionated
about
the
name
here,
but
you
can
see
the
the
general
idea
here
was
that
I
want
this
object
to
be
re
to
allow
references
from
this
this
other
resource
or
set
of
resources
in
this
other
namespace.
A
A
A
So
I
wanted
to
explore
this
and
see
how
it
would
work,
and
I
also
wanted
to
expand
on
all
the
previous
discussion,
but
this
is
just
the
cliff
notes:
version
of
reference
policy
if
anyone
else
wasn't
able
to
make
it
last
week,
so
I
chatted
with
nixom
and
came
up
with
something
similar
to
that,
but
it
really
my
goal
for
a
while
had
been
to
try
and
make
sense
of
all
the
things
that
we've
talked
about,
that
all
seem
like
they're
related
and
building
on
each
other.
A
And
how
can
we
put
this
all
together?
So
previous
meetings
covered
selection
policy?
I
think
that's
the
most
recent
and
relevant
here,
but
also
covered
cross
namespace,
forwarding
route,
inclusion
and
gateway
to
route
binding
and
so
for
cross
namespace
forwarding
I'm
talking
about
the
the
ability
to
forward
traffic
from
a
route
to
a
service,
or,
I
guess
any
back
end
in
another
namespace,
but
we're
primarily
concerned
about
service
and
then
route
inclusion
is
the
idea
of
I
want
to
include
a
route
in
a
different
name
space.
A
So
I
think
the
primary
use
case
for
that
is.
I
have
this
path,
let's
say
foo
and
I
want
to
delegate
it
to
namespace
foo,
so
we
already
have
the
idea
of
delegating
by
domain
with
gateway
listeners,
but
we
don't
have
the
ability
to
delegate
by
path
and
so
route
inclusion
would
allow
us
to
delegate
by
path.
A
So
those
were
the
ideas
and
there's
been
a
lot
of
discussion
on
this
already,
and
this
doc
just
tried
to
illustrate
some
of
the
options
we
had
for
connecting
all
these
pieces,
because
I
think
this
really
is
one
of
the
biggest
things
we
need
to
get
right
out
of
v1
alpha
2..
We've
spent
a
lot
of
time
discussing
how
all
these
different
pieces
need
to
interconnect,
and
I
wanted
it
to
be
somewhat
sensible
and
and
really
consistent.
A
A
So
with
that,
I
think
the
idea
is
at
a
minimum.
We
want
to
provide
a
way
for
the
following
to
cro
safely:
cross
name,
space,
boundaries,
gateway
to
route
or
route
to
gateway,
depending
on
your
perspective
and
then
route
to
route
and
route
to
service
and
then
kind
of
as
a
nice
to
have.
It
would
be
really
cool
if
we
could
include
secret
references
in
this,
but
I
don't
think
that's
completely
critical.
It's
just.
You
know
that
there
is
some
level
of
interest.
A
Comments,
cool
all
right,
I'll
keep
running,
so
the
first
proposal
I
had
here
is,
you
know,
direct
references
from
route,
and
this
proposal
really
just
makes
route
the
center
of
everything
and
everything.
B
Had
a
meta
comment:
if
we
were
going
to
reserve
some
time
at
the
end
to
just
go
through
issues
and
prs
yeah,
just
to
touch
them,
yeah,
absolutely.
A
I
think
this
is
going
yeah.
That's
that's
a
good.
Let
me
time
back
time
boxes
for
real.
In
my
mind,
I
thought
this
would
be
a
relatively
quick
thing,
but
I
I
could
be
very
wrong
there.
A
So
let
me
try
and
time
box
this
for
another
25
minutes
and
if
we
hit
that
time
so
for
me,
that's
around
10
35
and
if
we
hit
that
time,
we'll
move
on
to
other
things
does
that
sound,
fair,
yeah,
okay,
cool
yeah,
good
call,
okay,
so,
first
off
here
the
idea
is:
if
route
is
central,
that
means
route
is
pointing
up
to
gateway,
so
a
route
attaches
to
gateway,
but
route
can
also
include
other
routes
and
forward
to
services.
A
So
this
is
fairly
similar
to
our
existing
model,
and
I
should
note
I
this
isn't
entirely
clear,
but
in
this
model
we
we
have
to
have
kind
of
this
direct
reference
and
then
the
blue
arrows,
pointing
back,
are
representing
the
other
side
of
the
handshake.
The
this
is
okay
side,
so
I
you
have
a
direct
reference
and
then
the
other
side
is
saying.
I
trust
this
namespace
or
I
trust
references
from
this
namespace.
A
C
And
rob
the
the
black
arrow
is,
there's
a
more
explicit
reference
and
then
the
blue
one
is
a
more
widely
scoped
reference.
Yeah.
A
Exactly
so
in
this
case,
because
we're
talking
about
direct
references,
I'm
I'm
being
you
know,
these
references
are
route
to
this
specific
gateway
and
route
to
this
specific
route,
whereas
the
blue
arrows
I'm
discussing
here,
are
more,
I
trust
references
from
this
namespace
and
that's
it
just
the
namespace
as
a
whole.
I
trust
it.
So
that's
that's
what
I'm
trying
to
this
is
one
of
I
think
five
proposals
in
the
stock,
but
essentially
you
know
you
look
at
the
gateways
defining
the
name
spaces.
A
A
So
to
look
at
that
a
little
bit
more
concretely,
you
can
see
something
that
looks
similar
to
our
existing
gateway
model,
but
and
again,
this
is
this
is
not
trying
to
be
too
prescriptive
about
yaml.
This
is
just
the
the
ammo
was
kind
of
a
detail
I
tacked
on
at
the
end,
but
I'm-
and
this
is
the
only
proposal
that
has
some
yaml
associated
with
it-
I'm
really
just
trying
to
get
an
idea
of
the
directionality.
A
We
want
here
and
the
high
level
concept,
and
then
we
can,
you
know,
dig
into
yaml
a
bit
more,
but
because
this
one
seemed
a
little
bit
harder
to
visualize.
In
my
mind,
I
wanted
to
write
down
some
basic
yaml
that
could
represent
it,
and
the
specifics
again
are
not
as
important.
I
think
it's
just
the
concepts
here.
A
So
in
this
case
the
gateway
is
saying.
I
trust
http
routes
from
this
namespace
or
these
namespaces,
the
http
route
gets
a
new
concept
of
attach.
To
and
again
words
can
change,
concepts
can
change,
but
with
to
you're
saying
I
want
to
attach
to
kind
gateway,
so
parent
resource,
but
importantly,
it's
saying
I
can
attach
to
other
kinds.
A
Maybe
gateway
is
just
our
default
value
here
I
don't
know,
and
I
want
to
attach
to
the
gateway
in
namespace
infra
with
the
name
lb
and
then
potentially
I
don't
know
how
common
this
will
be,
but
potentially
you
may
want
to
attach
to
a
specific
name
of
listener
in
in
the
parent
resource,
so
this
would
be
a
way
to
accomplish
that.
We've
talked
about
these
kind
of
section
name,
references
in
other
contexts
as
well.
A
This
feels
very
similar,
very
simple
for
the
simple
gateway
example,
where
you
have
a
a
single
gateway
that
has
you
know
a
few
listeners,
and
I
just
want
to
attach
routes
to
it.
It
does,
admittedly,
get
more
complicated
if
you
have
a
gateway
with
a
dozen
plus
listeners
and
you
have
to
specify
the
listener
name
every
time
you
want
to
attach
that
to
me
feels
not
as
ideal,
but
this
is
just
you
know
one
option.
A
Similarly,
when
you're
talking
about
the
route
to
route
inclusion,
again
the
you
get
this
kind
of
direct
reference,
I
want
to
include
this
specific
route
and
then
the
route
uses
the
same
kind
of
terminology
as
it
did
to
attach
to
a
gateway,
but
this
time
to
attach
to
a
route
as
a
parent.
So
you
can.
You
can
see
this
kind
of
relationship
again.
A
I
include
this
route
for
this
path
and
then
I
attach
backwards
or
upwards
the
same
way
it
attached
to
a
gateway
and
then,
finally,
for
service,
the
service
gets
a
little
bit
more
complicated
because
I
we
we
don't
have
direct
control
over
this
api
and
so
you're
kind
of
stuck
with
some
kind
of
annotation.
A
So
this
is
this
is
proposal
one.
Let
me
stop
for
a
second
there's
a
lot
going
on
here.
Any
feedback
or
discussion
before
we
move
on.
A
All
right
I'll
keep
on
going
so
the
next
one
is
downward
references,
and
this
is
really
kind
of
most
similar
to
what
we
have
today.
So
gateway
selects
routes,
and
then
these
are
the
same
so
route
selects
or
includes
route,
service
and
and
forwards
to
service.
So
this
is
very
similar.
I'd
say
this
is
almost
identical
to
what
we
have
today,
so
it
should
feel
very
familiar.
I
just
wanted.
I
mean.
A
Obviously,
we
don't
have
the
ability
to
cross
namespaces
on
this
side,
but
if
we
were
just
going
to
extend
the
api
as
it
exists
today,
it
would
be
pretty
trivial
to
add
these
concepts
and
move
on
the
concern
I
have
with
download
references
is
we've
gotten
at
least
some
feedback
that
suggests
that
it's
it's
more
natural
to
attach
a
route
to
a
gateway
than
for
a
gateway
to
select
routes,
and
I
think
that
to
me
at
least
that
also
feels
more
indicative
of
what's
actually
happening,
so
a
gateway
can
select
things
by
label
which
may
give
the
illusion
of
control,
but
obviously,
if
you're
a
route
owner
you
you
ultimately
control
how
you
label
your
route,
so
you're
still
doing
the
attachment
to
gateway
by
how
you
label
your
route.
A
A
So
then,
the
next
couple
talk
about
reference
policy
and
reference
policy
is
again
that
that
idea
that
nick
proposed
and
I
wanted
to
explore
how
that
would
work,
and
I
think
it
works
remarkably
well
with
downward
references.
It's
fairly
easy
to
understand
in
my
mind,
so
gateway
selects
routes,
and
in
this
case,
instead
of
the
route
saying
I
trust
gateways
from
this
namespace.
A
A
The
downside
is
that
again
for
your
simple
use
case
you're,
you
know
I
just
I
just
want
to
reference
a
route
in
another
namespace,
the
examples
that
we've
covered
so
far.
The
examples
from
the
view
on
alpha
1
api
would
not
require
this
additional
resource
so
again
for
the
simpler
examples,
you're
creating
more
work
with
this
additional
resource,
but
the
additional
resource
gives
us
more
control
with
different
r
back
and
it
gives
us
a
a
more
generic
way
of
referencing
things
like
say
secrets
or
other
types.
A
A
This
works,
but,
as
you
can
see
it,
it
results
in.
I
think,
a
more
confusing
end
result
because
you
have
to
have
your
reference
policy
in
the
gateway
namespace
pointing
down
to
the
route,
so
I
trust
references
from
this
route
same
for
here.
I
trust
references
from
this
route,
but
then
service
can
never
be
an
upward
reference
because
you're
forwarding
to
it.
So
in
that
case
you
you
have
this
kind
of
combination
of
upward
and
downward
references,
and
it
results
in
a
relatively
confusing
story
for
reference
policy.
A
So
that
brings
me
to
the
last
example
that
I
have,
which
is
kind
of
a
hybrid
of
all
the
things,
and
that
says
we'll
do
upward
reference
from
gateway,
so
route
is
really
still
central.
A
So
just
I'll
just
take
a
quick
moment
and
scroll
back
up
to
the
top.
You
can
see
that
the
arrows
are
almost
identical
to
proposal
one,
but
the
idea
again
is
that
you're
referencing
you're
doing
the
the
trust
references.
These
blue
lines
are
coming
from
a
single
reference
policy
instead
of
the
service
and
route
itself
yeah.
A
So
oh
there's
a
there's
another
one.
Thank
you
mark,
yeah
mark.
Do
you
want
to
explain
what
you
were
thinking
here.
C
I
I
was
just
trying
to
kind
of
isolate
some
of
the
design
characteristics
of
some
of
these
options
as
you're
going
through
them,
because
that
was
something
that's
kind
of
present
in
every
single
one
of
them
is
one
there's
a
a
type
or
sorry
a
type
based
reference,
which
is
kind
of
like
the
bare
minimum
like
we
have
to
specify
what
type
is
being
referenced.
C
Just
that
has
to
be
explicit,
but
then,
like
the
least
specific
version
is
just
namespace
based,
and
that
would
be
like
currently
in
the
in
the
api
it
it's
that's
what
we
use
right.
Unless,
if
you
don't
have
a
label
selector,
it
will
select
all
of
that
type
of
resource
within
the
namespace
and
if
you
specify
a
different
namespace,
it'll
select
all
that
type
in
that
one.
C
Next,
one
up
is
the
label
based
reference
and
the
next
and
the
most
specific
is
the
direct
resource
reference
and
these
kind
of
exist
to
one
degree
or
another
in
all
of
them,
and
then
the
next
kind
of
characteristic
is
the
inline
versus
a
resource
based.
I
was
just
writing
that
up
which
I
think
I
guess
I
was
trying
to
to
isolate
the
the
benefits
that
gives
us,
which
I
think
the
resource
base
is
one.
It
works
for
things
more
than
just
the
route
and
the
gateway
right.
C
It
works
for
referencing
secrets,
so
that's
one
benefit,
and
then
the
other
benefit
is
that
it
I'm
trying
to
think.
I
think
that
was
the
primary
one.
Oh
yeah
services
services
don't
really
have
any
kind
of
reference
capabilities,
so
that
would
have
been
annotation
so
it
it
basically
makes
it.
You
know
more
consistent
in
having
reference
yeah
reference
semantics
for
services
and
secrets.
Basically.
A
If
you
can
write
to
services
in
this
namespace
and
someone
else
can
write
to
routes
in
this
other
namespace,
you
can,
you
can
do
cross-link
space
references,
whereas
what
we're
describing
here
is
you
may
want
to
have
someone
else
entirely.
Some
kind
of
this.
The
idea
of
reference
policy
is
similar
in
concept
to
network
policy,
where
you
can
imagine
an
org
admin
saying
hey.
I
trust
references
from
routes
to
services
across
these
bounds,
and
so
this
feels
like
a
more
organizational
policy
than
a
than
a
specific
reference.
C
It
separates
like
the
r
back
of
the
reference
from
the
resource
itself,
which
allows
like
an
administrator
to
control
that
policy
separately.
A
Itself,
yeah,
and
I
I
think
that
is
highly
valuable.
What
I
what
I've
been
trying
to
balance
here
is,
I
know
we
we
have.
A
We
already
have
an
api
that
is
fairly
complex
and
I
am
hesitant
to
add
that
kind
of
additional
concept
here,
but
I
think
the
value
it
adds
is
pretty
significant
in
the
you
know,
this
is
kind
of
a
hybrid
system
where
you
you
don't
have
it
on
this
side,
and
you
do
here.
You
know
what
one
of
the
things
that
reference
policy
yeah,
so
the
the
reason
I
should
back
up
and
describe.
Why
did
why
I
didn't
put
reference
policy
on
this
side
as
a
starting
point?
A
If
you
have
an
upward
reference
from
route
to
gateway,
you
really
want
the
gateway
to
be
able
to
describe
per
listener,
which,
which
namespace
is
it
trusts
so
as
an
example,
gateway
serves
foo.com
and
bar.com
for
food.com
it
trusts
routes
from
the
food
namespace
and
from
bar.com
and
trusts
routes
from
the
bar
namespace
and
that's
relatively
difficult
to
communicate
with
a
reference
policy
here
you
know
in
this
upward
reference
model,
it's
very
straightforward.
A
So
that's
why
I
kind
of
have
this
hybrid
in
proposal
five,
just
anyway,
with
that
said,
is
do
do
these.
Do
these
options
make
sense?
Is
there
a
preference
for
a
particular
direction
or
approach
that
that
is
standing
out
to.
A
Yeah
that
makes
sense
I
yeah
and-
and
originally
when
I
was
going
into
this,
I
thought
okay,
so
proposal
one
makes
a
lot
of
sense
to
me.
It's
it's.
It's
all
built
in
it's
a
a
standard.
You
know
no,
no
new
resources
and
it's
consistent
mostly,
and
it
avoids
any
kind
of
confusion
with
selectors.
You
get
direct
references,
so
you
know
very
clearly
what
you're
referencing
and
you
it's
easier
to
communicate
with
status.
A
If
you
know,
if
your
selector
doesn't
select
anything,
it's
unclear,
if
that
should
be
an
error
or
not,
whereas
if
you
have
a
direct
reference
and
that
doesn't
match
a
resource
or
the
resource
doesn't
accept
finding
from
you,
then
that's
a
very
clear
error
message,
so
I
I
like
the
the
direct
references
this
allows
and
the
lack
of
additional
resources,
but,
like
you
pointed
out,
harry
and
and
and
mark
the
idea
of
reference
policy
is
nice
in
the
additional
power
it
provides
for
any
of
these
different
options.
D
C
It,
I
would
say,
I'm
kind
of
leaning
towards
number
five,
because
it
does
feel
like
we
get
to
use
reference
policy
for
some
aspects,
basically
just
the
more
advanced
ones,
and
essentially
for
like
the
most
the
more
common
use
cases
you
know,
95
use
cases
will
not
have
to
need
not
to
worry
or
think
about
this
reference
policy,
especially
like
I
I
would
hate
for
like
this.
Api
is
already
complex
and
I
would
really
hate
for
their.
C
You
know,
especially
if
you
have
like
two
gateways,
and
you
know
two
routes
that
need
to
be
bound
to
like
an
external
gateway
and
an
internal
gateway
which
is
really
common
for,
like
k
native
example
for
that
to
for
each
route
to
also
require
reference
policy.
C
I
think
that
we're
not
going
to
convince
anybody
to
use
this
api
like
they're,
going
to
look
at
it
and
they're
going
to
say
that's
more
complex
than
istio
was
in
the
first
place,
so
why
you
know-
and
that's
what
I
really
worry
about
when
we
look
at
the
reference
policy.
C
A
Thanks
yeah
and
that
that
was
honestly,
I
kept
on
going
between
five,
the
the
fifth
proposal
and
the
first
proposal.
I
like
having
reference
policy
as
an
option,
because
it
does
allow
endless
extension
points
really
like
the
idea
that
hey
I
might
want
to.
I
might
want
to
reference
a
secret
in
another
name
space,
and
this
provides
a
mechanism
for
doing
that
and
the
the
thing
that
I'm
hesitant
about
with
proposal.
A
Five
is
we'd
have
to
have
a
very
clear
story
for
why
we
use
reference
policy
for
some
cross,
namespace
references
and
not
all-
and
you
know
I-
the
story
is
at
least
from
my
perspective-
that
the
gateway
to
route
has
a
a
very
kind
of
unique
relationship
and
that
you
really
want
this
to
be
per
listener
to
route.
And
you
know
you
want
each
listener
to
be
able
to
trust
a
different
set
of
namespaces,
which
is
different
than
what
we're
discussing
for
the
route
to
route
route
to
service
or
anything
else.
A
So
that's.
That's
really.
I
think
the
rationale
for
why
there's
differences
here,
but
that
may
not
be
immediately
obvious
and
maybe
confusing
to
some
users
that
you
know,
but
but
I'd
also
agree
with
what
you
said
mark
that
95
percent
of
users,
95
percent
of
users
are
going
to
end
up
using
this
route
to
gateway
as
the
only
means
of
names,
crossing
namespace
boundaries
and
the
other
ones
are
going
to
be.
At
least
I
would
think
more
fringe.
You
know
less
common
examples
than
this.
A
E
Approach,
I
I
think
kind
of
like
what
harry
said
earlier.
You
know
it's
just
seeing
this
for
the
first
time,
it's
hard
to
to
have
a
definitive
view
on
it,
but
I
think
proposal
5
seems
the
appropriate
way
to
go,
but
you
know
again,
I
need
to
spend
a
little
bit
more
time,
looking
at
it
and
the
implications.
A
Yeah
now
that
that
makes
sense
it
it
takes
a
while
to
to
process
this,
and
it
sounds
like
there's
enough
interest
in
proposal.
Five
that
I
should
for
me.
It
was
helpful
once
I
once
I
understood
proposal,
one
to
try
and
sketch
it
out
with
some
emel
just
to
understand.
Okay.
What
does
this
look
like?
More
concretely,
I
can
do
that
with
proposal
five,
as
well,
just
as
a
means
of
comparison
that
would
be
helpful,
yeah,
cool
and
yeah.
We
can.
A
We
can
run
with
that
and
definitely
want
to
get
some
more
eyes
on
this,
but
yeah
just
this
is
this
is
really
kind
of
what
I
see
is
the
culmination
of
all
these
previous
discussions
and
trying
to
shove
them
all
together
into
something
that
makes
sense,
and
it
I
don't.
I
don't
imagine
this
is
going
to
be
an
easy
process
to
get
complete
consensus
on
this.
But
hopefully
this
gets
us
a
bit.
C
A
Let
me
let
me
keep
on
moving
then
so
for
v1
alpha
2.
I
wanted
to
have
a
bit
of
a
discussion
around
timeline
here.
I
obviously
am
interested
in
giving
v1
alpha
2
out
as
soon
as
possible,
I'm
really
hoping
that
we
can
get
some
good
things
in
with
v1
alpha
2..
A
I
we've
had
a
lot
of
kind
of
core
discussions
here
and
I
think
the
the
big
ones
that
we're
trying
to
get
in,
or
at
least
that
I'd
like
to
get
in,
are
really
a
lot
covered
by
that
dock.
So
one
two
three,
the
gateway
route,
binding
route,
inclusion
and
crosstalk
space
forwarding
are,
you
know
all
things
we've
discussed
previously
pretty
heavily,
and
something
like
that.
I
tried
to
summarize
in
that
dock,
but
I
really
want
to
get
the
contents
of
that.
A
and
then
finally,
there's
been
a
fair
amount
of
discussion
around
well,
not
that
much
around
policy
attachment,
and
that's
this
large
dock
I
shared
a
couple
weeks
ago
now,
really
this
is
showing
how
we
could
attach
policy,
not
just
for
the
traditional
ingress
case
that
we've
been
very
focused
on,
but
also
how
this
could
apply
for
mesh
and
there's
been
some
good
discussion
in
here.
A
Oh,
it
looks
like
I
need
to.
Oh,
I
missed
the
follow-ups.
I
need
to
respond
on
these
so
yeah
good
discussion
here
and
encourage
anyone
to
continue
commenting
if
you've
missed
it.
But
this
is
something
I
also
want
to
get
in
and
this
this
is
not
really
much
or
any
api
changes.
I'm
not
sure
it's
more
of
a
pattern
that
I'd
like
to
settle
on
so
that
as
we're
extending
the
api,
we're
doing
it
in
a
consistent
way
across
implementations.
A
So
all
of
these
things
I
want
to
get
into
gateway
enhancement
proposals.
This
is
a
concept
that
bowie
has
a
pr
for
that,
I
think
is
almost
done.
I
think
there's
just
one
broken
link
left
and
then
it
looked
good
to
me.
I
think
there
may
have
been
a
couple
other
reviews
that
seem
promising,
but
as
soon
as
that
gets
in,
I
want
to
start
taking
some
of
these
concepts
and
turning
them
into
gaps.
A
So
we
can
continue
discussion
there
are
there
any
changes
that
we
haven't
discussed
yet
like
any
any
things
that
are
bothering
someone
with
api
that
you
know
might
be
breaking
changes
that
we
either
don't
have
in
yet
or
haven't
even
discussed
that
we've
completely
missed.
D
I
mean
there
are
smaller
ones
and
they
are
in
the
v1
alpha
2
road
map.
Or
what
do
you
call
that.
A
A
A
Thank
you,
yeah.
Thank
you
for
the
reminder
on
this.
I
meant
to
follow
up
on
this.
I
brought
this
up
at
sig
network
last
week
and
the
overwhelming
preference
well.
It
was
somewhat
of
a
preference
in
the
meeting,
but
then
some
comments
on
the
agenda
afterwards
made
it
pretty
clear
that
this
was
the
preference
for
api
group.
A
D
A
A
Can't
we
not
get
away
yeah
I
mean
yeah,
I
mean
I
I
already
have
that
the
terminology
is
is
difficult.
When
you're
talking
about
gateway
api
versus
route
api,
but
yeah,
I
it
could
be.
I
don't.
A
I
think
the
the
strong
preference
was
for
it
to
be
something
under
under
networking.kate's.
I
o
it's
I
mean
you
could
do
gateway
dash
api,
but
I
don't
think
there's
any
precedence
for
api
and
this
url
and
it
feels
weird
to
me
to
make
up
something
else.
Like
routing.net.
You
know
that
that
feels
unless
we're
trying
to
extend
it
with
other
things
in
the
future,
but
I
don't
think
so.
A
Let
me
let
me
link
this
in
the
agenda
as
something
that
is
rather
large
and
it's
not
like.
We
still
need
to
get
in.
A
A
D
D
A
A
Okay
cool,
so
it
seems
like
there's
nothing
too
big
that
we're
missing
in
scope
for
v1
alpha
2..
Thank
you
for
the
reminder
on
the
api
change.
That
is
a
big
one,
cool
all
right.
Well,
let
me
let
me
get
back
into
some
triage,
any
preference
on
where
we
start.
D
E
D
Where
you
propose
that,
if
we
default
kind
in
the
in
the
back
end
ref
to
service,
then
the
shortcut
and
the
backend
ref
has
only
a
single
line
of
difference.
Yeah,
so
is
the
shortcut
worth
it
or
not
and
does
and
is
what
we
are
discussing
in
my
preference.
I
think
leveling,
the
sort
of
playing
ground
between
services
and
other
references
is
is
better
because
it
it
removes
a
lot
of
corner
cases
like
what
this
one
is
talking
about,
and
it's
just
like
having
one
way
to
do
things.
A
Yeah,
I
I
agree.
I
it's
not
oh,
you
know.
When
I
look
at
these
two
examples.
It
is
clearer
to
me
what
this
means
than
what
this
means
right.
You
know
this
implies
a
kind
service
as
a
default,
which
I
think
is
a
very
reasonable
and
necessary
default
here,
but
still
it's
a
it's
not
quite
as
clear
for
anyone
reading
it
as
this
is.
A
But
with
that
said
I
I
agree
that,
just
in
terms
of
reliability
and
simplicity,
almost
I
having
a
single
way
to
do
things
is
going
to
be
better
than
kind
of
two
different
ways
like
what
what
we
were
running
into
that
led
to
this
discussion
is
okay.
Well,
if
we
had
a
namespace,
where
does
that
belong?
Does
it
do
do
we
have
because
we
had
either
service
name
or
backend
ref?
So
do
you
have
service
namespace
or
do
you
have
backend
ref,
dot
namespace?
A
A
D
Rob
if
you
can
scroll
up
a
little
that
provides
like
if
you
omit
the
default.
This
is
how
it
would
look
like
so
still
not
yeah
some
difference
for
sure
two
lines.
A
No,
we
can't,
as
I
was
going
to
ask
if
we
could
make
the
forward
to
a
top
like
get
rid
of
back
and
ref
ulti
like
just
have
everything
be
top
level.
You
know
forward,
to
name,
port,
etc.
D
A
E
A
A
I
could
get
confusing
so
okay,
that
that's
enough
to
convince
me
that
maybe
we
should
just
go
towards
back
end
ref,
and
you
know
something
like
this.
D
A
It
is
an
api
change.
Why
don't
we
test
out
the
process
and
and
see
see
how
painful
a
gap
is
and
the
the
hope
of
a
gap
would
be
that
it
would
be
small
enough.
You
know
lighter
weight
than
kubernetes
caps,
and
hopefully
it
wouldn't
add
too
much
overhead
here.
A
Yeah,
it
would
be
nice
to
document
some
of
the
alternatives
we
considered
instead
of
it
just
getting
hidden
in
this
pr
so
yeah.
This
is
a
good,
relatively
small
first
gap,
yeah
yeah.
Thanks
for
the
idea.
A
The
next
one
we
should
get
through
is
oh
yeah.
This
is
the
actual
guess
which
I
think
we're
just
waiting
on
one
last
change
yeah
this
the
the
markdown
link
is
confusing,
but
otherwise
it's
fine
bowie
also
uncovered
he.
I
wanna,
I
think.
Hopefully
this
is
the
last
place,
we're
using
service
apis
as
a
name,
but
they
just
keep
on
coming
out
every
now
and
then
I
just
you
know
I
never
thought
of
looking
at
service
api,
singular,
plus
apostrophe.
You
know
like
this.
A
This
particular
incantation
of
service
api,
but
it
will
be
gone
whenever
this
pr
gets
in.
D
A
Who
knew
and
then
this
is
a
larger
one
from
you
harry.
You
saw
this
listed
as
a
work
in
progress.
Do
you
think
it's?
I
know
there's
been
some
discussion
on
here
yeah,
maybe
that's.
A
D
A
D
Yeah,
so
added
an
example.
So
if
you
look
at
the
gateway
config,
if
you
scroll
a
little
prob,
there
are
two.
D
A
A
A
A
Okay,
all
right
yeah,
this
this
looks
very
close
to
me.
I
do
remember
going
through
this
earlier
great
yeah.
Let
me
let
me
take
a
another
look
at
it
later
today,
but
if
anyone
has
any
any
hesitation
about
this,
add
it
to
the
pr
soon.
Otherwise
I
just
merged
in.
A
A
D
A
Okay,
okay!
This
is
just
weird
all
right,
so
request
redirect.
How
did
I
miss
this
one?
This
is
an
empty.
Oh,
this
is
an
ancient
one.
D
Yeah,
this
has
gone
stale.
I
think
the
only
other
pr
we
have
is
the
recent
prs
conformance
yeah.
A
Let
me
let
me
run
through
that.
I
meant
to
cover
that
in
more
detail.
This
is
something
that
I
updated
relatively
recently
you'll
notice.
A
There's
two
commits
now
the
first
commit
uses
godog
the
second
commit
doesn't
so
if
you
want
to
see
with-
and
without
it's
now
included
in
a
single
pr
removing
it
was
not
that
difficult
I'd
say
it's
so
this
this
pr
is
still
very
much
a
draft
I've
been
running
through
these
tests
with
contour
and
istio,
just
to
get
some
variety
in
terms
of
you
know,
experience
running
conformance
tests
and
how
these
implementations
perform.
A
A
There
are
a
few
advantages
of
that.
You
know
like,
although
we
you
lose
the
I
kind
of
summarized
everything
here,
but
although
we
lose
some
of
the
you
know
easy
to
read,
feature
files
that
godot
provides.
I
think
this
isn't
that
hard
to
read.
Oh,
you
know
it's.
It's
fundamentally
similar.
A
It's
just
written
a
slightly
different
way.
What
I
really
liked
about
writing
tests.
This
way
is
one.
There
was
no
more
kind
of
extra
layers
of
abstraction,
so
less
could
get
broken
in
between
just
in
how
we're
writing
tests
and
it
was
much
easier
to
understand
where
a
failure
happened
because
instead
of
you
know,
okay,
so
I
look
at
this
feature
and
then
I
try
and
find
the
function.
A
That's
implementing
that
feature,
and
then
you
know
it's
it's
all
in
one
fairly
straightforward
place
and
then
we
also
get
intermediate
blogging
output
because
we
have
access
to
the
testing
variables
where
at
least
how
the
go
dog
tests
were
set
up.
Although
it
streamed
output,
it
was
not.
We
did
not
have
access
to
t
dot
log,
so
all
that
meant
at
least
as
far
as
I
could
use
it.
If
you
had
a
long
running
test,
you'd
get
output
at
the
end
of
a
test
of
a
specific
test
case.
A
But
if
you
had
a
test
case
that
waited
three
minutes,
there
was
no
way
even
with
verbose
settings
to
get
the
intermediate
output,
as
that
test
was
running,
which
you
can
obviously
easily
with
this.
I
may
just
be
missing
something
obvious,
but
that's
how
it
was
working
with
ingress,
controller
conformance
and
the
only
way
I
could
get
it
to
work
here.
So
I'm
pretty
fine
with
this
this
system,
but
I
wanted
to
get
a
bit
more
feedback
before
I
move
much
further
on
it.
A
So
if
anyone
has
time
to
take
a
quick
look,
I'm
I'm
not
in
any
way
trying
to
suggest
this
is
ready
to
be
merged
in
or
anything.
I
just
wanted
to
get
some
feedback
on
the
structure
and
rough
setup
of
these
tests
before
I
went
too
far
into
the
details,
but
these
work
I
know
they
pass
entirely
on
istio
last
I
checked.
Contour
was
not
setting
status
and
right
now
the
first
thing:
I'm
testing
a
status.
So
that's
not
going
to
work
but
yeah
that
that's
the
current
state
of
these.
A
And
I
think
we're
at
time,
so
I
encourage
anyone
who
has
time
to
pull
this
up
and
give
some
feedback,
but
thanks
so
much
to
everyone
for
the
feedback
on
this
and
we'll
talk
to
you
in
a
couple
weeks.