►
From YouTube: Kubernetes SIG API Machinery 20230823
Description
- [shaneutt] discuss policy attachment from Gateway API
Related:
https://gateway-api.sigs.k8s.io/geps/gep-713/
- [jpbetz] quick request for KEPs authors to announce what they have planned for 1.29 and ask that they line up (identify and request review bandwidth from) KEP reviewers
- [fedebongio] we did submit our 1 minute intro video to KubeconNA 23, will see if we make it!
A
B
And
good
morning,
good
evening,
good
afternoon,
depending
on
where
you
are,
this
is
Sig
API,
Machinery
kubernetes
by
weekly
meeting.
My
name
is
Federico
and
Giovanni.
We
have
a
short
agenda
today,
but
nevertheless
it's
going
to
be
great.
So
thank
you,
Shane
for
bringing
the
topic
and
for
joining
the
meeting.
I
will
leave
it
to
you
to
start
it.
C
We
have
this
concept
of
policy
attachment
which
we
would
probably
characterize
it
as
very
useful
and
necessary
for
a
a
variety
of
networking
related
things
that
we
need
to
do,
but
also
problematic,
because
of
how
references
between
objects
work
with
policy
attachment.
Today,
the
biggest
drawback
of,
let
me
actually
go
back
and
Define
and
then
I'll
talk
about
the
drawbacks.
C
Hopefully,
that's
clear
enough:
if
there
are
any
questions,
please
do
raise
your
hand
at
any
point.
If
you
want
to
interject
or
ask
questions,
but
the
biggest
drawback
with
that
today
is
we
wanted
to
have
that,
be
something
where
the
resources
are
actually
defined
in
the
specification
of
the
resource
that
is,
that
is
affected
by
them,
because
that
seems
more
declarative
and
more
clear
to
users.
C
But
what
we
have
today
in
an
experimental
state
is
unfortunately,
not
that
it's
more
like
there
are
problems
with
actually
being
able
to
find
out
what
policies
affect
your
HTTP
route
and
so
forth,
because
you
have
to
have
access
to
them,
go
search
them.
We
can
do
some
things
with
status,
but
we
I
think
everybody
here
knows
that.
That's
not
always
good
for
this
kind
of
a
thing
and
that's
kind
of
where
we
are
at
currently
yeah
sorry
I
should
explain.
A
gep
is
a
gateway
enhancement
proposal.
C
It
is
influenced
it's
the
it's
it's
influenced
by
cap
and
follows
some
of
the
same
ideas,
but
it's
meant
to
be
a
I.
Won't
say
that
it
always
manages
this,
but
it's
meant
to
be
a
quicker,
more
iterative
process,
with
smaller
PRS
leading
up
to
and
and
going
along
several
it's
similar
anyway,
so
yeah
I
hope
that
I
hope
that
kind
of
lays
the
groundwork.
C
You
have
resources
like
routes
like
HTTP
routes,
TCP
routes,
and
we
might
want
to
attach
policy,
like
maybe
a
timeout
policy,
or
something
else
that
affects
those
routes
or
like
changes,
how
they're
actually
configured
instrumented
and
routed.
Does
that
make
sense
to
any?
Does
anybody
have
any
questions
about
that?
C
D
C
Generally
yeah
I
mean
the
idea.
Is
we
have
this
concept
of
different
roles
in
Gateway,
API
and
I?
Think
most
it
doesn't
have
to
be,
but
most
of
the
time
somebody
is
creating
policies
and
like
associating
them
with.
Let's
just
for
the
sake
of
argument,
say
it's
associating
with
every
route
in
a
namespace
or
something
like
that
in
such
a
way
that
that
role
is
distinct
from
somebody
who's
like
the
application
developer,
making
the
route.
C
D
Almost
I
was
about
to
ask
so
an
open
in
openshift
we
have
a
similar
concept,
there's
someone
who
manages
say
a
router
configuration
and
that
router
configuration
has
an
impact
on
every
route
that
is
exposed
via
that
router
and
so
representing
in
status
or
somewhere
for
a
a
person
who
owns
the
route
to
know
that
someone
turned
on
hsts
for
them
is
kind
of
critically
important.
Is
the
policy
API
that
you're
talking
about
trying
to
resolve
that
as
well?
Or
is
that
the
part
you
said
we
haven't
solved
yet
at
the
beginning?
D
C
It's
similar
the
problems
we
haven't
solved.
Actually
policy
is
I,
think
I
missed
this,
and
I
apologize
policy
in
our
sense
is
actually
guidelines
for
how
to
make
these
kind
of
apis,
because
we
didn't
want
to
leave
it
completely.
We
didn't
want
every
user
to
go
between
different
Gateway
API
implementations
and
have
like
no
idea,
like
everything
works
completely
differently,
so
we're
trying
to
create
some
specification,
there's
actually
a
spec,
but
it's
it's
meant
to
be
kind
of
like
use
this
as
your
core,
but
you
have
your
own
crds.
D
C
C
Is
that
something
else
yeah,
they
might
have
their
own
policies
that
have
no
bearing
on
like
no
other
implementation
might
have,
but
we
want
them
to
follow
a
common
struct.
Basically,
okay,
That's
Where,
It's
At.
Today
it's
got
a
lot
of
problems
and
we're
aware
of
it.
That's
why
it's
an
experimental,
but
it
also
has
a
lot
of
value,
so
getting
getting
to
kind
of
I
have
questions
for
this
group
and
I'll
I'll
pair
the
first.
C
The
first
thing
that
led
to
me
putting
this
on
the
agenda
was
I,
had
a
discussion
with
a
guy
named
Flynn
who
works
on
the
mesh
side
of
Gateway
API
with
me,
where
we've
we're
feeling
really
strongly
that
you
should
be
able
to
see
any
policy
that
affects
you
in
the
resource
that
you
retrieve
that
that
feels
more.
It's
not
the
right
word
necessarily
but
declarative.
C
The
maintainers
of
Gateway
API
is
help
and
maybe
feedback
on
what
might
be
better
approaches,
but
the
idea
that
I
came
up
with,
which
was
really
bombastic
I.
Think
that's
the
right
word
like
just
really
it's
a
lot,
and
it
would
take
a
lot
to
do
was
that
maybe
meta
resources
could
actually
be
something
that
exists
in
the
API
like
ink
to
kubernetes
API,
that
you
could
make
it
possible
to
do
a
cube
cuddle,
get
on
a
resource
and
in
the
response
much
like
spec
or
status
or
metadata.
C
D
D
C
D
A
Shane
I
have
a
question.
Sorry.
She
says
this
is
later.
I
was
a
few
minutes
to
three
minutes.
Late
and
I
didn't
understand
the
use
case
for
this,
so
we
want
to
have
some
policy
attachment
at
a
finer
collaterality,
so
it
is
more
than
like
a
coarse
grain
policy
that
applied
to
entire
resource,
but
you
want
at
a
different
level
within
the
resource
to
have
a
policy,
and
my
question
is:
doesn't
this
limit
the
reusability
of
it?
A
Adding
complexity
here
is
a
lot
maintaining
their
policies
and
then
what
is
the
like
with
the
maintenance,
overhead
and
everything
and
the
security
risks
that
is
employed
with
that
and
the
impact
on
the
performance?
What
we
do?
What
do
we
get
here?
Explain
to
me
a
use
case
that
is.
This
is
useful
for
that
sorry,
thank
you.
A
C
I'm
open
to
all
all
possibilities
that
was
the
that
was
my
some
conversation.
I
was
pretty
sure
when
I
said
it
that
it
was
a
little
too
much
but
yes,
I'm,
open
to
suggestions
here,
but
what
I
I
mean.
Ideally
I
would
like
to
see
Cube
cuddle
get
okay,
here's
my
HTTP
route
here
are
the
policies
that
are
applying
to
me.
D
Yeah
so
so
we
have
historically
said,
if
you
want
to
be
able
to
do
something
like
run
a
graphql,
where
you
find
all
reachable
things
from
my
thing,
you
would
push
it
all
to
a
different
data,
store
and
issue
that
query
you're
right.
It
isn't
new
right.
This
is
existed
since
we
had
pods,
plus
events
and
wrote,
describe
right,
and
we
have
chosen
to
solve
that
client
side,
because
it
greatly
simplifies
the
concerns
about
fan
out
the
concerns
about
having
to
get
information
a
before
getting
information
B.
D
So
you
end
up
with
high
latency.
It
resolves
problems
around
authorization.
Is
a
user
allowed
to
see
all
the
things
that
are
influencing
this
choice,
and
so
our
API
server
is
very
much
a.
You
can
see
the
thing
that
you
have
and
if
you
want
to
use
that
information
to
get
something
else,
you
absolutely.
B
D
So
there
are
ways
to
structure
an
API
where
you
would
be
able
to
do
that.
I,
don't
think
right
now,
I
would
be
in
favor
of
trying
to
expand
the
notion
of
I
want
to
do
a
get
and
then
get
the
things
related
to
this
thing.
Because
of
the
concerns
around
fan
out
and
permissions
and
the
depth
of
how
far
you
go.
C
I
understand
that
so
where
we
are
at
today,
basically
we're
pushing
forward
in
two
fronts:
client
side,
which
is
actually
something
you
kind
of
mentioned.
We
actually
have
a
Gateway
cuddle,
which
is
meant
to
help
with
this.
It's
not
a
perfect
solution.
It's
not
a
going
to
end
up
being
a
ubiquitous
thing
that
people
will
I
mean
it
could
I
guess,
but
we
could
plug
in
it
or
something,
but
we
also
don't
want
to
do
things
only
through
cuddle.
C
D
Why
would
a
status
region
with
external
references
be
purely
a
stop
Gap
right,
like
I?
That
seems
like
a
pretty
reasonable
way
to
structure
I.
Have
these
other
things
that
I
suggest
you
look
at
or
or
I
I
suggest?
You
have
this
query
you
think
about
when
you
read
a
service
and
you
get
back
the
label
selector
it's
natural
to
them
to.
B
C
At
least
in
its
current
state
I
think
it's
because
it's
kind
of
we
just
haven't
gotten
the
specification
down
like
very
well
and
we're
trying
to
get
something.
That's
rough
in
time
for
our
GA,
which
is
supposed
to
be
within
a
couple
months
here,
because
not
because
again,
these
are
not
our
crds,
but
we
want
this
guidance
in
place
as
soon
as
we
can
you're
not
wrong,
though
like
I
guess
I.
Oh,
it
was
too
much
to
say
that
it
is
that
using
status
in
general
is
a
stop
Gap.
C
We
just
have
a
stopgap
solution
today.
I
think
that
if
we
had
some
really
good
rules,
written
up,
maybe
status
ends
up
being.
What
we
do
I
would
hope
for
better,
but
maybe
we
could
you
know
I
would
hope
for
something
other
than
status
for
a
variety
of
reasons,
but
it's
not
a
terrible
solution,
and
sometimes
you
can't
have
a
perfect
one.
So
that
might
end
up
being
the
long
term,
I'd
like
to
try
to
think
about
potential
Alternatives,
but
yeah
go
ahead.
E
Yes,
so
I
had
two
thoughts.
One
was
for
the
feature
in
beta
now
called
validating
admission
policies.
We
kind
of
made
this
problem
easier
for
ourselves,
because
we
do
have
this
problem
where
somebody
can
Define
how
a
policy
is
applied
in
a
customer
resource
and
the
way
that
we
make
those
findable
is
that
there
is
a
standard
type
called
like
a
validating,
an
admission
policy
binding
that
sits
between
the
the
policy
rules
and
how
they're
bound,
and
so
it's
there
is.
E
There
is
a
known
object
that
you
can
go
and
probe
and
say
like
find
all
the
policy
Bindings
that
match
this
to
that,
and
that
gives
you
a
way
to
find
stuff.
It
sounds
like
part
of
your
problem
here.
Is
that
you've
got
it
could
be
any
crd,
so
I
don't
even
know
where
to
look
to
see
where
the
references
to
my
thing
are.
But
if
you
had
like
a
linking
object,
it
said,
like
the
spines,
this
policy
to
these
things
that
might
but
it
introduce
a
new
objects.
D
C
D
Thing
that
we
have
in
openshift
types
that
have
on
status
a
field
called
related
objects.
We
have
client-side
tools
that
look
and
say:
oh,
you
have
a
related
objects.
I
know
that
this
means
whatever
you've
listed
here
is
a
thing
that
I
should
look
up.
If
you
have
permissions
to
do
it,
I
will
pull
it,
and
if
you
do
a
command,
not
a
get,
but
you
do
an
inspect.
D
E
B
C
Well,
these
are
a
couple
of
interesting
things
for
me
to
think
about.
My
co-maintainers
I
think
wanted
to
come
to
one
of
these
two,
so
I
guess
my
last
question.
I
have
one
last
question
and
then
I'm
willing
to
be
kind
of
done
and
take
some
time
to
go.
Think
about
these
and
go
talk
with
Nick
and
rob
a
little
bit
about
it
and
then
we'll
probably
come
back
to
one
of
these
in
the
future,
as
we
continue
working
on
this
I
actually
want
like.
C
Does
anybody
like
really
hate
the
I,
like
the
idea
that
I
threw
out,
though
I
mean
like
I'm,
not
convinced
of
it?
But
like
is
the
idea
that
you
could
just
do
a
get,
and
you
would
have
something
like
meta
resources,
and
you
could
see
that
on
not
worrying
about
the
implication.
The
implications
of
the
implementation
details
that
actually
sound
good
or
does
it
sound
like
nah?
That's
not
something
that
would
really
be
helpful
in
my
world,
where
I
have
resources,
referencing
and
affecting
other
resources.
D
Such
an
API,
I
think
comes
into
into
question
right
because
in
the
case
that
you
have,
you
know
well
you're
interested
in
policies
by
the
time
you
add,
related
resources
on
this
thing
on
onto
a
route.
For
instance,
I
would
expect
that
HTTP
route
to
reference
things
like
services
or
endpoints
or
pods,
and
you
go
transitively
down
now.
You're,
referencing
nodes
and
and
what
you
really
wanted
was
show
me.
The
policies
that
are
impacting
this
route
and
so
I
think
that
is
I,
think
it'd
be
better
to
Target
the
the
individual
problem.
C
Okay,
it's
good
thoughts
and
I
mean
I
kind
of
know.
These
things
like
in
the
back
of
my
head.
These
are
thoughts
that
I've
had
I
know
it's
a
little
quixotic,
so
I
have
plenty
to
go
on
for
like
what
I
needed.
I
really
appreciate
everyone's
time.
Thank
you
for
the
conversation.
If
anybody
wants
to
ask
me
more
questions
or
continue,
the
conversation
I'm
happy
to,
but
I'm
good
to
kind
of
digest
this
for
now
come.
B
A
E
Yeah,
this
is
just
a
really
quick
announcement.
I
mean
whenever
we
finish
a
kubernetes
release
the
next
one's
coming,
really
quick,
so
1.29
we're
going
to
be
going
up
against
enhancement,
freeze
in
no
time,
I
actually
didn't
look
up
to
date.
Maybe
if
somebody
is
timing,
it
tell
us
that'd
be
great,
but
it's
coming
quick.
E
If
you
are
planning
to
do
an
enhancement
in
the
release,
it
would
be
very
much
appreciated
if
you
would
tell
us
what
you're
thinking
of
doing
you
can
do
it
on
slack.
If
you
know
now,
you
can
do
it
and
then
also
try
and
line
up
your
reviewers
so
that
we
can
make
sure
we
Can
anticipate
load
and
can
distribute
load
of
all
the
things
that
need
to
be
reviewed
so
identify
somebody
in
leads
that
you
think
would
be
inappropriate
reach
out
to
us.