►
From YouTube: Kubernetes KubeBuilder 20191113
Description
KubeBuilder Meeting for 2019/11/13. See https://sigs.k8s.io/kubebuilder for more details.
A
A
B
So
these
are
both
questions,
so
the
first
question
is
about
v1c
RDS
instructional
schema.
There's
this
issue
currently
in
the
queue
builder
project
that
Eric
created,
there's
been
some
discussion
on
so
I
just
wanted
to
see.
If
there
was
any
progress,
if
you
guys
need
any
help
on
things,
if
there's
any
other
related
issues
that
we
could
jump
in
and
start
helping
on,
this
is
something
that's
come
up.
A
A
We
have
support
for
the
various
structural
schema
annotations
it
just
merged
like
last
week,
ish
I
think
basically
there's
now
option
in
C
or
D
gen
that,
where
you
can
specify
the
versions
of
the
CRD
object
itself
that
you
would
like
to
generate
so
by
default,
it
generates
to
be
one
beta,
one
for
compatibility
reasons,
but
you
can
say
we
won
or
you
can
pass
a
list
if
you
want
to
generate
both
in
two
different
files
for
various
reasons.
So
that
is
now
like
that.
A
A
Marker
server-side
apply
like
list
type
markers,
are
still
in
an
ongoing
PR
that
needs
to
be
merged,
but
I
think
other
than
that
all
the
v1z
are.
The
features
have
actually
been
merged,
as
for
did
web
hooks
go
to
stable
as
well
I
believe
so
yeah,
okay,
so
we
haven't
done
web
hooks,
so
web
hooks
would
be
appreciated,
file,
a
tracking
issue
and
controller
tools.
If
you
want
to
help
with
up
with
those
but
other
than
that,
I
think
I
think
we're
actually
mostly
good
with
CR
dv1
awesome.
A
B
A
We
like
one
one
option
it
depending
on
like
what
we
wanted
to
do
just
like
off
the
top
my
head
strum,
and
we
could
just
let
it
be
an
option
like
a
patch
or
something
we
could
have
a
little
shim,
which
we've
traditionally
so
far,
not
done,
but
we
could
have
a
little
shim.
That
was
like
call
discovery,
see
a
few
ones
available.
If
so
choose
to
be
one
one
or
something
like
that,
just
but
yeah.
B
A
B
A
B
B
A
A
A
C
You
know
I
just
got
into
this
operator.
Development
communities
may
be
like
couple
of
months
back
and
then
I
just
kind
of
look
at
what
is
the
best
way
to
write
an
operator,
and
the
first
thing
I
started
with
is
the
SDK
the
operator,
so
I
did
a
little
bit
and
then
I
found
Q
builder.
Then
I
switch
it
to
Q
builder.
For
a
few
reasons
and
the
main
one
being
the
Q
builder,
documentation
is
fantastic.
The
book
was
very
nice.
C
You
know
I
really
like
that,
and
the
webhook
support,
of
course-
and
you
know
that's
something
that
I
wanted
the
validation.
So
for
those
reasons,
the
switch
to
Q
builder
but
I
I
just
discovered
that
there
is
a
issue
on
github
that
says
these
two
are
being
integrated.
So
can
you
just
elaborate
being
on
the
front
these
two
tools.
A
Yeah,
so
there
there's
actually
a
full
design
document
that
kind
of
lays
out
what's
going
on
in
the
queue
builder
repo,
but
the
TLDR
it's
on
the
designs
folder,
the
TLDR
is
that
because
operator
SDK
and
queue
builder
already
actually
share
a
lot
of
code
and
tooling
operator,
SDK
is
going
to
be
relying
on
the
queue
builder.
Scaffolding
for
scaffolding
out
go
operators
from
operator
SDK,
so
you
will
basically
end
up
using
the
same
tooling
and
scaffolding
for
both
tools
getting
the
same
tooling
and
scaffolding.
A
B
Pretty
much
covers
it,
yeah
so
I
think
the
goal
like
like
Sally
said
the
goal
is
like
once
we
finish
this
integration,
the
yep
will
scaffold
the
exact
same
project
layout
operator,
SDK
and
queue
builder
should
be
generally
compatible
and
interchangeable
for
go
projects,
and
then
the
SDK
team
will
start
developing
and
maintaining
and
contributing
into
the
queue
build
projects
a
lot
more
rather
than
having
this
separate
operator.
Sdk
go
libraries
that
are
kind
of
a
little
bit
more
difficult
to
integrate
if
you're
using
queue
builder.
C
C
Think
one
of
you
referred
to
the
error
handling
before
I
didn't
catch
it
completely,
but
I
was
kind
of
looking
at
how
best
to
you
know,
deal
with
errors
and
kind
of
introduce
back
off
between
requests
back
down
the
queue
and
limiting
the
number
of
retries
and
I
found
that
there
is
a
operator
SDK,
the
github
project,
you
that
utility
functions
kind
of
thing,
but
that's
that
for
our
SDK.
So
you
have
any
plans
for
like
error,
handling,
adding
error,
handling,
Cubism.
C
A
C
A
C
B
C
And
I
have
one
final
question
again
based
on
my
testing.
What
I
see
is
that
my
reconciliation
is
successful
and
immediately
another
reconciliation.
The
question
comes
in
for
the
same
resource.
It
happens
all
almost
all
the
time
hundreds
actually
saw
me
I
couldn't
find
out
why
a
reconciliation,
the
question
being
issued.
So
is
there
any
way
to
figure
out
why
so.
A
This
is
this
is
actually
like
a
good
idea
for
another
doc
bug
so
like
thank
thank
you
for
bringing
it
up
yeah,
so
hey!
Well,
there's
actually
two
doc
bugs
in
here
or
to
book
two
two
issues
in
here.
The
first
is
that
a
there's
not
really
a
good
idea
right
now
to
find
out
why
a
reconciliation
was
triggered.
A
We've
had
some
talk
of
integrating
tracing
before
into
the
cute
builder
and
or
we
could
add
better
logs
there.
So
that's
like
one
issue
that
probably
should
be
filed.
So
thank
you
for
moving
that
up
and
the
other
one
is
the
I
get
another
reconcile
immediately
after
my
first
reconciled.
Is
is
a
really
good,
FAQ
question,
so
that's
usually
caused
by
the
fact
that
you
actually
submitted
an
update
because
you
submitted
an
update.
The
API
server
goes
up,
something
changed.
A
You
need
to
reconcile
again,
but
because
it's
the
update
use
a
minute,
you
should
be
in
steady-state
right.
So,
like
you
know,
you'll
presumably
got
the
got.
The
reconcile
request
see
that
you're
in
steady
state
and
nothing
will
happen
and,
depending
on
what
you're
changing
you
may
be
able
to
use
like
the
generation
changed
predicate
to
avoid
this.
But
this
is
another
really
good
case
where,
like
this
is
a
frequently
asked
question
and
we
could
definitely
be
clearer
on
this
in
the
documentation,
I
think.
D
C
A
B
So
is
that
blogging
flags
at
so
to
see
I
think
put
together
and
there
was
another
PR
before
his
sabes.
That
has
some
improvements
for
making
the
Zap
lager
more
customizable
from
the
calling
perspective.
This
is
in
controller
runtime,
where
now
there's
like
very
attic
options
and
it's
easier
to
turn
on
and
turn
off
different
aspects
of
the
logger.
B
One
thing
that
we've
done
an
SDK
and
this
was
kind
of
a
while
ago-
and
we
don't
have
the
exact
same
interface,
but
we
have
like
a
like
an
at
like
a
bind
Flags
method
on
the
logger
that
will
basically
enable
an
operator
to
call
this
and
then
have
flags
added
to
their
binary.
That
would
make
it
easier
to
configure
the
longer
from
Flags,
rather
than
just
in
code,
so
I'm
curious.
If
that's
something
you're
interested
in
having
us
contribute
in
controller
runtime.
B
A
Think
having
having
Flag
support
would
be
having
helpers
for
Flags
option
will
help.
Those
helpers
for
flights
will
be
awesome.
Just
because
that's
the
way
most
people
do
things
right
now.
It
would
be
great
to
eventually
get
to
something
like
component
config,
but
the
reality
is
most.
People
won't
have
flags
at
the
moment
so
yeah
and
in
that
PR,
if
they
they
should
make
use
of
the
very
otic
options
if
possible.
If
it's
not
like
super
clunky
to
do
so,
and
if
it
is,
we
can
figure
out
something
else,
but
yeah.
D
A
The
only
consumer
that
we
can
find
on
github
on
all
of
github
of
testing
frameworks
and
there's
some
stuff
that
we
actually
would
like
to
do
in
the
testing
frameworks
as
well.
I
have
a
really
hacky
version
of
this.
Pr
posted
as
part
of
the
work
I
did
to
add
support
for
off
and
the
secure
port
to
the
end
test
framework.
A
But
if
someone
wanted
to
like
separate
that
out
and
do
a
little
code
cleanup
or
if
you
have
ideas,
I
think
one
of
the
things
we
can,
we
kind
of
have
like
two
layers
of
indirection
right
now,
I'm
so
like
ultimately,
I
think.
What
we
want
to
do
is
like
first
step
port
integration,
testing
framework
into
internal,
the
parts
that
we
can
into
internal
and
the
public
stuff
into
public
and
then
like
step.
A
Two
would
be
to
like
see
if
we
can
actually
reduce
the
layers
of
indirection
that
we
have
so
we
don't
have
like
M
test
wrapping
high
level
integration
framework.
Wrapping
like
the
internals
of
integration
framework.
There's
like
three
layers
right
now,
I
think
we
can
collapse.
That's
like
one
or
two
and
makes
the
code
a
lot
more
simple
and
make
it
easier
for
us
add
cool
stuff
to
the
integration
framework
yeah.
So
that
was
a
really
long-winded
way
of
saying.
I
am
definitely
I'm
wash
well.
D
A
A
If
nobody
has
anything
else,
I
have
one
more
thing
for
the
end.
So
recently
we
merged
a
official
guidelines
for
kind
of
what
in
kubernetes,
is
referred
to
as
the
contributor
ladder.
So
this
is
how
to
gain
more
a
more
formal
role
in
the
queue
builder
project,
in
terms
of
officially
being
recognized
as
a
like,
a
trusted,
reviewer
or
approver,
and
so
I
know.
There
are
a
bunch
of
you
that
have
been
leaving
really
awesome
reviews
and
are
really
knowledgeable
about
particular
areas
of
queue,
builder
and
controller
runtime
and
controller
tools.
A
And
so,
if
you
are
at
all
interested
in
you
know
having
a
more
formal,
formal
role
in
things,
I
would
highly
encourage
you
to
look
at
those
and
then,
if
you
have
any
questions,
feel
free
to
reach
out
to
me
directly
on
slack
or
you
know,
submit
a
PR
to
add
yourself
as
a
reviewer
in
an
owner's
file.
Or
what
have
you,
but
definitely
please,
I,
know,
there's
there's
a
bunch
of
you
who
are
super
knowledgeable
about
certain
things.
So
definitely,
if
you're
interested,
please
speak
up.