►
From YouTube: Kubernetes KubeBuilder Meeting 20200507
Description
KubeBuilder Meeting for 2020/05/07. See https://sigs.k8s.io/kubebuilder for more details.
A
A
B
So
we
recently
got
the
plugins
pyaare
merged
into
master.
Thank
you.
Everybody
participated
in
reviewing
that
it
was
quite
a
long
slog.
I
think
it
sounds
perdant
to
have
a
minor
release
before
we
have
a
major
release,
including
that
so
we
can
get
people
using
it
and
find
any
bugs
and
adds
follow-ups.
A
C
B
A
B
A
Think
that's
something
well
I
think
removing
v1
project
support
is
something
we'd
also
want
in
v3,
yeah,
okay,
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
more.
B
C
E
E
B
A
B
A
Always
good
to
have
more
people
learn
the
two
owing
in
the
process.
Yeah,
we
can
work,
we
can
I
can
walk
you
through.
That
thing
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
yeah.
D
Yes
and
it
might
be
opening
a
big
can
of
worms.
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
the
manager
per
cluster
that
is
somehow
used
in
any
controller
is
created
and
because
the
constructor
of
the
controller,
the
controller
that
new
needs
to
get
a
manager-
and
this
in
turn
is
needed
because
the
controller
needs
some
things
from
the
manager
like
I,
think
to
catch
the
client.
D
It
caused
the
whole
injection
logic
and
so
on,
and
this
in
turn
means
that
for
such
a
case
of
the
multi
cluster
controller,
you
end
with
the
very
weird
startup,
because
you
need
to
add
the
second
manager
to
the
main
manager,
which
then
means
the
main
minute.
I
was
at
the
second
manager
after
a
quiet,
adiga
leaderless,
and
this
means
that
the
cache
of
the
second
manager
will
only
be
attempted
to
start
it
after
the
main
manager
got
its
leader
lease
and
similar
tenuously
by
the
main
manager
starts.
D
The
first
one
is
to
construct
a
set
of
things
like
caches
and
the
client
and
potentially
a
constructor
fathers
can
be
passed
in,
but
basically
hold
it
and
pass
it
on
to
other
things
that
needed
and
second
to
ensure
that
we
start
up
things
in
the
correct
order
and
because
the
manager
also
does
the
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.
D
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
our
cached
client
container
for
now,
I,
don't
have
an
idea
for
by
the
name
and
basically
used
that
when
constructing
a
new
controller-
and
this
way
allowed
my
ot
classic
controller
without
needing
to
have
more
than
one
manager.
D
A
Mainly
because,
like
the
the
act
of
the
active
starting,
the
caches
is
somewhat
like
fiddly
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.
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.
D
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
measure,
probably
to
use
this
other
thing,
but
like
keep
the
public
API
at
the
wages
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
follow
yeah,
I
guess.
D
My
point
right
now
is
mostly
that
I
wanted
to
hear
if
the
idea
as
such
make
sense-
and
this
definitely
did
needs
a
design
document
and
that
in
terms
most
likely
needs
a
small
proof-of-concept
who
like
to
think
about
what's
actually
possible,
but
I
wanted
to
get
some
feedback.
If
people
like
the
idea,
yeah.
A
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.
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
cue
builder,
and
just
a
lot
of
people
have
arrived
at
some
really
weird
kind
of
like
multiple
manager.
Solutions
like
you
have
so
I
think
having
having
a
more
cohesive
story
for
that
would
be
super
awesome
and
having
something
that
was
less
clunky
than
like
just
stick.
B
A
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,
and
it
shall
be
three
lilies.
Do
folks,
have
thoughts
on
plugins
phase,
two
and
kind
of
the
roadmap
for
that
or
the
the
kind
of
time
roadmap.
So
to
speak
for
that
I.
B
A
C
Think,
like
I,
think
we're
probably
planning
on
like
we
as
an
operator.
Sdk
community
is
plenty
on
like
pushing
that
starting.
You
know
this
summer
timeframe,
so
I
I
think
we
wanted
to
get
it
done
in
the
next
I.
Don't
know
three
to
four
months,
but
it'll
it'll
depend
on
on
the
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
gonna
try
to
push
it
sooner
rather
than
later.
A
B
Just
quickly
before
we
end
do
we
definitely
want
to
go
ahead
with
moving
API
and
controller
into
package.
It
sounds
like
there's
consensus
for
this
on
the
issue.
You
just
want
to
make
sure,
because
I
can
select
for
that.
What's
the
issue
moving
in
continue
builder
moving
the
scaffolded
API
and
controller
directories
into
the
package
directory
kind
of
like
how
the
current
operator
SDK
the
scaffolded
go.
Project
layout
is.
A
A
A
A
A
A
It
was
kind
of
confusing
for
some
folks
like
what
what
went
in
package
and
what
went
in
command
and
like
we're
weird
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
in
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.
B
Myself,
itit
it's
a
little
bit
confusing
because
for
it
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
to
the
API
types
are
definitely
bad,
but
even
then
you're
like
using
them
within
the
same
project,
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.
I
think
it's
more
a
matter
of
preference,
yeah.
A
So
yeah
I'd
be
fine
with
making
it
up
like
again,
I'd
be
I,
think
I'd
be
fine
with
making
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,
all.
B
Right
yeah,
it
sounds.
It
sounds
good
to
me
follow
up
with
some
things
in
the
issue.
I
hesitate
to
agree
with
making
an
optional
just
because
it
does
increase
complexity
or
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
and
just
like
make
changes
to
scaffolded
files,
but
for
COO
builder
to
support
both.
Maybe
it
yeah,
that's
too
much
complexity.