►
From YouTube: Kubernetes KubeBuilder Meeting 20210408
Description
KubeBuilder Meeting for 2021/04/08. See https://sigs.k8s.io/kubebuilder for more details.
A
Hello
and
welcome
to
the
q
builder
controller,
runtime
and
controller
tools
meeting
for
thursday
april
8
2021.
As
a
reminder,
this
is
being
recorded,
so
don't
say
anything
you
don't
want
uploaded
to
youtube.
A
All
right
looks
like
we
have
a
relatively
short
agenda
for
today.
So
I
think
I
have
the
first
item.
There
might
be
some
debate,
so
we
can
probably
move
this
to
last.
So
let's
see
the
second.
The
second
item
is
the
just
release.
Check-In,
let's
see
is.
A
One
of
camilla:
do
you
wanna
or
eric?
Do
you
wanna
give
a.
B
B
That
was
purchased
by
jesus.
In
my
opinion,
we
can
move
on
with
the
rc
today
and
debug
fix
awakening
address
for
this
table
release.
Unless
someone
has
any
objection,
I
think
this
is
the
goal.
If
we
find
any
issue
with
yourself
before
the
stable
one.
C
Yeah
hi,
so
I
just
wanted
to
bring
up
this
topic
for
discussion
in
this
forum.
So
it's
regarding
the
plan
for
deprecating
the
injector
interface.
So
a
little
background
here,
so
the
injector
package
is
used
to
propagate
any
of
the
dependencies,
maybe
client
or
cache
or
config
from
the
controller
manager
or
to
the
other
components
which
are
registered
with
it.
C
So
it
was
decided
earlier
that
we
would
be
deprecating
this
package,
since
it's
essentially
not
scalable,
to
maintain
a
code
base
where
we
have
to
implement
this
interface
methods
for
all
the
types
which
we
may
be
adding.
But
the
problem
here
is
that
it's
not
simple
to
remove
all
of
it
at
once,
since
this
is
being
extensively
used
internally
in
the
controller
and
time
itself.
So
I've
provided
a
rough
list
of
where
it's
used
in
the
issue,
so
I
just
wanted
to
bring
this
up
so
that
we
can
talk
about
this.
C
A
Yeah,
I
think,
just
to
follow
up
from
like
at
least
from
my
concerns.
From
my
perspective.
A
One
of
the
main
points
of
difficulty
that
I
think
we
might
encounter
is
that
there
are
spots
where
we
don't
have
dependencies
that
need
to
be
passed
to
things
until
later,
and
so
one
of
one
of
like
the
things
that
enables
a
lot
of
our
kind
of
just
like
pass
in
this
thing,
and
things
will
work
as
opposed
to
having
like
giant
explicit,
initialization
blobs
at
various
times
or
like
creating
something
adding
it
to
the
manager
and
then
like
later
initializing.
A
A
dependency
somehow
is
is
the
dependency
injection
code
and
like
some
of
it,
some
of
it
can
be
replaced
in
a
pretty
straightforward
manner.
So,
like
obviously
like
what
we've
been
doing
in
our
q
builder
scaffolded
code,
where,
instead
of
implementing
inject
client
on
the
scaffolded
types,
we
we
call
get
client
and
stuff
like
that.
But,
like
there's
points
internally
where
that
is
a
lot
harder
to
do,
I
seem
to
recall,
like
the
channel,
the
sources
are
going
to
be
difficult
there
and
stuff
like
that.
A
Controllers
might
have
issues
the
controller
object
might
have
issues
as
well,
so
either
we're
gonna
need
to
like
work
out
how
to
do
that
without
impacting
the
usability
or
we're
gonna
need
to
like
design
a
new,
a
new
kind
of
injection
method,
which.
A
Might
might
be
the
like,
we
might
end
up
just
having
to
go
with
like
the
lesser
of
two
evils
and
just
have
a
better
designed
injection
system
from
through,
like
context
or
something,
but
but
that
is
that
is,
I
think,
the
thing
to
think
about
as
you're
doing
this.
B
D
So
this
does
sound
like
a
pretty
extensive
design
change
and
I
I
think
we
knew
it
was
going
to
be,
but
at
the
time
when
we
were
like
initially
talking
about
this
and
just
kind
of
hand,
waved
it,
we
didn't
really
think
about
it.
So
I
I'm
wondering
if
this
is
grounds
for
like
an
ep
or
if
this
is
just
a
whole
bunch
of
somewhat
connected
changes
that
need
to
happen.
Iteratively,
I'm
wondering
about
your
thoughts
on
this.
A
I
think
it's
probably
grounds
for
like
the
way
I
would
probably
handle
this
was
would
be
like
do
do
like
a
couple
prototypes
and
then
maybe
post
post,
the
the
prototypes
and
then
maybe
like
explicitly
as
this
is
a
prototype.
Do
not
merge.
A
We're
just
gonna
use
this
to
see
how
it
looks
and
then
maybe
take
that
and
write
up
a
little
write
up
a
little
enhancement
proposal
from
what
we
decide
more
more,
as
document
like
documentation
for
what
for
what's
going
on
and
like
a
summary
of
our
discussion
and
then
go
from
there,
because
I
think
this
is
one
of
the
cases
where,
like
a
actually
going
through
and
like
doing
it
for
some
of
the
gnarlier
spots
it
and
be
like
actually
seeing
the
code
and
seeing
how
it
looks,
are
going
to
inform,
inform
a
lot
more,
not
that
they
don't
usually
but
like
I
I
have
I
have.
A
I
expect
that
like
trying
to
do
it
partially
we're
gonna
and
then
writing
an
ep
and
then
like
finishing
up
or
something
as
opposed
to
a
more
fleshed
out
prototype
like
we're
gonna
end
up
missing
spots
and
and
having
issues
that
we
haven't
foreseen.
So
I
think
the
prototype's
going
to
be
very
important.
E
Some
of
the
things
you
said
initially,
I
know,
are
not
too
slowly
like
the
source
doesn't
use
a
channel.
The
controller
doesn't
use
anything
anymore
today,
but
it
was
true
in
the
past,
so
I
think
it
needs
to
be.
Someone
just
goes
through.
All
of
this
finds
out
the
spots
that
don't
have
an
obvious
thing
to
do,
and
then,
based
on
that,
we
have
a
prototype
and
probably
design.
A
D
I
think
it's
like
in
when
you
add
a
runnable
you,
depending
on
what
kind
of
runable
it
was
you
do
that
so
yeah.
It's
like
this.
I
I
remember
looking
through
all
the
the
layers
of
calls
that
it's
quite
a
big
change,
depending
on
what
you
pass
in,
and
I
mean
in
a
lot
of
cases
like
like
you're
saying
it's,
it's
really
difficult
to
get
around
that
without
using
some
sort
of
like
interface
injection,
so
that
that
does
worry
me
a
little
bit
as
well.
So
I
guess
those
are.
E
Yeah,
I
also
want
to
mention
that
especially
the
fact
that
we
have
this
whole
long
change
thing
is
a
reason
why
we
should
do
this,
because
people
create
issues
where
they
somewhere
very
down
some
culture
and
don't
have
a
dependency
anymore.
They
expected
to
have-
and
I'm
seeing
this
pull
request
and
I've
literally
no
idea
how
this
was
supposed
to
work
and
if
the
change
is
going
to
do
what
it's
supposed
to
do,
because
it's
so
invisible
the
way
it's
done
today
and
I
think
that
needs
improvement.
A
A
I,
like,
I
don't,
or
at
least
think
about
that.
I
don't
particularly
like
drawing
that
distinction
usually,
but
we
may
want
to
say
like
there
is
no
guarantee
that
these
types
will
be.
There
is
no
particular
guarantee
that
anything
will
be
passed
through
in
the
new
system.
A
That
might
be
optimistic
in
terms
of
how
people
deal
with
things,
but
we
can
at
least
potentially
put
out
a
statement.
D
Yeah,
I
think
that's
a
really
good
point.
I
just
quickly
want
to
touch
on
this
as
a
final
point
for
me.
So
there
are
people
that
probably
depend
on
this
as
an
api,
but
like
the
I
guess,
the
real
question
is:
is
it
necessary
as
an
api
like?
Is
there
another
way
around
this,
because
I,
I
think
a
lot
of
the
injection
code
that
I've
seen
in
fact
most
of
it
is
internal
to
controller
on
time.
D
I
don't
think
there's
much
of
a
need
to
actually
use
it
outside
of
controller
on
time,
because
people
like
while
they
are
doing
complex
things
with
controller
on
time
apis.
They
are
pretty
much
already
set
up
at
the
point
at
which
people
use
them
and
don't
need
resource
injection.
D
I'm
sure
there
are
people
who
are
eating
them,
but
it's
probably
a
small
subset
of
people.
At
least
that's
that's
anecdata.
So
if
anybody
has
any
contrary
points,
please
let
me
know.
A
Like
more
explicitly
I
that
kind
of
matches
what
I've.
A
Seen
all
right,
if
no
one
else
has
any
opinions
on
the
matter,
we
can
move
on
to
the
last
thing,
which
is
actually
the
first
thing
hope
nope,
oh
okay,
yeah
camilla
did
you
want
to
say
anything
about
the
the
that
last
thing
and
then
we'll
go
on
to
my
first
thing.
B
Sure
sure
it's
very
effective
I
just
would
like
to
share
the
hpr.
Dpr
is
for
we
document
the
plugins
stuff
and
how
people
can
create
their
their
own
plugin
as
a
follow-up.
It
has
a
fault
that,
should
you
like
to
create
a
tutorial
as
well
with
his
examples,
so
I
would
like
to
kindly
ask
if
he's
someone,
if
he's
for
who
has
interested
on
that,
try
to
to
help
you
on
the
reviews.
Would
you
be
nice?
We
got
to
the
chimers.
A
Awesome
all
right
so,
for
the
last
thing
I
have
at
various
points,
we
have
various
points
come
across
like
basically
issues
with
the
okay,
sorry
step
back
currently
the
client.
A
For
a
couple
of
reasons.
This
has
caused
us
design
issues.
I
think
it
caused
us
design
issues
when
we
were
looking
at
the
initial,
like
our
initial
attempts
at
like
how
do
you
do
a
filtered
list
watch
and
I
recently
encountered
a
scenario
with
an
end
user
in
which
they
started
using
v2
of
their
crd
in
some
places
in
their
code
base
and
other
places
they
used
v1,
and
they
didn't
quite
realize
that
this
would
establish
two
caches
and
which
is
like
an
easy
mistake
to
make.
A
I
think,
if
you're,
not
especially
if
you're
not
like
super
duper
thinking
about
like
the
implications
of
that
and
then
they
ended
up
starting
to
get
bugs
where
like
state
was
lagging
behind,
because
they
were
getting
watch
notifications
from
v1
and
then
fetching
from
the
cache
of
v2,
which
was
like
ever
so
slightly
behind
and
it
manifested
as
like,
really
weird,
occasionally
kind
of
flaky
bugs.
A
And
so
I
think
we
should
either
reconsider
that
behavior
or
make
it
optional
and
make
it
instead
be
like
an
error.
If
you
try
to
get
something
from
the
cache
that
you
haven't
watched
beforehand
and
then
maybe
make
an
option
to
like
add
something
to
the
cache
without
explicitly
setting
it
up
as
a
watch
or
maybe
figure
out
like
if
there's
some
mitigations
or
protections
against
things
we
can
do
as
especially
the
v1
versus
v2.
I'm
surprised
I
haven't
seen
anyone
else
hit
that
as
people
start
to
introduce
multiple
versions
to
their
code
base.
A
D
A
It
it
was,
it
was
a
feature
it
was
kind
of
it.
It
was
kind
of
like.
Oh,
we
want
the
cache
to
be
as
completely
transparent
to
people
as
possible
so
like.
If
you
try
to
get
something.
That's
not
cached
but
like
is
on
the
api
server.
We
want
it
to
be,
or
you
try
to
get
a
type.
That's
not
that's,
not
cached,
but
is
available
like
in
general.
A
We
want
the
cache
client
to
act
exactly
as
a
live
client
would
act
in,
in
which
case
we
need
to
auto
establish
the
cache,
so
it
was
originally
intended
as
a
feature.
A
I
think
in
many
cases
that
I've
seen
practically
people
don't
get
stuff
that
they
haven't
set
up
in
a
controller
watch
with
a
relation
and
and
like
getting
stuff
that
you
haven't
set
up
with
an
explicit
relation
from
the
cache
may
kind
of
be
an
anti-pattern,
but
that's
not
always
the
case,
and
so,
like
someone
pointed
out
that
they
have
encountered
this
being
useful
before
so,
is
that
that
answer
your
question.
E
I
can
just
say
from
my
personal
experience
that
literally
everyone
was
surprised
by
this
behavior
and
even
more
confused
once
they
learned
that
the
unstructured
are
excluded
from
this,
which
is
why
we
now
added
an
option
to
exclude
other
things
as
well.
If
you
want
that-
and
I
think
I
personally
would
prefer
to
be
a
more
explicit
api
where
you
have
to
opt
in
for
everything
you
want
to
cache
and
everything
else,
you
will
just
get
from
the
api
directly.
A
Yeah
that
that
that
surprisingness
matches
matches
some
of
the
stuff
I've
seen
too
that's
a
good
point.
I
had
forgotten
about
like
we
have
gotten
a
number
of
bug
reports
too,
about
like
people
yeah
exactly
that,
especially
the
unstructured
decision,
which
has
its
has
its
reasons.
I
I'm
not
sure
either
way
was
better
but
yeah.
A
Okay,
if,
if,
if
folks,
can
weigh
in
on
that
bug,
that
would
be
super
useful
and,
like
I
have
some
ideas
about
like.
Maybe
what
we
could
tweak
to
to
then
for
for
new
options,
maybe
make
it
so
you
can
turn
it
off
or
whatever,
but
if
other
folks
have
ideas
on
like
what
what
to
kind
of
replace
it
with
or
or
how
to
modify
it,
it
would
be
great
if
you
could
weigh
in
as
well.
F
Yeah,
if
what
is
worth
that
was
basically
my
same
thinking
when
I
read
this
bug
just
before
the
meeting
started,
this
issue,
like
totally
agree
with
things
that
are
stated
here,
generally
agree
with
all
the
other
things
that
people
stated
in
this
meeting,
like
the
caching
is
super
helpful
in
fact
very
important
in
a
lot
of
circumstances
to
direct
developers
toward
caching
and
ensure
that
nobody's
accidentally,
not
caching,
when
they're
using
a
client,
for
example.
F
But
the
big
question
mark
is
like
okay,
given
these
issues
in
front
of
us
with
what
we
have
right
now.
What's
the
alternative
and
weighing
that
against
the
alternative
will
be
probably
the
interesting
thing,
so
I'm
I'm
kind
of
eager
to
see
actually
some
ideas
of
what
specifically,
we
might
consider
otherwise,.
A
A
All
right,
if
not,
I
will
see
everyone
in
a
couple
weeks.
Talk
to
y'all
later,
thanks,
see.