►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210712
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
We
are
recording
this
is
the
gateway
api
meeting
for
july
12th,
and
we've
got
lots
to
cover
today.
So
again,
this
is
first
on
the
agenda.
Is
a
v1
alpha,
2
release
plan?
I
I
wanted
to
run
through
this.
We've
been
talking
about
v1,
alpha
2
for
a
very
long
time,
and
I
wanted
to
actually
reach
a
point
where
we
could
have
a
rough
timeline
for
when
we
can
actually
launch
this,
and
I
think
in
our
last
community
meeting
that
was
end
of
june.
A
So
with
that
said,
first
off
as
far
as
get
timeline
I
wanted
to
you
know
recently:
we
we
have
introduced
this
concept
of
gateway
enhancement,
proposals
and
the
goal
here
is
to
help
track
gaps
and
when
we
can
expect
them
to
be
proposed,
approved
and
implemented.
A
So
in
this
in
this
model
we
have
really
three
weeks
the
first
week
and
I'm
saying
this
is
week
one
we
introduce
new
gaps,
so
there's
a
couple
gaps.
I
wanted
to
discuss
today
at
the
community
meeting
and
just
kind
of
a
time
boxed
way,
maybe
15
or
20
minutes
on
each
gap,
and
then
we
continue
that
discussion
on
the
prs
and
the
following
week.
A
If
we
haven't
already
reached
consensus
and
the
get
pr
is
not
merged
in,
we
spend
maybe
five
minutes
or
less
covering
up
any
loose
ends
and
then
finally
giving
a
yes.
No,
this
is
ready
to
go,
and
hopefully
that's
all
it
takes
to
get
a
get
pr
in
as
an
implementable
concept
and
from
there
we
want
to
go
into
implemented
implementation
phase,
where
someone
can
actually
take
that
gap
and
turn
it
into
reality
within
the
v1
alpha
2
api.
A
This
is
just
a
really
rough
concept,
but
you
can
see
here
that
I
have
cross
namespace
references
from
routes
and
policy
attachment
today
and
then
I
wanted
to
cover
gateway
route
binding
and
I
throw
in
http
rewrites
for
next
week,
but
if
there
are
other
things
that
we
want
to
prioritize
here,
as
gaps
feel
free
to
add
them
to
the
list
feel
free
to
add
yourself
as
a
proposer
or
as
an
implementer
for
any
one
of
these.
A
So
with
all
that,
and
with
that
timeline,
you
can
do
some
basic
math
and
say
well,
hopefully
that
would
lead
us
to
a
state
where
these
are
implemented
and
checked
in
by
august
2..
Now,
obviously
these
are.
This
is
not
a
complete
list
of
everything
in
the
api.
We
have
a
lot
more
than
this
that
we
would
like
to
get
into
v1
alpha
2..
I
don't
think,
there's
anything
major,
but
there's
lots
of
little
small
things.
A
So
with
that
said,
I
wanted
to
propose
setting
a
goal
of
august
9
for
the
actual
date
that
we
think
we
can
have
everything
ready
for
v1
alpha
2
and
hand
it
over
for
the
final
step
of
api
review
since
we're
official
kubernetes
api.
Now
we
need
to
go
through
a
bit
more
process,
but
I
wanted
to
aim
for
that
date
so,
one
week
after
the
final
gap
is
and
implemented
as
when
we
want
v1
alpha
2
to
be
ready.
A
So
I've
talked
a
lot
about
this.
This
is
just
you
know,
a
process,
a
concept
that
I
I've
been
thinking
about
for
a
bit
about
how
we
can
actually
turn
all
these
broad
ideas
into
actual
real
decisions
and
api,
and
I'm
wondering
if
this
this
makes
sense
to
others.
If
this
timeline
seems
reasonable,
any
thoughts,
feedback.
A
I
will
take
silence
again.
It
has
good
news
all
right.
Let
me
let
me
keep
on
running
here.
Can
you
hear.
B
A
A
Yeah,
sorry,
okay,
all
right!
Sorry!
I
know
someone
was
speaking
and
I
missed
it.
So
go
ahead!
This.
B
Is
a
travesty
rob
I
I
can't
stand
for
this.
Oh,
I
was
curious
about
the
http
rewrites
when
we're
saying
august
9th,
but
nobody's
on
that
and
like
what's
the
kind
of
expected
timeline
for
that
one,
because
that
one's
got
to
be
in
right,
yeah.
A
This
this
one,
I
threw
out
there
it's
an
issue
that
I
created
a
while
ago,
as
is
something
that
I
thought
would
be
nice
to
have.
It's
got
an
a
few
thumbs
up
or
whatever
it.
It
seemed
like
all
the
other
gaps.
I've
proposed
here
are
rather
large
in
concept
and
take
some
thought
to
get
through
http
rewrites.
It's
it's
almost
borderline.
In
the
sense
it
almost
doesn't
need
a
gap.
A
I
want
to
go
through
the
get
process
because
we
have
it
now,
but
it's
a
simpler
concept
in
my
mind,
maybe
I'm
wrong
there,
but
it
it's
something
that
we've
had
as
a
feature
request
and
I'd
love
to
get
it
in.
If
we
can,
it
is
one
of
those
things
that
I
absolutely
recognize
is
something
like
we
can
add.
After
v1,
alpha
2
is
launched.
It's
going
to
be
fully.
A
A
A
Yeah,
that's
it
and,
and
there's
I
also
you
know
I
I've
kind
of
started
this
process
off.
So
I
put
myself
down
as
a
bunch
of
leads
for
proposing
this
and
getting
the
proposal
in,
but
there's
an
entirely
different
side
which
is
taking
that
proposal
and
actually
implementing
it.
That's
taking
all
the
code,
all
api
changes
that
proposed
and
trying
to
actually
check
that
in
as
a
separate
pr
and
if
anyone
is
looking
for
ways
to
contribute
signing
up
in
any
of
these
columns
would
be
greatly
appreciated.
A
So
if
you
have
any
bandwidth,
it's
a
great
way
to
contribute,
and
as
I
mentioned
before,
if
there
are
other
things
that
you
really
want
to
see
included
in
v1,
alpha
2
try
and
make
sure
it
gets
on
this
timeline.
A
Yeah
all
right
well,
we've
got
plenty
else
to
go
through.
So
if
there
are
no
further
comments,
I'll
keep
on
going.
A
All
right
next
on
the
agenda-
and
I
do
want
to
time
box
both
of
these
are
a
couple
gaps
I
created
in
the
past
few
days
I
get
709.
I
think
I
created
on
friday
this
both
of
these
gaps
are
not
going
to
be
new
to
anyone.
These
came
from
docs
that
have
been
circulated
and
discussed
before
this
cross
namespace
reference.
One
really
includes
bits
of
selection
policy
route
delegation
cross,
namespace
forwarding.
So
you
can
see.
These
are
all
topics
we
discussed
before
and
I'm
trying
to
merge
them
all
together
into
a
meaningful
gap.
A
So
with
that,
let
me
go
ahead
and
walk
through
this
gap
and
we
can
take
some
time
to
get
any
feedback
that
we
might
have
through
the
process
and
thank
you
to
everyone
that
there's
already
been
some
great
feedback.
I've
responded
to
some,
but
I
am
a
bit
behind.
So
let
me
work
on
that
soon,
but
before
I
do,
I
think
the
easiest
way
to
read
through
these
guts
is
actually
in
the
deploy
preview.
A
So
this
is,
I
get
709,
and
this
is
really
trying
to
merge
all
these
concepts
together
and
I'll
at
that.
At
the
outset,
try
and
time
box
this
to
around
15
minutes
at
most
20,
but
for
me,
that's
going
to
be
around
3
30
that
I
want
to
end
this
conversation
so
cross
namespace
references
from
routes.
A
If
you
look
at
cross
name,
space,
forwarding
route
inclusion
and
the
reference
policy
proposal
they're
all
tackling
a
similar
thing
of
how
can
we
safely
cross
these
namespace
boundaries?
These
are
really
common
feature,
requests,
we're
seeing
and
in
some
cases,
it's
already
possible
with
ingress,
it's
just
done
poorly
and-
and
that
doesn't
always
have
a
good
result,
and
so
it's
clearly
something
users
want,
and
we
need
to
provide
a
way
to
do
it
safely.
A
Reference
policy
gives
us
a
great
deal
of
flexibility,
and
I
think
it's
worth
digging
into
a
bit
more,
so
routes
will
be
able
to
reference
services
and
other
namespaces
and
eventually
include
routes
and
other
namespaces
for
the
sake
of
scoping
this
cap
gap
in
a
relatively
small
fashion.
This
is
not
small,
but
it
could
be
larger.
A
Like
tls
configuration
and
how
that
might
map
with
route,
inclusion
and
and
other
things
that
I
think
feel
a
little
more
complicated
and
might
deserve
its
own
gap,
but
for
now
I
just
want
to
focus
on
how
this
single
policy
concept
can
apply
to
both
cross
namespace
forwarding
that's
the
route
to
service
in
another
namespace
or
route
inclusion,
so
I'll
jump
down
to
this
really
simple,
simplified
policy.
Well
simplified
example:
in
this
case,
you've
got
a
forward
two
and
we're
forwarding
to
a
namespace,
hey
service
and
another
namespace.
A
This
does
not
look
that
that
groundbreaking,
but
the
idea
that
you
can
forward
to
something
like
in
another
namespace
is
really
quite
unique
in
kubernetes
and
so
to
kind
of
keep
that
safe.
The
proposal
is
to
introduce
a
reference
policy
that
describes
the
group
kind
and
namespace
you
trust
references
from
and,
to
you
know,
services
within
my
namespace,
so
I
trust
references
from
routes
in
namespace
through
to
services.
In
my
namespace,
that's
what
reference
policy
means,
and
you
can
imagine
that
an
admin
of
a
namespace
may
create
these
beforehand.
They
say:
okay!
A
Well,
I
trust
these
specific
connections.
These
specific
references
and
then
their
app
developers
their
route
config,
whatever
can
work
within
those
rules.
A
A
E
A
I
so
yeah
that
that's
we
have
to
be
very
careful.
Thank
you
for
it,
and
I
I
noticed
I
think
john
also
had
us
a
similar
question
on
the
pr
as
well,
and
we
have
to
be
very
careful
about
the
scope
of
this.
This
is
intended
only
for
gateway
api
implementations,
but
what
I
am
saying
is
that
this
could
apply
to
references
from
gateway,
api
resources
to
non-gateway
api
resources.
A
So
service
is
not
within
the
scope
of
gateway
api,
but
it
could
be
control.
You
know,
references
to
it
could
be
controlled
via
this
resource,
at
least
from
the
the
concept
of
gateway
api.
Now,
similarly,
you
think
of
service
import.
That's
a
multi-cluster
resource,
that's
also
not
really
in
the
scope
of
this
api,
but
it's
something
that
could
be
affected
by
it
now.
I
do
not
want
this
to
become
a
generic
thing.
That's
used
across
all
of
kubernetes.
This
is
very
much
a
gateway.
F
A
G
Yeah
yeah,
I
think
when
I,
when
I
initially
thought
I
had
the
same
thought
rob
when
when
I
was
initially
writing
the
selection
policy
thing
was
like
oh
hey.
This
might
be
useful
for
lots
of
different
types
across
native
space
resources,
but
I
think,
as
bowie
says,
it's
really
important
to
make
sure
that
we
keep
this
tightly
scoped
too
we're
proposing
this
for
the
gateway
api.
Only
you
know
hey.
G
Maybe
if
you
like,
like
the
idea-
and
you
want
to
use
it
somewhere
else,
that'd
be
neat
but
like
the
scope
of
this
is
for
gateway
fbi,
yeah
yeah.
Get
that
one
thing.
One
thing
that
I
had
that
I
haven't.
I
haven't
looked
at
this
yet
nothing
man,
sorry,
but
one
thing
that
I
thought
of
a
lot
when
I
was
doing
the
initial
selection
policy.
G
One
is
that
the
design
of
the
like
what
what
you
actually
do
for
the
structs
is
reasonably
important
in
those
from
and
two
stanzas,
and
I
think
that
to
me
to
mandate.
G
I
originally
had
the
same
structure
used
for
the
from
and
the
two,
but
I
think
to
make
sure
that
it's
only
this
namespace,
you
actually
have
to
have
a
different
one
so
like
that,
the
two
needs
to
not
have
a
namespace
field
in
it,
because
the
two
is
always
this
name
space,
and
so
it's
quite
important
that
the
two
does
not
have
a
name
space
field.
A
That's
that's
that's
great
to
hear
actually
that
I
came
across
that
exact
same
like
aha
moment,
not
not
too
long
ago
like
yes,
these
do
have
to
be
different
yeah.
I
completely
agree
so
yeah
just
just
to
build
on
that.
I
I
wanted
each
reference
policy
to
start
with
a
single
from
and
two
section.
It
would
be
very
easy
to
build
a
list
of
lists
inside
this,
but
reference
policy
is
similar
to
network
policy
and
concept
in
that
it's
really
additive.
A
So,
although
you
could
have
a
list
of
from
statements
in
it
well,
you
could
have
this
entire
spec
concept,
as
I
have
it
right
now
in
a
separate
list.
I
think
it's
simpler
to
avoid
that.
So
let
me
dig
into
the
actual
details
of
this
api.
A
There's
a
from
and
a
two
the
from
is
just
exactly
as
you
would
think,
and
it's
to
describe
where
references
can
come
from
and
the
two
describes
what
may
be
referenced
from
from
for
for
lack
of
a
better
term
there.
Each
needs
to
have
at
least
one
item
in
the
list
and
if
you
go
down
into
from
you
see
that
from
includes
group
kind
and
namespace,
so
it
allows
you
to
say
I
trust
resources.
A
I
trust
hp
routes
in
namespace
foo
and
then
in
your
two.
It
would
be
to
reference
services,
so
you
just
have
group
and
kind
and
exactly
what
what
nick
just
mentioned,
you
should
not
have
namespace
in
this
scope,
because
the
whole
idea
of
reference
policy
is
you're.
Trusting
re
you're,
trusting
cross
namespace
references
into
your
namespace.
A
G
Yes,
I
accept
references
into
my
namespace,
but
like
that,
there's
there's
no
control
on
outbound
references,
there's
only
control
of
inbound
references
and
the
reason
for
that
is
that
the
control
on
outbound
references
is
expected
to
be
that
an
object
has
to
reference
something
that's
in
another
namespace
all
right,
so
that
the
control
on
outbound
references
is
the
actual
reference
itself
right.
So
there's
no
point
having
a
reference,
an
outbound
reference
policy
when
it's
going
to
have
the
same
stuff
in
it
as
the
actual
reference
itself
will
have
yeah.
G
So
the
yeah
I
when
I
was
originally
noodling
about
selection
policy,
I
did
consider
having
a
thing
where
you
can
control
outbound
references
as
well,
but
it
doesn't
actually
add
any
utility
on
top
of
just
having
a
reference
itself,
and
that
was
one
of
the
things
that
came
up
when
people
were
looking
at
that
dock,
that
a
few
people
sort
of
said.
Well,
why
would
I
have
a
ref,
an
outbound
reference
at
all,
and
I
was
like
well
yeah.
You
actually
don't
need
it.
G
A
That
is
a
great
way
to
I
should
I
should
write
that
specific
summary
down
somewhere,
because
that's
a
good
way
to
describe
it.
I
ran
through
just
a
few
benefits
here,
it's
very
similar
in
concept
to
network
policy
and
other
concepts
here,
and
I
think
it's
it's
fundamentally
familiar
to
users
of
kubernetes.
A
I
I
think,
there's
a
lot
of
benefits
with
this
approach
and
it's
just
so
much
better
than
another
approach,
I'd
considered,
which
I
can
get
down
into
alternatives,
but
just
you
could
annotate
all
these
resources.
You
could
annotate
service
and
say
I
trust
re
references
from
foo
or
bar
name
space,
but
it
just
that
gets
very
messy
very
quickly,
and
I
think
this
is
just
so
much
better
and
more
flexible.
A
There
is
one
exception.
I
added
here
that
is
kind
of
new
talking
through
this
and
trying
to
figure
out.
Are
there
exceptions
to
this
rule?
Are
there
things
where
reference
policy
may
not
apply,
and
apparently
my
list
formatting
did
not
come
through
here,
so
I'll
fix
that.
But
there
are
some
cases
I
think,
and
we
need
to.
I
encourage
a
great
deal
of
feedback
here.
A
I
don't
know
that
we
have
time
to
get
into
the
weeds
today,
but
I
think
there
are
some
mechanisms,
especially
traffic
originating
from
side
cars,
where
this
kind
of
reference
policy
may
not
make
as
much
sense
and-
and
so
let's
say
that
there
are
other
mechanisms
that
may
apply
so
your
traffic
is
originating
from
the
same
place.
It
would
otherwise
originate
so
that
you
don't
need
what
we're
really
concerned
about
with
reference
policy
is
traffic,
bypassing
controls
in
some
way,
and
reference
policy
helps
us
avoid
that
concern.
A
If
your
traffic
is
already
originating
from
the
same
source.
That
otherwise
would
I
think
there
are
potential
ways
you
could
argue
you
could
exclu.
You
could
create
exceptions
for
those
implementations.
I
don't
think
that
ever
applies
to
ingress
at
all,
but
there
are,
it
may
apply
to
some
mesh
implementations.
A
I
need
to
work
on
the
wording
here
and
try
and
figure
out
the
specifics
of
what
this
means,
but
I
I
recognized,
as
I
was
writing
this
out,
that
it
doesn't
universally
apply
to
all
potential
implementations
of
the
api,
and
I
need
to
scope
that
appropriately.
But
feedback
on
this
exceptions.
Section
is
very,
very
welcome
so.
G
To
put
that
another
way,
are
you
saying
that,
in
the
case
that
you've
got
some
sort
of
other
compensating
control
to
to
handle
the
the
cross
namespace
reference,
then
having
a
reference
policy
as
well
as
kind
of
redundant?
A
Yeah
this
is
this
is
a
a
generic
mechanism
that
enables
this,
but
I
we
need
to
recognize
that
there
are
other
implementations
that
where
network
policy
may
apply,
network
policy
does
not
traditionally
apply
to
ingress,
but
it
may
apply
to
you
know:
cross
namespace
mesh,
you
know
east-west
traffic,
it
may
apply
to
other.
You
know
other
things.
It
doesn't
apply
to
all
measures.
A
A
G
So
it's
like
something
like
an
implementation,
may
opt
out
of
a
reference
policy
functionality
if
and
only
if
the
cross
namespace
traffic
is
controlled
in
some
other
fashion.
If
so,
the
implementation
must
document
that
the
that
it
does
not
that
it
does
not
use
reference
policy.
A
Yeah,
that's
yeah,
exactly
yeah
that
that's
a
good
summary
the
last
bit
of
this.
This
proposal
here
is
in
adding
a
namespace
field
to
the
forward
two
and
back
and
ref,
and
that's
really
just
to
enable
the
cross
namespace
forwarding.
So
all
of
that
reference
policy
work
is
really
just
to
make
the
seemingly
tiny
change.
A
Of
course,
I
think
it
also
really
enables
route
to
route
inclusion
in
the
future
and
other
potential
use
cases.
I
I
think
this
is
a
very
flexible
model,
so
I'm
excited
about
getting
it
in,
but
I've
I've
spoken
a
lot
about
this,
I'm
interested
in
what
others
think
is.
Is
this
a
reasonable
approach
to
move
forward
with
any
kind
of
concerns
here.
G
I
mean
obviously
I'm
in
favor
of
it,
since
you
know
I
did
a
lot
of
similar
work
and
I
think
the
other,
the
other
use
case
that
I
have
seen
in
the
past.
I
think
john
raised
a
few
queries
about
it,
which
I
think
are
probably
fair,
but
things
that
I
have
seen
used
are
the
thing
that
contour
does
with
the
tls
certificate
delegation,
because
you
can
use
any
use
this
for
any
reference.
G
You
know
in
a
lockdown
namespace,
but
you
can
refer
to
the
secret
in
other
things,
and
as
long
as
the
controller
has
access
to
read
it,
the
person
who
owns
the
namespace,
that's
referring
to
the
to
the
secret,
doesn't
have
to
be
able
to
see
the
secret
so
for
sensitive
tls
keypairs
is
the
ingress
use
case
that
that's
really
useful
for
and
reference
policy
as
a
stance.
A
A
Obviously
this
is
a
relatively
small
starting
point
for
reference
policy,
but
I
think
we
can
expand
it
a
lot
in
the
future,
so
yeah
cool
all
already
some
good
feedback
that
I
I
need
to
follow
up
on
on
this
pr.
But
again,
this
is
pr
711,
so
appreciate
any
any
feedback
on
here
and
I'll
I'll
be
active.
I
really
am
trying
to
get
this
pr
in
this
week.
A
You
know
by
monday
of
next
week,
and
so,
if
at
all
possible,
I
would
I
would
like
feedback
as
as
soon
as
possible,
just
to
keep
this
process
moving
and
make
sure
we
can
get
v1
alpha
2
out
the
door
sometime
soon
all
right.
Well,
I
know
I
said
I
was
going
to
time
box
that
a
couple
minutes
over
there,
so
let
me
run
on
to
713,
which
is
policy
attachment.
A
If
that
last
gap
looked
big,
this
one
is
even
larger,
so
yay.
This
is
a
policy
attachment.
This
is
also
really
coming
back
from
a
dock
that
I
was
proposed
a
few
weeks
months.
I
don't
know
I've
lost
track
of
time,
but
it's
it's
linked
in
this
gap
as
well.
A
So
this
one
is
really
trying
to
standardize
policy
attachment
and
it's
somewhat
unique
in
that
it
really
doesn't
make
many
api
changes
or
propose
many
api
changes
to
gateway
api
itself.
It
proposes
a
pattern.
It
proposes
an
attachment
pattern
and
a
few
tweaks
within
gateway
api
that
can
enable
that
attachment
pattern.
But
this
is
not
not
as
much
an
api
change
as
it
is
proposing
a
pattern
that
can
hopefully
work
as
broadly
as
possible
so
that,
even
though
users
may
be
you
know,
every
implementation
may
have
its
own
different,
unique
policies
that
they
support.
A
Users
of
this
api
get
a
consistent
experience
when
it
comes
to
attaching
those
policies
and
moving
in
between
implementations.
So
with
that
said,
I
there
were
really
two
concepts
here.
I
was
trying
to
merge
together,
because
policy
attachment
is
a
a
pretty
large
and
broad
scope.
A
One
is
obviously
I
wanted
to
provide
a
way
to
attach
policy
for
traditional
ingress
use
cases.
This
is,
you
know,
gateway
through
to
route
through
to
back-end
service
and
from
them
the
most
simple
example.
This
is,
you
might
want
to
attach
a
timeout
policy
or
some
kind
of
policy
to
a
gateway,
and
that
would
apply
to
all
requests
to
that
gateway.
A
A
So
this
is
a
fairly
simple,
simple
use
case.
It's
pretty
easy
to
see
how
this
would
expand,
though
you
could
say
I
want
to
attach
a
timeout
policy
gateway,
a
retry
policy
on
the
route
and
a
health
check
policy
on
the
service.
These
are
all
kind
of
made
up.
I
don't
know
that
everyone
would
have
different
policy
resources
for
each
of
these
concepts,
but
hopefully
it
at
least
shows
the
concepts
where
we're
getting
at
them,
where
different
policies
might
be
attached
now.
A
Another
another
more
recent
potential
use
case
and
implementation
of
this
api
is
mesh
and
for
mesh
there's
a
great
deal
of
overlap.
You
know
between
these
two
use
cases
and
we
want
policy
attachment
to
be
as
similar
as
possible.
A
So
in
this
case
you
look
at
timeout
policy.
Well,
I
want
to
apply
a
specific
timeout
for
requests
from
my
namespace
to
servicefu
and
this
other
namespace,
and
so
you
just
create
your
timeout
policy
in
the
consumer
namespace
and
target
this
service,
and
it
it
just
works.
That's
the
timeouts
that
apply
to
users
to
decide
cars
in
your
mesh,
making
requests
to
that
service.
A
That's,
I
think,
the
most
simple
example
of
policy
attachment
for
meshing
how
it
could
work
in
this
world
a
more
complex
example.
I
think,
is
this:
really,
let's
try
and
do
everything
right.
So,
let's
add
a
route.
Let's
say
we're
going
to
target
this
service
with
host
name,
foo
and
forward
traffic
and
and
split
traffic,
split
requests
that
were
intended
for
foo
between
fue
and
fubi,
so
you're
introducing
some
traffic
splitting,
and
we
want
to
also
apply
this
timeout
policy
which
is
being
attached
to
the
route.
A
A
So
that's!
That's!
All
existing
we've
already
covered
that
in
previous
discussions
about
policy
attachment.
What
is
relatively
new
here
is
this
target
ref
api.
I
went
through
and
tried
to
sketch
out
what
made
sense
to
include
in
this
target
ref,
because
really
so
much
of
this
whole
discussion
is
around
how
you
can
reference
resources
attach
policy
consistently.
A
Most
of
this
is
going
to
look
like
your
standard.
Everyday
object.
Reference
in
kubernetes
you've
got
a
group.
You've
got
a
kind,
you've
got
a
name.
These
all
look
familiar.
One
relatively
new
concept
is
a
section
name.
This
is
the
name
of
a
section
within
the
target
resource.
In
some
cases
it
could
be
helpful
to
attach
policy
to
a
gateway
listener,
to
a
route
rule
or
to
a
specific
service
port.
A
Again
I
don't
imagine
this
is
going
to
be
the
most
common
use
case,
but
introducing
the
concept
of
section
name
could
be
helpful
here,
but
I
think
it
can
also
be
helpful
in
other
discussions
like
the
gateway
route
binding,
but
I'm
not
going
too
far
down
that
that
rabbit
hole.
Quite
yet
so
that's
section
name.
A
Namespace
is
the
namespace
of
the
reference,
so
adding
an
optional
namespace
field.
This
feels
like
something
that
will
almost
never
apply
to
ingress
use
cases,
which
is
why
I've
left
it
under
extended
and
optional.
But
what
it
allows
is,
let
me
scroll
back
up
for
a
second,
this
example
right
here.
The
idea
of
I
want
to
apply
policy
to
a
service
and
in
a
different
name,
but
of
course
it
only
applies
to
requests
from
my
local
namespace,
so
you're
not
really
doing
anything
to
affect
the
producer.
A
I
think
this
is
really
intended
for
you
and
finally,
the
last
concept
here
is
class
name,
there's
been
some
discussion,
some
feedback.
I
got
on
the
dock
about
how.
How
can
we
limit
what
a
policy
applies
to?
There
are
some
cases
where
you
may
want
a
policy
only
to
apply
to
a
specific
class,
a
specific
gateway
class.
For
instance.
Let's
say
you
have
a
policy
you
only
want
to
apply
to
east-west
traffic
or
whatever
it
might
be.
A
I
think
class
name
is
our
best
way
of
representing
that
so
saying
I
want
to
restrict
this
policy
to
only
apply
to
traffic.
Using
this
specific
gateway
class
seems
like
it
may
be
our
best
option
here,
I'm
very
open
to
feedback
on
this
one,
but
this
this
is
the
most
recent
edition
in
this
in
this
list,
at
least
in
my
mind,
but
I
think
it
gives
us
a
little
bit
more
flexibility
when
it
comes
to
policy
attachment.
A
G
One
small
thing
for
me
that
in
the
namespace
thing
it
should
you
should
say
even
when
a
policy
targets
a
resource
in
a
different
name
space,
it
must
only
apply
to
traffic
may
if
you're
talking
rfcs
may
means
can
choose
to
so
must
you're
completely
right
yeah.
Thank
you.
H
Yeah
I
just
wanted
to-
I
guess,
highlight
the
class
name
aspect
of
this.
I
think
I
think
it's
really
useful,
I'm
wondering
to
others
how
they
think
this
might
be
implemented
now.
Obviously,
these
policies
are
all
controller
specific
right,
so,
like
generally,
two
different
controllers
will
not
use
the
same
policy
crd
because
they're
all
you
know,
custom,
but
a
controller
might
have
might
have
different.
You
know
it
would
support
different
gateway
classes,
and
so
I
guess
the
the
intention
here
is
like
let's
say
I
have
an
external
gateway
class.
H
A
Yeah
that
that's
my
intent
and
I
recognize
and
and
thank
you
for
calling
that
out-
I
recognize
that
can
add
significant
implementation
complexity,
but
I
I
do
think
it's
a
worthwhile
and
in
some
cases,
necessary
distinction
to
make.
G
I
think
that
it's
pretty,
it
is
pretty
useful
in
exactly
that
use
case
in
the
ingress
use
case.
It
is
really
useful
to
be
able
to
say
you
know,
even
for
something,
that's
basically
just
talking
about
policy
right
to
be
able
to
say
if
you're
referring
to
this.
If
this
is
coming
from
external,
then
it
has
this
timeout
policy.
If
it's
coming
from
internal,
has
this
timeout
policy
that
that
does
seem
like
it
would
be
useful
to
me.
G
A
I
I
actually
had
controller
name
first
and
I
thought
well
hold
on.
You
know
that
that
that
may
not
be
sufficient.
So
I
I
went
the
next
level,
but
yeah.
F
Yeah
I'd
agree,
I
would
agree
with
nick
and
controller
name
would
not
be
ideal
from
from
my
perspective
as
well
causing
problems
for
us.
So.
F
H
Rob
should
this
be
a
list
or
is
it
supposed
to?
I.
A
I
thought
about
that,
but
I
I
honestly
don't
know
how.
Broadly
I
I've
been
trying
to
keep
this
as
focused
and
possible
as
possible
here,
so
it
I've
also
kept
target
ref
to
be
a
single
object
and
if
we
need
to
there's
plenty
of
precedent
for
changing
a
single
object
into
a
list
in
kubernetes
apis
in
non-breaking
ways,
so
it's
something
we
could
expand
to
in
the
future.
But
I
would
love
to
avoid
it
as
long
as
we
possibly
can.
H
Yeah,
I
am,
I
feel,
like
sorry,
god,
kicker
now,
you're
good,
I
was
gonna
say.
I
think
that,
like
how
this
will
end
up
getting
used
will
depend
a
lot
on
how
all
the
implementations,
like
the
shape
of
their
service
policy,
crds
like
how
shared
are
they
amongst
gateway
classes?
What's
the
granularity
like,
I
know
that,
like
we've
talked
about
it
internally
for
gke
that,
like
they
there's
definitely
a
balance
like
we
certainly
don't
want
a
service
policy
resource
for
individual
fields.
Like
kind
of
the
examples
like
we
will
make
them
as
big
as
possible.
H
That
makes
sense
like
we
have
like.
We
have
a
whole
basket
of
features
for
cdn.
We
have
a
whole
basket
of
features
for
for
cloud.
For
you
know,
cloud
firewall
and
those
worth
kind
of
thinking
would
each
be
its
own
crd.
That
has
like
you
know
anywhere
from
like
five
to
20
fields
or
something
like
that
and
not
clear
whether
we
would
how
much
they
would
be
shared
between
different
classes.
Right,
like
our
external
load,
balancers
support,
all
these
waf
capabilities,
the
internal
ones,
don't
have
the
same
capabilities.
H
We
probably
would
want
to
reuse
the
same
crds
and
some
of
the
fields
just
wouldn't
be
relevant
for
some
gateway
classes.
And
so,
if
there
is
a
high
degree
of
sharing
between
then
that
probably
points
towards
we'd
want
to
make
this
class
name
a
list.
If
there
isn't,
then
it'd
probably
be
easy
for
it
to
be
just
an
individual
class
name,
but.
G
G
Yeah
yeah,
I
think
yeah
it
doesn't
contour
like
we
already
have
inside
http
proxy.
We
already
have
timeout
policy
load,
balancer
policy
health
check
policy
as
like
structs
on
their
own,
so
we
will
probably
be
just
lifting
those
and
turning
them
into
cds
for
this
sort
of
thing
anyway,
and
to
be
honest,
there's
a
good
chance,
I'm
going
to
lift
this
whole
thing
and
bring
it
into
the
and
make
it
work
with
http
proxy
as
well,
because
then
it's
the
same
mechanism,
yeah
that'd,
be
awesome.
A
Cool,
let
me
let
me
keep
on
running.
I
know
I
wanted
to
we're
running
out
of
time
on
this
one.
Just
take
a
couple
more
minutes.
I
wanted
to
propose
a
new
policies.
Field
on
that
would
be
added
in
status
for
gateways
and
routes.
This
seems
like
at
least
to
me.
It
would
help
provide
visibility,
but
john
has
already
pointed
out
in
the
pr
that
there
are
some
limitations
like
that
from
from
this
one,
it's
a
scale
limitation
if
you
have
tons
of
policies
applied,
but
two.
A
What
I
was
originally
thinking
here
is
this
would
apply
to
policies
that
directly
referenced
a
route
so
route
dot
policies
includes
policies
that
have
been
directly
attached
to
that
route.
But
since
we're
talking
about
hierarchy
and
some
concept
of
you
know,
inferring
defaults
from
above
a
policy
status
may
become
confusing
in
the
sense
that
you
only
see
your
tiny
little
local
piece
of
the
picture
or,
alternatively,
you
see
a
really
huge
overwhelming
list,
neither
of
which
seem
great.
A
So
I
I
don't
actually
have
a
good
solution
to
this
one
yet,
but
that
is
some
some
limitations
of
a
policies
field
on
route
or
gateway
status.
So
if
anyone
has
thoughts
on
how
we
can
address
those
concerns,
I'm
open
to
them,
I
want
to
jump
ahead.
Actually,
the
other
way
that
I've
proposed
making
this
a
little
bit
simpler
to
understand
is
a
coupe
cuddle
plug-in.
A
G
I
think,
in
terms
of
status,
it's
a
good
idea
to
crib
from
the
idea
of
conditions
here
and
say
you
can
subclass
the
you
know
you
can
embed
the
the
core
definition
of
like
what
a
policy
is
as
long
as
it
as
long
as
whatever
you
have
pipes
back
to
these
you
know
has
these:
has
these
fields
and-
and
you
can
duct
type
it
back
to
a
thing
that
is
referenceable,
then
then
a
q
plugin
will
work
or
anything
else
can
also
infer
information
about
the
cid,
even
without
knowing
the
full
structure,
the
full
spec.
A
Yeah
agreed,
I
think,
if
we,
if
we
have
a
consistent
structure,
which
I
think
this
this
back
outline's
reasonab,
it
would
be
consistent
enough.
I
think
you
could
get
some
pretty
useful
information
out
of
a
plug-in
out
of
some
kind
of
standard
standard
way
of
interpreting
policy,
and
I
think
that's
going
to
be
universally
helpful
to
all
implementations
of
this
api
yeah.
So
there's
there's
a
lot
more
in
this
gap.
I
don't
have
time
to
get
through
all
of
this.
A
A
At
this
point,
I
had
had
a
brief
conversation
around
this.
I
think
with
with
harry
about
how
how
this
could
interact
and
there's
definitely
a
lot
of
overlap
between
a
policy
attaching
to
a
route
and
a
filter
within
a
route
pointing
out
to
a
custom
resource,
they're
they're,
a
very
similar
concept,
and
what
I
have
suggested
right
now
proposed
right
now
is
that
there
should
be
no
overlap.
A
So
if
something
can
serve
as
a
filter,
it
should
not
be
a
policy,
and
if
something
is
a
policy,
it
should
not
be
a
filter.
There
is
certainly
room
for
merging
those
concepts,
but
if
we
do,
we
really
have
to
figure
out
how
things
like
precedence
and
hierarchy
actually
work
for
now.
I
think
it's
simplest
to
consider
them
separate
concepts
that
don't
overlap.
H
C
H
H
A
Let
me
let
me
run
up
here
to
one
other
point.
I
want
to
highlight.
A
The
idea
that
it's
it's
really
similar
to,
I
think,
mark
originally
proposed
that
the
allow
override
concept-
so
I
don't
think
enforce,
is
the
correct
word
here,
but
what
I'm
trying
to
describe
here
is
essentially
the
inverse
of
allow
override.
So,
let's
say
no
over,
I
I
don't
know,
maybe
there's
a
better
term,
but
basically
these
two
structs
that
can
exist
in
any
policy
resource
and
when
they
exist
our
plug-in
anything
interpreting
policy
resources
would
understand
that
anything
below
this
in
our
hierarchical
model
cannot
override
this
specific
value.
A
What
this
does
not
mean
is
it?
You
know
if
something
is
already
enforced,
a
layer
above
this
that
that
is
what
it
is
right.
You
can't
this
is
really
just
saying
nothing
below
can
override
it.
It's
not
talking
about
anything
above
in
in
the
terms
of
hierarchy,
so
this
is.
This
is
really
coming
back
to
that.
Allow
override
concept
just
in
a
different
way.
I
think
this
is
not
the
right
term,
though
so
suggestions
very
welcome
for
naming
on
this
one
or
other
ways
to
handle
this.
A
I
I
started
with
required
actually
and
came
full
circle
with
the
stop
at
final
and
then
in
four,
it's
been
around
but
yeah.
Something
like
something
like
here:
suggestions.
A
I
think
the
the
biggest
concern
with
enforce
that
I
had
is
that
someone
may
attach
a
policy
at
some
kind
of
low
level
that
could
be
overridden
above
and
they
may
look
at
enforce
and
say.
Well,
I
know
this
is
going
to
be
true,
whereas
something
like,
like,
let's
say,
no
override
a
bad
name,
but
it's
clear
that
this
just
means
nothing.
G
You're
overriding
cdn
enabled
true
for
any
child
for
any
descended
descendant
policies
but
like,
but
you
can
override
an
override
right
like
because,
if
you're
higher
up
the
tree,
then
you
get
to
go
first
right
like
and
so
the
way
that
you
process
this
tree
of
pro
policies,
then,
is
that
you
take
overrides
from
high
up
and
they
get
blasted
through,
like
they
get
blasted
through
all
the
way
down
and
then
and
then
you
take
any
defaults
to
the
left
over
yeah.
Actually
I
I
like
that.
Okay.
C
C
C
A
Yeah
I
I
agree
that
there's
some
level
of
ambiguity
when,
when
it's
just
override,
I
mean,
if
you're
familiar
with
the
model,
you
recognize
that
override
is
overriding
things
below
you,
not
above
you,
but
if
you
had
some
concept
of
dick
directionality
in
there
like
override
child,
maybe
that
helps
but
the
longer
the
name,
the
the
greater
likelihood
of
typos
so
yeah,
okay.
A
Well,
we
are,
we
have
blown
past
my
time
box
on
this
one,
but
some
great
feedback
all
around
here
again,
I'm
really
really
hoping
that
we
can
get
these
gaps
in
in
the
last
in
the
next
week,
the
next
seven
days.
That
means
I'm
going
to
try
and
be
as
responsive
to
feedback
as
possible
and
just
trying
to
to
move
on
these
as
quickly
as
possible,
because,
as
a
reminder,
my
my
goal
here
is
to
get
both
of
these
gaps
approved
july,
19
and
then
implemented
and
merged
in
by
july
26th.
A
So
any
help
we
can
get
along
the
way
through
feedback
and
just
consistently
digging
into
these
pr's
would
be
great.
I
do
want
to
make
kind
of
concrete
decisions,
and
just
have
these.
These
timelines
be
relatively
firm
just
so
that
we
can
actually
make
some
progress,
make
some
final
decisions
and
get
v1
alpha
2
moving
again
so
yeah,
that's
that's.
A
My
goals
feel
free
to
suggest
different
timelines
for
anything,
but
this
is
really
what
I
would
prefer
in
terms
of
getting
things
out
the
door,
and
with
that
I
would
love
to
get
to
pr
an
issue
triage,
but
I
think
we
are
just
out
of
time.
So
thank
you.
Everyone
for
the
great
great
discussion
on
this.