►
From YouTube: Service APIs Meeting (APAC Friendly Time) 20210615
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
Cool
this
is
the
gateway
api
meeting
for
june
15..
We've
got
a
few
things
on
the
agenda,
but
most
notable
is
policy
attachment,
I'm
not
sure
how
long
we'll
spend
on
this,
but
I
do
want
to
time
box
it
to
say
40
minutes
or
so.
So
we
have
some
time
left
over
for
pr
and
issue
triage.
There's
a
few
items
here
that
would
be
good
to
get
to
get
to
on
that
front.
A
Does
it
make
sense
to
do
it
in
reverse
order,
yeah
sure
yeah,
I
don't
mind
doing
that.
So
I
actually
want
to
start
on
pr's,
because
there's
a
few
pr's
that
have
just
kind
of
gotten
stuck
conformance
tests.
We
talked
about
last
week,
they're
moving.
I
I'm
actually
increasingly
okay
with
godog
this
this
pr,
although
it's
mark
league
yeah,
what's.
A
I
don't
know,
I'm
not
sure
I
I
I
so
it's
scoped
out
and
it
works
I'll
say
that
I,
a
lot
of
the
a
lot
of
the
helpers
from
ingress
controller
conformance
are
helpful,
but
the
thing
I'm
not
sure
of
is
if
the
extra
bit
of
I
don't
know
what
extra
bit
of
abstraction
here
is
helpful
or
not.
A
A
I,
like
you,
look
at
this
file
and
it's
like
yeah.
I
completely
understand
what
you're
trying
to
do,
but
you
try
and
debug
any
of
this
and
you
try
and
dig
into
it
and
it
becomes
a
little
bit
more
complicated.
So
I
know
I
said
I
was
I
I'm
more
okay
with
with
godog,
but
I
I'm
open
to
feedback
on
this
one.
I
know
there's
already
been
a
little
bit
of
feedback
on
this
pr,
but
if
anyone
wants
to
take
a
look
at
it,
I
would
appreciate
it.
It's
still.
A
You
know
it
still
is
a
work
in
progress.
I've
been
testing
it
with
istio.
I've
been
testing
it
with
contour
I've
been,
you
know,
it's
it's
easier
to
write
conformance
tests
when
they
pass
and
for
the
most
part
they
they
do
with
istio
contour
hasn't
implemented
status.
Yet
so,
since
I'm
starting
with
status,
doesn't
really
work
that
well,
but
you
can
see
how
it
could
so
anyway,
that
that's
the
state
of
this
interested
in
feedback.
A
I
have
a
corresponding
pr
that
implements
something
like
this
without
godog,
but
I'd
say,
go
dog
is
really
just
kind
of
the
layer
on
top.
It's
not
that
important
in
the
grand
scheme
of
things
all
the
helpers
and
all
the
functions
are
going
to
be
similar.
It's
just
whether
you
have
these
these
the
spec
written
in,
go
or
written
in
something
else.
B
C
Yeah,
I
think
I
mean
from
a
community
standpoint.
Go
dog
is
not
something
that,
and
I
could
be
wrong
here.
We
have
seen
in
other
spaces
in
the
kubernetes
community,
and
second,
is
this.
The
the
customers
here
are
really
are.
You
know
implementers
who
I
expect
will
be
very,
very
familiar
with
go
testing
so
so
reusing
that
would
make
their
life
easy.
A
I
I
agree
with
that,
but
I
think
so
where
we
got
stuck
in
well
stuck
is
the
wrong
word,
but
because
the
ingress
controller,
conformance
tests,
which
are
quite
new,
I
happen
to
use,
go,
go
dog
and
happen
to
use
this
structure.
A
B
Yeah,
it's
mostly
so
yes,
it's
kind
of
my
fault,
but
the
reason
I
liked
godog
was
what
you're
showing
on
the
screen,
which
is
this
nice
description
that
matched
to
some
tests.
Now,
if
we
could
do
that
in
go,
which
I
think
we
discussed
like
hey,
why
don't
we
just
put
this
and
go?
That's
fine.
I
think
it's
as
long
as
we
have
this
description
that
people
can
read
and
understand
as
part
of
the
spec.
B
That's
really
what
I
wanted,
like,
I
think,
kubernetes
e
to
e
is
probably
really
bad
for
this.
Like
you,
looking
at
the
e2e
test,
you
have
actually
no
idea
what
the
desired
state
was
like.
It's
just
like
do
this.
Do
this?
Do
this?
Do
this
and
then
like?
Does
it
pass?
Well
sure?
But
I
don't
know
what
it
actually
tested.
A
Yeah
yeah,
I
I
agree
with
that.
I'd
say
the
kubernetes
conformance
tests
are,
although
somewhat
simple
and
in
just
an
extension
of
e2e
tests
they
for
someone
that
that
is
just
trying
to
be
conformant.
It
takes
a
lot
of
effort
to
read
through
those
tests
and
understand
what
they
should
do.
C
So
so
boy
to
dig
a
little
deeper
into
that.
What
you
what
I
mean,
what
we
expect
if
we
have
this
file,
is
anybody
who's
writing
the
test
is
disciplined
enough
to
write
this
file
and
describe
it
properly.
B
Yeah,
so
it
has
to
be
structured,
I
said:
rob
like
a
sketch
was.
We
would
actually
have
a
reference
to
the
documentation
as
like
a
field
in
the
ghost
struct
or
something
so
imagine
replacing
this
with
like
a
ghost
struct
instead
of
this
yama,
and
it
would
actually
literally
like
create
a
hyperlink
to
the
to
the
documentation
so
that
we
can
run
through
the
structure
and
generate
like
a
report
with
got
it.
Yeah.
B
B
You
can
make
sense
of
each
test
case,
that's
like
what
it
actually
is,
and
then
it
links
to
the
documentation
that
describe
the
spec
or
api
or
whatnot,
and
then
someone
who's
implementing
it
can
go
run
through
and
if
it
fails,
they
can
just
click
through
to
understand
like
where
it's
coming
from
and
then,
of
course,
if
there's
some
mismatch,
then
we
can
resolve
it
in
upstream,
but
like
that's
really
what
we
need
not
necessarily.
It's
super
fancy,
like
english
text
description.
C
Yeah,
I
think
I
agree
with
that.
I
mean
I
like
the
sound
of
what
you're
like
just
describing
here.
I
think
it
it's
much
smaller
in
scope
and
much
easier
to
write,
test
against
and
maintain
right.
Like
what
happens
you
know
go
dog
decides
to.
I
don't
know,
pivot
and
or
whatever
right
so
things
like
that,
yeah.
A
Yeah,
no,
that
all
makes
sense.
I
think
this
is
all
I
would
say
that
the
vast
majority
of
this
is
is
code
that
translates
easily
to
any
top
level
test
framework,
even
like
obviously,
there's
not
much
to
this-
that
this
is
easy
to.
You
know
just
in
in
subtest
to
define
this
in
some
kind
of
go
test,
and
this
is
really
the
only
thing
that's
unique
to
go
dog
about
this
pr.
A
B
B
A
B
A
All
right
well
sounds
good.
I've
got
plan
to
work
on
with
that
and
I'll
I'll
follow
up
harry.
This
one
is
yours.
I
I
forgot
where
this
pr
got
stuck.
Do
you
remember.
C
A
A
I
I
was
arguing
that
either
we
just
shouldn't
have
service
name
or
maybe
at
least
to
start.
We
should
just
be
adding
anything
more
complex
to
backend.
Ref
like
anything
like
namespace
should
just
live
there.
Instead
of
having
to
deal
with
both
service
name
space
and
back
end
ref
name
space
and
and
if
you
need
need
a
more
complex
reference,
it's
in
back
end
ref.
C
So
what
I'm
trying
to
recall
here
is
how
is
like
that
related
to
clarifying
requirements
for
port,
like
how's,
the
namespace
requirement
here
redirected
to
I'm
sorry
how
is
like
port
and
namespace
related
here.
I
think
it's
more
about
what
happens.
A
Yeah,
okay,
all
right!
So
this
this
really
did
become
quite
tangential
and
it
was
the
the
idea
that
port
is
optional.
With
back
end
ref-
and
I
and
in
my
mind
I
was
thinking
well
back
and
rev
can
still
be
used
to
reference
a
service
and.
A
A
C
A
B
A
Yeah
so
go
ahead.
I
think
what
I
should
say
what
what
might
be
clear
here
is:
port
is
optional
for
non-service
back-ends,
something
like
that.
A
C
Yeah,
I
think
that's
reasonable
yeah
I
mean
it
might
be
ambiguous
because
what
you
suggested
like
you
could
have
a
service
and
back
and
drift.
I
don't
know
how
many
people
will
think
through
that
yeah
how
many
implementers
and
then
users
should
get
creative.
So.
A
A
Go,
oh
you've
got
a
proposal
for
enhancement
proposals.
I
think
this
just
got.
A
B
A
Yeah,
cool
harry,
you
have
a
pr
for
request.
Redirects.
I
got
some
feedback
on
here.
It's
still
marked
as
work
in
progress.
I
think
yeah
draft.
C
Yeah
I
mean
I
really
opened
this
up
to
figure
out
like
how
do
people
like
this,
so
I
know
we
have
a
couple
folks
there
like
is
this
part
of
a
filter?
Do
we
want
it
not
to
be
a
filter
like
how,
like
you
know,
maybe
folks
on
this
call,
can
give
some
additional
context
and
then
I
can
sort
of
make
it
ready.
The
reason
I
didn't
want
to
put
in
a
lot
of
time
with
something
that
we
weren't
sure
of
doing
it.
That
way.
A
Yeah,
this
is
a
good
question.
I
I
think
of
redirecting,
because
our
filters
right
now
so
far
have
primarily
been
modifiers
or
or
something
that
doesn't
affect
the
the
request.
Well
it
so
it
could
mirror
the
request.
That's
probably
the
closest
thing
to
redirect,
but
other
things
are
you
know,
modifying
headers
things
that
are
are
more
modification
than
just
which
I
guess
redirect
is
a
bit
of
a
modification.
A
B
C
C
A
So
I
don't
know
if
I'm
comfortable,
because
I
know
we've-
we've
left
that
open
for
other,
like
it's
very
possible
that
you'll
have
an
authorization,
filter
and
yeah.
You
can
drop
things
in
a
filter
right
and
and
maybe
that
even
reader
I
don't
know,
maybe
in
some
cases
that
doesn't
redirect
itself.
I
I
don't
know.
A
B
A
B
Yeah,
I
guess
it
doesn't
seem
super
fundamental
either
way.
We
just
need
to
make
sure
it's
natural
yeah
for
the
user
to
understand.
C
B
C
A
Is
there
an
argument
to
be
made
that
route
isn't
the
appropriate
place
for
protocol
or
port
redirects,
because
it
really
doesn't
have
anything
to
do
with?
Well,
I
shouldn't
say
that,
but
whereas
something
like
gateway
can
handle
that
and
and
this
could
be
more
of
a
path
redirect.
B
A
B
A
That's
fair,
okay,
so
it
should
belong
in
route.
Filter
is
not
the
worst
place
for
it.
It
may
be
the
best
place
and
yeah.
A
Like
maybe
I
mean
I
yeah,
the
only
alternative
is
to
make
another
top-level
field
that
is
on
the
same
level
of
forward
two.
That's
just
redirect
to,
and
I
see
I
think
that
is
adding
more
complexity
than
we
need.
I
think
a
filter
may
be
just
yeah,
I
mean
we
can
always.
E
E
E
Yeah
just
want
to
do
a
time
check.
A
Yeah,
I
was
just
about
to
say
the
same
thing
we're
around
halfway
through.
We
did
not
make
it
too
far
through
these
these
pr's.
So
again
a
reminder
to
so
I
actually.
As
a
as
I
was
looking
before
this
meeting,
I
was
wondering
why
didn't
this
pr
get
in
it's
so
simple,
and
then
I
realized
I
forgot
to
follow
up.
I
missed
some
feedback
from
you
harry,
so
I
will
do
that
after
this
meeting.
A
There's
this
one
just
got
lost,
it's
got
just
okay,
real
quick
because
I
see
it's
got
lgtm
approved
and
then
needs
a
rebase.
Is
it
what
what
do
we
need
to
wait
on
on
this?
One.
A
A
Yeah,
that's
yeah,
it's
a
busy
time!
Okay,
so
I
think
that
the
big
change
here
is
that
we
would
be
using
going
from
s
I's
to
host
names
as
the
field
name
inside
tls
route.
Right.
A
A
Okay,
let
me
run
over
to
the
proposal,
because
I
did
want
to
take
some
time
on
that
and
if
we
have
any
time
left
over
I'll
run
with
that,
so
this
is
kind
of
just
another.
Follow
follow-up
on
mark's
original
discussion
around
service
policy.
A
This
got
some
good
feedback
from
nick
and
steve
and
ongoing
discussion.
I
responded
to
nick
yesterday
on
here,
but
I
also
linked
to
the
doc
that's
linked
in
the
agenda
as
well.
A
I
some
of
the
concerns
that
nick
raised
about
any
kind
of
policy
attachment
here
is
that,
if
we're
not
careful
we're
going
to
end
up
with
you
know,
you
know
this
kind
of
just
api.
That's
no
longer
portable,
essentially
that
more
and
more
things
get
pushed
into
policy,
get
pushed
into
extension
points
and
we
run
the
risk
of
a
no
longer
fully
portable
api.
A
So
that
that's
my
rationale
here
for
this
doc
and
discussion,
this
is
meant
to
be
kind
of
establish
a
pattern,
and-
and
this
is
again
a
proposal
meant
to
establish
some
kind
of
a
pattern
for
how
we
attach
policy
both
if
we
have
some
kind
of
core
back-end
policy
resource
that
we
build
on,
or
maybe
it's
called
service
policy.
I
don't
know
what
it
is,
but
if
we
have
some
kind
of
resource
entry
that
we
can
define,
that
has
some
concepts.
A
I
think
this
pattern
would
be
used,
but
also,
I
think
we
would
highly
recommend
that
other
implementations
use
the
same
pattern
so
that,
as
users
switch
between
implementations
of
this
api,
they
have
a
consistent
experience.
When
it
comes
to
attaching
additional
policy,
obviously
this
is
something
that
we
can't
really
enforce
just
encourage,
but
I
think
it's
still
useful
to
have
some
guidelines
here,
as
so.
A
This
is
at
this
is
my
first
shot
at
anyway,
so
goals
that
I
had
one
were
to
establish
a
pattern
for
policy
attachment
that,
as
I
mentioned,
could
be
used
for
policies
included
within
the
gateway
api
spec,
but
in
addition
for
any
implementation,
specific
policies
that
are
used
along
with
gateway,
api
resources,
so
kind
of
both.
A
A
As
a
way
of
providing
defaults
or
requirements
within
a
namespace-
and
this
is
also
providing
a
means
of
attachment
that
works
for
both
ingress
and
mesh
use
cases
of
this
api-
I
I
mentioned
mesh
specifically
because
it's
it's
a
use
case
of
this
api.
That
really
policy
is
a
key
idea
there,
and
I
wanted
to,
as
as
I
was
thinking
about
this
at
least,
make
sure
that
whatever
we
use
for
policy
could
at
least
work
for
that.
A
I,
I
think,
there's
plenty
of
different
ways
that
policy
could
work
well
for
both
use
cases,
and
so
that
that
was
a
goal
and
provide
a
consistent
way
that
both
included
implementation.
Specific
policies
can
be
interpreted.
So
I
think
this
is
a
really
key
idea
here.
A
A
We've
had
plenty
of
discussion
about
what
could
be
attached
with
policy,
but
for
this
I
really
just
wanted
to
focus
on
a
pattern,
and
the
solution
is
that
I've
proposed
is
very
similar
to
you
know
what
what
we've
already
discussed.
I
guess
you
could
say
it's
very
similar
to
back-end
policy,
and
I
also
have
some
alternatives
that
I
explored
below
this,
and
this
is
kind
of
just
building
on
all
of
these
concepts.
It's
it's.
A
I
the
way
I
look
at
it
is,
if
you
take
the
existing
back-end
policy
and
how
that
attaches-
and
you
take
mark's
ideas
with
service
policy
and
you
try
and
merge
those
together,
you
get
something
that
looks
kind
of
like
this.
So
if
you
look
at
the
ingress
use
case,
it's
pretty
straightforward.
A
You
attach
policy
to
a
gateway
or
route
or
whatever
it
may
be,
but
in
this
case
the
timeout
policy
references
the
gateway,
so
it
says
I
want
to
apply
this
timeout
policy
to
this
gateway,
and
this
shows
a
few
important
things.
One.
Anyone
who
can
create
a
policy
of
this
type
can
apply
that
policy
to
anything
within
the
same
namespace.
A
So
it's
a
slightly
different
way
of
authorization
than
a
forward
reference
model,
but
I
think
it's
actually
pretty
powerful
well
as
powerful
as
you
could
make
it
with
our
back
in
the
sense
that
someone
within
the
name
space
can
control
timeout
policies
or
can
control.
A
That
seems
like
a
fairly
powerful
concept
that
gives
us
about
as
granular
access
control,
as
we
can
hope
for
so
in
this
pretty
simple
example,
this
time
out,
policy
would
apply
to
all
requests
through
this
gateway
and,
of
course,
you
can
just
blow
this
out
and
make
it
highly
complex.
So
you
could
attach
a
policy
here.
A
You
could
attach
a
policy
to
the
route
or
you
could
attach
a
policy
directly
to
a
service
and
again
this
is
these
kind
of
what
I
would
call
them
backward
references
but
from
policy
to
target,
and
so
they
apply
in
this
direction.
A
A
Let
me
stop
there
and
I
because
this
is
a
lot,
a
lot
of
content
here
and
I'm
not
sure
how
much
sense
it
makes.
So.
Any
questions
comments.
A
Cool
I'll
keep
on
running
all
right.
The
next
concept
is
how
this
could
apply
to
mesh,
and
this
is
a
slightly
different,
but
also
very
similar
idea.
This
idea
is,
I
want
to
apply
a
policy
to
request
from
my
namespace
to
this
service,
so
this
would
be
like
a
a
let's
say:
it's
a
mesh
specific
policy
resource,
and
I
want
to
attach
this
specific
policy
to
any
request
from
my
namespace
to
this
specific
service.
Whatever
it
happens
to
be,
this
is
a
pretty
common
concept
through
the
mesh
implementations.
A
A
I
want
to
have
a
highly
complex
example,
and
this
is
one
that
I
think
shows
all
the
different
permutations
that
could
be
possible
with
this
policy
attachment
approach,
so
one
we're
going
to
attach
a
timeout
policy
to
a
route
that
route
is
going
to
apply
to
requests
to
this
service,
and
it's
going
to
say,
hey
instead
of
sending
traffic
to
this
service.
Request
of
this
service
should
actually
be
split
between
fue
and
fubi,
and
I
really
only
want
this
specific
routing
and
this
specific
policy
to
apply
to
this
workload.
A
What
were
what
I'm
less
sure
of
is
the
policy
resources
that
a
mesh
implementation
attaches
here,
so
so,
some
of
them,
like
we're,
probably
going
to
have
some
generic.
I
don't
know
service
policy
backend
policy,
whatever
we
can
call
it
that
is
included
inside
the
core
api
and
the
gateway
api
and,
of
course,
we'd
expect
that
to
be
portable
across
all
implementations.
C
Yeah
this
is
this
is
interesting.
I
mean
I've
seen
this
pattern
does
exist
in
mesh
products,
at
least
a
couple
of
mesh
products
that
I'm
familiar
with
kuma
being
one
that's
by
kong,
yeah
and
like
this
also
overlaps
with
okay,
I
mean
it
doesn't
overlap
with,
but
this
follows
the
same
pattern
as
network
policy
right.
C
A
Yeah
I
mean
that
that's
what
I
think
is
kind
of
powerful
about
this
idea.
Is
that
we're
taking
really
familiar
concepts
like
this
is
a
concept
that's
familiar
to
gateway
api
already
and
it's.
It
applies
to
ingress,
and
you
can
look
at
this
and
say
well
hold
on
this.
This
very
similar
concept
applies
pretty
well
to
mesh
this
pattern,
this,
like,
as
I
spent
some
time
looking
at
other
other
mesh
implementations.
Otherwise,
you
know
and
and
trying
to
find
a
pattern,
and
this
this
seemed
like
a
pretty
common
one.
A
So
if,
if
you
can
say
well,
hey
this
api
is,
is
generic
enough,
but
also
provides
this
pattern
that
works
well
for
both.
I
think
that's,
that's
pretty
compelling.
E
I've
been
meaning
to
write
something
up,
but
I
think
that,
like
this,
this
kind
of
is
based
on
on
the
belief
that,
like
there
is
one-to-one
portability
or
like
what
I
would
call
like
absolute
portability,
where
it's
like
copy
and
paste
it'll
work
in
any
environment
and
then
there's
conceptual
portability,
and
I
think
that
this
is
much
more
like
this.
This
is
conceptual
portability
where
the
core
concepts
are
portable.
E
The
resources
themselves
are
not
they're
all
implementation
specific,
but
the
fact
that
the
resources
attach
all
the
implementation,
specific
resources
attach
in
the
same
manner
makes
understanding
the
entire
system
much
easier.
So
right,
it's
like
again,
it's
just
conceptual
portability
and
we
should
probably
define
that
because
actually
like
in
in
at
google
we've
been
talking
to
other
teams
about
this
that
have
networking
products
and
they've
like
the
the
first
question
is
always
well.
E
This
isn't
portable,
like
you,
can't
copy
and
paste
this
and
have
the
portable
and,
like,
I
think,
that's
kind
of
not
the
point
is
that
that's
not
really
what
users
expect
right,
because
they
there's
so
many
implementation,
specific
features
you
couldn't
use
any
of
them,
and
so
that's
that's.
What
I
feel
like
is
a
more
powerful
concept.
A
Yeah
and
just
to
build
on
that,
I
think
one
of
the
things
I'm
I'm
excited
about
the
potential
of
with
this
kind
of
consistent
pattern
is,
you
can
take,
say
a
coupe
cuddle
plug-in
if
and
and
describe
all
the
policies
that
have
been
attached
to
your
route
or
your
back
end
or
that
apply
in
a
certain
path,
and
it
doesn't
matter
who's
implementing
those
policies.
It
just
you.
A
All
right
well
I'll,
keep
on
running.
This
is
one
that
I
I
kind
of
wanted
to
dig
into
more
and
that's
the
idea
of
hierarchy,
and
this
is
something
that
mark
covered
with
the
service
policy
proposal
he
had
earlier.
But
the
idea
that
okay,
so
a
policy
referenced
at
a
gateway,
is
going
to
have
precedence
over
a
policy
at
route
over
a
back
end
kind
of
thing
and
and
similar
for
for
a
mesh
hierarchy.
A
This
is
how
I
imagined
the
hierarchy
working,
and
I
also
had
this
idea
that
again
similar
to
mark's
original
idea
here
with
service
policy,
that
you
could
have
a
required
and
a
default
concept
here.
So
in
this
case
I'm
using
the
example
to
be
clear.
This
is
nothing
that
this
this
does
not
exist,
but
and
just
trying
to
give
the
idea
of
some
kind
of
vendor-specific
policy
out
there
right.
A
This
is,
this
is
what
it
has
to
be
and
if
something
at
a
lower
level
says
is
required
for
cdn
to
be
off,
then
that's
a
conflict
and
that's
an
error
state
that
we
need
to
handle,
but
this
clearly
shows
the
intent
of
a
policy,
and
then
policy
can
also
provide
default
values
here
and
you
can
override
that
at
a
lower
level.
If
you
want
so
in
this
case,
you
have
one
policy,
that's
attached
to
a
gateway
and
one
policy
that's
attached
to
a
route,
and
you
can
see
how
the
route
is
overriding.
A
default.
A
Does
this
example
make
any
sense
again
it's
it's
probably
familiar
if
you
remember
mark's
earlier
proposal,
but
it's
just
a
slightly
different
version
of
it.
D
I
definitely
think
it
makes
sense.
I
guess
the
only
question
I
had
is
a
little
bit.
Bigger
is
just
be
clear.
Are
we
talking
about
policy
being
only
the
input,
implementation,
specific
type
parameters,
or
would
it
also
be
say
you
know
like
if
I
had
a
like
some
policy
about,
like
my
tls
config,
you
know
something
that's
directly
supported
by
the
the
gateway
api,
but
I
wanted
to
apply
it
different.
You
know
force
different
defaults
or
or
requirements.
A
Yeah,
that's
a
good
point.
We
we
do
have
a
really
similar
concept
built
into
the
api
for
tls
config
of
allow
override,
and
I
think
that
that
applies,
but
for
I
think,
the
more
generic
concept
of
policy
that
can
fit
inside
gateway
api
inside
the
gateway
api
spec.
I
think
this
same
pattern
would
apply
in
in
my
mind,
and
I
think
mark
had
written
something
out
earlier
in
an
issue.
A
A
If
less
than
half
of
implementations
can
support
any
given
concept,
I
don't
think
we
can
argue
that
it's
portable
enough
to
be
a
you
know
built-in
policy,
but
if
we
can
get
concepts
that
have
that
level
of
support,
I
think
we
should
push
for
them
being
included
inside
the
gateway,
api,
spec
and
that's
kind
of
an
arbitrary.
You
know,
I
don't
think
we'll
be
doing
precise
math
here,
but
that's
kind
of
a
rough
guideline
for
what
I've
been
thinking.
E
Yeah,
I
think,
basically,
as
a
first
class
part
of
the
gateway
api,
even
if
it's
extended,
which
is
like
you
know,
not
not
required
by
all
implementations
but
portable.
If
it
is
supported,
I
feel
like
trending
towards
that,
if
possible
is
always
better
because
it
ends
up
leading
to
a
more
streamlined
api
like
if
there's
like,
for
instance,
weights
like
weights,
I
don't
even
know
if
that
makes
sense.
Actually,
but
let's
say
that
that
was
part
of
policy
right
now.
E
So,
if
possible,
we,
I
think
we
should
air
towards
first
class,
but
might
think
the
majority
of
you
know
the
entire
configuration
universe
around
traffic
and
load
balancing
is
probably
not
first
class.
Just
because
of
how
much
is
out
there.
A
Yeah
I'd
say:
95
percent
of
the
time
people
are
using,
you
know
five
percent
of
the
features
and
those
will
be
portable
and
then
all
those
kind
of
more
obscure
features
that
every
implementation
has
are
going
to
be
harder
to
make
portable.
But
you
know
like
the
core
is
something
that
most
people
are
going
to
be
focused
on,
but
allowing
all
these
extra
features,
I
think,
is,
is
still
very
useful
and
doing
it
in
a
consistent
way.
A
Each
controller
would
be
responsible
for
populating
the
status
again,
we
don't
have
status,
but
we
would
have
status
on
gateways
and
routes
that
included
references
to
policies
that
had
been
applied
to
that
gateway
or
that
route.
Unfortunately,
we
don't
have
a
path
to
do
this
with
services
or
namespaces.
A
Yet,
but
I'm
sure,
if
this
pattern
becomes
popular
enough,
we
can
try
to
add
this
to
status
on
either
of
those
resources
upstream.
This
is
really
one.
You
look
at
this
all
these
examples
and
it
may
feel
overwhelming
and
complex,
and
one
compromise
that
I
think
helps
make
this
a
little
bit
easier
to
understand
is
the
idea
that
each
policy
can
only
target
a
single
resource
at
a
time.
A
A
So
in
my
mind,
target
references
can
cross
namespaces,
but
policies,
referencing
targets
and
other
namespaces
would
only
apply
to
traffic
originating
in
the
same
namespace
as
the
policy.
So
really,
this
is
a
mesh
specific
concept.
I
don't
know
how
to
differentiate
this.
I
don't
know
if
this
is
something
like
that.
Only
some
policies,
like
only
implementation,
specific
mesh
policies-
support-
I
I
haven't
thought
through
this
enough,
but
I
think
there's
value
in
this
being
possible
with
the
appropriate
limitations.
A
I
I
thought
a
little
bit
about
a
coupe
cuddle
plug-in
if
you
label
a
crd
appropriately,
like
as
an
example
you
have
this.
This
is
a
policy
crd.
Then
a
coupe
cuddle
plugin
can
read
from
the
crds
that
existed
in
a
kubernetes
cluster
understand
which
are
policy
resources
and
then
use
dynamic
client
to
read
from
them
as
long
as
they're
structured.
A
This
way
you
can
compute
policy
in
the
same
way,
regardless
of
the
policy
type
you're
you're
interacting
with
so
I
think
it
actually
is
possible
to
provide
a
consistent,
ux
and
understanding
of
what
policy
applies
where,
as
long
as
we
enforce
these
patterns
and
label
things
appropriately,
I
I
worked
through
some
advantages
and
disadvantages
of
this.
I
think
this
obviously
is
is
a
pretty
flexible
approach.
A
A
It
really
requires
minimal
api
changes
here
and
related
to
that,
if
you're
packaging,
an
application
or
deployment
that
includes
say
route
or
something
to
expose
your
application,
you
don't
need
policies
to
be
part
of
that
templating.
The
policies
can
be
bolted
on
just
by
targeting
that
resource,
that's
included,
so
I
think
in
a
lot
of
ways.
This
is
a
simpler
approach.
A
A
And
yeah
requires
all
policy
objects
to
implement
the
same
structure,
the
same
target,
referencing
and
yeah.
So
I
I've
covered
a
lot
here
and
I
know
we're
nearly
out
of
time.
I
just
I'll
leave
a
couple
minutes
here.
If
anyone
has
feedback,
let
me
know
I'm
I'm
interested
in
what
people
are
thinking
about
this.
C
Rob
I
just
pasted
a
comment,
I
think
yeah,
I'm
I'm
liking
what
I'm
seeing
or
what
I'm.
I
think
we
need
to
think
a
little
bit
about
is
like
how
do
we
go
about
enforcing
this
right?
Like
do
we
have
some
api
reviews
or
we
can't
really
can
we?
We
can't
really
have
tests
for
these,
or
maybe
we
could,
if
you
know
something
like
that,
yeah
I
mean
if
it
works
with
cube,
cutter
plug-in
or
things
like
that.
A
Yeah,
I
think
a
lot
of
this
right.
It's
it's
almost
like
yeah.
The
cube
cuddle
plug-in
is
really
the
the
the
source
of
all
of
this
right.
If
the
coupe
cuddle
plug-in
is
responsible
for
calculating
and
describing
how
how
policy
is
computed,
you
can
compare
that
with
your
own
implementation
of
that
policy
to
ensure
it
lines
up,
and
obviously
the
plugin
will
complain
if
crd
is
either
not
labeled
as
expected,
or
the
target
ref
is
improperly
formatted
or
does
not
include
the
fields
it
expects.
A
A
Yeah,
so
this
is
a
huge
dock,
there's
a
lot
more
I've,
I've
thought
of,
and
some
open
questions
here
about
how
this
could
be
applied
to
other
concepts.
This
is
gonna.
Take
some
more
discussion,
I'm
sure,
but
I
wanted
to
at
least
introduce
introduce
this
concept
today
and
get
some
initial
feedback,
but
I
know
we're
at
time
now.