►
From YouTube: Kubernetes KubeBuilder Meeting 2020507
Description
KubeBuilder Meeting for 2020/05/07. See https://sigs.k8s.io/kubebuilder for more details.
A
Now,
all
right
as
this
is
the
q
builder
controller,
runtime
and
controller
tools,
meeting
for
may
7th
of
2020
as
a
reminder,
this
is
being
recorded
and
will
be
posted
and
publicly
available
on
the
internet.
So
don't
say
anything
that
you
don't
want
recorded
in
the
animals
of
history
all
right,
so
it
looks
like
we
have
currently
two
things
on
our
agenda
for
today.
The
first
is
from
eric,
so
why
don't
you
take
it
away
eric.
B
Sure
so
we
recently
got
the
plug-ins
pr
merged
into
master.
Thank
you.
Everybody
who
participated
in
reviewing
that
it
was
quite
a
long
slog.
B
A
A
It-
and
I
think
the
nice
thing
about
the
the
alpha
and
the
beta
two
is
that,
because
it's
like
an
alpha,
there's
a
little
bit
of
ora
beta,
there's
a
little
bit
of
a
call
out
of
hey.
There's
this
shiny
new
thing
that
we
really
want
feedback
on
kind
of
thing,
like
the
the
fact
that
it's
in
a
pre-release,
which
we
don't
usually
do
unless
we
have
a
big
feature,
is
kind
of
an
indication
of
like
hey.
Try
this
out.
B
A
I
have
we
have
we
accumulated
a
lot
of
other
fixes.
Besides
this.
A
Think
I
think
that's
something
well,
I
think
removing
v1
project
support
is
something
we'd
also
want
in
v3
yeah,
oh
yeah,
so
I
think
the
only
reason
to
do
a
minor
would
be
if
there
was
like
stuff
before
those
two
that
we
wanted
to
get
out
in
a
release
so
like.
If
we
were
to
cut
a
minor,
I
would
say
cut
it
before
the
two
major
or
before
the
at
the
very
least
before
the
breaking
change,
which
is
removing
v1
support
and
then
have
those
last
two
commits
be
in
the
v3
pre-releases.
A
B
D
D
B
Well,
we
should
definitely
take
a
look
at
that
and
make
sure
that
it's
either
done
or
moved
elsewhere
before
we
actually
cut
a
release
but
yeah.
I
I
think,
after
going
through
the
issue
backlog,
we
could
probably
just
cut
an
alpha.
A
The
other
thing
is
since
we're
since
we're
doing
like
alphas
at
an
alpha
like
we
can
continue
to
like
do
v3-ish
stuff
in
the
alphas
and
betas.
If
we
need
to
like
if
we
catch
something
but
yeah.
B
Okay,
yeah
just
just
wanted
to
bring
that
up.
I
can
help
or
fully
do
the
release.
I've
never
done
one
for
people
ever
before,
but
I'm
fine
doing.
A
Awesome
always
good
to
have
more
people
learn
the
tooling
in
the
process.
So
yeah
we
can
walk.
We
can.
I
can
walk
you
through.
That
being
me
at
some
point
and
the
hopefully
like
the
guides
in
our
release.
Documentation
are
almost
sufficient,
not
sufficient,
but
wow.
We
can
try
to
identify
gaps
and
stuff.
A
Okay
cool,
it
looks
like
the
second
one
is.
E
So
the
background
is
that
recently,
I've
come
again
in
the
situation
of
building
a
controller
that
talks
to
more
than
one
cluster,
and
this
is
possible
today,
but
it
does
require
that
a
manager
per
cluster
that
is
somehow
used
in
any
controller
is
created
and
because
the
constructor
of
the
controllers,
the
controller.new,
needs
to
get
a
manager,
and
this
in
turn
is
needed
because
the
controller
needs
some
things
from
the
manager
like,
I
think,
the
cache
the
client
it
calls
the
whole
injection
logic
and
so
on,
and
this
in
turn
means
that
for
such
a
case
of
a
multi-cluster
controller,
you
end
up
with
a
very
weird
startup,
because
you
need
to
add
the
second
manager
to
the
main
manager,
which
then
means
the
main
manager
will
start.
E
The
first
one
is
to
construct
a
set
of
things
like
caches
and
the
client
potentially
a
constructor,
for
this
can
be
passed
in,
but
basically
hold
it
and
pass
it
on
to
other
things
that
need
it
and,
second,
to
ensure
that
we
start
up
things
in
the
correct
order
and
because
the
manager
also
does
this
first
thing.
The
controller
constructor
needs
to
get
a
manager,
even
though
at
that
point
it
doesn't
need
the
manager
part
that
is
responsible
for
starting
up
things.
E
So
my
thought
was
that
it
would
probably
make
sense
to
move
all
this
part
that
creates
the
clients
and
the
cache
and
holds
them
into
its
own
package
and
interface.
Let's
call
it,
I
don't
know
cached
client
container.
For
now
I
don't
have
an
idea
for
a
better
name
and
basically
use
that
when
constructing
a
new
controller-
and
this
way
allowed
to
have
a
multi-cluster
controller
without
needing
to
have
more
than
one
manager
does
that
make
sense,
and
what
do
people
think
about
that?
It
was
a
little
bit
complicated
explanation.
A
I
would,
I
think
I
would
need
to
think
about
the
exact
semantics
or
like
see
like
a
a
concrete
sketch
or
something
mainly
because,
like
the
the
act
of
the
act
of
starting,
the
caches
is
somewhat
like
fiddly,
the
the
order
of
how
the
caches
are
started
and
how
they're
added
to
the
controller,
I
think,
is
somewhat
fiddly.
But
I
think
that
could
work.
A
I
think
probably
we'd
still
want
to
keep
like,
have
have
a
have
a
manager
that
draws
those
together
for
like
the
fast
path
where
you're
like
or
a
quote-unquote,
then
probably
like
the
normal
path,
kind
of
where
you're,
where
you're
just
in
a
single
cluster.
And
so
you
just
have
a
single
manager.
And
you
don't
have
to
worry
about
instantiating,
multiple
things,
but
I
think
it
makes
sense
to
to.
I
think
it
could
make
sense
to
decompose
those
two
to
make
like
cases
like
yours,
more
or
easier
to.
E
Implement
yeah,
so
the
basic
idea
was
definitely
to
like
for
the
normal
use
case
from
a
user
perspective.
Keep
everything
at
it
is
like
change
the
implementation
of
the
manager,
probably
to
use
this
other
thing,
but
like
keep
the
public
api
the
way
it
is
just
enable
this
other
case,
and
that
would
require
that
the
manager
has
a
specific
path
to
start
caches
first,
for
example,
and
to
be
able
to
have
more
than
one
cache.
Actually
that's
the
follow-up
of
that
yeah.
A
Yeah,
I
think
that
makes
a
ton
of
sense
you're
you're,
not
the
only
one
to
bring
up
the
cluster
multi-cluster
use
case
too.
I
think
it's
something
that
we've
kind
of
done.
A
lot
of
at
least
I've
done
a
lot
of
kind
of
hand
waving
with
on
on
q
builder,
and
just
a
lot
of
people
have
arrived
at
some
really
weird
kind
of
like
multiple
manager.
A
B
A
Oh
before
we
go,
I
have
one.
I
have
one
quick
thing
that
we
don't
need
to
discuss
now,
but
I
was
just
curious:
if
people
had
brief
thoughts
on
it
do
does
after
we
do
once
we
do.
The
v3
initial
v3
release
do
folks,
have
thoughts
on
plugins
phase,
two
and
kind
of
the
roadmap
for
that
or
the
the
kind
of
time
road
map.
So
to
speak.
For
that.
B
That's
at
the
very
least,
the
goal
I
have.
Probably
sooner
than
later,
I
have
an
issue
open
that
opens
the
discussion
for
how
we
want
to
implement
phase
two
that
I
can
link
in
a
hot
second.
A
Okay,
cool,
that's
mostly
what
I
was
looking
for:
yeah,
no,
no
super
rush
or
anything,
especially
with
all
the
stuff
that's
going
on.
I
was
just
yeah
that
that's
that
answer
was
kind
of
exactly
what
I
was
looking
for.
A
C
I
think,
like
I
think,
we're
probably
planning
on
like
we
as
an
operator.
Sdk
community
is
planning
on
like
pushing
that
starting.
You
know
this
summer
time
frame,
so
I
I
think
we
want
to
get
it
done
in
the
next.
I
don't
know
three
to
four
months,
but
it'll
it'll
depend
on
other
priorities
and
whether
it's
something
that
we
absolutely
need
for
some
of
our
other
things.
So
I
think
eric's
not
wrong,
but
I
think
we're
going
to
try
to
push
it
sooner
rather
than
later.
B
B
Just
quickly
before
we
end
do
we
definitely
want
to
go
ahead
with
moving
api
and
controller
into
package.
B
B
What's
the
issue
moving
in
builder,
moving
the
scaffolded
api
and
controller
directories
into
the
package
directory
kind
of
like
how
the
current
operator
sdk
scaffolded
go,
project
layout
is.
A
Yeah
I
mean
we
can
just
discuss
it
here,
a
little
bit
if
chat
will
open
for
me
as
opposed
to
ins
instead
of
displaying
a
blank
box.
If
this
is
what
I
was
thinking,
if
this
is
the
issue
I'm
thinking
of
actually,
can
you
just
say
the
issue.
F
B
F
F
C
A
Yeah,
I
I
I
am
kind
of
I
personally
really
like
the
package
list
layout
and
one
of
the
reasons
that
we
initially
did.
It
was
that
it
was.
A
It
was
kind
of
confusing
for
some
folks
like
what
what
went
in
package
and
what
went
in
command
and
like
where,
where
they
should
start
looking
in
the
new
project
like
and
so
one
of
the
reasons
we
have
the
package
and
command
command
list
structure
where
we
just
have
api
and
controllers
in
the
root
is
because
then
like.
The
first
thing
you
see
is
main.go
and,
like
that's
a
really
obvious
place
to
go.
Looking.
A
So
I
think
maybe
making
it
optional
would
would
be
like
okay,
but
I
personally
at
least
would
be
in
favor
of
keeping
the
package
less
right.
B
Model,
I'm
yeah
as
the
d
I'm
pretty
indifferent
myself.
I
it's
a
little
bit
confusing
because
for
for
me
at
least
I
think
of
the
package
directory
as
a
place
where
you
put
code
that
you
want
to
use
as
a
library,
a
controller
is
kind
of
that
the
package
type
the
the
api
types
are
definitely
that,
but
even
then
you're
like
using
them
within
the
same
projects,
and
so
it's
like
library-ish,
it's
it's
a
bit
of
a
gray
area.
So
I
don't
even
think
using
that
reasoning
helps
here.
A
Yeah
and
like
on
that
subject
like
when
you
go
to
import
the
api
like
we're,
we
kind
of
have
a
mixed
bag
in
kubernetes,
even
like,
obviously
like
kubernetes
kubernetes
has
package
apis
and
like
some
of
the
like
all-in-one
dependencies
like
api
extensions,
api
server
have
package
apis,
but
then,
like
the
actual
api
package,
is
just
case.
Dot
io
slash
api,
there's
no
package
there
right.
A
So
yeah,
I
I'd
be
fine
with
making
it
up.
I
again
I'd,
be,
I
think,
I'd
be
fine
with
making
it
optional,
but
I'd
like
to
see
a
little
bit
more
discussion
or
kind
of
evidence
is
probably
the
wrong
term,
but
like
more
more
reasoning
as
to
why
to
use
packaging
command
by
default.
If
we're,
if
we
wanted
to
do
that.
B
All
right
yeah,
it
sounds.
It
sounds
good
to
me
follow
up
with
some
things
in
the
issue.
I
I
hesitate
to
agree
with
making
it
optional,
just
because
it
does
increase
complexity
for
almost
like
no
reason
in
the
projects
and
in
builder
itself,
like
it's
kind
of
just
moving
a
bunch
of
directories
around
which
you
can
do
yourself
in
the
end
it
and
just
like
make
changes
to
scaffolded
files,
but
for
cool
builder
to
support
both,
maybe
yeah.
That's
too
much
complexity.
A
That's
fair,
I
mean
the
other
thing
we
could
do
is
we
could
see
if
it
we
could.
We
could
use
that
as
another
kind
of
like
mini
test
plug-in
if
that
see
yeah
and
see
if
that
fits
into
like
the
plugins
v2
model,
because,
like
hypothetically,
that
could
fit
into
the
plugins
v2
model
right,
like
you
get
the
you,
you
get
the
world
set
of
files
and
you
look
for
anything,
that's
a
go
file
and
you
move
it
over
yeah.
B
That
is,
that
is
a
good
point
that
would
be
fun
to
that's.
A
Okay,
I'll
I'll
drop
that
in
a
comment
in
the
in
the
issue,
just
so
that
we
have
that
for
posterity
awesome.
Thank
you.
A
All
right,
if
nobody
has
anything
else
that
they'd
like
to
discuss,
we
can
end
the
meeting
now
and
I'll
see
y'all
in
two
weeks.
G
Real
quick
question
I
was
sure
I
threw
in
a
chat,
is
anybody
working
on
eight
six.
G
Issue:
eight
six,
eight
in
controller
runtime,
it's
in
the
zoom
chat,
hi.
A
G
I
saw
someone
assigned,
I
wasn't
sure
if
anybody
was
actively
pursuing
the
issue,
I'd
be
happy
to
give
it
a
look.
A
Yeah,
it
doesn't
look
like
the
person
assigned
is,
is
still
actively
working
on
it.
It
might
just
be
worth
you
know,
adding
a
comment
saying:
I'm
gonna
start
taking
a
look
at
this,
but
let
me
know
if
you're
still
actively
working
on
it.