►
From YouTube: What's New In Operator Framework? - A Greene, Austin Macdonald & Varsha Narsing, Jonathan Berkhahn
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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.
What's New In Operator Framework? - Alexander Greene, Austin Macdonald & Varsha Prasad Narsing, Red Hat; Jonathan Berkhahn, IBM
Speakers: Austin Macdonald, Alexander Greene, Varsha Prasad Narsing, Jonathan Berkhahn
Operator Framework is an open source project for scaffolding, deploying, and managing Kubernetes Operators and includes Operator SDK and Operator Lifecycle Manager. Come learn about recent developments in Operators, including RukPak and Deppy, two of the new-and-improved components of Operator Lifecycle Manager.
A
Where
we're
going
to
explain
to
you
what's
new,
what's
happening
over
an
operator
framework
land,
so
by
way
of
introduction,
my
name
is
Jonathan
birkhan
I
work
for
IBM
I'm,
one
of
the
steering
committee
members
of
operator
framework
and
then
also
here
we
have
Austin
McDonald
from
Red
Hat.
Also,
a
steering
committee
member
Alex
Green
from
Red
Hat,
also
a
steering
committee,
member
and
farsha
from
operator
SDK
she's,
one
of
our
maintainers.
C
A
Of
hands
here
who
here
has
used
any
of
the
things
on
this
page?
Have
you
ever
built
an
operator?
Do
you
know
what
an
operator
is?
Have
you
ever
used?
Okay,
so
pretty
much.
Everybody
here
is
at
least
passingly
familiar
with
what
we're
gonna
be
talking
about
today,
but
in
case
you
aren't
what
is
an
operator
an
operator
is
a
design
pattern
for
deploying
software
on
top
of
kubernetes,
rather
than
statically.
Deploying
your
software
by
you
know.
Writing
a
pod,
spec
and
running
that
on
top
of
a
kubernetes
cluster.
A
What
if
we
taught
kubernetes
how
to
make
your
thing
by
extending
the
API
and
then
we
would
provision
and
interact
with
those
resources?
The
same
way
we
interact
with
the
normal
kubernetes
core
resource
types,
so
I'm
sure
we're
all
familiar
with
cop
that
Coop
CTL
create.
You
can
use
that
to
push
pods
well,
we're
going
to
teach
kubernetes
to
Coop
CTO,
create
your
thing
and
there's
going
to
be
some
process
that
lives
somewhere.
That's
called
a
controller,
that's
going
to
see
those
new
objects
being
created
and
is
going
to
go,
make
them
happen
whatever.
A
D
So
one
of
the
things
that
I've
encountered
with
people
coming
to
the
booth
is
that
they're
not
aware
that
the
operator
at
SDK
and
Cube
Builder
are
now
on
the
same
team.
If
you're
scaffolding
a
go
operator,
you're,
basically
going
to
be
getting
the
same
stuff
that
you'll
be
getting
from
Q
Builder,
because
we've
fully
integrated
and
we've
done
that
by
introducing
a
plug-in
architecture
which
means
that
all
of
the
new
cool
stuff
with
Cube
Builder
automatically
comes
down
to
us.
D
D
So
first
of
all,
we've
got
the
grafana
plugin.
If
any
of
you
came
to
my
talk
on
Wednesday,
one
of
the
best
practices
for
developing
operators
is
to
start
collecting
metrics
early
in
the
development
cycle,
so
that
you
can
track
how
that
performance
changes
over
time
with
the
grafana
plug-in
it
will
automatically
scaffold
for
you
the
configuration
that
you
need
to
plug
straight
into
grafana.
D
So,
not
only
are
you
collecting
Prometheus
metrics
right
out
of
the
box,
you
can
now
visualize
those
metrics
right
out
of
the
box,
and
we
need
to
thank
Tian
Tony
for
writing
that
for
us
and
hire
him
next
up.
We've
got
the
deploy
image
plugin
for
the
most
basic
use
cases.
If
all
you
need
to
do
is
deploy
an
image.
This
will
do
it
for
you.
It
basically
would
get
you
through
our
entire
tutorial
right
out
of
the
box,
and
we
have
to
thank
nikhil
Sharma
for
providing
that
to
us.
D
But
what
you
can
think
of
is
that
a
bundle
can
represent
an
operator,
it's
just
a
set
of
manifests
and
then
a
set
of
bundles
or
operators
is
a
catalog.
This
catalog
is
going
to
be
more
human,
readable.
It's
no
longer
going
to
be
an
sqlite
which
hopefully
none
of
you
had
to
deal
with
those
problems,
but
more
on
that
in
a
bit,
and
the
last
thing
that
I
wanted
to
talk
to
you
all
about
is
that
you
can
use
external
validators
now
with
the
operator
SDK.
D
B
Foreign
ER
SDK
does:
let's
look
into
operator
package
manager,
our
OPM,
so
the
main
task
of
opium
is
to
distribute
operator
content
across
clusters,
so
olm
initially
used
the
format
of
having
sqlite
based
Registries,
where
we
had
operator
catalogs.
Now
we
had
indexes
where
we
had
operator
images
and
we
have
the
process
of
fetching
content
through
that
and
distributing
it
now.
Unfortunately,
the
apis
which
olm
exposed
were
insufficient
enough
to
enable
operator
authors
to
look
into
a
bundle
or
to
even
debug
it.
B
Now
imagine
the
daunting
task
of
download
downloading
animates
locally
and
tiring
it
and
then
typing
a
bunch
of
sqlite
commands
and
then
reaching
the
point
where
you
can
debug
a
bundle.
Now
that
seems
a
very
daunting
task
for
an
operated
developer.
Now
a
solution
for
this,
where
file
based
catalogs
the
main
goal
of
a
file
based
catalog,
is
to
enable
better
catalog,
editing,
verification
and
extensibility.
Now,
as
the
dependency
scale,
and
we
have
a
lot
more
releases
in
a
bundle
file
based
catalogs
become
a
little
bit
more
complex.
B
Now,
veneers
were
introduced
as
an
approach
to
make
the
interaction
with
file
based
catalogs
easier.
So
we
have
two
kinds
of
fpcs:
one
is
the
basic
sorry.
We
have
two
kinds
of
veneers:
one
is
the
basic
linear
format
and
other
ssmovenia
format.
The
basic
veneer
format
is
pretty
straightforward.
It
helps
in
bundle
identification.
It
basically
lists
out
the
bundle
images
which
can
then
be
extended
into
a
full
file
based
catalog
and
December.
Veneer
is
a
little
bit
more
opinionated
and
a
little
bit
more
complex.
B
So,
as
the
dial
suggests
here,
it's
it
has
an
increased
automation
level,
so
it
not
only
lists
the
bundle
images.
It
also
gives
a
holistic
view
of
the
channels
and
the
bundles
which
are
being
promoted
inside
the
channel.
The
packages
and
an
interesting
feature
which
operator
authors
would
love.
The
most
is
a
visualization
of
an
upgrade
cycle.
B
E
F
E
E
What
this
looks
like
in
practice,
for
you
guys
is
you
create
an
operator
with
the
operator
SDK.
You
then
package
it
with
OPM
and
finally,
you
ship
it
out
to
your
customers.
Olm
would
notice
that
you
released
a
new
version
and
would
notify
all
your
customers
that
an
upgrade
can
convince
if
they're
on
a
previous
version
or
allow
them
to
install
the
new
version
of
your
operator
and
that
ability
to
push
releases
that
developers
off
their
cluster
make
to
customer
clusters
has
been
very
powerful
and
well
received
by
the
community.
E
E
So
frankly,
olm
has
been
in
the
game
since
crds
have
been
in
their
beta
format.
A
lot
of
the
design
decisions
that
we
made
early
on
in
olm's
development
life
cycle
were
based
off
of
assumptions
in
terms
of
where
we
thought
crds
were
going
to
go
early
in
olm's
development
cycle,
crds
had
no
versioning,
they
didn't
have
conversion
web
Hooks
and
a
lot
of
these
other
nuanced
changes
really
affected.
E
E
So
rockback
installing
a
set
of
manifest
it
notice
that
I
didn't
say
it's
in
charge
of
installing
operators.
What
is
an
operator?
An
operator
is
simply
a
set
of
manifests,
one
of
which
is
a
crd
that
extends
the
kubernetes
API
we've
mentioned
that
the
ability
for
to
allow
our
developers
to
create
a
solution
and
package
it
and
then
share
it
with
all
their
customers
is
really
powerful.
E
The
first
one
is
the
bundle
crd
now
Austin
had
mentioned
this
earlier
in
our
presentation,
but
a
bundle
is
a
collection
of
stuff
that
defines
a
version
of
something
you
want
customers
to
use
right,
so
Mana
a
bundle
points
to
a
set
of
manifests
that
you
want
to
install
or
right
now,
the
second
crd.
It's
called
the
bundle
deployment
crd
a
bundle,
deployment
effectively
points
to
a
bundle
which
again
specifies
a
set
of
manifests
that
you
want
to
install
on
the
cluster.
E
E
E
So
what
does
this
look
like
today,
So
today
we're
going
to
look
at
on
the
left
side
of
the
screen,
we're
going
to
see
a
example
of
a
bundle
deployment
within
that
bundle
deployment.
The
first
field
in
the
spec
is
the
provisioner
class
name.
Each
provisioner
will
have
a
unique
provisioner
class
name
that
allows
the
provisioner
to
effectively
know
like
I
am
supposed
to
handle
this
bundle
deployment.
E
E
E
The
next
thing
in
the
spec
is
the
template.
Bundle
deployments
allow
you
to
specify
bundles
in
the
spec
of
the
bundle
deployment
so
that
you
only
have
a
single
surface
that
you
have
to
interact
with.
This
is
nice
for
a
development
model
where
you
just
want
to
Define
it
inline
it
gives
you
one
API
you
have
to
create
for
one
CR
you
have
to
create.
Alternatively,
you
could
point
to
a
bundle.
That's
on
cluster,
and
so
in
that
template
you'll
see
that
the
template
has
a
spec
and
there's
a
source.
E
The
Source
type
is
how
you
define
where,
where
the
bundle
content
is
going
to
come
from-
and
in
this
case
we're
looking
at
an
image
type
and
then
within
the
source
structure,
there
is
an
image
and
a
ref
field
and
the
ref
field
points
to
the
image
that
needs
to
be
pulled
down
and
unpacked
right
and
once
again
you
see
the
provisioner
class
name.
It's
the
plain
Rock
pack
provisioner.
So
again,
you
could
use
any
combination
of
provisioners
to
retrieve
the
stuff
off
cluster
and
then
deploy
it
onto
the
cluster.
E
So
it's
a
very
plug-and-place
kind
of
system
right
bring
your
own
provisioner.
Now.
What
does
the
image
actually
look
like?
You
can
see
that
on
the
right
side
of
the
screen,
where
there's
a
single
directory
called
manifests
and
a
whole
bunch
of
resources
that
need
to
be
deployed.
Those
are
the
resources
associated
with
the
version
of
the
thing
that
you
want
to
install
so
those
that
is
the
bundle
that
is
ultimately
going
to
be
deployed
onto
the
cluster.
E
What's
really
cool
about
the
plane
provisioner
is
that,
if
anything
follows
that
format,
it
can
effectively
apply
it.
So
the
plane
provisioner
today
supports
you
specifying
an
image
that
has
a
manifest
directory
in
the
base
level,
and
then
it
will
apply
the
manifests.
You
could
just
as
easily
point
it
at
a
GitHub
repository.
It
will
pull
down
the
little
repo
or
look
at
it.
E
It
will
look
for
a
manifest
directory
and
it
will
apply
this
stuff
in
there
and
I
believe
you
can
also
point
it
at
HTTP
endpoints
and
as
long
as
it's
set
up
with
a
directory
structure,
you're
good
to
go
one,
some
other
provisioners
that
are
actively
under
development.
Right
now
are
a
Helm
chart
provisioner
so
effectively,
you
can
specify
charts
and
you
know
the
bundle
deployment.
E
B
So
a
bit
more
about
Debbie,
it's
the
most
interesting
module
of
the
whole
structure.
So,
okay
Debi,
is
basically
a
kubernetes
API,
which
is
an
independent
module
that
helps
independency
resolution
for
drug
pack
based
mode.
So
what
can
it
do?
It
can
decide
on
what
to
install
it
can
decide
a
set
of
constraints
can
be
met
and
it
can
identify
any
dependencies.
Basically,
if
I
have
or
if
a
user
has
to
install
an
operator.
It
can
check
and
tell
me
if
the
operator
is
installable
without
breaking
any
other
dependencies
present
in
the
cluster.
B
Just
as
a
note,
this
project
is
still
under
design
discussion.
We
are
brainstorming,
a
lot
about
it,
so
we
do
welcome
you
all
to
give
your
inputs
and
suggestions,
so
we
have
GitHub
repositories
for
rock
pack
and
dippy
and
we
have
independent
slack
channels,
Rock
pack,
Def
and
depedev.
So
please
do
give
your
thoughts
in
suggestions
on
how
we
would
like
olmv2
to
look
like
and
just
as
a
note
I
know
today
is
the
last
day,
but
we
do
have
interesting
demos
on
few
of
the
topics
which
we
all
spoke
about.
B
B
D
Not
that
I'm,
aware
of
but
with
the
plug-in
architecture,
if
they're,
if
you
have
a
specific
need,
it
would
not
be
very
complicated
to
add
a
new
plugin,
but
do
mention
that
in
our
kubernetes
operators,
channel
in
kubernetes,
slack
or
actually
a
better
place
might
be
the
operator
SDK
Dev
channel.
In
slack
and
possibly
we
can
create
an
issue
and
see
if
we
can
meet
that
need
good.
E
A
F
A
That
is
probably
a
thing
running
in
a
pod
somewhere
and
you
have
a
controller,
that's
responsible
for
reconciling
it,
and
you
got
to
look
through
the
logs
in
the
various
places
to
see
how,
where
is
it
getting
stuck
where
you
know?
Why
is
it
causing
it
to
just
sit
there
and
not
actually
come
up
and
run
so
if
you're
familiar
at
all
with,
like
debugging,
like
just
applications
running
on
kubernetes?
It's
a
very
similar
experience.
E
Oops
sorry,
oh
one
thing
I
might
add
on
to
that-
is
that
the
SDK
and
possibly
key
Builder
I
forget
if
they
do
this,
but
they
provide
the
ability
to
actually
run
your
operator
from
the
command
line.
What
this
effectively
looks
like
is
that
you
know
it
uses
your
Cube
config
and
it
will
just
run
the
code
like
you
know.
E
Any
code
would
run
on
your
computer
and
it
will
use
the
coupon
pig
that
you
supplied,
and
so
you
can
do
rapid
development,
just
testing
to
make
sure
that
it's
receiving
events
against
the
API
and
reconciling
them
without
even
spinning
up
a
pod.
So
you
can
just
control
C
out,
make
a
change
spin
it
back
up,
and
it
just
allows
you
to
really
quickly
iterate.
On
the
you
know,
State
and
status
of
your
controller.
You.
D
I've
got
one
more
hot
tip,
so
apparently,
CERN
has
an
operator
to
deploy
all
of
their
Drupal
based
websites,
which
is
apparently
like
a
thousand
websites,
or
something
like
that,
and
they
have
a
really
interesting
pattern
where
they
add
an
annotation
that
tells
the
operator
to
stop.
So
basically,
you
could
tell
the
operator
to
stop
at
any
point
in
your
reconcile
Loop,
which
is
a
really
great
way
to
get
in
there
and
get
some
fantastic
debugging
at
exactly
the
moment
that
you
need
it.
D
D
You
would
add
this
to
your
reconcile
Loop
by
hand
in
a
development.
You
wouldn't
want
this
in
production,
but
you
can
think
of
it
as
like
a
GDB
statement
that
will
just
stop
the
operator
in
its
tracks
right
then,
so
it
won't
be
adding
any
more
logs.
It
won't
be
being
noisy
anymore,
and
the
last
thing
that
you'll
see
in
the
logs
will
be
the
bit
of
information
that
you're
interested
in.
B
And
just
to
add
a
bit
more
to
it,
we
do
have
a
scorecard
testing
framework
where,
basically,
you
can
test
your
operator
on
cluster
without
actually
deploying
it.
So
it's
more
kind
of
validation
where
you
can
write
particular
set
of
rules
to
check
if
this
is
what
is
expected,
and
if
it's
that,
if
that's
what
is
happening
before
you,
send
it
to
the
production
environment.
G
E
Should
be
pretty
seamless,
we
have
a
registry
V1
provisioner.
So
once
again
you
can
write
a
provisioner
to
handle
whatever
format
you
like
keeping
your
stuff
in
right.
So
the
registry
V1
provisioner,
is
aware
of
csvs,
and
so
it
is
backwards.
Compatible
I
think
there's
like
some
Nuance
there,
but
it
should.
It
should
be
relatively
painless.
I'll.
A
Play
with
that
from
the
operator
SDK
side
of
things,
assuming
you
use
that
to
generate
your
bundles,
the
plan
is
it's
going
to
be
completely
seamless.
You're
going
to,
you
know,
cut
a
new
version
of
your
operator,
you're,
going
to
generate
a
bundle
for
it
and
the
interface
and
user
experience
should
be
literally
identical,
although
different
stuff
will
be
going
on
behind
the
scenes,
so
you
hopefully
shouldn't
notice
a
difference.
E
Oh,
oh
here
we
go
okay!
Okay,
sorry!
One
last
note,
so
this
is
a
feature
that
I
kind
of
just
glossed
over,
but
the
existing
bundle
format
is
whitelisted,
so
you
can
only
accept
certain
resources
inside
the
bundle
with
the
plane
provisioner.
It's
currently
anything,
so
there's
no
longer
a
limitation
there.
If
you
have
something
you
want
included
in
it,
you
can
just
throw
it
in
this
support
will
be
provider.
Sorry
provisioner,
dependent.
H
Foreign,
so
thanks
for
the
presentation
of
Alm
and
I
have
a
questions,
probably
because
I
was
not
quite
following
the
idea
of
Orlando,
because
so
for
basically
before
that,
if
we
have
to
create
an
operator-
and
we
want
to
deploy
it,
we
possibly
will
try
to
First,
install
the
crd
and
deploy
the
operator
and
then
I
guess.
The
oim
has
helped
to
resolve
the
overall
process
and
you
can
just
use
one
stop
command
and
try
to
over
cover
all
of
the
things
like
that.
H
So
my
question
is
like
if
we
do
want
to
deal
with
that,
like
what
is
kind
of
a
difference
between,
we
want
to
wrap
it
in
the
helm
chart
versus
we
deal
with
it
in
olm.
And
if
we
run
this
in
the
operator
and
it's
possible,
is
it
possible
that
we
drive
The
Operators
through
lrm,
which
that
is
not
scaffolded
by
operator
SDK?
But
it's
rather
like
a
customized
operator.
E
Yeah
so
I'm
gonna
answer
that
second
question:
first,
because
it's
a
little
more
scoped
olm
doesn't
really
as
long
as
you
package
it
in
a
format
that
olm
like
b0
supports,
which
includes
a
CSV
you,
oh
I,
will
run
it.
We
we
don't
care
if
it
how
it's
written
it
just
needs
to
be
packaged.
The
way
we
wanted,
but
with
the
new
model
it
no
longer
because
of
provisioners
Right
Where
You
Can
Define
your
own
format
for
deploying
stuff.
E
A
E
Sdk
does
make
it
very
easy
to
build
a
bundle
that
subscribes
to
the
old
packaging
format
and
they
will
do
it
for
the
new
one
too,
and
so
going
back
to
your
earlier
question.
Why
would
you
use
olm
versus
Helm,
so
I
think
they've
serve
slightly
different
purposes
and
they're
both
great
tools
that
you
can
use
to
meet
your
needs,
depending
on
what
they
are?
What
olm
really
tries
to
emulate
is
that
you
have
you
have
bought
in
to
a
new
cluster
admin
on
your
cluster.
E
That's
going
to
automatically
know
when
new
versions
of
things
appear
so
that
it
can
move
it
along
it
handles
the
upgrade
automatically.
If
you
want
it
to,
you
can
do
it
in
a
manual
mode
where
you
just
click,
OK
yup
approve
the
upgrade,
and
the
ability
to
subscribe
to
the
latest
and
greatest
is
a
really
powerful
on
cluster
thing.
E
If
there's
a
thing
that
breaks
olm
is
going
to
recover
like
if
you
installed
an
operator
and
something
somebody
deleted
it,
olm
is
going
to
come
in
and
recreate
it
so
that
that
service
is
still
available
on
your
cluster.
That
means
devops
teams
aren't
going
to
get
pinged
and
app
be
asked
to
like
go
in
and
fix
this
thing
after
it
breaks,
and
one
last
thing
is
that
Helm
has
somewhat
shied
away.
E
So
as
you
introduce
new
versions
of
the
crd,
there
is
a
potential
to
invalidate
the
existing
CRS
in
the
SCD
database
and,
if
you
invalidate
them,
that
means
they
can't
be
updated
until
they
subscribe
to
the
new
storage
format
and
what
olm
does
which
is
kind
of
cool?
Is
it
doesn't
do
it
before
you
kick
off
the
upgrade,
but
once
you
kick
off
the
upgrade,
oh
and
we'll
say
hey.
This
upgrade
includes
a
new
crd
version.
That's
the
new
stored
version
that
new
stuff
there's
stuff
on
cluster.
I
E
So
you
are
able
to
even
with
the
existing
olm
version,
you
are
able
to
find
admission
and
conversion
web
hooks
right.
So
there's
no
issue
there.
We
I
will
like
add
in
an
asterisk
and
say
that
we
only
support
it
with
self-signed
certificates
from
olm,
which
can
be
like
kind
of
you
know.
Wonky.
So
I
would
just
like
know
that
in
advance,
but
the
so
yes
they
like.
If
you
create
an
admission
web
hook
or
a
conversion
web,
it
will
be
there
and
we
will
handle
the
upgrade
and
installation
of
those
things.
E
I
I
do
recommend
it.
In
general,
though,
moving
away
from
web
Hooks
and
looking
up
the
CL
or
Cel
expressive
language,
that's
recently
been
introduced
to
crds
web
hooks
can
be
fairly
dangerous
if
they
ever
are
not
available.
You
effectively
work
garbage
collection,
like
kubernetes
garbage
collection
and
that
can
really
cause
some
problems
on
a
cluster
in
terms
of
resource
consumption.
So
I
I
I
really
encourage
anyone.
Who's.
Writing
a
crd
to
look
at
the
new
CEO
expressive
language
that
has
been
introduced.