►
Description
OpenShift Commons Gathering @ Kubecon/NA San Diego November 18 2019
Operator Framework Update
A
A
Hopefully,
maybe
it's
some
of
your
customer
sites
as
well
and
I
want
to
start
this
with
kind
of
talking
about
the
goal
of.
Why
do
these
operators
exist?
I
came
from
core
OS
and
we
introduced
this
concept
I
think
in
2016,
or
something
like
that,
and
it's
all
about
having
a
SAS
like
experience
on
your
own
infrastructure.
So
you
heard
some
of
the
folks
at
Broadcom
and
others
talking
about
how
individual
teams
are
experts
in
their
own
domain
and
they
want
to
remain
that
way
and
they
don't
need
to
be.
A
You
know
these
really
broad
experts
on
it.
Don't
need
to
know
terraform
if
that's
not
part
of
their
job.
Think
about
that
SAS
experience
that
you
get
when
somebody
wants
to
pull
off
a
database
from
a
cloud
service
and
then
use
it.
You're,
not
an
expert
in
MongoDB
you're,
not
an
expert
in
Postgres,
but
you
know
how
to
connect
to
that.
You
know
your
application
works
with
it.
A
That's
the
goal
that
we're
aiming
for
with
this
operator
concept,
and
this
is
across
all
different
types
of
applications:
databases,
queues,
storage,
other,
like
DevOps
tasks,
AI
ml,
all
this
kind
of
stuff,
all
totally
works
great
with
an
operator
on
open,
shipped,
so
just
level
set.
What
is
this
thing?
What
is
an
operator?
Well,
it's
taking
that
knowledge
of
an
application
from
the
experts.
Whoever
built
this
thing,
you
know
either
an
open-source
community
or
a
commercial
entity,
and
it's
packing
that
into
a
piece
of
software
that
then
drives
a
kubernetes
cluster.
A
So
this
is,
you
know.
At
the
end
of
the
day,
you're
gonna
have
deployments
and
staple
sets,
and
maybe
some
secrets
and
maybe
a
config
map,
all
the
things
that
would
drive
an
application,
but,
as
you
get
to
a
reasonably
complex
application,
it's
not
just
gonna,
be
I,
don't
know
five
of
these
things.
It
might
be
like
nine
hundred
objects
if
you're
running.
You
know
this
really
highly
scale
up
multiple
tier
application,
and
you
can
bake
all
that
expert
Chason
to
an
operator
such
that
you're
not
having
to
wrestle
with
all
of
these
objects.
A
So
we
built
something
called
the
operator
framework
to
help
you
do
this.
This
is
a
number
of
different
sub
tools.
Inside
of
the
framework
itself,
the
main
one
being
the
operator
SDK,
which
helps
you
build
these
operators.
How
do
you
take
the
knowledge?
Is
in
your
head
about
your
application
and
put
it
down
into
a
piece
of
software
and
then,
once
you
have
these
built,
the
operator
lifecycle
manager
helps.
You
actually
run
these
on
a
cluster
and,
if
you
think
about
you,
know
some
of
these
really
large,
open,
shipped
clusters
that
we've
heard
about
today.
A
You
know
it's
not
just
gonna
be
one
or
two
of
them:
you're
gonna
have
maybe
nine
clusters
and
they're.
You
know
30
to
40
nodes,
you're,
not
probably
gonna,
be
running
one
operator,
there's
gonna
be
a
few
of
them,
and
so
you
need
to
handle
the
permissions.
How
do
I
wire
up
the
lifecycle
of
these?
How
do
I
upgrade
them?
All?
That
is
what
the
lifecycle
manager
does
and
then,
hopefully,
you've
heard
of
operator
hub
IO.
A
At
this
point,
this
is
a
community
listing
of
operators
for
the
entire
kubernetes
community
to
discover
and
play
around
with
those.
You
also
get
some
of
that
content
inside
of
your
open
ship
for
cluster
as
well,
so
the
SDK.
What
does
it
actually
look
like
under
the
hood?
So
there's
actually
three
different
flavors
of
this
sdk.
The
first
one
is
our
helm
sdk,
and
this
is
great
for
folks
that
have
investing
invested
in
charts
for
helm
already,
so
you've
got
teams
that
understand
that
whole
flow.
A
What
you
can
do
is
bake
that
into
an
operator
so
that
you
had
this
immutable
artifact.
You
know
an
operator
is
really
just
some
code
inside
of
a
container
just
like
anything
else
in
kubernetes,
and
you
can
now
stash
that
away
and
then
hand
that
off
to
any
QA
teams,
other
teams
that
might
want
to
consume
your
application
and
run
it
in
their
environment,
their
CI
system,
whatever
it
is,
and
the
nice
thing
is.
A
This-
is
all
driven
based
off
of
kubernetes
extensions,
so
that
you're
just
talking
to
a
kubernetes
api
to
deploy
out
your
WordPress
site
or
anything
else.
You
know
your
scale
out
application
now,
if
you
have
an
investment
and
say
something
like
ansible,
you
can
also
make
an
ansible
based
operator,
and
this
is
taking
your
existing
playbooks
and
other
ansible
modules
and
once
again
wrapping
them
in
that
operator
sdk.
A
So
it's
reacting
to
cluster
events
and
you
can
deploy
your
that
way
so
think
about
all
the
automation
that
you
get
out
of
an
scible,
even
if
you
need
to
say
poke
and
prod
an
external
load
balancer
like
a
hardware,
load
balancer
and
then
bring
that
into
the
kubernetes
world
and
reuse.
All
that
existing
knowledge
that
you
have
but
bring
that
into
the
kubernetes
event
stream,
and
then,
lastly,
we
have
our
go
SDK,
and
this
is
based
on
the
same
tools
upstream
kubernetes
uses
to
build
kubernetes
itself.
A
A
A
You're
also
gonna
hear
us
talk
about
this
operator
capability
model,
so
once
we
have
these
SDKs,
what
are
you
actually
producing
at
the
end
of
the
day?
So
you
want
to
have
a
high
quality
operator.
You
want
that
sass,
like
experience
running
on
your
own
infrastructure,
and
so
the
way
we
think
about
this
is
trying
to
move
operators
as
far
to
the
right-hand
side
of
this
as
possible
to
these
phase
5
these
autopilot
operators-
and
this
is
just
think
about,
like
your
ops
hero.
A
This
is
like
a
person
on
your
operations
team
that
is
always
on
it.
Reacts
in
milliseconds
knows
every
single
combination
of
every
config
flag,
what
you
should
be
doing
every
best-practice
about
a
database
or
something
like
that.
This
is
what
that
autopilot
is
describing,
and
we
want
all
of
the
operators
in
the
world
to
get
to
this
level.
A
But
you
know
that
doesn't
always
happen
at
first,
and
so
these
different
capabilities
in
between
just
kind
of
communicate
that
out
to
the
community
down
here
you
can
see
the
different
types
of
SDKs,
so
the
some
of
the
helm
operators,
you
know,
are
just
interacting
with
kubernetes
objects.
So
there's
not
like
you
know,
log
processing
or
doing
anomaly
detection
is
not
something
that
you
can
do
there
that
you
can
do
in
some
of
the
other
frameworks,
and
so
that's
kind
of
where
you
see
the
spectrum
on
the
end
of
them.
A
So
a
bunch
of
these
operators
have
already
been
produced,
which
is
great.
We
have
a
certification
program
for
them.
You
can
find
these
in
your
open,
shift4
cluster
today,
if
you've
got
one
up
and
they
really
run
the
gamut
across
all
these
different
categories,
which
is
really
great
for
security
tools,
monitoring
tools,
storage,
databases,
security
scanners,
all
kinds
of
stuff
and
remember
these
folks
have
built
their
expertise
into
these.
A
So
our
helm,
sdk
is
underway,
getting
support
for
helm
3,
which
is
just
released
last
week.
We're
really
excited
about
that.
Our
ansible
operator,
sdk,
is
gonna,
get
its
1.0
version
out
here.
Hopefully
this
quarter,
so
they've
been
doing
a
lot
of
hard
work
on
that
using
their
new
ubi
base
image.
If
you're
familiar
with
that,
and
then
the
the
golang
library
is
always
getting
new
versions
of
kubernetes.
So
we're
looking
at
kubernetes
1:14
changing
around
some
of
the
way
that
the
modules
work
as
go.
A
The
community
has
changed
that
up
as
well
a
whole
bunch
of
other
really
great
stuff
going
on
there
and
further
tying
all
those
together.
So
I
mentioned
this
operator
hub
and
that
you
can
get
these
inside
of
your
open
ship
cluster.
This
is
what
that
looks
like
today.
So
you've
got
the
community
listing
operator
hub
bio.
You
can
find
that
inside
of
your
open
ship
cluster,
as
well
as
Red
Hat
products.
A
One
cool
new
feature
that
I
want
to
call
out
is:
if
you
are
packaging,
an
operator
we
have
this
new
bundle.
Editor.
The
CSV
is
the
metadata
file
that
describes
an
operator
and
it's
got.
You
know
it's
version
in
the
description
and
some
of
the
permissions
that
it
needs,
etc
how
it
gets
upgraded
and
you
can
actually
build
these
live
on
operator
hub
io
now,
which
is
really
nice.
It's
really
great
for
me.
A
A
That
I
think
are
kind
of
interesting
to
y'all,
as
maybe
you're
getting
your
first
dose
of
this,
and
you
know
you're
on
in
like
an
open
ship,
3
world
or
maybe
you've
interacted
with
some
of
this,
and
these
are
some
of
the
ways
that
this
is
getting
better
in
successive
OpenShift
versions.
So
in
open
ship
for
one
we
did
static
dependency
resolution.
This
is
a
really
key
part
of
operators
and
the
lifecycle
manager
is
actually
you
can
have
operators
that
depend
on
each
other.
So
I
bet
everybody
here
has
an
application.
A
That
probably
has
a
logging
stack
that
it
depends
on.
So
if
you've
got
your
efk
stack
or
whatever
it
is,
you
could
actually
defer
that
entire
thing
to
an
operator
already
deployed
on
your
cluster,
so
that
your
team
doesn't
have
that
operational
burden.
You
just
say:
hey:
I
need
a
stack
and
prod
and
in
dev
and
staging
etc-
and
you
go
do
that
so
and
for
one
this
was
static,
but
in
42
it's
now
automated.
So
through
the
lifecycle
manager,
it
will
go
find
based
on
the
kubernetes
CR
DS.
A
That
you've
said
you
depend
on
which
would
be
like
that
blogging
stack,
it'll
go,
find
an
operator
that
works
for
you
and
install
that.
So
it's
the
same
thing
if
you
were
looking
for
a
database
or
a
queue
or
a
web
server
or
any
of
those
types
of
things,
a
caching
layer
that
you
can
automatically
do
this
across
your
cluster,
which
is
really
great.
Now
you
can
do
this
for
all
the
certified
and
Red
Hat
products
and
all
the
stuff
I've
been
talking
about,
but
even
more
powerful
is
doing
it
for
your
internal
applications.
A
A
Also
really
important
is
operators
are
typically
interacting
with
cluster
wide
resources,
or
at
least
the
CR
DS
are
registered
cluster
wide,
and
so
it's
important
to
have
a
little
bit
of
indirection,
because
you
don't
want
all
of
your
users
installing
CR
DS.
What
you
do
is
you
use
the
lifecycle
manager
to
do
that,
and
so
that
is
I'm
gonna
safely,
install
them
as
well
as
wire
up
a
bunch
of
permissions.
So
I
want
to
install
this
operator
in
a
specific
namespace
go
generate
a
service
account
attach
that
to
a
dynamic
role.
A
That
is
only
needs
the
minimum
set
of
required
security
permissions
and
then
make
that
all
work
for
me.
So
what
you
can
do
now
in
openshift,
42
is
actually
choose,
like
kind
of
a
custom
run
level
that
these
can
reach
up
to.
So
if
you
want
to
lock
down
your
environment
a
little
bit
more
for
either
a
specific
environment
or
a
class
of
users
or
specific
teams,
divisions
whatever
you
can
now
do
that
in
OpenShift
via
OLN,
one
that
I'm
super
excited
about
is
gonna
help.
A
The
experience
for
all
of
our
partners
and
teams
that
are
building
operators
have
a
more
seamless
experience
is
to
be
able
to
auto
install
one-click
CRS.
A
CR
is
just
the
instance
of
a
cluster
resource,
and
so,
if
you
have
something
like
a
metering
stack
or
a
chargeback
stack
or
maybe
even
like
a
storage
stack
and
you're,
only
gonna
run
one
of
them
inside
of
open
ship
now,
you'll
just
click
a
single
button
and
just
get
that
instantiated
versus
something
like
database
operator.
A
Where
you
might
run
30
of
them,
you
actually
need
to
you
know:
each
team
is
going
to
make
their
own
objects
their
their
prod
database,
their
staging
database
in
their
namespaces
from
their
quota.
So
this
is
just
something:
that's
gonna
be
really
awesome
for
products
that
are
more
like
cluster
add-ons.
Think,
like
security
scanners,
one-click
install
it
from
any
of
the
partners
that
work
on
openshift
and
battersby
a
really
nice
way
to
get
started
with
that,
as
well
as
a
bunch
of
OpenShift
products
themselves.
A
Also,
something
that's
coming
in
29th
and
2020.
Excuse
me
is
simplifying
the
object
model
for
operators,
so
we're
gonna
introduce
a
new
single
operator
object
right
now.
This
is
kind
of
split
between
a
few
different
versions
of
objects,
just
for
reasons
that
we're
not
gonna
get
into,
and
so
what
this
is
gonna
allow
you
to
do
is
have
a
really
easy
local,
dev
and
registration
process
for
if
you
are
developing
an
operator
internally,
especially
making
it
very
easy
to
load
into
your
cluster.
A
So
what
that
looks
like
is
you
you
know-
would
use
one
of
these
SDKs
on
the
CLI
to
build
a
type
of
operator,
push
it
to
a
container
registry
with
all
of
its
assets.
Just
like
you
would
any
other
container
image,
and
then
you
can
pull
and
start
that
on
a
cluster
today,
we've
got
some
tools
for
doing
validation
of
this
process,
but
we
want
to
make
it
really
really
easy
for
engineering
teams
inside
of
your
organization's
to
build
these
operators.
A
Empower
themselves
to
you
know,
be
a
little
bit
more
automated
and
how
they're
doing
deploys
doing
get-ups
workflows
and
that
type
of
thing
something
else
that's
really
cool
is
especially
for
any
of
our
partners
in
the
room
is
in
openshift.
You
can
extend
our
console
to
integrate
your
product
into
the
experience.
You
can
also
do
this
for
internal
applications
that
you
have,
and
so
some
things
you
could
do
like
our
openshift
dedicated
product
that
we
talked
about
earlier.
A
You
can
all
do
this
via
the
operator,
which
is
really
powerful,
and
then
our
third-party
partners
can
also
register
you
know
here.
You
can
see
an
example
of
a
Couchbase
operator
that
has
said
hey.
I
have
a
dashboard
that
is
useful
to
users
of
this
cluster,
because
they're
going
to
be
using
Couchbase,
and
so
you
can
start
registering
those
inside
of
this
menu
and
we're
going
to
be
introducing
more
and
more
of
these
over
time.
A
Also
really
important
is
for
in
the
deployment
of
these
operators
when
you're,
actually
making
your
instances
of
your
databases
and
queues
and
things
having
a
UI
to
do.
This
is
really
helpful,
not
everybody.
You
know
lives
in
OC
or
coop
cuttle
or
not.
Everybody
has
hooked
us
up
to
a
Jenkins
pipeline
for
deploying
these
things,
and
so
we're
actually
going
to
auto
build
some
UI's
based
on
the
open
api
schema
in
your
c
RDS.
A
So
if
you
weren't
aware
open
api
schema,
I
believe
is
going
to
be
required
in
coop
116
for
new
CR
DS
going
forward,
and
so
we
can
actually
use
that
rich
data
to
say
this
is
optional.
This
is
required.
This
is
an
integer.
This
has
a
very
specific
set
of
inputs
that
are
allowed,
and
then
we
can
build
kubernetes
specific
widgets
for
that.
A
So
if
you
were
making
the
database-
and
you
want
to
take
some
cluster
quota
and
have
some
limits
and
requests
on
it,
we
have
to
have
a
special
little
widget
that
actually
helps
you
do
that
and
can
do
some
smart
validation,
because
it
understands
kubernetes
same
thing.
If
you
have
an
operator
that
requires
a
secret
either
to
be
passed
into
it
or
it's
going
to
generate
it
for
you,
it
knows
that
hey.
This
is
a
secret
path.
I
can
open
up
a
drop-down,
and
actually
you
can
pick
from
a
secret.
A
A
This
is
what
that
looks
like
over
on
the
right
hand,
side
here,
you
can
see
that
this
is
a
drop-down
that
says,
hey
pick
your
secret,
that
you
want
to
do,
and
this
is
all
a
bunch
of
secrets
on
the
cluster.
You've
got
these
boolean
toggles,
and
things
like
that.
You
can
also
contribute
these
yourself,
so
our
console
is
open
source
just
like
the
rest
of
openshift
and
so
we'd
love
to
work
with
you
on
those.
If
you
have
them
all
right.
The
last
thing
is
super
exciting.
A
Who
here
uses
the
open
service
broker,
or
at
least
has
heard
of
this
project
and
any
of
the
binding
capabilities
that
it
has
all
right,
a
few
people
so
we're
bringing
that
to
the
operator
world
and
what
this
is
gonna
look
like
is
right.
Now,
it's
a
separate
operator
that
you
can
find
on
operator
hub
and
what
it's
gonna
do
is
look
across
your
cluster
and
try
to
fulfill
these
binding
requests
and
effectively
what
those
are.
A
Our
label
queries
on
each
side
of
that,
so
a
front-end
needs
something
from
a
back
and
you
can
match
those
up
via
label
query
and
then
gets
those
secrets
registered
within
those
applications,
and
this
operator
makes
that
happen.
We'd
like
to
see
this
probably
built
into
the
lifecycle
manager
over
time.
It's
kind
of
an
experimentation
phase.
Right
now
and
I
know.
A
Also
new
and
for
two
is
a
new
topology
view
in
our
developer.
Focused
UI.
These
bindings
and
relationships
are
represented
in
that
as
well.
So
if
you
haven't
checked
that
out,
it's
pretty
cool,
so
if
you
dynamically
update,
these
it'll
show
those
being
wired
together.
So
once
again,
if
you're,
not
if
you're
a
command
line,
person
totally
fine,
but
if
you
like
to
use
the
UI
to
see
the
representation
of
these
applications
a
little
bit
more
powerful
there
as
well
I
mean
you
can
check
this
out
in
an
operator
hub.
It's
a
it's.