►
From YouTube: Kubernetes KubeBuilder Meeting 20200521
Description
KubeBuilder Meeting for 2020/05/21. See https://sigs.k8s.io/kubebuilder for more details.
A
Good
morning
this
is
the
q
builder
controller,
runtime
and
controller
tools
meeting
for
thursday
may
21st
in
2020.
As
a
reminder,
this
meeting
is
being
recorded
and
will
be
posted
to
youtube
and
publicly
available.
So
don't
say
anything
you
don't
want
recorded
for
people
to
find
200
years
from
now
on,
an
archive
of
all
content,
the
internet,
all
right.
So,
let's
see
what's
on
the
agenda,
we
have
two
things
looks
like
eric.
Has
the
first
thing?
So
why
don't
you
take
it
away?
Eric.
B
Yeah,
hey
everybody.
I
want
to
discuss
the
the
difference
between
the
three
versions
that
currently
exist
in
cube
builder
master,
there's
the
queue
builder,
binary
version
that
gets
released
and
that
people
pull
from
and
run
the
binary,
the
binary
for
the
project
version,
which
is
in
the
configuration
file
scaffolded
for
each
people,
their
project
and
then
plug-in
versions,
which
are
the
semantic
version
attached
to
the
new
builder
cli
plugins
that
were
recently
added
to
master
a
few
weeks
ago.
B
B
The
second
phase
is
going
to
be
something
that
we'll
be
working
on
that
deals
with
a
more
fine-grained
approach
to
modifying
the
bass.
Scaffold
that
can
builder
provides,
but
right
now,
phase
one
is
what
is
in
master
and
phase.
One
provides
a
few
things
and
changes
the
project
the
layout
a
little
bit,
so
it
provides
a
versioning
scheme
and
a
fully
qualified
naming
scheme
for
plugins.
B
B
We
added
resources,
and
possibly
one
other
thing,
if
I
remember
correctly
and
then
in
v3,
which
is
currently
v3
alpha,
we've
added
the
layout
key
and
the
plugins
key
so
based
on
the
project
version,
we
know
what
is
going
to
be
in
the
project
file.
What
we
can
assume
will
be
there
and
q
builder
can
save
whether
it
supports
the
current
version
being
used
or
not.
B
Now
the
plugin
version
is
different.
That's
what
will
go
in
the
layout
key
and
it
is
only
relevant
for
right
now,
project
versions,
p2
and
v3.
The
reason
I
say
it's
relevant
for
project
versions
is
because
plugins
need
to
support
a
particular
project
version,
because
all
people
have
projects
with
project
version.
B
That's
part
of
the
plug-in
interface
spec,
but
it's
different
from
the
project
version
because
plugins
are
specifically
plug-in
version
is
specifically
talking
about
these
scaffolds
and
what
that
plug-in
knows
about
at
that
particular
point
in
its
development
life
cycle
at
the
point
that
it's
released.
It
knows
that
I
can
scaffold
these
things
based
on
this
version.
That's
in
the
layout
key,
so
they
are
different
and
should
be
differentiated
when
bumping
either
version.
B
B
A
That's
clearly
a
bug
fixing
it
so
that
the
plug-in
no
longer
panics
seems
to
be
pretty
clearly
a
bug
fix
in
my
head,
like
I'm,
I
was
just
trying
to
think
of
like
a
category
of
things
that
are
like
this.
Is
this
is
kind
of
unambiguously
we
could
consider
a
bug
fix,
so
that's
that's
at
least
some
set
of
things
that
I'd
consider
to
be
in
in
that
kind
of
patch
category
for
a
plug-in.
C
B
Asked
hold
on
hold
on
one
sec,
and
so
so
I
ask:
does
that?
Does
a
patch
version
actually
matter,
then,
when
encoding
this
in
a
plug-in's
version
like
if,
if
both
of
those
things
don't
matter,
then
why
not
just
get
rid
of
patch
versions
all
together
and
use
major
minor
right?
Because
if
you
can
match
the
layout
key,
the
version
in
the
layout
key
against
the
major
minor
version,
then
patch
version
doesn't
matter.
A
C
I
I
just
think
that
you
would
you
be
easier.
Go
through
to
this
question,
because
it's
kind
of
conclusion:
we
have
three
things:
three
different
types
of
versions.
If
we
come
back
one
step
and
you
think
about
the
concept
so
just
to
clarify,
I
can
can
I,
as
a
contributor,
do
a
change
that
will
result
a
break
change
for
virtual
projects,
for
example.
If
I
would
you
like
to
to
do
a
fix
that
you'll
be
able
to
exchange
okay,
are
you
do
a
new
version
of
the
plugin?
C
Since
science
is
a
great
change,
you'll
be
a
verb,
but
this
blogging
could
not
be
executed.
In
my
opinion,
in
the
video
projects,
for
example,
in
all
the
projects,
I
I'm
you're
right,
chancey
to
confirm
lucky,
I'm
just
trying
to
define
here.
The
proposed
of
each
version,
you
know
is
my
understands
correctly
that
the
proposal
of
the
project
versions
are
related
to
the
skull
folds.
C
What
I'm
trying
to
say
is,
I
understand
so
far
is
that
before
we
move
from
view
v1
to
v2,
but
which
has
brake
chains
in
the
scout
forged
project,
we
created
cheese
very
soon
and
you
have
a
migration
guide.
So
in
the
kobe
builder,
if
I
want
to
for
any
reason,
introduce
and
break
change,
I
need
to
go
for
a
upper
version
of
the
project
version,
any
break
change
for
the
skull
folded
projects.
C
D
So
eric
and
sully
correct
me
if
I
get
this
wrong,
but
I
think
what's
happening
as
part
of
the
move
to
project
version,
three
is
that
project
version
as
of
project
version.
Three
no
longer
means
no
longer
has
a
relation
to
the
scaffold
in
one
and
two.
It
did
because
there
was
only
ever
a
go
project
version.
A
C
Yeah,
my
goal
is
just
to
try
to
figure
out
how,
for
example,
as
a
contributor,
I
came
into
a
new
change:
I'm
ready
to
change
a
new
version
of
a
plugin
and
if
it
is
plugin,
should
you
be
available
for
the
oldest
versions
of
projects
as
well
or
just
for
the
releases
one
jesus
is
the
point.
She
often
actually
put
a
question.
You
know
it's
like
a
a
broke
up
concept,
for
we
try
to
understand
to
define
how
we
could
move
forward
to
engineer
things.
A
A
A
D
A
A
B
A
Ahead,
I,
I
could
potentially
see
a
case
where
you'd
actually
now
that
I'm
thinking
about
it,
where
you'd
want
the
minor
version.
So
if
you
make
an
improvement
and
there's
somehow
like
an
old
version
of
the
plugin
that
doesn't
have
that,
doesn't
know
about
that
edition
and
it
tries
to
scaffold
new
files
that
might
confuse
things
so
like.
Let's
say
you
have
version
3.1
and
then
that
would
be.
I
guess
that
would
be
breaking.
D
Yeah,
I
think
you're
saying
like
if
you
go
backwards
like
if
you've,
if
you've
scaffolded
a
project
that
and
the
layout
key
says
version
two,
but
really
the
plugin
was
version
2.1,
let's
say,
and
it
does
some
stuff
and
then
somehow,
for
whatever
reason,
you're
using
a
binary
that
doesn't
support
3.1
but
for
2.1,
but
supports
two.
So
like
everything
still
seemingly
works,
but
really
in
fact
whatever
that
2.1
improvement
was,
is
a
change
in
so
far
as
the
the
plug-in
that
you're
using
that
is
a
version.
2.0
plug-in,
doesn't
work
for
some
reason.
A
B
So
I
I
think
for
scaffolding
stuff
it,
it
is
something
we
can't
anticipate
and
be
like.
If
you
have
to
have
a
case
where,
if
you're
adding
some
new
thing
to
scaffolding,
then
you
have
to
consider
the
case
where,
like
if
sorry,
if
you
do
not
consider
the
case
where
this
thing
you
assume
to
exist,
does
not
exist,
then
you
must
make
a
breaking
change.
But
if
you
build
in
logic
to
be
like
backwards
compatible,
then
we
don't
have
to
make
a
breaking.
B
C
D
Well,
if
you
add
a
new,
if
you
add
a
new
file
and
like
change
the
make
file
in
a
in
an
updated
version
of
an
existing
plugin
like
that,
could
be
a
breaking
change,
because
if
you
go
back
to
an
older
version,
the
addition
of
that
file
might
somehow
break
something
from
the
older
version.
It's
hard
to
talk
about
this,
because
we
have
nothing
concrete.
A
A
So
the
argument
that
is
not
a
breaking
change
is
that
you're,
probably
scaffolding
that
you're
scaffolding,
the
docker,
ignore
file
out
on
project
init,
and
so
nothing
else
should
need
to
would
would
need
to
update
it
or
modify
it.
So,
whether
or
not
it's
there
is
kind
of
immaterial
except
to
the
scaffolded
project
right.
A
So
if
it's
there,
you
get
nice
behavior
around,
like
not
accidentally
copying
in
soft
extraneous
stuff
during
your
build
phase,
and
so
it's
just
a
you
kind
of
a
user
visible
feature
if
but
like
new,
adding
adding
a
new
file
or
something
probably
isn't
going
to
change
it.
If
we
structure
it
correctly,
however,
the
point
at
which
it
becomes
a
breaking
change
is,
if,
for
some
reason,
like
q
builder,
create
controller
needs
to
then
modify
that
docker
ignore
file.
A
D
So
so
in
that
case,
I
think
that's
a
good
example.
So
in
that
case
I
think
what
we're
basically
saying
is
like
if
you
scaffold
something
during
init
and
then
you
expect
that
thing
to
be
there
during
other
commands
or
even
if
you
scaffold
something.
Basically,
if
you
scaffold
any
files
and
then
later
expect
them
to
be
there
in
other
commands,
then
that's
potentially
a
breaking
change,
because
older
versions
of
that
plug-in
don't
know
about
the
presence
of
that.
B
I
would
I
would
say
that
we
shouldn't
worry
about,
because
we
should
in
the
spec
for
phase
two
say:
if
you
are
a
phase
two
plug-in
and
you
expect
things
to
be
there,
then
the
burden
of
proof
is
on
you
and
you
need
to
check
what
the
layout
key
is
to
make
sure
that
you
are
receiving
the
right
input,
because
then
I
think
we
get
into
like
dependency
management
with
plug-in
versions,
and
I
don't
think
we
want
that.
Does
that
sounds
like
the
direction
we
would
be
going
in
that
case.
A
Yeah,
I
think
that
seems
reasonable.
I
think
that
makes
maybe
a
little
bit
of
an
argument
that
we
should
continue
to
have
a
minor
version.
Sort
of
a
plug-in
is
just
like.
Well,
I'm
not
gonna
do
feature
detection
and
I
just
always
need
you
know
the
version
of
at
least
the
version
of
this.
With
the
docker
ignore
file.
D
D
I
guess
what
I'm
asking
is
like
in
the
if
it's
scoby
2
versus
ghost
b7,
it's
a
really
simple
like
does
this
equal?
Well,
I
guess
even
in
that
case
like
is
it
at
least
v2
right
like
you,
maybe
you
say
that
you're
going
to
support
v2
through
v4,
but
not
b5
and
b6
and
b7.
So
I
guess
you
don't?
You
still
have
the
problem
of
semantic
range
checking
even
with
just
major
versions.
A
Yeah-
and
I
mean
like-
I
think,
the
you
know-
the
semantic
range
checking
probably
won't
end
up
being
famous
last
words,
probably
won't
end
up
being
too
complicated.
It'll
probably
be
like
is
major
version.
Two
like
is
major
version
equal
equal
to
and
then
like.
Sometimes
it
might
be,
is
minor
version
greater
than
two
or
equal
to
two
right,
like
I
don't
think
it's
going
to
be
like
crazy,
complicated,
like
major
version,
two
less
than
four,
except
not
3.6,.
D
D
D
So
in
my
mind
that
opens
another
question
which
I
think
like
right
now:
there's
a
based
on
that
there's
a
fix
that
we're
gonna
make
to
remove
the
patch
version,
but
then
there's
a
current
bug.
I
think
where
right
now
we're
only
doing
like
exact
matching
of
layout
keys
with
plugins,
so
we
probably
need
to
like
if
you're,
if
your
project
file
says
I
support
version,
I
was
scaffolded
with
plug-in
version
2.0
and
then
later
there's
a
2.1
plug-in.
A
B
D
Hey,
we
noticed
your
layout
version
key
is
this:
we
have
a
plug-in.
That
is
like
an
improvement
on
that.
Do
you
want
to
use
it
like?
Are
you
okay
with
this?
If,
yes,
like
great,
we'll
do
it
and
then
then
we
could
potentially
also
have
have
either
part
of
that
same
prompt
or,
as
a
separate
prompt
say.
D
B
A
A
B
D
But
it's
still
unclear
to
me,
like,
like
the
example
I
gave,
of
the
make
file
and
we're
adding
a
make
target
unless,
like
I
guess,
it's
possible
for
plugins
to
like
run
make
targets,
but
that
seems
like
an
odd
thing
potentially
for
them
to
do
so.
There's
there
seems
like
there's
like
a
class
of
things
that
well,
I
guess
that's
not
true.
Right,
like
the
nip
runs,
make.
A
D
C
C
I
don't
know
if
he
just
should
try
make
simple
like
in
the
docker
file,
if
he
okay,
if
they
knew
docker
fire,
that
they
knew
very
something
plugging
you
well
is
you
which
break
something
because
it
the
clear
features,
do
not
expect
it
to
have
the
docker
fire,
that's
it.
It
doesn't.
Have
it
there
before
so
watch
problem
each
king
calls.
You
know.
D
D
So
I
guess
what
I'm
asking
like
is
like
in
that
second
class
of
things
like
when
we
tell
a
plug-in
author,
how
to
version
their
plug-in
like
what
guidance,
I
guess
I
guess
what
it
boils
down
to
is:
what
guidance
are
we
giving
plug-in
authors
for
how
to
version
their
stuff
yeah
like
what
things
can
reasonably
be
considered
non-breaking
and
what
things
should
we
say
are
breaking,
even
if
it
can
be
very
conservative
about
that,
so
that
lots
of
things
are
breaking.
I
don't
know
it
seems
like
a
tough.
A
A
C
No
sorry,
I
I
just
had
to
say
that
they
created
someone
niching
they
have
before.
Just
before
we
tried
to
clarify
the
purpose
of
each
very
some.
Do
you
know
angie
how,
as
a
contributor,
how
I
exactly
that's
like
the
guidance
like
a
joe
spoken,
you
know
how
how
I
know
when
I
should
bump
in
the
big
one,
the
media
one.
You
know
how
I
should
work
with
that.
B
Yeah
I
can
I
can
draft.
I
can
summarize
everything
that
we
talked
about
today
in
an
issue
after
this
and
address
your
concerns.
Yeah,
it
sounds
like
we
need
to
have
a
spec
as
to
what
exactly
a
non-breaking
versus
a
breaking
change
is
and-
and
I
for
for
future
discussion.
I
do
think
that
we
can
concretely
define
these
things
and
that
this
isn't
an
unsolvable
problem.
A
So
if
you
could
conceivably
reference
a
change
in
another
file,
then
it
should
be
breaking
and
if,
if
you
could,
if
you
could
not
reference
a
change
in
another
file,
then
it
perhaps
could
be
considered
non-breaking
so
like
adding
a
new
public
variable
to
main.go
could
be
considered
breaking
because
something
else
would
probably
want
to
reference
it.
Adding
a
private
variable
might
not
be
because
something
else
probably
wouldn't
want
to
reference
it.
You
know
kind
of
same
with
the
make
file
targets.
B
C
A
A
A
I'd
largely
expect
people
that
are
doing
like
file
manipulation
like
that
to
be
doing
a
very
mostly
constrained
set
of
operations
and,
if
they're
outside
of
this
operation
set
of
operations,
I'm
kind
of
like
well
you're
doing
something
that
might
be
a
little
brittle.
But
like
the
things
that
I'd
expect
you
to
be
able
to
do,
are
like
go
path
rewriting
which,
like,
like
you,
know,
adding
adding
slash
package
or
like.
A
You
know
being
able
to
add
an
additional
thing
and
so
like
that
set
of
changes
would
generally
be
considered
safe
because,
like
removing,
that
line
is
probably
a
breaking
change,
and
so
that's
that
line
is
kind
of
like
the
public
interface
but
like
if
you're,
if
your
plug-in
is
depending
on
some
random
line
being
present
somewhere.
That's
not
like
declared
as
explicitly
this
is
a
scaffolding
point
then,
like
yeah,
you're,
you're,
probably
doing
something
weird
that
we're
we're
not
con.
We
don't
want
to
consider.
B
A
A
D
D
C
I
don't
know-
maybe
I'm
cb
sorry
for
my
city
questions,
but
she,
for
example,
that
chipotle
question
that
is
in
the
agenda
that
she
is
the
proof
of
the
concept.
It's
like
small,
really
small
change
that
she,
if
he
will
do
that,
to
change
in
the
scaffold
you
break
the
future
projects.
Okay,
so,
theoretically,
should
be.
I
understand
the
upper
version
of
the
plugin,
the
3.0,
so
my
question
is
studio3
also
be
available
for
v2
or
in
this
case
only
for
v3
alpha.
C
C
C
A
Yeah
so
so
plug
say,
saying:
project
version
two
in
your
in
your
project
file
is
kind
of
semantically
equivalent
to
saying
project
version
three
alpha
layout
2.0,
and
so
you
wouldn't
expect
layout
2.0
to
change
right.
Yeah,
it's
a
good
point,
and
so
you'd
have
to
do
if
it
was
a
breaking
change.
You'd
have
to
do
layout,
go
slash,
3.0
and
there's
no
way
to
express
ghost
3.0
and
project
version
2.,
so
like
project
version
2
should
not
now
not
change.
B
B
A
Do
do
we
want
to
change
the
interface
slightly
so
that
a
plug-in
receives
the
I
mean,
I
guess
a
plug-in
knows
the
version
that
it's
being
called
with,
because
it
can
look
at
the
layout
key.
So
hypothetically,
if
your
plug-in
is,
is
simple
enough
and
there's
just
like
minor
changes
between
v2
and
v3,
you,
you
don't
have
to
duplicate
or
you
can
you
can
import
a
lot
of
the
scaffolding
code
yeah.
C
So
jessica
confirmed
my
understanding,
so
if
he
me
or
any
any
developer
in
the
community,
the
site
should
do
something.
That
is
a
great
change
since
you'll
be
a
new
new
plugin
person.
Pretty
dope
entities
cannot
change
the
old
layout
of
project.
Reversals
b2
cheese
will
be
a
change.
Interesting
v3
alpha
weighing
the
v3
alpha
be
a
stable
one
can
actually
happens,
needs
to
be
before.
Consequently,
is
right.
My
wonder
statement.
D
I
think
camilla,
if
you
want
to
make
a
breaking
change
to
an
existing
plugins
scaffolding,
then
the
way
things
work
now
is
basically
have
to
create
a
new
plugin
that
returns
its
new
layout
key
and
when
you
call
the
init
and
create
api
create
web
commands
like
it'll,
do
those
things.
So
it's
basically
a
brand
new
plugin
and
I
think
what
sully
was
saying
is
like
there's,
there's
potentially
like
tons
and
tons
of
overlap
between
version
two
and
version
three.
So
we
have
to
like.
A
C
So
then
we
would
need
if
it
okay,
v4
v5,
is.
However,
we
create
new
versions,
all
support
genevieve3.
All
these
plugins
will
support
the
same
project
version
angel
eog
choose
the
upper
one:
okay
unlikely.
We
will
choose
the
d4.
Now
I
have
the
f5,
so
I
would
like
to
use
the
five,
but
if
for
the
users
that
she
has,
the
project
is
comfortable
for
the
two.
We
need
a
migration
guide
in
the
case
it
has
because
it
has
a
breaking
change.
So
the
four
to
five
blue
game
requires
a
migration
guide.
A
C
Angie,
okay,
they
now
have
other
questions
that
I
made
for
eric.
Maybe
I
am
silly,
but
he
all
will
be
stable
in
victory.
So
what
will
be
the
purpose
of
the
projective
person?
After
that?
You
know
in
the
future,
because
we
will
change
the
the
plugins
versions
until
we
kill
the
concept
of
of
the
project
versions,
because
before
it
was
cheesy
stuff,
though
no
breaking
chains
engine
now
we
can
introduce
vector
chains
and
make
the
migration
variance
based.
A
So
I
I
expect
the
only
time
we
want
to
change.
Project
version
is,
if,
like
project
version,
is
now
an
indicator
of
the
structure
of
that
project
file.
So,
like,
let's
say
we
add,
we
rearrange
the
layout
or
we
change
the
name
of
one
of
the
keys
in
the
project
file
or
we
decide
that,
like
we're,
really
bored
and
all
the
yaml
keys
are
now
unicode
emoji
characters.
A
Then
we'd
we'd
have
project
version
v4,
because
you
know
we've
we've
changed
layout
to
be
the
layout
key
to
be
a
house
emoji,
that's
kind
of
a
silly
example,
but,
like
you
know,
it
does
happen,
sometimes
that
the
structure
of
config
that
configuration
file
might
change.
If
we
look
at
like
other
projects
like
we
might
decide
that
we
want
to
rename
like
we
want
to
merge
the
layout
key
and
the
extra
plugins
configuration
key
into
like
a
single
list
or
a
single
dictionary.
A
C
A
C
B
I
agree
and
also
we're
running
out
of
time
here.
I
just
want
to
say
that
we
should
probably
have
some
documentation
talking
about
everything
that
we've
discussed
here
before
we
release
the
next
version.
Does
that
sound
like
a
reasonable
thing?
I
I
agree
okay,
so
I
will
get
started
on
that
and
I
think.
D
I
think
circling
back
there's,
it
sounds
like
there's
a
bug
fix
or
a
feature
that
we
need
to
do
to
to
support,
like
the
semantic
version
plug-in
execution
against
older
versions.
I
guess
that's
something
we'll
cover
in
the
in
the
issue
you
create
eric,
but
that
seems
like
something
that
needs
to
be
fixed
fairly
quickly.
Also
before
we
release.