►
From YouTube: Kubebuilder and Controller Runtime 2021/03/11
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
B
You
have
to
stop
sharing
yours,
yeah,
yeah,
okay,
so
the
first
one
is
about
some.
There
were
a
couple
issues
about
sporting,
a
couple
packages
that
we
were
using
as
internal
before
they
were
already
trades
accepted
in
tuesday's
meetings,
and
this
one
and
the
previous
one,
if
I'm
not
mistaken
and
to
you
know
in
order
to
do
these
ones,
there's
they,
sir.
B
B
This
enables
the
other
two
draft
pull
requests
that
also
linked
in
the
agenda
that
are
82
and
83
that
are
that,
do
the
current
export
of
those
packages
and
as
it
is
a
breaking
change
and
we
are
already
in
a
bit.
I
would
like
to
know
so
comments
some
comments
about
this.
I
already
asked
eric
about
this
one
and
he
I
don't
know
if
you
want
to
share
your
your
thoughts
on
this
or
should
I
make
a
fast
summary
of
it.
C
Yeah,
I
can
talk
a
little
bit
about
it,
so
I
I
think
this
is
a
really
good
idea.
I
did
have
one
concern
about
the
level
of
hoisting,
this
abstraction
or
to
which
level
the
abstraction
was
wasted,
because
at
the
beginning
of
this
whole
plugins
development
thing,
we
were
a
little
bit
skeptical
about
exposing
a
particular
library
for
flags
which
is
the
spf
13
flag
library.
C
I
don't
think
that's
as
big
a
concern
here,
because
this
file
system
abstraction
directly
mirrors
the
os
package
effectively,
so
we're
not
really
losing
that
much,
but
I
just
wanted
to
make
that
concern
public
and
also.
I
was
a
little
bit
concerned
about
the
the
files
to
be
injected
at
the
cli
layer,
just
because
that's
kind
of
irrelevant
to
what
the
cli
layer
does
like
the
plugin
technically
could
not
even
scaffold
any
file,
see
that's
kind
of
the
point,
so
it's
kind
of
weird
to
have
the
file
system
injected.
C
I
think
that
would
still
be
a
problem
for
end-to-end
tests,
but
I'm
sure
we
could
work
around
that.
So
those
those
are
my
thoughts,
I'm
I'm
not
diametrically
opposed
to
doing
things.
The
way
that
you
have
them
set
up
here,
but
I
did
want
to
raise
the
idea
that,
even
though
end-to-end
testing
and
atomicity
is
more
possible
by
injecting
the
file
system
at
the
cli
layer,
we
don't
necessarily
need
to
do
that.
B
Yeah,
just
a
brief
comment:
the
reason
why
the
client
is
the
one
that
is
creating
the
file
system
and
injecting
it
is
because
it's
also
used
to
scaffold
the
config
file,
the
brake
configuration
file
and
that
file
it's
created
by
the
client
itself.
It's
not
created
by
a
plugin
or
by
a
sub
command.
So
if
we
want
to
have
the
automaticity
or
the
end-to-end
test
that
you
are
mentioning,
we
need
to
have
the
same
file
system
for
both
the
config
file
and
under
scaffold
the
files.
B
So
we
can't
do
it
like
deeper
in
the
plug-in
layer
or
something
like
that.
We
need
to
do
it
from
the
client.
The
user
doesn't
have
to
provide
it.
It's
it's
just
created
by
the
in
a
creation
of
the
of
the
client,
so
yeah,
that's
a
bit
of
a
concern,
exposing
both
affair
and
and
also
having
that
responsibility
moved
to
the
client.
But
I
think
that
the
benefits
that
we
could
get
from
this
are
pretty
significant
and
also
these
packages
that
we
want
to
support
this
one.
B
The
machinery,
the
scaffolding
machinery
is
being
duplicated
by
operator
sdk
and
basically
it's
being
copy
pasted
and
using
internally,
and
if
we
manage
to
expose
it
instead
of
copy
pasting
it
they
will
just
use
the
one
that
we
are
offering
and
I
think
that
will
reduce
the
the
duplicated
code.
A
lot
they're
like
it's
like
a
thousand
lines
or
something
like
that
that
would
be
removed
from
that
are
duplicated
right
now.
So.
C
A
B
B
B
A
A
A
Someone
or
other
person
you
like
to
speak
about
the
phone
science.
Do
you
think
that
it's
a
bigger
problem,
or
not
in
july
angel?
What
is
the
biggest
one
after
this
comfort?
Okay,
make
it
public.
It
is
internal
college.
I
think
it's
fine
because
we
decide
to
find
another
place.
So
this
is
a
concern
that
she,
if
you
will
decide
for
other
files
and
the
other
things
that
you
are
using
just
internally,
that
it
was
before
jessica
being
the
beast.
So
I
think
they're
really
the
same
holy
apply
about
to
the
japanese.
A
A
B
B
There
is
a
small
breaking
change
when
sporting,
the
mac,
the
machinery,
because
there
were
some
errors
that
were
being
exposed,
weren't
being
exposed
but
were
being
exposed
through
a
function
that
created
them
and
a
function
that
check
if
they
were
that
kind
of
error,
and
that
has
been
moved
to
a
properly
a
golan
1.13
errors
that
use
errors,
dot
us
to
to
check
the
type,
but
it's
without
taking
check
on
that
part
is
not
breaking
so
the
other.
The
other
two
drafts
will
request.
A
A
B
B
Yeah
this
one,
it
adds
some
concepts
like
the
like
the
plugin
bundle
or
or
some
other
concepts
that
weren't
introduced
in
the
first
one.
So
if
you
can
get
some
time
and
review,
this
one
would
be
nice
to
get
it
merged
before
and
the
main
point
about
the
plugin
phase
1.5
and
the
current
state
is
that
we
are
currently
on
beta
dot
0
and
it
has
some
breaking
chains.
B
B
This
means
that,
right
now
we
can
only
a
use.
One
plugin
at
a
time
this
is,
we
can
either
use
the
go
plugin
version
2
or
the
go
plugin
version
3..
Once
we
merge
this
part,
we
will
be
able
to
to
join
plugins
to
change
them
and
the
go
plugin
would
do
the
first
part
of
the
scaffolding
and
the
declarative
pattern.
Plugin.
B
B
Aside
from
from
adding
this
plugin
changing
due
to
the
fact
that
we
are
adding
this
plugin
changing
a
feature,
we
will
be
able
to
to
split
the
monolithic
go
plugins
which
are
pretty
big
into
a
base,
go
plugin
and
some
extra
plugins
that
will
do
some
part
of
the
of
the
scaffolding.
For
example,
the
component
config
x.
Scaffolding
is
a
clear
candidate
for
a
separate
plugin.
B
Extracting
the
config
directory
related
scaffolding
to
a
to
a
different
plugin
is
also
one
of
the
clear
things
that
could
be
implemented.
As
plugins
also
operator,
sdk
is
doing
its
own
plugin
chaining,
like
using
alpha
releases
and
better
releases
to
of
q
builder.
So
if
we
merge
1.5,
it
will
be
able
to
to
use
the
official
supported
one,
and
those
are
some
of
the
advantages
that
just
plug-in
changing
will
will
bring
to
the
table.
B
There's
also
with
this
plugin
phase.
It
also
improves
a
bit
the
plugin
resolution
algorithm.
So
there
will
be
some
cases
that
weren't
supported
before
and
will
be
supported
right
now,
for
example,
if
you
expect,
if
you
specify
a
set
of
plugins
that
will
be
used,
but
you
don't
specify
the
project
version
that
will
be
used,
the
client
will
try
to
to
resolve
it
by
itself.
B
For
example,
if
all
the
plugins
only
support
a
common
version
and
that
version
is
version
four,
it
will
be
used
that
one,
so
it
it's
a
bit
more
intelligent
in
the
resolution
plugin
in
their
solution,
algorithm,
but
that's
transparent
for
everyone,
and
that
has
no
breaking
chains
at
all.
So
those
are
some
of
the
scenarios
that
will
be
like
the
advantages
of
implementing
plugin
phase
1.5.
A
A
So,
by
moving
forward
to
fgs,
we
came,
for
example,
kobe
builder,
in
it
blue
games,
aj
put
it
rolling
and
any
other
option
plugin
that
is
called
folds
things
on
top,
so
by
default,
for
example,
any
api
that
you'll
use
comfort.
We
will
use
these
options
currently,
in
kobe
builder,
we
have.
It
is
declarative
partner.
That
is
our
agile,
including
that
is
the
way
that
you'll
be
college
before
that
you
do
things
in
the
controller.
A
The
other
advantage
is
like
we
want
to
run
copy
builder,
create
api
plugins
as
flag
and
jp
is
a
chain
of
plugins
that
you
like
to
do
nice
things
in
that
scaffold.
So
we
will
do
the
the
full
discover
the
default
files,
the
the
full
behavior
using
goal,
for
example,
then
we
can
use
again
the
declarative,
as
example,
so
just
in
for
that
api
we
will
do
the
customization
on
top,
so
we
could
do
very
things
very
nice.
We
have
another
proposal
that
she
was
accepted
as
well.
A
It
is
blockage
by
the
cheese
one
that
is
generate
the
full
code
for
deploy
an
image
in
on
the
cluster,
which
means
like
a
lot
of
people.
Would
you
like
just
to
create
operator,
to
have
the
solution
cluster
and
by
using
this
plugin?
Would
you
have
the
templates?
The
full
code,
like
eric
type,
is
still
folded
by
the
folk
following
what
you
believe
that
you
would
be
good
practice
like
a
conditional
status,
finalizers
things
like
that,
so,
which
is
also
going
to
help
people
learn
how
to
do
the
projects,
have
the
solution.
A
Faster
engineering
also
can
change
the
culture
that
is,
you
know,
reached
by
the
food.
This
is
one
of
the
ideas
into
the
other
options.
Highlight
is
the
possibility
after
we
say
that
you
one
plugin,
is
composed
for
other
plugins.
So,
for
example,
if
you
would
like
to
have
a
plugin
that
is
required,
as
they
haven't
plugging
into
the
gold
plugin
discovered,
both
we
could
make
a
composition
and
today
create
another
plugin
that
you
do
the
change,
the
associations
that
you
will
want.
So
we
can,
we
we
will
provide.
A
A
B
Yeah
yeah,
I
forgot
to
mention
that
you
will
be
able
to
set
the
plugins
flag
at
init,
and
that
would
mean
that
those
plugins
will
be
used
for
the
whole
project
for
all
your
command
calls
or
you
will
be
able
to
override
those
for
a
specific
command.
For
example,
I
could
use
the
basic
one.
The
google
one
for
the
init
and
all
my
controllers
and
apis
would
be
the
normal
ones.
A
However,
so
the
idea
was
like
if
you
will
be
able
to
extract
to
the
conflict,
and
it
is
be
completely
transparent
for
the
users,
because
all
this
change
doesn't
change
anything
for
the
asg
users
just
for
the
api
points
of
view.
So
if
you
are
able
to
do
that,
we
can
have
a
good
strategy
to
opting
and
opt
out
the
configuration
which
would
help
us
like
give
it
his
flexibility
to
to
move
forward
to
ensure
the
backyard
compatibility.
A
B
B
Anyone
has
any
concern,
or
any
doubt
please
feel
free
to
to
interrupt
me.
There
is
one
concern
that
was
raised
and
the
main
one
is
that
we
are
introducing
a
breaking
an
api
breaking
change
in
beta.0
when
there's
nothing,
there's
no
rule
that
forbids
us
from
doing
that.
But
it's
not
the
most
elegant
pattern
either.
B
So
it's
a
bit
of
a
concern,
so
the
idea
was
to
try
to
reduce
at
a
minimum
which
part
we
are
going
to
modify
from
from
the
api,
as
we
are
close
enough
to
a
release
so
that
we
should
care
about
that
and
in
order
to
do
so,
they've
only
well,
the
only
the
the
related
the
only
api
change
is
related
to
the
enhancement
proposal
that
was
merged.
The
rest
of
the
breaking
changes
are
related
to
the
previous
pull
requests
that
we
saw
about
exporting
some
files
and
removing
and
exporting
some
packages.
B
So
the
current
implementation
also
contains
that,
but
once
we
merge
that
it
will
erase
so
that
they
don't
have
those
files
and
we'll
use
the
exported
ones
and
without
taking
that
into
account.
The
only
breaking
change
is
the
modification
in
the
ipa.
This
means
that
end
users
won't
be
affected
at
all
users
of
the
client
of
either
keybuilder
or
operator.
Sdk
won't
see
any
effect.
B
They
will
only
see
the
enhancement
in
the
plugin
resolution
algorithm,
but
that's
quite
transparent
and
it's
an
enhancement.
It's
it's,
not
a
working
change.
Cli
developers
such
as
a
operator
sdk
well
operator,
is
the
case
both
a
clear
developer
and
a
plugin
developer.
It
has
its
own
plugins
and
it
also
uses
a
a
clito,
but
from
the
creation
of
the
cli,
the
api
will
be
exactly
the
same.
B
There
won't
be
any
changes
either
and
the
only
changes
will
be
in
the
great
integration
of
the
plugins,
so
they
are
and
those
and
those
breaking
changes
are
already
approved
in
the
enhancement
proposal.
So
I
think
we
are
quite
safe
merging
this
proposal.
I
think
it
is
a
concern
to
modify
the
api
in
the
beta0,
but
we
are
not
in
a
release
candidate
or
already
with
a
with
a
major
version
release.
So
it's
not
forbidden
thing
to
do
and
the
it
has
been
already.
Quite.
B
B
I
just
rebased
today
to
the
last
exchanges
in
sdk.
The
plugins
in
sdk
has
have
been
ported
to
this
phase.
1.5
and
all
the
ca
dies
are
also
passing.
So
I
think
we
have
a
pretty
good
coverage
and
testing
support
for
for
this
feature,
and
I
think
that
even
being
a
breaking
chainsaw
in
a
one
in
a
beta
state
right
now,
I
think
we
can
merge
it
and
and
release
it
as
part
of
the
version
3.0.
B
The
alternatives
to
this
could
be
waiting
until
the
next
major
version,
and
in
which
case
I
don't
know,
when
version
two
was
released,
but
I'm
sure
that
it
was
a
couple
years
ago
or
something
like
that.
I
don't
know
when
version
4.0
will
be
released,
but
I
think
it's
quite
long
in
the
future.
So
I
waiting
for
our
next
version.
I
think
it's.
A
B
The
the
whole
plugins
would
have
to
be
duplicated
with
all
the
templates.
Maybe
the
templates
can
be
shared,
but
the
plugins
themselves
will
have
to
be
duplicated.
Any
change
that
we
do
to
a
plugin
will
have
to
be
done,
at
least
in
two
places,
and
maybe
even
four,
if
we
are
also
doing
it
for
go
version
two.
B
C
B
If
we
have
both
support
for
version,
1
and
version
1.5,
we
will
have
to
duplicate
them.
For
the
api
of
a
plugin
is
different,
it
doesn't
have
only
urban
methods.
Now
it
has
a
scaffold
process,
scaffold
press
scaffold,
so
we
will
probably
have
to
duplicate
them.
There
may
be
some
shortcut
for
this
part,
and
most
of
the
code
would
would
have
to
be
duplicated.
Somehow.
C
C
But
when
it
comes
to
the
cli
package
yeah
there
would
be
a
decent
amount
of
duplication
there.
It
wouldn't
really
be
duplication
because
you'd
be
rewriting
a
lot
of
it
for
phase
1.5
yeah.
I
just
I
just
wanted
to
point
out
that
there's
not
as
much
duplication
as
as
you
think,
but
there
still
is
a
decent
amount.
B
A
B
Sorry,
I
know
you
eric
was
you
were
the
one
that
who
raised
this
this
concern
the
one
about
the
beta
release.
Right
now,
I
think
I
have
reduced
to
the
minimum
the
aap
breaking
changes
to
only
be
the
those
that
were
approved
in
the
first
enhancement
proposal
that
was
merged,
so
I
I
do
think
that
it
can
be
merged
and.
A
B
D
B
But
but
that
change
itself
is
not
a
breaking
change.
It's
just
it's
just
an
extra
feature
that
is
needed
to
so
that
operator,
sdk
doesn't
break
backwards
compatibility,
but
it's
not
a
breaking
feature
so
in
case
that
wasn't
merged
for
version
3.0
that
could
be
merged
for
version
3.1
or
even
yeah.
So
that's
not
the
main
concern,
because
it's
just
an
addition
of
the
apa,
but
it's
needed
to
in
order
for
for
operator
sdk
to
maintain
full
backwards,
compatibility
and
use
this
new
plugin
system.
It
requires
the
the
bundle,
the
banter
concept.
A
So
I
think
the
the
question
that
you
we
need
to
answer
here,
actually
no
needing
somebody.
The
goal
of
of
these
is
like.
We
need
reacha
consensus,
we
will
merge
1.5
before
the
stable
release
or
we
will
do
this
table
really
easy
now
and
you
don't
manage
1.5
plugins.
So
in
that
document,
if
you
can,
can
you
show
the
agenda
please
what
I
did?
A
I
tried
to
put
at
least
all
pros
and
cons
that
was
in
my
mind
to
help
us
to
reach
the
best
decision
for
us
regards
the
consent
like
we
are
in
a
beta,
so
we
cannot
breaking
do
introduce
a
breaking
change.
I
would
agree
with
that.
If
the
breaking
change
affects
the
in
the
users,
which
is
not
the
case
or
if
we
are
going
to
have
an
api
provided
by
the
project.
A
A
A
A
So
this
is
something
that
I
don't
think
it's
nice
and
you
keep
it
engine
that
you
need
to
keep
maintaining
forever
until
the
next
one.
The
reason
one
one
option
was
like,
let's
put
it
using
the
4.0,
but
we
don't
want
to
make
it
the
4.0
soon
as
well.
So
I
think
it
is
start
to
be
out
of
the
table,
so
we
have
just
two
options
or
maybe
now
do
another
better.
A
I
know
more
one
or
two
how
many
be
required
and
she
will
be
able
to
do
this
table
or
try
to
make
it
is
compatible
after
the
release
without
introducing
breaking
chains
which
can
break
okay,
which
can
bring
more
effort
to
keep
the
project
maintained
after
that
angie.
Probably
a
bad
experience.
If
someone
started
to
use
t's,
this
part
of
the
api
that
you
know
that
she
is
born
is
born
and
deprecated.
You
know,
I
think
the
feature
is
are
very
important
because
it
brings
flexibility.
A
You
solve
a
lot
of
problems,
engaging
sdk
regarding
antenna,
village
ng
will
provide
more
more
real
plugging
options
for
others
projects
as
well,
so
I
think
they
are
very
valid,
so
it
doesn't.
You
know.
The
only
cons
that
I
see
is
that
you
will
delay
will
need
to
delay
the
release
again
like
for
two
or
three
weeks
in
the
max.
I
think
it
is
going
to
be
fine.
B
B
A
A
A
B
C
Yeah,
I
think
my
biggest
problem
was
like
this
whole,
bundling
idea
not
being
in
the
ep,
but
you've
remedied
that
by
creating
an
update
to
the
ep
for
bundling.
So
I
think
once
that
gets
well.
First
of
all
that
isn't
a
breaking
change,
that's
a
feature,
so
that
can
be
that
can
go
in
after
three
zero
zero,
like
you
said
so.
What
exists
now
is
a
breaking
change,
the
1.5
ep
and
implementation,
and
I
think
now
that
everything
in
the
ep
is
implemented
and
nothing
more
than
that.
D
A
B
A
A
I
would
like
to
do
more
one
question
eric
after
the
things
that
you
checked
so
far,
the
implementation
and
about
all
this
stuff.
Do
you
have
any
other
concern
that
is
not
only
related
to
the
liberties
we
delay?
Anyone
see
any
problems
should
delay
the
release.
For
I
don't
know
two
weeks
three
weeks
has
someone
any
other
concern
that
was
not
removing
the.
A
B
A
B
I
will
finish
yeah,
so
I
think
the
idea
here
is
to
merge
the
pull
request
that
I
mentioned
before
about
the
sporting
day
packages.
I
will
rebase
the
implementation
to
to
only
have
the
changes
about
the
api
and
get
some
more
reviewers
over
there
to
to
make
the
sure
that
the
implementation
code
is
correct,
and
once
we
do
it,
we
can
merge
it.
A
D
B
E
E
For
rest
per
resource
type,
so,
for
example,
we
were
like
registering
to
node
resource
so
and
every
one
of
our
pods,
where,
where
is
where
we're?
Caching,
like
all
the
nodes
of
the
cluster,
so
in
clusters
of
size
between
100
and
500,
the
spike
on
masters
for
the
api
server
for
cpu
and
memory
is
huge
because
it
sends
you
its
sending
us
all
the
nodes
every
req
after
cycle,
but
at
every
of
our
posts
we
were
just
interested
in
then
in
the
node
that
was
running
this
specific
board.
E
So
with
this
in
mind,
we
found
an
issue
at
control
runtime,
so
people
talk
about
similar
issues
and
we
hack,
so
we
we
did
hack
something
in
our
product
and
then
we
try
to
put
some
pr
app
stream
at
control.
Runtime
and
alvaro
told
me.
That
is
a
good
idea
if
we
start
maybe
with
a
design
document,
which
is
this
pull
request,
and
so
this
is
it
more
or
less
what
it
does.
E
Is
it's
adding
a
new
field
to
cache
the
options,
so
you
can
traverse
all
the
code
until
you
reach
the
list
watch
for
the
informers,
and
this
way
you
can
filter
out
or
filter
in
the
stuff.
You
are
caching,
and
this
is
the
the
simple
approach
we
have
found
and
I
suppose
an
alternative
will
be
like
change
the
builder.
E
E
D
A
D
Yeah,
the
the
main
debatable
thing
about
this
is
there's
a
very
long
standing
issue
about
not
having
any
kind
of
filtering
possibility
on
the
cache
which
we
so
far
blocked.
By
saying
we
want
some
nice
integration
with
the
cashback
client.
If
we
do
that
and
with
this
change
we,
if
we
merge
this,
we
would
go
away
from
the
stands
and
say:
okay,
you
can
configure
this
on
the
cache.