►
From YouTube: Declarative Testing Clusters with KUTTL - Ken Sipe, D2iQ
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Declarative Testing Clusters with KUTTL - Ken Sipe, D2iQ
The facts are the Kuttling releases a cocktail of hormones in our brains including dopamine, serotonin and oxytocin. It can lower your blood pressure and heart rate. Nothing raises your blood pressure more than software written for Kubernetes that isn't tested. The KUbernetes Test TooL (kuttl) is a tool for declarative testing of Kubernetes and Cloud Native software. kuttl empowers developers and end users to test operators, Helm charts, Kubernetes distributions, and Kubernetes itself. This session introduces attendees to testing kubernetes custom controllers using KUTTL with the expectation that all attendees already understand Kubernetes and operators. The session will include: * Testing in different environments; mocked, KinD and full stack clusters. * Test setup * Controller injecting * Asserting state goals Do yourself a favor... lets lower your blood pressure and KUTTL!
https://sched.co/ekAs
A
That's
right,
packed
full
of
fun
kit
number.
Seven.
This
session
is
taking
a
look
at
declarative
testing
of
your
kubernetes
cluster,
using
cuddle,
a
project
that
I
am
one
of
the
committers
on,
and
I
was
fortunate
enough
to
last
very
last
minute
get
a
hold
of
a
co-presenter,
and
let
me
introduce
you
to
him.
It
is
the
loud
mile
shnook
look.
B
A
A
A
Let's
get
started
well:
cuddle
stands
for
the
kubernetes
test
tool,
as
you
can
see
here.
The
origins
of
it
is
that
we
were
creating
kudo,
the
kubernetes
universal
declarative
operator,
with
a
focus
on
declarative
operators.
We
thought
it
made
sense
to
create
our
test
in
a
similar
way,
so
we
went
after
declarative
testing.
When
we
look
at
testing
there's
a
number
of
different
types
of
tests.
A
A
A
First
of
all,
it
should
probably
be
worth
stating
that,
thank
goodness,
there
are
tests
that
that's
fantastic
and
someone
probably
did
what
they
knew,
but
what
we
have
here
in
kubernetes
test,
cmd,
crd
and
there's
a
series
of
them,
of
course,
in
this
directory,
is
an
sh
file.
So
a
shell
script
of
some
sort.
Imagine
what
you
need
to
know
in
order
to
accomplish
your
end
goal
of
just
testing
end
to
end.
Here
we
have
json
that's
kind
of
interweaved
inside
of
this
sh
file.
A
Perhaps
it
would
be
easy
to
mistakenly
put
in
a
comma
or
an
extra
line,
and
you
could
test
it.
You
know
by
running
the
sh
file,
but
there's
there's
really
no
way.
You
could
get
a
validator
to
validate
this
shell
script,
but
it
would
be
really
challenging
to
validate
these
files,
the
the
json
or
yaml
files.
You
can
also
see
you
know
some
crypticness,
some
imperative
way
of
of
managing
certain
aspects
you
can
see
here.
I'm
gonna
get
the
object,
assert
of
custom
resource
definitions,
a
variety.
A
Well,
what
does
it
mean
to
be
declarative,
then?
Well,
when
we
say
declarative,
what
we
mean
is
the
setup.
The
actual
creation
of
state
or
existence
of
objects
in
the
cluster
can
be
declared
just
like
any
any
kubernetes
object
would
normally
so
here
we
have
the
creation
of
the
doghouse,
which
is
an
nginx
pod,
that's
going
to
run,
so
this
is
step
one,
it's
just
a
yemo
file,
so
so
we
can
use
a
yaml
editor
and
all
the
features
of
beautify
and
prettier
and
all
those
things
that
you
might
be
used
to
as
a
user.
A
We
can
use
it
for
testing.
What
does
it
mean
for
a
cert?
Well,
it
means
we
use
a
yaml
file
and
in
this
case
we
need
to
be
explicit
about
the
thing
that
we're
after
in
this
case,
we
want
to
know
that
the
status
phase
is
to
running,
that's
it
and
and
what
you
can
express
here,
as
we
will
see
further
in
the
presentation,
is
you
just
express
the
thing
that
you're
interested
in
asserting
anything
else
is
ignored?.
A
And
we
can
go
further
with
those
assertions
the
assertion
here
is:
we
have
we
have
some
special
types
within
cuddle,
I'll
detail
that
through
this
presentation,
so
here
we
have
the
test
assert
and
we
can
change
the
timeout.
We
can
add
some
collectors
we'll
talk
about
what
that
means.
You
can,
of
course,
have
a
series
of
yaml
in
the
manifest
file.
This,
as
you
can
see,
is
zero,
zero
assert.yaml
and
it
is
setting
the
timeout
setting
up
a
collector
and
it
is
making
sure
that
the
status
is
running.
A
So
I
ask
you
the
question:
if
you
could
do
things
imperative
or
you
would
do
it
declarative?
What
would
you
do
you
know?
The
funny
thing
about
introducing
froghorn
in
this
presentation
is.
This
is
the
one
thing
I
remember
about
him
is
he
said
the
words
I
do
declare,
and
I
cannot
find
one
example
of
that.
All
I
see
is
the
meme
so
that
that's
kind
of
comical,
I'm
not
sure
what
happened.
I
don't
know
if
those
are
lost
or
if
I
my
mind
just
made
things
up,
but
why
don't
we?
A
Who
is
the
target
audience
for
cuddle?
Cuddle
was
originally
written
for
operators
kudo
in
particular,
we
quickly
needed
to
use
it
for
helm,
charts
and
for
other
operators.
It's
basically
for
anybody,
putting
a
workload
on
top
of
kubernetes
and
as
such,
cuddle
is
being
used
in
kudo,
of
course,
but
also
has
been
newly
added
into
the
operator
sdk
for
the
scorecard.
So
if
you'd
like
you
could
read
those
manuals
now
that
I
see
that's.
A
I'll
spend
some
time
showing
you
how
to
do
exactly
what's
in
those
manuals.
So
how
do
we
get
started?
Well,
first,
do
a
brew,
install
or
a
crew
install
probably
be
the
easiest
way
to
get
cuddle
on
your
platform?
Well,
I
say
what
are
you
trying
to
do
boy
build
a
better
trap
than
mine?
Well,
let's
get
started
with
the
basics.
Then
I
might
run
through
this
fairly
quickly,
but
through
the
magic
of
video
you
can
go
back
and
re-listen.
I
want
to
make
sure
we
have
plenty
of
time
for
demos.
A
A
As
the
first
argument,
the
other
one
that
might
be
useful
to
understand
is
the
assert
I
recently
added
that
and
where
you
normally
pass
in
the
test
suite
to
the
test
sub
command
with
the
assert
you
pass,
the
direct
yaml
file
of
the
thing
you
want
to
assert
as
you're
starting
out
and
you're
building
up
certain
state
within
your
cluster,
and
you
want
to
assert
something
to
be
true.
You
can
use
this
assert
to
verify
that
along
your
path.
A
You
could
also
use
it
to
verify
that
the
state
of
things
is
exactly
the
way
you
intended
it
outside
of
cuddle
altogether.
Then
we
have
the
major
sub
command,
which
is
test
and,
as
I
mentioned,
there's
a
bunch
of
options
here.
The
one
that
you
see
at
the
top
is
cube
cuddle,
cuddle
test
and
I'm
passing
in
a
test.
Folder
called
test
within
a
given
test.
There
are
test
steps
and
those
are
your
yaml
files.
A
So
if
there
are
any
other
file
extensions
within
that
directory,
maybe
like
your
your
readme
files
or
some
kind
of
setup
details
or
your
licensing
files,
all
of
those
are
ignored.
The
only
thing
we
pick
up
are
yaml
files
and
then
it
has
a
specific
nomenclature
to
it.
So
we
have
an
index
dash
and
a
step
name.
Oh
it's
important
to
point
out
that
the
test
e
to
e
is
our
test
suite.
A
The
example
is
the
test,
and
then
we
have
test
steps
underneath
the
test,
so
zero
zero
pod
would
be
during
the
create
or
update
phase
of
a
step,
and
then
the
assert
is
the
assertion
or
errors,
phase
of
a
step
which
we're
going
to
learn
more
about.
It
is
also
very
common
to
see
multiple
yammels
within
a
manifest
file.
During
the
creator
update.
This
is
critical
for
people
new
to
cuddle.
We
do
a
match
against
the
gbk,
so
the
group
version
kind
of
given
the
name
or
a
filter
for
the
unique
object.
A
A
So
if
you
created
an
object
in,
let's
say
step
one,
and
then
you
assert
it
in
step
one
and
then
you
want
to
augment
or
change
that
object.
Then
you
just
need
to
provide
the
delta
of
the
thing
you
want
changed,
and
that
is
that's
an
important
concept.
If
the
object
already
exists,
it's
just
going
to
augment
it.
A
If
you
normally
run
with
multiple
namespaces
and
then
run
all
in
one
name:
space
very
common
for
people
to
have
failures
that
are
surprising
and
it's
because
usually
because
they
were
used
to
having
test
isolation
through
name
spaces
and
now
they
don't
and
they
didn't
have
proper
cleanup
after
their
test.
So
this
is
a
really.
A
Then
we
have
the
assert
or
air
heirs
file
again
an
index
and
the
assert
all
of
the
ammo
within
the
assert
within
a
certain
period
of
time.
The
default
is
30
seconds.
The
state
that
is
defined
within
the
cert
file
will
have
to
be
true.
Otherwise
we
fail
the
test
and
the
errors
is
just
the
opposite
of
that.
It's
the
state
of
something
that
should
not
exist,
so
you
want
to
ch
test
for
the
absence
of
something,
maybe
even
the
absence
of
the
object,
even
existing.
A
Let's
go
through
some
of
the
terms
now
I've
already
covered
some
of
them,
but
let's
put
a
nice
bow
around
it.
The
terms
of
service.
We
have
the
test
suite,
which
is
a
collection
of
tests.
We
have
the
tests
themselves,
which
is
a
collection
of
test
steps.
We
have
a
test
step
which
has
multiple
phases,
kind
of
the
create
update
and
then
the
assert
phases,
and
then
we
have
the
test
assert.
What's
also
important
to
note
here
is
that
the
test
suite
the
test
step
and
the
test
assert,
are
all
object,
types
defined
within
cuddle.
A
A
Now
there
is
a
couple
of
areas
that
could
use
some
improvement
within
cuddle.
This
is
one
of
them.
There
are
two
concepts
that
are
completed
together,
I'm
going
to
just
draw
them
out
here.
So
a
test
suite
the
test.
Suite
is,
as
you
see,
on
the
left.
A
folder
in
this
case
is
called
test
data,
that
is,
the
collection
of
tests,
so
every
folder
that
you
see
underneath
there
are
tests.
A
The
test
data
is
the
test
suite,
but
also
we
have
this
object
type,
which
is
the
configuration
yaml
of
a
kind
of
test
suite
you
see
on
the
right
we're
looking
at
a
test
suite
in
that
particular
example.
We
can
actually
create
a
number
of
test
dirs,
which
would
be
a
series
or
an
array
of
test,
suite
folder
locations
or
what's
conflated
together,
is
the
startup
of
the
test,
harness
which
should
be
separated
out
from
the
concept
of
a
test
suite.
But
today
this
is
what
we
have.
A
You
got
your
signals
mixed,
but
I
know
what
you
mean
glad
you
got
it
okay,
so
then
the
test,
as
you
see
here,
we
have
a
test.
Pods
folder:
that's
within
our
test
data
test,
suite
the
test
folder,
I'm
sorry
that
the
list
pods
is
the
name
of
the
test.
So
when
you
see
that
reported
within
the
stream
of
logs
for
a
test,
it
will
be
listed
as
the
list
pods
test.
A
It's
also
very
common
for
people
new
to
cuddle
to
actually
point
to
a
test
folder
when
they
are
starting
up
the
test
harness
so
they
say,
cube,
cuddle,
cuddle
test
and
then
they
specify
the
location
of
a
test.
We
look
for
the
tests
within
the
test,
suite
not
finding
any.
It
won't
run
anything.
So
that's
a
very
confusing
point
for
people
starting
out.
You
need
to
point
to
one
folder
up,
which
is
the
test
suite
itself.
It
will
discover
all
the
tests
with
underneath
the
test
suite
and
it
will
run
those
tests.
A
Then
we
have
the
test
step
and
again,
in
this
case,
there's
two
concepts
to
it,
but
they're
more
or
less
match.
So
in
this
particular
case
we
have
our
list
pods
and
then,
under
that
we
have
files.
We
have
the
zero
zero
pod
and
the
zero
zero
assert.
Those
are
the
steps
and
zero
zero
is
the
zero
zero
step
you
can
have
any
number
of
files.
Of
course
you
want
it
to
be
somewhat
manageable,
but
within
that,
then
you
could
also
be
very
explicit
and
declare
a
test
step.
A
So
if
you
wanted
to
do
what
you
see
here,
you
could
define
within
the
zero
zero
pod
a
kind
of
test
step
which
would
actually
apply
in
this
case
some
commands,
assuming
that
you
had
some
commands
that
you
wanted
to
run,
maybe
creating
a
service
account
creating
a
service
itself,
doing
something
that's
outside
for
whatever
reason
of
your
declarative
files.
And
finally,
we
have
our
test
assert
and
again
this
falls
into
the
same
idea
as
the
test
steps.
We
have
an
assert
file
in
this
case.
It's
zero
zero
assert.
A
We
can
have
multiple
things
in
it.
We
also
have
a
test,
a
cert
kind.
So
within
the
assert
file,
we
can
say
that
this
particular
test
doesn't
take
the
default
30
seconds.
It
takes
20
seconds.
In
addition
to
that,
we
want
to
assert
that
pod
named
test.
2
has
a
certain
quality
of
service
and
it
will
assert
that
to
be
true
within
20
seconds
or
the
test
will
fail
and
then
finally,
we
can
run
the
test,
so
cube,
cuddle,
cuddle,
test
and
then
location
of
the
test
directory
before
we
get
to
a
demo.
A
A
We
understand
that
there
are
certain
environments
for
which
you
may
not
have
permissions
to
do
that,
and
we
have
ways
of
getting
around
that
by
focusing
tests
on
one
test
namespace.
That
said
this
is
the
default
nature
of
it.
You
will
get
nice
isolation
of
your
tests
through
namespaces,
and
you
may
need
to
make
adjustments
to
your
test
suite.
If
you
change
from
this.
A
Well,
before
we
get
to
a
demo,
let's
talk
about
what
you
need
to
do
to
do
your
very
first
cuddle.
You
have
cuddle
cli
installed,
nothing
else.
What
do
you
do?
First,
let's
create
our
test
suite,
so
we
create
the
tess
e
to
e
folder.
Next,
we
need
a
test.
So,
let's
create
the
dog
house
within
the
dock
house,
we'll
create
the
zero
zero
install.yaml
file,
which
for
us
is
just
a
very
simple
nginx.
A
A
You
could
just
use
the
test
the
way
they
are
and
point
the
test
harness
the
first
argument
of
the
test
to
the
folder
to
the
test,
suite
folder
or
you
could
create
a
cuddle
test.yml
file,
a
configuration
file
of
test
suites
and
then
include
directory
that
you're
it's
supposed
to
be
pointed
to.
If
you
have
this
file,
then
it's
nothing
more
than
saying
cuddle
test.
It
will
discover
where
those
tests
are
and
run
them.
In
this
particular
case,
we
have
two
tests,
you
can
see
them
running
right
here.
A
We
have
the
doghouse
and
we
have
the
hen
house.
Both
of
them
have
been
started.
You
can
see
that
we
created
a
namespace
for
the
doghouse
and
we
created
the
namespace
for
the
hen
house,
so
we
have
test
isolation.
This
is
the
default
behavior.
What
if
we
just
wanted
to
run,
run
one
of
those
tests?
Well,
we
could
actually
specify
dash
dash
test
and
specify
the
test,
in
which
case
only
one
of
those
tests
would
be
run.
Let's
get
to
a
demo.
This
is
a.
A
As
you
can
see,
I've
just
created
a
a
cluster
with
kind
and
there's
nothing
running
in
it.
So,
let's
start
by
putting
something
in
it,
we'll
just
run
an
instance
of
nginx
and
then
let's
create
an
assert,
and
I've
already
done
that.
So
there's
the
assert
file
we're
going
to
assert
for
a
pod
named
engine
x
that
has
reached
the
running
state.
A
Let's
switch
back
to
the
command
line
in
this
case
we're
not
going
to
run
a
test,
we're
going
to
just
validate
the
assert
and
we're
going
to
specify
a
short
timeout
and
we're
already
asserting
it
to
be
valid.
Let's
take
a
look
at
what
a
failure
might
look
like.
Maybe
we
misspelled
something
I
hit,
save
there.
Obviously
that's
spelt
incorrectly
and,
let's
run
the
same,
assert.
A
In
this
case,
it
takes
three
seconds
we
had
to
wait
for
that
we
get
a
full
diff,
which
seems
like
a
lot.
There
are
actually
two
errors
that
come
back.
This
is
a
very
verbose
diff
of
everything
that
was
not
specified.
That
was
present,
but
then
you
get
a
second
targeted
message,
which
is
this
resource
for
status.phase
had
a
value
mismatch.
It
was
looking
for
running
with
one
n,
but
we
actually
found
running
with
two
n's
seems
pretty
simple
right.
Why
don't?
A
A
Then
house
actually
has
a
couple
of
other
new
features
that
might
be
interesting
to
look
at
the
one
is
you
may
have.
You
might
have
some
yaml
that
you
repeatedly
use
in
either
steps
or
tests,
and
you
may
have
it
out
here
all
by
itself
like
this
henhouse
example
right
here
in
the
pod.ammo
here,
within
the
zero
zero
install,
we
say
apply,
and
then
we
provide
a
list
of
yamls
that
we
want
to
include.
So
I
can
use
a
bunch
of
them
across
tests.
I
could
put
pathing
there.
A
This
could
say
dot,
dot
slant,
dot,
dot,
assuming
you
know
where
one's
at
it
could
sit.
Just
as
well
said
that
it
could
be
in
subfolders,
it
could
be
in
a
variety
of
places.
In
this
case,
this
is
the
location
that's
close
to
this
file,
which
is
the
pod
notice
that
we've
defined
a
test
step.
So
there's
a
number
of
things
we
could
do
within
the
test
step.
One
of
them
is
commented
out,
but
I
could
have
put
in
commands
and
that
would
be
a
list
of
commands.
Then.
B
A
Our
assert,
which
is
a
little
bit
unique
as
well
worth
showing
off
a
few
things
one
we
could
have
changed
the
timeout,
so
I
could
have
switched
to
maybe
60
seconds.
We
have
a
collector
and
I'll
talk
about
that
in
just
one
second,
so
this
changes
the
test,
assert
configuration,
and
then
this
is
the
assert
and
could
be
a
series
of
assert.
This
also
shows
multiple
yamls
in
the
same
manifest
file
with
collectors.
It's
it's
common
or
interesting,
sometimes
to
collect
additional
information
if
a
failure
were
to
occur.
A
So,
in
the
case
of
say
this,
this
test
failing.
We
have
two
options
with
collectors.
Currently
one
is
pod
and
one
is
commands.
So
if
it
was
command,
you
could
just
run
any
command,
so
you
could
gather
whatever
you
wanted
and
that
will
just
be
dumped
right
in
the
log
with
with
the
test
with
the
pod
you're,
specifying
that
you
want
to
collect
the
logs
out
of
the
pod.
So
the
pod,
that
is
the
hen
house
pod,
will
have
its
information
dumped
within
the
log
file.
A
So
much
tongue
sunburn
and
that's
it.
We
could
then
just
as
well
run
that
test.
Let
me
clear
the
screen
cuddle
test
and
in
this
case
we
want
to
run
the
ede
test,
and
now
we
have
it
running
eventually
passing
one
more
really
cool
feature
that
I'd
like
to
show
you
before
we
leave
this
demo.
Is
I've
taken
the
example
that
we've
seen
here,
the
in-house
and
dog
house
and
the
test
suite
that
it
is?
A
I
have
tarballed
that
and
have
put
that
up
on
github,
so
we
could
run
the
test,
cube,
cuddle,
cuddle
test
and
specify
the
url
of
the
test
suite
it
will
pull
down
the
test,
suite
extract
all
of
the
files
and
then
run
the
whole
test
suite.
So
we're
running
the
exact
same
test
suite
we
were
before,
except
for
now
we've
pulled
down
the
archive
from
the
github.
That's
it
super
cool
right.
Let's
look
at
some
additional
features.
A
The
first
is
that
we
can
obviously
do
a
delete.
You
can
do
a
delete
based
on
a
number
of
things.
So,
as
you
see
here
in
the
example,
I
can
get
rid
of
a
pod.
That's
my
pod
or
a
pod
with
labels
of
app
nginx.
We
can
delete
things
as
part
of
a
test
step,
and
you
just
include
that
into
your
step.
Additionally,
we
could
add,
commands
and
you
it's
an
array
of
commands.
A
B
A
As
I
mentioned
before,
it
is
possible
to
set
up
cuddle
so
that
it
doesn't
create
a
test,
a
namespace
per
test.
The
danger
here,
of
course-
and
the
thing
you
need
to
be
aware
of
is
you-
may
have
to
do
some
additional
test
design.
You
may
need
to
delete
things
and
then
assert
that
those
things
are
gone,
using
the
errors
prior
to
moving
on,
because
you
do
not.
A
You
no
longer
have
the
isolation
that
you
would
normally
have,
but
otherwise
a
useful
feature
for
for
many
people,
as
we've
shown
before
you've,
I
I'm
so
dumb.
I
I
didn't
realize
that
I
had
this
in
my
slides
he's
so
dumb.
He
thinks
the
mexican
border
pays
rent.
The
example
here,
of
course,
is
that
we
can
apply
some
more
tips.
Everything
is
accessible
to
cuddle,
so
here
we're
asserting
an
event
occurred.
Of
course,
remember
that
events
are
short-lived
things,
but
the
test
is
only
going
to
run
for
a
short
period
of
time.
A
A
Another
tip
is
we're
going
to
take
a
look
and
see
how
you
might
start
up
your
tests
with
crds,
but
perhaps
you
have
crds
that
you're
going
to
be
creating
or
adding
along
the
path
or
along
the
way
prior
to
using
the
crd,
is
to
assert
that
the
crd
exists,
which
you
see
on
the
left,
the
zero
zero
assert.yml
after
you've
asserted
it.
Then,
in
the
next
step
you
could
use
it.
So,
in
this
case,
we've
asserted
that
the
crd
exists
prior
to
it
being
used.
A
A
common
use
in
kubernetes
world
is
using
helm,
so
here
we
see
examples
of
using
the
command
and
using
helm
to
do
installations
and
potentially
even
setting
up
service
accounts
and
role
bindings,
and
that
kind
of
thing,
and
as
I've
indicated,
we
can
pull
test
suites
straight
from
any
given
url.
We
can
even
include
them
in
our
test
configurations
notice.
How
great
this
is
that
you
could?
A
You
could
have
a
suite
of
tests
available
to
any
of
your
customers
and
clients
and
they
can
test
in
their
environment,
and
what
I've
not
shared
up
to
this
point
is
that
it
is
possible
to
add
some
flags
so
that
it
doesn't
delete
anything.
So
the
creation
of
something
establishes
the
state
according
to
what
you
desired
and
then
asserts
that
that
state
is
there
and
then
leaves
the
cluster
without
tearing
down
the
tests.
This
can
be
a
very
useful
feature
of
using
cuddle.
A
Another
great
feature
that
cuddle
provides
is
a
report.
If
you
specify
a
report,
you
can
specify
either
xml
or
json.
If
you
specify
xml
it'll
be
a
junit
xml
report,
you
can
see
two
examples
of
an
xml
report
here,
one
with
all
succeeding
tests,
and
then
you
have
an
example
here,
a
failing
test
in
the
doghouse
since
cuddle
was
originally
created
to
test
operators
kudo
in
particular.
Let's
take
a
look
at
the
features
that
support
that
the
first
is.
A
We
need
to
enable
the
ability
to
install
crds
cuddle,
has
the
ability
to
install
manifests
or
crds
or
apply
them
within
the
kubernetes
cluster.
The
difference
is
that
when
we
see
crds
within
the
crd,
dir
cuddle
will
wait
until
the
crd
has
been
realized
within
the
kubernetes
cluster.
Then,
when
we
talk
about
working
with
or
testing
an
operator,
there
are
two
different
styles
or
different,
two
different
ways
that
a
an
operator
might
be
being
used
within
the
cluster.
A
The
first
is
that
it
is
being,
it
is
a
released
operator,
and
the
other
is
that
it's
an
in-dev
operator.
The
example
you
see
here
is
that
we
have
a
kudo
init
that
is
initializing
the
controller
within
the
cluster
and
the
weight
process
will
wait
until
it's
complete.
This
is
how
we
establish
kudo
running
within
our
cluster
and
then
we'll
have
a
series
of
tests
that
follow
in
dev.
We
do
it
slightly
different
in
dev.
A
We
actually
apply
the
crds
and
there's
a
wait
period
of
time
for
that,
and
then
we
invoke
a
command
on
the
code.
That
is
part
of
the
ci
environment,
where
we
invoke
the
manager-
and
we
put
that
in
the
background
what's
important
about
this-
is
that
the
standard
out
by
default
will
be
part
of
the
test
logs.
There
is
a
way
of
opting
out
of
that
now.
You
can
see
how
cuddle
supports
the
released
testing,
as
well
as
the
in-depth
testing
of
operators.
A
Yeah
right,
let's
put
some
closing
remarks
around
this.
First
of
all,
there's
a
lot
more.
I
would
love
to
share
with
you
or
show
you
if
I
would
recommend
a
place
to
get
some
feel
for
the
different
tests.
I
would
recommend
this
location
under
github
underneath
cuddle
itself.
If
you
want
to
get
some
more
cuddling
in
the
other,
is,
is
the
first
release
was
march
of
this
year.
We've
had
the
zero
seven
release
I
just
got
out
in
october.
A
We
have
a
release,
cadence
that
happens
about
once
a
month
and
if
you'd
like
to
get
involved
with
that,
you
can
find
the
project
in
this
location.
You
can
find
us
on
kate's
slack,
underneath
kudo.
We
haven't
had
a
need
or
demand
to
drive
it
out
to
its
separate
channel,
but
if
enough
demand
happens,
we'll
do
so.
We
do
follow
a
process
and
we
do
once
a
month
meet
and
talk
about.
Community
issues
would
love
for
you
to
get
involved
and
with
that,
that's
all
folks.