►
From YouTube: State of the Operator: Framework, SDK, and the best practices - Guilherme Barros (Red Hat)
Description
OpenShift Commons Gathering
Milan Italy 2019
Title: State of the Operator Framework, SDK, and best practices
Speaker: Guilherme Barros (Red Hat)
A
B
We
call
it
herding,
cats
I
help
integrations
come
together
and
in
particular,
operators
have
open.
My
latest
focus,
so
you've
heard
a
lot
about
operators
in
the
last
few
hours,
sort
of
a
high-level
I'm,
gonna
dig
a
little
deeper
into
operators
today
and
tell
you
why
you
should
care,
why
it's
important
and
what
you
can
get
out
of
them.
We're
also
going
to
talk
about
best
practices
and
really
what
we've
learnt
in
the
past
two
years,
roughly
that
we've
been
doing
operators
and
what
we've
sort
of
created
to
help
you
get
there.
B
B
But
what
we're
seeing
also
is
that
ISPs
are
really
looking
also
at
operators
as
for
their
commercial
products
for
their
enterprise
distributions
as
the
way
to
deploy
on
open
shift.
So
I'm
going
to
assume
that
you
have
some
experience
with
operators.
You've
been
here
for
a
couple
of
hours.
That's
sufficient
experience,
we'll
we'll
dig
into
that
a
little
more
and
we're.
B
Of
course,
you
have
some
experience
with
kubernetes
and
openshift,
so,
let's
add
to
that
operators
are
procedural,
best
practices
they
take.
What's
in
the
minds
of
your
admins,
your
developers
on
how
to
lifecycle
your
application,
how
to
do
everything
from
day
one
deploy
the
application,
install
it
to
fun
stuff,
like
metrics,
like
health
checks
like
Auto
tuning
day,
one
is
fairly
well
understood
right.
There
everybody
has
a
script
to
install
their
app.
Everybody
has
an
installation
tool,
that's
easy
day.
Two
is
difficult
right.
B
How
do
you
make
sure
that
you
can
scale
when
scaling
time
when
scaling
time
happens?
How
would
you
detect
that
you
need
to
scale?
How
do
you
detect
that
there's
something
wrong
with
the
health
of
your
app
and
act
on
that
without
having
to
rely
on
the
one
admin,
the
one,
the
one
person
who
deployed
it?
Who
remembers
how?
Oh
you
have
to
do
it
like
this?
Otherwise
this
breaks.
B
B
Why
should
you
care
and
I
mentioned
that
it's
automating
things
that
are
in
people's
heads,
that
you
don't
want
to
get
that
pager
in
the
middle
of
you
know
Saturday
night,
so
make
it
so
that
we
can?
We
can
do
this
and
and
the
day
to
stuff
that
I
mentioned
is
the
complicated
stuff
right,
resizing
isn't
just
scaling
resizing
is
I,
have
to
add
stuff
to
load.
Balancers
I
have
to
talk
about
quorum,
I
have
to
decide
where
to
scale
something
to
is
it
gonna
be
in
this
data
center?
Is
it
on
this
server?
B
Is
it
over
there?
Does
it
have
to
be
in
asia-pacific?
Does
it
have
to
be
in
the
US?
So
there's
a
lot
more
to
resize
than
just
add
one
more
instance,
and
you
can
do
that
with
operators.
Same
thing
for
upgrades
right
up
upgrades
tend
to
be
complicated.
You
tend
to
worry
about
them,
but
if
you
codify
all
of
that
in
your
operator,
it
simplifies
it
and
I'll
talk
in
more
detail
about
that.
As
we
go
reconfiguring
or
configuring
your
app
a
lot
of
times.
B
There
are
five
hundred
thousand
possible
tunable
configuration
options,
but
you
know
you
really
only
want
your
app
or
your
users
to
change
five
of
those
right.
You
don't
want
them
to
change
every
other
little
thing.
That's
gonna
break
something
else.
You
only
want
them
to
change
a
few
of
those
settings,
so
you
can
make
it
so
that
your
operator
configuration
options
only
include
the
ones
that
you
want.
Your
users
to
change.
B
But
it's
it's
it's
more
complex
than
someone
looking
at
the
dashboard
and
saying:
oh,
this
is
Orange.
Now
what
do
I
do?
Well,
you
can
make
your
operator
know
what
a
bad
state
is
no
to
set
it
Orange
and
then
know
how
to
fix
that
is
it?
Are
you
running
out
of
resources?
You
need
to
move
workloads
around
things
like
that,
but
let's
get
into
a
little
bit
more
of
what
makes
a
good
operator
right.
What
are
the
best
practices?
Those
are
scenarios
or
situations
in
which
an
operator
would
be
useful.
B
B
But
let's
talk
about
some
of
these,
so
this
is
for
the
development
side.
Do
I
have
a
planner
I.
Do
excellent
I'll,
try
not
to
blind
anybody,
so
this
is
for
the
development
side
of
your
operator
right.
So
look
if
there's
one
thing
that
you
should
leave
with
here
today
is
operators
should
do
one
thing
and
do
it
well,
don't
create
an
operator
that
deploys
your
entire
stack,
create
an
operator
that
does
that
one
part
of
the
app
you
know
deploys
your
app.
B
You
know
these
three
other
things
but
have
OLM
the
operator
lifecycle
manager
handle
those
dependencies
because
you
don't
want
to
own
the
operator
for
all
of
these
other
apps.
All
of
these
other
open
source
projects,
which
aren't
your
responsibility
right,
those
those
should
be
handled
by
the
subject
matter.
Expert
of
those
operators,
which
I
think
is
the
first
two
bullets
there
use
use
an
SDK.
The
Opera
SDK
already
creates
all
of
the
scaffolding,
like
all
of
the
reusable
reusable
code,
that's
necessary
to
make
an
operator.
B
Work
is
already
provided
for
you,
so
using
an
SDK
in
the
end.
I'm
gonna
have
some
links
to
a
lot
of
the
documentation
on
this,
but,
more
importantly,
also
a
link
to
the
learned,
OpenShift
org
page,
which
walks
you
through
creating
an
operator.
It's
it's.
How
I
learned
to
do
operators
a
year
ago?
Is
you
just
click
the
learn
button
and
it
pops
up
an
environment
for
you
and
it
pops
up
the
step-by-step.
B
This
is
how
you
create
an
operator
and,
of
course,
it
uses
the
operator
SDK,
which
we'll
talk
about
a
little
more,
don't
hard-code
things
still
hard
code.
Namespaces
you'd
be
surprised
how
often
this
happens
and
there's
a
collision
out
there
waiting
to
happen.
Not
all
of
your
environments
are
going
to
look
the
same
and
I
think.
B
Lastly,
on
this
one
api's
have
a
tendency
of
sticking
around
for
way
longer
than
we
expect
so
version
them
properly
have
have
different
versions
for
your
operators,
make
sure
that
they
make
sense
and
there's
there
are
to
be
Nettie's
guidelines
and
just
simpler
guidelines
for
how
to
do
that
so
running,
running
operators
on
clusters,
the
the
the
scaffolding
the
framework
is
already
set
up,
so
that
you
don't
need
to
run
your
operators,
routes
and
I
know
you're
thinking.
Oh
no,
my
my
specific
scenario
requires
my
operator
around
his
routes.
B
It
probably
doesn't
talk
to
us
about
that.
We're
happy
to
help.
There's
there's
a
whole
team
of
us
that
help
people
with
their
operators
help
them
develop
their
operators,
help
them
troubleshoot
their
operators
and
we've
created
this
framework
so
that
things
that
usually
would
need
to
be
run
as
routes
are
handled
by
the
framework.
So
your
operator
itself
doesn't
have
to
write.
You
don't
need
to
handle
all
those
privileges
that
could
cause
the
issues
in
the
future,
so
things
like
CRTs
get
registered
by
OLM.
B
Writing
meaningful
status
information
is
surprisingly
a
problem
that
we
bump
into
fairly
often
so
the
one
of
the
groups
I'm
in
validates
and
tests
and
provides
feedback
on
operators
that
show
up
in
our
github
repository
for
operator
hub.
So
I
look
at
a
lot
of
operators
during
the
day
and
I
review
them
and
test
them,
and
one
of
the
big
things
when
I'm
testing
an
operator
is
I.
Don't
know
that
much
about
your
app
I
read
the
description.
B
I
read
a
paragraph
about
your
app
and
I'm
trying
to
deploy
your
operator
and
the
first
thing
that
I
look
for
when
it
doesn't
look
like
this
installed
right.
It
doesn't
look
like
this
operators.
Working
is
what
are
this?
What
are
the
stat?
What's
the
status
codes
that
I'm
seeing
like
what
are
the
status
messages?
Is
it
telling
me
that
it
broke?
B
Is
it
telling
me
anything
useful
about
how
it
broke
and
think
think
of
me,
as
a
user
right
like
I'm,
a
good
example
of
a
person
in
your
organization
or
a
person
out
on
the
web?
Who
is
interested
in
deploying
your
app
is
interested
in
using
your
operator,
but
doesn't
know
as
much
as
you
do
about
it.
So
tell
me
as
much
as
possible
in
those
error
messages
in
those
status
codes
and
there's
proper
places
to
put
them
in
the
in
the
customer,
resource,
objects,
etc.
B
We'll
talk
about
updating,
but
the
key
thing
this.
This
is
not
the
company
line.
This
is
my
line.
The
key
thing
for
operators,
for
me
is
one
operator,
one
app
version,
so
don't
have
an
operator
version,
deploy
eight
different
versions
of
your
app
I'll
talk
about
that
for
later,
but,
more
importantly,
an
operator
version
that
should
be
able
to
understand
how
the
N
minus
1
version
of
that
operator
works
and
update
that
so.
B
When
you
in
you
know,
when
you
develop
version,
you
know
1.1
of
your
operator,
it
gets
installed
on
the
system,
it's
going
to
be
working
with
an
existing
version
of
your
app
and
it
needs
to
be
able
to
update.
So
that's
the
one
thing
that
you
should
focus
on
is
that
logic
needs
to
go
from
n
minus
1
to
n,
don't
think
of
n
minus
2,
n
minus
3
minus
4,
because
we're
just
going
to
do
it
incrementally,
don't
deploy
other
operators.
B
Okay,
so
should
always
be
able
to
play
and
come
up
without
user
input.
So
that's
another
piece
of
feedback
that
I
have
from
installing
you
know
a
dozen
or
hundreds
of
operators
over
the
last
year
is
I.
Don't
always
know
what
all
the
possible
to
nobles
are
I,
don't
know
what
the
required
configuration
options
are.
So
when
I
install
an
operator
it
should,
when
I
subscribe
to
an
operator,
it
should
install
the
most
amazing
version
of
the
app
with
the
most
commonly
used
configuration
settings.
So
the
app
should
come
up
at
that
point.
B
I
should
go
in
there
and
configure
it,
and
the
operator
will
then
configure
the
app,
but
it's
better
for
when
you
deploy
an
operator
to
your
cluster,
for
it
to
come
up
with
a
version
of
the
app,
then
for
it
to
immediately
error
out
and
say
you
didn't
configure
blah
blah
blah
know
just
have
it
install
like
a
basic.
You
know
this
app
can't
talk
to
anybody,
but
it's
up
and
it
and
it
works,
because
then
you
give
that
feedback
to
the
user,
that,
oh,
ok,
everything
is
good.
B
It's
working
I
just
now
need
to
go
and
configure
it
alright.
So
how
do
we
do
this?
Hopefully
you
memorize
the
previous
two
slides.
There
is
a
quiz
at
the
end,
a
test
and
that
will
define
how
many
beers
you
get
at
the
end
of
the
day.
It's
how
well
you
score
on
this
way,
so
we'll
get
there
so
the
operator
framework.
So
we've
were
aware
that
there's
a
lot
of
best
practices
that
there's
a
lot
of
things
that
we're
telling
you
you
should
do
it
like
this.
You
should
do
it
like
that.
B
You
shouldn't
do
this,
so
we've
tried
to
sort
of
codify
all
of
this
into
a
framework
right
like
the
operator
mentality
is
like
put
the
logic
in
something
so
that
you
don't
have
to
repeat
it,
and
we've
created
some
tooling.
So
three
big
parts
of
this
is
the
operator
SDK,
which
I
mentioned
before
it
basically
creates
all
that
framework
for
the
operator,
so
that,
when
you're
writing
your
operator,
you're
really
just
having
to
focus
on
writing
the
logic
necessary
to
get
that
up.
B
You
know
to
get
that
app
deployed
right,
you're,
not
worried
about
to
the
controller
stuff,
you're,
not
worried
about
the
Reese,
or
you
know
like
your
we're
trying
to
make
it
as
simple
as
possible.
The
operator
of
lifecycle
manager
is
what's
running
on
the
cluster
which
handles
the
the
output,
the
catalog
it
handles,
providing
access
to
the
operators
to
the
users,
and
also
it's
it's
it's
what's
taking
care
of
the
lifecycle
of
the
operator
right.
We've
talked
about
metering
a
good
bit
already,
so
I'm
not
gonna.
Go
into
that.
B
But
you
know,
as
you
expect
me,
to
work
through
operators
as
well
on
a
per
namespace
basis,
etcetera,
etc.
So
we're
gonna
go
through
a
couple
of
sort
of
a
step
by
step
scenario
on
how
this
works.
I
usually
call
this
person
Jane,
but
I
think
Julia
would
be
better.
Okay,
so
Julia
the
developer
uses
the
operator
SDK
to
create
a
new
operator
for
her
app.
You
know
the
operator,
decay
does
all
the
scaffolding
and
she
adds
the
custom
logic
right.
She
adds
the.
B
How
do
I
actually
deploy
this
app,
and
now
she
has
an
operator
easy
enough.
She
gets
to
focus
on
the
custom
logic,
taking
a
step
back,
so
we've
sort
of
come
up
with
a
sort
of
a
five
phase.
You
know
like
what
are
the
the
depth
of
the
operator
that
you
should
that
you've
created
right
so
phase
one
and
two,
of
course,
are
the:
are
the
most
common
basic
install
right?
B
You
can
you
can
install
your
app
and
you
can
upgrade
it
from
you
know:
version
one
to
version
two
or
whatever
and
you'll
see
that
there's
three
different
options
for
how
you're
going
to
write
your
operator,
helm,
charts.
Of
course,
a
lot
of
you
already
have
them,
but
they're
somewhat
limited
in
that
they
can
really
only
handle
install
on
upgrades
the
we'll
get
into
a
little
bit
more
detail
on
those.
B
The
cool
thing
about
doing
this
with
helmet
is,
if
you
already
have
the
helm
charts,
the
SDK
can
basically
just
take
those
and
run
with
it.
It's
it's
very
little,
very
low
barrier
to
entry,
of
course,
you're.
It's
a
good
start,
but
you're
limiting
yourself
a
little
bit
on
on
how
much
functionality
you
get.
B
If
you
use
ansible
it's
it's
fairly
similar.
You
need
to
be
able
to
use
the
ansible
kubernetes
modules,
but
otherwise
it's
just
ansible,
which
you
already
know,
and
the
operator
SDK,
can
take
your
ansible
playbooks
and
and
run
with
them
with
some
adjustment.
But
if
you
really
want
the
full
breadth
of
what
you
can
do
with
operators
write
it
and
go
and
you'll
go
from
you'll
go
from
there,
while
that
was
terrible,
but
yeah.
So
three
options
on
how
you
can
get
her
app.
B
Mom
article
I
roll,
the
arm
article,
okay,
so
Michael
will
take
Julia's
operator,
he's
gonna,
add
some
metadata
and
package
it
up
and
then
add
the
operator
into
the
lifecycle
manager
right.
So
the
metadata
is
just
things
like
what
kinds
of
permissions
our
users
gonna
have,
which
kinds
of
users
have
different
permissions.
You
know
the
the
our
back
stuff
and
once
it's
in
the
lifecycle
manager,
the
user
who
will
name
later,
can
then
see
that
operator.
You
know,
look
at
the
packages
things
like
that.
B
This
is
I
think
what
I
mentioned
this
before
right.
So
operators
are
really
first-class
citizens,
which
means
they
can
do
things
via
OLM
that
require
escalated
privileges
or
without
having
those
privileges
and
LM
really
sort
of
manages
these
these
operator
components
for
you,
so
you
don't
have
to
worry
about
doing
a
lot
of
that
lifecycle
stuff.
You
don't
have
to
worry
about
pre
retrofitting
CR
DS.
You
don't
have
to
worry
about
setting
the
actual
role
bitings.
B
You
don't
have
to
worry
about
setting
role,
based
access,
control
or
namespaces,
or
any
of
that
so
operator,
lifecycle,
manager,
really
sort
of
helps,
set
the
system
up
and
get
things
going,
but
talking
about
OLM
and
the
life
cycle.
So
the
way
this
works
is
we
you
subscribe
to
the
operator
right,
so
the
user
is
subscribing
to
the
operator
that
you
know
was
in
the
catalog
right.
Mac
we'll
put
the
operator
in
the
in
the
oil
M
catalog,
then
the
user.
B
What
did
I
call
the
user
Luca
Luca?
Is
the
user
Luca
subscribes
to
the
operator
on
his
system
and
the
operator
gets.
You
know
sort
of
life
cycles
in
versions
as
as
it
goes
right,
so
whenever
a
new
version
of
the
operator
gets
put
in
the
in
the
lifecycle
manager,
the
cluster
updates
as
OLM
updates
it
on
the
system.
So
if
we
take
this
a
step,
further
I
lost
an
app
off
the
end
of
the
screen.
B
If
we
take
this
a
step
further,
we're
talking
about
you
know,
operator
version
1.1
to
being
you
know,
deploying
your
app
version,
3
and
1.13,
deploying
your
app
version,
3.1
and
etc.
So
this
operator
knows
how
to
update
from
this
one
to
this
one
easy
right,
which
means
this
operator
knows
how
to
update
this
version
of
the
app
wait.
This
version
of
the
app
this
version
of
the
app
and
not
necessarily
previous
version,
so
it
doesn't
have
to
do
that
because
that's
too
complex,
why
you
know
why
make
your
life
too?
B
You
know
I
I
may
get
annoyed
when
I
see
that
in
the
the
operator,
when
I'm
reviewing
it
but
yeah,
okay,
they
wanted
to
do
that,
go
ahead
and
how
you
do.
This
is
basically
just
set
the
configuration
option
in
your
in
your
resource
and
say
deploy
of
this
version,
and
then,
if
you
want
to
update
it,
you
would
just
change
the
resource
to
ok,
deploy
the
next
version
and
handle
the
updates.
This
seems
complex
to
me.
B
B
So
dependencies
right,
so
we've
talked
about
having
your
operator.
Do
one
thing:
keep
it
simple.
Do
one
thing
well,
and
that
means
your
operator
is
just
gonna
say:
I
require
Jaeger
or
I
require
cockroach,
DB
and
OLM
is
going
to
then
go
and
install
those
for
you.
So
don't
write
your
own
version
of
the
operator
for
Jaeger.
B
They
there's
already
a
Jaeger
operator
use
it
lifecycle
manager
will
take
care
of
that
for
you
here
we
go
Giulia,
Marco
and
Luca
alright,
so
the
operators
made
it
to
here
and
now
Luca
says:
oh
okay,
I
want
that
app.
So,
let's
subscribe
to
that
operator
channel,
you
know
I'm
gonna
say
which
namespace
I
want
it
to
be
deployed
on
and
then
suddenly
there's
an
operator
instance
and
the
operator
creates
a
managed
application.
B
Easy
enough
note
that
Marco
sets
the
the
privileges,
so
Luke
is
only
gonna
see
or
have
access
to
install
the
operators
that
he's
able
to
like
he's.
He
has
the
privileges
too.
So
when
we
look
at
when
Luca
looks
at
the
operator
hub
in
his
open
shift,
console
he's
gonna
see
you
know
certain
operators
in
his
catalog
and
which
ones
he
can
install.
He
just
goes
and
clicks
install
in
this
namespace
and
he's
good
to
go.
B
So
that
was
my
10,000
foot
view
of
operators.
What
they
do
why
you
care?
There
are
some
links
on
how
to
get
started.
I,
don't
have
a
learned
out,
openshift
comlink
here,
I'm
sorry,
but
you
saw
that
in
some
of
the
other
talks,
but
yeah
go,
take
a
look
at
operators.
Go,
try
them
out
there,
it's
very
easy
to
try
them
out.
B
If
you
go
to
try
it
out,
openshift
org,
it
will
deploy
a
cluster
for
you
and
then
you
can
go
into
the
console
and
into
the
operator
hub
in
the
console
and
just
click
through
and
install
an
operator.
Try
it
and
play
with
creating
operators.
I
learned
that
OpenShift
artwork,
it's
it
makes
it
really
easy.
It
was
the
first
time
I've
used
that
sort
of
interactive
learning
system.
It's
all
in
the
web
browser
you
don't
need
your
own
cluster
or
anything.
It
all
happens
in
your
browser.