►
From YouTube: Kubernetes KubeBuilder Meeting 20200716
Description
KubeBuilder Meeting for 2020/07/16. See https://sigs.k8s.io/kubebuilder for more details.
A
A
A
A
B
B
A
A
C
A
D
A
A
C
Follow-Up
was
a
design
type
proposal
to
for
a
way
to
inject
errors,
so
that
we
could
test.
I
think
I
put
some
a
little
bit
of
pseudocode
in
the
in
the
design
proposal,
so
you
know
just
if
you
wanted
to
test
your
handled
versus
unhandled
error
cases
in
your
controller's
reconcile
logic.
This
could
be
a
good
use
case
for
injecting
errors
into
the
vacline
and
so
that
it
returns
back
for
testing.
C
A
A
A
Messed
up
a
lot
in
with
the
equivalent
functionality
in
in
core
kubernetes,
where
people,
like
inverted
action
and
resource
type.
I
think
I
did
that
once
actually
a
piece
of
code
and
I've
seen
other
other
tests,
do
it
as
well.
So
if
we
could
figure
out,
I'm
assuming
resource
type
is
just
the
resource
string.
Yeah,
it's
it's!
It's
like
a.
A
C
E
We've
had
this
separate
metric
server
running
that
that
has
its
own
separate
informer.
That
is
basically
just
like
watching
for,
create
or
delete
events
on
crs
and
then
creating
metrics
for
those
with,
and
what
we've
been
doing
now
is
we
just
have
like
a
simple
like
gauge
back
and
we
set
it
to
one
when
there's
a
cr
available
and
we
delete
the
thing
when
the
cr
goes
away.
So
you
basically
have
this
way
of
looking
at
like
how
many
you
can
kind
of
do
metering
kind
of
things
with
this.
E
So
what
I
was
wondering-
and
we
were
starting
to
look
at
like-
can
we
improve
this
at
all,
is?
Can
we
make
a
handler
support
one
of
these
metrics
instead,
so
that
we're
not
starting
up
a
separate
informer
and
we're
not
running
a
separate
server
and
we're
basically
kind
of
just
hooking
into
something
that
already
exists?
And
it's
you
don't
have
to
worry
about
all
the
informer
scope,
concerns
and
all
this
other
stuff,
that
kind
of
happens
when
you
run
a
separate
conformer,
so
I've
got
this
branch,
I
don't.
E
I
haven't
created
a
pr.
Yet
I've
got
this
branch
that
basically
adds
a
enable
resource,
metric
boolean
value
to
the
enqueue
request
for
object
handler,
and
then,
if
that's
it's
defaulted
to
false.
But
if
you
set
it
to
true,
then
it
starts
basically
populating
a
new
metric
for
every
cr
that
comes
in
with
the
creation
timestamp
and
you
get
like
group
version
kind,
name
and
name
space
labels,
and
you
basically
get
the
same
thing
that
we
we've
been
doing
in
operator
sdk.
A
A
E
F
F
A
A
Okay,
so
there's
that's,
that's
usually
the
best
way
just
and
as
as
this
is
just
like
a
general
call
out
to
anyone.
That's
listening,
so
the
the
kubernetes
ci
robot
will
like
suggest
approvers
and
reviewers
in
like
the
little
comment
it
leaves
and
we
actually
at
this
point
we
tried
to
keep
our
list
of
potential
reviewers
and
approvers
up
to
date
and
stuff
like
that.
So
the
person
it
suggests
is
probably
a
good
initial
bet.
A
You
know
occasionally
we'll
have
to
reassign
things
or
or
people
will
come
in
and
be
like.
Oh,
this
other
person
is
probably
more
qualified,
but
that's
probably
a
good
initial
bet.
So
if,
if
something's
like
sitting
there
yeah
either
try
try
making
sure
it's
assigned
or
or
ping
someone
in
the
slack
as
well.
D
A
A
F
I
don't
think
I've
made
any
changes
but
yeah
that
was
about
it
adding
a
time
encoder
flag
to
make
sure
the
operator
developers
can
specify
you
know
a
specific
time
encoding
to
their
encoder,
because
we
are
already
giving
options
on
which,
what
kind
of
encoder
that
you
can
add
using
command
line,
plugs
whether
json
or
console
or
anything
else.
So
that
being
said,
if
you
also
provide
a
time
encoder
that
would
it
just
makes
user
experience
easier.
That's
what
that?
That's?
A
E
I
put
a
comment
in
here
in
sdk.
We
added
this
because
at
least
one
of
our
users
was
like
hey
I'd,
really
like
to
be
able
to
set
this
as
a
flag
rather
than
hard
coding
it
in
my
operator,
so
it
seemed
like
there
were
cases
where,
for
some
reason-
and
I
agree-
sadly,
this
does
seem
a
little
weird,
but
it
seemed
like
there
were
use
cases
where,
for
some
reason,
an
operator
developer
would
want
to
give
the
admins
running
their
operator
the
ability
to
decide
which
time
format
to
use.
E
E
So
if,
if
we're
kind
of
duplicating
things
in
sdk
that
are
mostly
already
supported
in
controlled
runtime,
if
it's
something
that
seems
like
it
could
be
more
generally
useful
for
more
operator
developers,
we're
just
trying
to
have
these
conversations
to
bring
these
things
upstream
so
that
we're
not
you
know
forcing
people
to
choose
between
well,
do
I
use
control
runtime
or
do
I
use
operator
sdk?
Do
I
have
to
use
both
those
kind
of
questions
that
always
seem
to
come
out.
E
But
again
like,
if
we
decide
we
don't
want
this
flag
in
control
of
runtime,
I
think
it's
fairly.
I
think
it's
fairly
simple
for
us
to
implement
this
flag
kind
of
separately
and
then
incorporate
it
into
the
existing
controller.
Runtime
go
api,
although
I
haven't
actually
looked
to
see
how
doable
that
is.
E
That
might
actually,
maybe
that's
one
of
the
reasons
it's
potentially
hard
to
do
that,
because
of
the
way
that
we
set
up
the
encoders
in
the
way
that
zap
works.
So
you
have
to
so
control.
Runtime
sets
up
the
encoder
and
you
have
to
define
the
time
encoder
before
you
set
up
the
encoder,
so
you
have
to
somehow
inject
the
time
encoding
into
controller
runtimes
apis
to
be
able
to
set
it
by
the
time
controller
runtime
creates
the
encoder.
A
A
It's
it's
just
mostly
that
I
I
don't
want
to
have
like
a
bajillion
flags
which
is
fair,
which
just
ends
up
getting
super
confusing.
I
I
so
the
other
thing.
The
other
thing
is
I,
I
click
through
to
the
linked
pr,
and
it
looks
it
looked
like
the
the
comment
was
was
largely
just
even
in
debug
mode.
The
timestamps
are
are
hard
to
read
and
or
in
debug
mode,
so
like
in
with
the
quote-unquote
human
readable
output.
A
E
Maybe
what
we
could
do
like
as
an
initial
thing
would
be
so
the
way
this
pr
is
set
up
right
now
is
we
add
some
new
options
to
the
zapdot
options:
struct
that
would
enable
callers
and
users
of
the
struct
to
set
up
these
options
and
they're
generic.
It's
just
encoder
options,
so
it's
not
specific
to
the
time
format
the
the
things
that
are
exposed
in
the
option
struct.
So
what
we
could
do
is
basically
have
this.
E
Pr
just
have
the
updates
to
the
the
options
struct
that
supports
generic
encoder
options
and
then
also
obviously
update,
like
the
add
defaults
function
to
handle
those
things
such
that
when
it
creates
the
con,
when
it
creates
the
encoder,
it
honors
the
options
that
are
configured
in
the
options
and
then
out
of
tree,
then
we
we
could
add
that
flag
and
have
it
tweak
this
option,
struct
and,
and
then
we're
kind
of
where
both
of
us
seem
like.
We
want
to
be
potentially.
E
E
So
what
I
was
thinking
is,
it
might
be
nice
if
we
had
this
and
or
composite
predicate,
where
you
basically
it's
basically
boolean
right,
so
it'll
loop
through
all
the
predicates
that
are
passed
to
it
and
apply
whatever
boolean
function.
It
is,
and
then
you
can
obviously
chain
these
together
in
basically
an
arbitrary
boolean
logic
function.
So
the
idea
is,
we
could
more
easily
support
kind
of
building
block
predicates
rather
than
monolithic.
A
D
A
I
was
just
trying
to
also
and
additionally
think,
of
a
way
that
we
could
maybe
make
predicates
a
little
bit
easier
to
compose
by
hand
as
well,
so
that
the
the
right,
because,
like
the
equivalent,
like
quote
unquote
obvious,
go
code,
seems
like
it
should
be
just
like
to
be
able
to
pass
a
function
that
just
orders
them
together
but
like
since,
since
it's
a
big
interface,
you
can't
do
that
at
the
moment,
but
yeah.
I
I'm
I'm
fine
with
this.
I
think
this
is
fine.