►
Description
What's the best way to install, manage and upgrade Operators and their dependencies in a cluster? Operator Lifecycle Manager (OLM) is a core component of OpenShift. OLM is the Kubernetes feature/function that enables the deployment, management, and lifecycle management of all the Operators that make up OpenShift itself and the Operator-managed applications deployed.
In this stream, we'll take an in-depth look at the components of OLM and how they work together to manage everything from cluster deployment and upgrades to on-demand databases and services. So join us to explore OLM and learn why it's the best way to manage Operator collections.
Learn more:
https://github.com/operator-framework/operator-lifecycle-manager#overview
About Ask an OpenShift Admin:
Do you have questions? We want to answer them! Every Wednesday at 11am ET, hosts Andrew Sullivan and Chris Short sit down to answer your questions about Red Hat OpenShift.
Follow us:
Andrew Sullivan https://twitter.com/practicalandrew
Chris Short https://twitter.com/chrisshort
Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_confirmation=1
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
Openshift.com https://red.ht/33Fh6uV
OpenShift on github https://github.com/openshift/
OpenShift on redhat.com https://red.ht/2o4ccDk
#RedHat #OpenShift #ContainerPlatform
A
A
A
A
A
A
A
Good
morning,
good
afternoon,
good
evening,
welcome
to
a
special
edition
of
ask
an
openshift
admin.
I
am
chris
short
host
of
red
hat
live
streaming
showrunner
with
the
most,
I
guess
yeah.
I
do
lots
of
things
for
streaming
these
days,
I'm
joined
by
the
one,
and
only
andrew
sullivan
and
andrew
we're
gonna
do
a
deep
dive
today
into
some.
We
are
super
helpful.
I
feel
like.
C
B
B
Yeah,
you
know
it's
time
is
moving
more
slowly.
You
know
if
you
will
so
yeah,
but
yeah
hello,
everyone.
So
this
is
one
of
our
office
hours
series
of
live
streams,
which
means
that
we
are
just
like
if
you
had
a
teacher
that
had
office
hours
or
if
you've
ever
had
a
manager
that
had
office
hours
right,
we're
here
to
answer
your
questions
whatever
it
is,
that's
on
your
mind,
whatever
you
want
to
talk
about,
whatever
you
want
to
bring
up.
That's
what
we're
here.
A
B
Yeah
and
one
of
my
responsibilities,
because
we
just
went
through
and
did
a
whole
spreadsheet
of
who's
responsible
for
what
right
happens,
to
be
operators
and
an
olm.
So
this
is
not
necessarily
andrew
showing
off,
but
rather
than
just
a
an
opportunity
for
us
to
talk
about
something
that,
as
you
pointed
out,
is
a
core
critical
aspect
and
component
of
openshift
itself.
B
So
yeah
as
the
title
gives
it
away.
Opera
hater,
lifecycle
manager
is
today's
subject,
but
don't
let
that
limit
the
things
that
you
want
to
ask
about
talk
about
with
us
exactly
you're?
More
than
welcome
to
ask
us
about
anything
and
everything.
I
I
will
say
life
advice
may
not
be
the
best
topic,
because
oh
I've
got
a.
B
C
A
A
B
B
Know
you
know
so,
yes
top
of
mind
topics.
Let
me
switch
to
my
other
tab
here,
my
other
other
tab.
So
I
can
see
my
list
of
links
so
the
first
one
that
I
want
to
talk
about
is
so
if
you
are
paying
attention
to
our
releases.
So
this
is.
I
went
to
console.redhat.com
openshift
clicked
the
releases
button
here,
and
it
tells
us
quite
quite
helpfully
what
all
of
the
latest
releases
are
and
their
status,
so
you'll
notice
that
4.8
stable
is
still
4.8.5
despite
fast
being
4.8.9.
B
Likewise,
if
you
are
currently
running
openshift
4.7,
you
will
also
notice
that
there
is
no
updates
available
and
I
thought
I
had
one
of
those
anyways.
I
thought
I
had
a
tab
open
that
would
have
the
upgrade
path,
thing
that
showed
that
they're
all
blocked,
so
they
are
blocked
at
the
moment
due
to
a
what
feels
like
a
very
familiar
bug.
B
So
essentially
the
team
discovered
that
there
is
an
issue
with
openshift
on
vsphere
and
well
hardware
version
14..
So
we'll
take
this
bug.
If
you
haven't
already
chris
we'll
paste
that
into
the
chat
here,
you
can
dig
through
this.
You
can
see
that
effectively.
This
is
very
similar
to
what
we
saw
back
in
the
early
4.7
days
as
well,
where
there
is
an
offload
issue
causing
packet
loss.
C
B
Haven't
hit
this
one,
you
know
knock
on
wood,
so
it
seems
to
be
a
you
know,
but
before
it
was
very
consistent,
I
couldn't
even
get
a
cluster
deployed
right.
None
of
the
the
you
know
the
sdn
basically
wouldn't
come
up
because
it
was
losing
so
many
packets,
and
this
time
it
seems
a
little
more
inconsistent,
but
you
can
see
going
through
that
some
folks
are
having
it.
I
think
down
here
at
the
bottom,
is
some
suggested
workarounds
anyways.
B
If
you
are
curious,
if
you
are
trying
to
or
attempting
to
deploy
into
vsphere
4.8
into
vsphere
and
you're,
having
issues
definitely
give
this
one
reads,
but
this
is
currently
the
main
blocker
for
those
4.8
updates
and
just
keep
in
mind
that
we
will
as
soon
as
we
can,
they
will
release
those
updates.
They'll
make
the
the
updates
available
and
all
that
other
stuff.
B
I
do
appreciate
that
engineering
is
being
sometimes,
I
won't
say,
overly
cautious,
but
they
are
being
appropriately
cautious
with
these
very
we,
we
don't
want
to
accidentally
disrupt
somebody's
production
cluster
or
anything
like
that.
So
you
know
seeing
that's
you
know
if
we
look
at
fast.
Let's
assume
that
the
fix
is
in
fast
or
in
4.8.9,
you
know
seeing
that
we're
at
a
9y
release
before
we
unblock
and
I'm
I'm
just
I'm
not
saying
we
are
I'm
saying
if
we
do,
you
know
upgrades
from
4.7
to
me.
That's
a
good
thing.
B
That
means
that
you
know
we're
relying
on
that
telemetry
we're
making
those
decisions
to
consciously
not
disrupt
folks.
So
is
it
just
for
upgrades
or
fresh
installs,
so
the
bug
applies
to
both
yeah.
So
if
you
do
a
fresh,
install
on
vsphere,
you
have
the
potential
of
encountering
that
issue,
but
it
is
the
reason
why
upgrades
are
blocked.
B
And
so
so
internally,
the
engineering
folks
have
a
blog
so
for
any
red
hatters
that
are
listening,
reach
out
to
chris
or
I
and
we'll
shoot
you
the
link
to
that
internal
blog
that
they
have.
That
goes
through
like
details
of
releases,
so
they
have
like
update
metrics
and
success
and
failure
rates
and,
like
all
kinds
of
other
stuff,
that
feed
into
that
it's
really
good
information
yeah,
but
the
4.6.
B
B
It's
been
a
little
bumpy,
there's
been
a
few
things
that
they've
found,
but
fortunately
most
of
them
have
been
in
the
candidate
stage.
Do
remember,
though,
that
both
stable
and
fast
are
fully
supported.
So
if
there's
something
that
you
absolutely
need
in
4.8-
and
you
want
to
do
that
upgrade
to
4.8,
you
know
from
4.7
to
4.8.
Today
you
can
use
the
fast
channel.
B
A
B
So
the
second
thing
that
I
wanted
to
talk
about
here-
I
actually
don't
have
a
tab
open
on
this
one,
but
somebody
was
asking
on
the
openshift
sme
mailing
list.
Basically
saying
you
know
hey
my
customer
wants
to
know,
should
they
use
iscsi
or
nfs
or
fiber
channel
for
their
openshift
cluster
and
always
a
great
question
yeah.
This
is
a
fun
question
for
me,
so
I
I
came
from
a
storage
vendor
right.
B
My
previous
employer
was
a
storage
vendor
and
we
would
get
that
question
pretty
frequently,
especially
because
I
was
one
of
the
vmware
specialists
right.
My
my
focus
point
was
vmware
on
you
know,
storage
and
we
would
get
the
same
sort
of
thing
and
my
response
for
years
has
been
whichever
one
you
like
the
best.
You
know,
whichever,
whichever.
C
B
B
It's
there
can
be
a
lot
of
I'm
gonna,
say
passion
involved
in
those
decisions,
yeah
for
a
number
of
different
reasons,
so
andrew's
take.
It
entirely
depends
on
whether
or
not
it
is
capable
of
meeting
your
needs.
You
know,
nfs
has
good
things
and
bad
things
right.
Bad
thing,
there's
multiple
versions,
you
know
do.
Does
my
application
work
best
with
v3
v4
v4.1
4.2,
whereas
you
know
iscsi
fibre
channel
it's
just
it's,
it's
blocked
right
block
is
blocked.
You
know,
nfs
has
good
things.
The
manageability
aspect
is
pretty
nice.
B
You
know
I
can
go
in
and
I
can
resize
that
nfs
export
and
it
automatically
shows
up.
I
don't
have
to
do
anything.
I
don't
have
to
resize
a
file
system.
I
don't
have
to
worry
about
any
of
that
craziness,
so
they're
definitely
good
and
bad.
I
will
say
that
with
the
ip
based
solutions,
so
iscsi
nfs-
and
I
I
hope
in
2021
after
15
years
of
you-
know
virtual
machines
on
nfs
and
iscsi
that
we've
learned
these
lessons,
but
the
network
team
needs
to
participate
in
those
discussions.
B
B
We
need
to
apply,
you
know
an
os
patch
to
our
router,
so
we're
going
to
apply
it
we're
going
to
reboot
it,
and
it's
like
you
know
who
it's
a
couple
of
packets.
What
that's?
What
tcp
is
there
for
it's
designed
to
retransmit
if
a
packet
gets
dropped,
it'll
be
fine?
Well,
no!
No!
Not
when
not.
When
there's
a
bunch
of
I
o
blocks
that
are
flowing
through
there.
B
The
operating
systems-
and
I
remember
rel
in
particular,
drops
a
few
blocks
and
then
marks
all
the
file
systems
read
only
and
then
you
got
to
go
in
and
either
reboot
all
the
vms
or
log
into
each
one
and
unmark.
You
know
re
put
it
back
as
read,
write
yeah,
so
yeah,
but,
as
always,
you
know
same
same
story.
Different
different
topic.
Work
with
your
peers
in
storage.
Work
with
your
peers
in
networking
make
sure
that
the
requirements
are
known
and
understood
so
that
everybody
can
architect
appropriately.
C
A
B
C
A
B
There's
a
couple
of
things
that
come
to
mind
so
one
it
could
be
a
network
issue
so
most
likely
something
like
drop
packets
or
if
we're
talking,
you
know
going
back
to
that
vsphere
issue,
so
keep
an
eye
for
that.
You
in
that
instance,
I
would
look
at
the
logs
for
the
api
server
pods
as
well
as
what
was
the
other
one
authentication
operator.
B
C
B
So
if
you
start
to
see
issues
right,
if
it
says
you
know
not
expected
or
whatever
it
should
have
some
sort
of
error
inside
of
there.
You
can
also
look
down
here
in
the
related
objects,
and
this
is
an
easy
way
to
find
out,
for
example,
which
namespaces
will
have
pods
related
to
this
service.
So
down
here,
we've
got
resource
namespaces,
name,
openshift,
config,
openshift,
config
managed
openshift
api
server
operator
openshift
api
server.
B
A
B
A
B
B
B
Well,
which
is
true,
except
if
30
servers
all
back
up
at
the
same
time,
suddenly
everybody's
doing
something
so
that
and
that
would
cause
a
huge
you
know,
surge
in
traffic
across
the
storage,
the
network,
the
compute,
the
backup
system
and
and
all
of
those
other
things
so
yeah.
Any
number
of
things
can
affect
that.
B
What
was
the
next
thing
so
the
next
thing,
so
storage
protocols
use
whichever
one
works
best
for
you
take
into
account
kind
of
end
to
end
everything
that
needs
to
be
inside
of
there.
One
of
the
things
like
again
going
back
to
performance.
Do
you
need
like
a
hundred
gigabits
of
throughput
between
two
endpoints?
B
B
On
the
other
hand,
if
you
need
11
gigabits
of
throughput
and
you've
only
got
10
gigabits
of
network
well
you're
never
going
to
hit
11.,
whereas
with
fibre
channel
and
it's
just
link
aggregation
lacp
with
networking,
isn't
a
it's.
Not
an
addition,
a
single
flow
can
only
achieve
the
maximum
throughput
of
us
of
a
single
link.
B
Go
across
a
single
link,
single
link,
one,
you
know
one
point
to
many
or
many
to
many
will
distribute
across
all
of
them,
so
your
total
throughput
is
more
right,
but
for
an
individual
flow
it
maxes
out
at
a
single
length.
Fiber
channel,
on
the
other
hand,
works
the
way
you
would
expect
with
a
link
aggregate
right
of
it
is.
In
addition,
if
I
link,
if
I
aggregate
you
know,
4
16
gigabit
fiber
channel
links,
I
can
do
64
gigabits
of
throughput
across
that
aggregate
on
a
single
flow.
B
B
So
we
see
this
pretty
commonly
it's
a
relatively
expected
again
common
pattern
with
virtualization,
especially
where
my
ip
based
storage
will
have
a
dedicated
network,
whether
it's
a
separate
physical
network
or
whether
it's
a
separate
logical
network.
A
separate
vlan
is
pretty
common,
mostly
because,
at
least
in
my
experience,
both
iscsi
and
nfs
are
unencrypted
traffic.
So
folks
want
to
have
some
protection
on
that.
B
B
B
It's
literally
turn
off
the
vm
or
server
add
in
the
new
network
adapter
and
then
turn
it
back
on,
and
then
you
configure
it
in
the
same
way,
regardless
of
how
the
network
adapter
got
there,
you
can
figure
it
the
same
way,
which
is
either
dhcp
or
static
network
configuration
static
network
configuration
if
you're
doing
it
at
install
time.
I
would
recommend
either
the
live:
iso
booting
to
the
live
iso
using
an
mcli
or
nm2e
or
using
kernel
parameters.
B
So
you
can
use
kernel
parameters
configure
more
than
one
network
adapter
or
you
can
use
the
especially
if
you're
physical
and
you
have
something
like
openshift
fertilization
deployed.
The
nm
state
operator
is
fully
supported
with
openshift
virtualization.
I
think
it's
still
tech
preview
without,
if
I
recall
correctly,.
B
B
B
B
So
if
you
are
using
calm
with
on
your
nutanix
platform,
there's
a
set
of
blueprints
in
here,
so
you
can
use
those
to
deploy
openshift
clusters
pretty
easily
inside
of
there.
So
do
notes-
and
this
is
explained
throughout
their
docs
and
everything
today
it
is
a
non-integrated
installation.
There
is
no
cloud
provider
for
nutanix,
but
there
is
a
csi
provider
right,
there's
lots
of
other
stuff
inside
of
there.
So
yeah
it's
a
good
platform.
I've
been
experimenting
with
it
a
little
bit
and
you
know
it.
It
does
exactly
what
they
say.
B
B
B
B
Can
put
fiber
channel
over
ethernet
or
you
can
do
ethernet
over
rdma?
You
can
do
nvm
over
fabric,
so
I
I
don't
know
whether
or
not
that
supported
an
open
shift
or
kubernetes,
but
I
do
know
yeah
I
used
to.
I
had
a
conversation
with
a
storage
fender
who
is
doing
something
like
single
digit
microseconds
of
latency
for
storage
wow
using
envioumo
wow,
so
envious.
B
A
B
C
B
B
A
C
A
B
B
B
Yeah
yeah,
our
hope
nine
will
netapp
get
trident
operator
on
operator
hub.
Yes,
so
we
are
working
with
them
to
do
operator,
certification
and
all
that
other
stuff,
so
speaking
of
which
I'll
I'll
plug
it,
because
I
can
so
if
you're,
a
netapp
customer,
keep
an
eye
on
your
inbox
or
keep
an
eye
on
netapp.com,
so
we're
actually
doing
a
joint
webinar
with
them
in
the
future
for
astra
and
openshift
and
we'll
also
be
doing
a
live
stream.
B
B
Yep
so
as
the
the
the
host
with
the
most,
if
you
will
I'll
chris
crystal
manage
all
of
that
stuff,
but
yeah
so
keep
an
eye
on
that.
I
think
the
webinar
is
towards
the
latter
part
of
september,
so
yeah
well
lots
of
interesting
stuff
happening
there
and
including
operator
certification,
and
at
that
point,
there'll
be
an
operator
hub
anyway
from
the
openshift
cli
to
obtain
the
image
id
of
a
running
container.
B
B
B
B
So
that
is
a
limitation
of
both
the
entry
and
the
csi
provisioners.
They
don't
work
with
data
store
clusters
so
for
the
entry
I,
even
if
there
is
an
rfe,
it
won't
happen.
Quite
frankly,
so
we
are
in
the
process
and
not
just
we
meaning
the
entire
kubernetes
community,
red
hat
included
of
migrating
away
from
entry
provisioners
and
towards
csi.
B
B
A
C
C
B
B
B
Default
data
store
anyways,
there's
a
way
that
you
can
use
a
tag
in
order
to
select
have
the
provisioner
say,
use
any
data
store
that
has
this
tag
associated
with
it.
It
technically
works,
but
it
behaves
a
little
weird.
By
that
I
mean
it
will
first
like
it
will
randomly
select
one
of
the
data
stores.
B
First
and
then
all
pvcs
will
be
provisioned
into
that
data
store
until
it
fills
up
and
it'll
randomly
select
another
one
and
it'll
go
in
that
sequential
manner,
so
you
can
have
unexpected
capacity
consumption
if
you
will,
when
you're
doing
it
that
way.
So
if
you're
and
it
doesn't
stop
provisioning
those
until
the
data
store
reaches
100
either.
B
B
B
So
a
with
vsphere
in
a
thin
provision
data
store.
Everything
is
great.
Until
the
data
store
hits
100,
you
know
full
and
then
nothing
can
write
any
data,
so
any
vmdks,
any
vms
that
are
in
there
come
to
a
screeching
halt
at
that
point.
So
if
you
have,
let's
say
an
overzealous,
you
know
kubernetes
administrator,
who
starts
provisioning.
Pvcs
inside
of
there
and
accidentally
fills
up
the
data
store.
You
could
impact
every
virtual
machine
that
has
a
disk
inside
of
there.
C
A
A
B
My
terminal
window
here,
because
that's
what
I
want
to
use
to
illustrate
today's
content,
so
operator
lifecycle
manager
so
way
back
in
episode.
Gosh,
like
oh
wow,
oh
now,
you're,
I
want
to
say
it
was
in
the
late
teens.
I
think
we
talked
about,
maybe
even
earlier
than
that
we
talked
about
operators
and
how
they
relate
to
openshift
and
open
shift
administrators
as
a
whole.
I'm
going
to
paste
the
link
to
that
in
the
chat
here.
B
Thank
you
so
digging
it
up
yeah.
So
so.
Operators,
as
you
pointed
out
when
we
opened,
are
a
critical
component
of
openshift
right.
They
are,
I
think
most
of
us
would
agree
that
operators
were
the
major
change
that
led
from
you
know,
version
three
to
version
four
of
openshift,
so
to
say
that
they
are
important
to
openshift
is
a
bit
of
an
understatement
and
and.
B
B
B
So
olm
is
really
what
deploys
openshift
itself
right
each
one
of
these
is
an
operator.
That's
managed
through
olm
operator.
Lifecycle
manager
is
also
one
of
the
core
critical
components
for
things
like
updates
and
upgrades
right.
We,
when
you
do
an
update
the
cluster
service
or
the
cluster
version
operator.
Cvo
goes
in
and
basically
says:
hey
olm
go
update
all
of
these
operators
and
then
olm
does
what
it
does.
B
B
So
that's
where
this
particular
image
comes
in.
So
when
we
look
at
olm,
olm
provides
all
of
these
functions.
All
of
these
features
to
those
operators
that
are
deployed
so,
for
example,
this
dependency
resolution
and
collision
detection
are
really
important.
When
we
do,
for
example,
an
update,
hey,
I
need
to
update
openshift
api
server.
Okay,
what
dependencies
does
openshift
api
server
have?
Okay,
what
dependencies
do
they
have
and
it
generates
that
lovely
word
that
we
all
well.
I've
learned
from
from
the
installer,
actually
a
directed
oscillostatic
graph
and
say.
B
B
B
So
yeah
all
of
that
plays
an
important,
important
role
in
managing
the
cluster,
as
well
as
any
application
that
is
deployed
using
the
operator
paradigm
inside
of
the
cluster.
So
this
is
my
really
long-winded
way
of
basically
saying:
let's
dig
in
right,
because
operator
lifecycle
manager
plays
such
a
critical
role.
Let's
look
at
some
of
the
components.
Let's
look
at
what
all
of
this
means
and
what
we
can
do
with
it
and
chris
I
see
you
helpfully
posted
the
docs
links.
C
B
B
Scroll
down
to
the
handy,
dandy
operators
section
and
then
we
go
to
understanding
operators
and
finally
operator
lifecycle
manager.
We
have
a
series
of
documentation
in
here
that
walks
through
a
bunch
of
different
concepts,
a
bunch
of
different
things
that
exist
inside
of
here.
So
this
is
where
I
want
to
start
is
to
look
at
some
of
these
things
inside
of
a
cluster
and
how
does
that
relate?
What
does
that
look
like
across
different
things?
B
So
the
first
thing
that
I
want
to
talk
about
here.
The
first
thing
that
I
want
to
address
is
an
operator
and
olm.
Managing
that
operator
is
not
the
same
thing
as
an
operand.
I
mentioned
this
before.
I
said
that
we
were
talking
a
little
bit
about
today's
topic
of
olm
manages
operators
opera
an
operator
is,
you
can
think
of
it
as
being
effectively
automation
that
translates
an
application
into
kubernetes
objects.
B
So
I
have
let's
say
I
have
an
operator
for
well,
let's
not
say
I
have
it.
We
literally
have
an
operator
for
the
registry,
so
when
you
say
create
me
a
registry
instance,
that's
not
olm.
That's
managing
that!
That's
the
operator
itself.
The
operator
creates
an
operand,
the
registry,
and
it
manages
that
when
you
change
the
configuration
of
that
operand,
the
operator
changes
that
instance
of
the
application.
B
B
So
when
the
operator
needs
to
be
updated,
the
automation
that
then
controls
those
operands
needs
to
be
updated.
That's
where
olm
comes
into
play,
so
I
I
know
that
that
can
be
a
little
confusing.
It's
it's
hard
for
me
to
describe
so
I'm
sure
it's
hard
to
to-
or
it's
taken
me
several
iterations
to
get
to
that,
but
I
still
consider
not
great
description,
so
just
keep
in
mind
that
they
are
separate
things.
An
olm
operator,
lifecycle
manager
does
not
control
application
instances.
B
A
C
C
B
Pod,
so
we
can
see
that
we
have
this
openshift
api
server
operator
pod,
so
this
pod
represents
the
code,
the
automation
that
is
managing
the
instances
of
the
application
up
here.
So
I
I
don't
know,
but
let's
say
that
there
is
a
a
scale
property
right.
I
can
edit
the
configuration
of
the
api
server
instance
and
change
the
scale
from
three
to
four.
B
The
api
server
operator
would
be
the
one
responsible
for
that.
Olm
is
responsible
for
managing
this
operator
and
doing
its
life
cycle
management,
so
replacing
it
with
a
new
version
or
restarting
it
in
the
case
or
or
recreating
it
if
it
gets
deleted
most
likely.
This
is
a
deployment,
so
it
wouldn't
be
responsible.
Yes,
it
is
so
it
wouldn't
be
responsible
for
restarting
it.
Rather,
that's
an
intrinsic
kubernetes
function
with
a
deployment.
B
B
B
B
B
So
let's
do
oc
get
co
and
then
I
want
to
take
the
api
server
and
then
we
already
did
a
describe
on
it.
I
showed
all
of
those
different
resources
that
it's
responsible
for
right,
namespaces
and
all
that
other
stuff.
So
it's
an
easy
way
to
kind
of
start.
The
troubleshooting
process,
in
addition
to
just
doing
that,
describe
and
looking
at
any
error
messages
that
show
up
in
the
status.
B
A
A
That's
a
great
question.
I
think
folks
often
don't
unders,
don't
understand
that,
like
the
operator
instantiates
and
maintains
where
you
know
it's
sometimes
like.
Oh,
the
operator
does
everything.
Well,
if
that
operator
pod
is
down,
does
that
mean
everything
else
is
down?
No,
it
doesn't
necessarily
yeah.
It
could
mean
that,
but
it's
not
a
one-to-one
kind
of
ratio.
There
yeah.
B
And
it
would
mean
things
like
so,
let's
say
again
in
this
instance:
api
server
operator.
Let's
say
it
has
a
configuration
for
scale.
If
I
change
that
config,
if
this
operator
instance
isn't
running,
then
it's
not
going
to
enact
that
configuration
change
right
exactly,
but
again
it
won't.
If
these
api
server
pods
start
failing
they're
a
deployment,
their
their
running
is
not
dependent
on
the
operator
running.
In
that
instance,
their
configuration
is
so
what
you'll
see
and
when
you
do
updates.
B
What
you'll
see
is
olm
will
update
the
operator
code,
the
operator
pod
and
then
the
operator
will
take
action
to
update
the
application.
Pods,
so
you'll
see
kind
of
a
multi-step
thing
that
happens
there.
This
is
also
if
you
are
deploying
applications,
if
you're
using
say
crunchydb
or
you
know,
mysql
or
the
logging
operator
any
of
those,
so
that
has
to
do
with
the
approval
policy.
B
B
C
B
B
How
can
you
check
whether
an
operator
is
managed
by
olm
or
not?
So
that
is
excellent
question.
So
one
of
the
things
one
of
the
questions
that
I
had
pre-staged
here
is:
do
you
need
olm
to
use
operators
no,
and
the
answer
to
that
is
absolutely
not
so
the
best
way
that
I
have
found
to
do
that
is
to
query
the
catalog
and
see
which
ones
are
installed.
B
B
B
So
first
we
have
multiple
catalog
sources,
so
remember
olm
in
addition
to
managing
the
deployments
of
those
operators.
It
also
provides
that
catalog
of
operators
that
are
available
inside
of
here
so
up
above
in
my
cluster
operators.
I
see
we
have
this
catalog
operator,
so
that
is
responsible
for
using
the
package
server
server.
So
basically,
what
happens
here?
The
order
of
operations
is,
I
add,
a
new
catalog
source.
Let's
do
an
oc
describe
catalog
source
spell
it
correctly
certified
operators,
so
this
catalog
source
is
actually
an
image
right.
B
The
certified
operator
index
so
we'll
pull
down
that
image
and
then,
if
we
scroll
back
up
here,
the
package
server
is
the
one
that's
responsible
for
then
serving
that
image
that
grpc
endpoint
back
to
the
rest
of
the
cluster.
This
is
so
that
when
you
browse
the
catalog,
so
if
I
do
like
a
oc
get
package
manifest.
B
B
B
B
If
we
look
inside
of
here,
this
is
effectively
the
csv.
So
if
we
come
up
here
right,
current
csv
csv
description
right
all
these
things,
so
the
csv,
the
cluster
service
version,
is
what
describes
all
of
the
things
that
olm
needs
to
create
to
deploy
the
operator.
So,
for
example,
here's
the
custom
resource
definitions,
the
crds
that
it's
responsible
for
see.
If
we
scroll
down
here,
there
will
eventually
be
whole.
B
B
B
So
controller
here
are
here's
our
dependents
right.
We
can
see
exactly
which
our
back
roles
need
to
be
created,
which
service
account
it's
going
to
use.
So
let's
take
a
step
back.
Let's
look
at
the
overall
flow,
so
now
I've
got
yep.
So
I've
got
a
catalog
that
says
here
all
the
operators
available
to
you
right
and
in
those
package
manifests.
It
describes
the
csv.
B
C
A
B
A
B
Yep,
so
this
subscription,
if
we
can
scroll
up
here
to
the
spec,
is
basically
describing
you
know:
hey
the
catalog
has
this
operator,
so
the
red
hat
operators
catalog,
has
this
operator
web
terminal.
You
know,
please
deploy
it
using
this
csv
version.
If
I
want
to
provide
a
specific
one
that
will
result
in
an
install
plan
being
generated,
so
you
can
see
the
the
reference
here
so
oc
get
install
plan
okay.
B
B
B
So
we
see
these
are
all
of
the
things
that
make
up
our
operator
deployment
if
you
are
having
issues
where
an
operator
won't
deploy.
This
is
where
you
want
to
start
looking.
So
if
you,
if
I
were
to
click
that
you
know,
hey
deploy
the
web
terminal
operator
and
it
just
refuses
to
deploy
for
some
reason,
check
the
install
plan
and
see,
if
there's
any
errors
inside
of
here
or
associated
with
any
of
the
objects
it's
trying
to
create.
B
Let's
say
the
operator
fully
deploys
and
I
go
and
create
to
create
a
new
instance
of
in
this
case.
The
web
terminal
right,
hey
web
terminal
operator,
create
me
a
new
web
terminal.
If
that's
failing,
then
you
would
check
the
operator
logs
or
the
pod
logs.
So
sometimes
it's
like
a
crash
loop
back
off
hey.
I
can't
find
this
image
that
would
be
reflected
in
the
created
object
logs.
A
So
I
want
to
say
two
things
here:
real
quick
coming
up
next
on
the
channel,
we
are
actually
going
to
dive
into
writing
a
java
operator.
I
think
it's
important
to
point
out
that
you
don't
have
to
write
your
operators
in
go.
You
could
use
ansible.
You
could
use
java
bash
python.
There's
all
kinds
of
frameworks
out
there
for
writing
operators
in
a
language
of
your
choosing,
so
don't
be
scared
of
operators.
You
can
make
your
own.
B
Yeah
and
and
to
be
clear
right
red
hat,
has
you
know
we?
We
support
the
operator
framework
which
focuses
on
ansible
helm
and
go,
but,
as
you
just
pointed
out,
those
are
not
the
only
three
options,
not
the
only
things
that
so
one
thing
we
did
not
get
time
to
do
I'll
include
a
link
in
the
blog
post.
So
just
a
reminder.
Every
week,
after
the
after
the
stream,
we
have
a
blog
post
that
summarizes
everything
with
links
to
where
in
the
stream
it
happened.
B
B
Yes,
real
quick,
I
know
we
have
a
heart
stop!
Thank
you
everybody
for
tuning
in
today.
If
you
have
any
questions,
if
there's
anything
that
we
can
help
with,
please
don't
hesitate
to
reach
out.
You
can
find
me
at
practicalandrew
on
social
media
on
twitter,
just
like
my
username
here
in
twitch
has
been
and
rebroadcast
everywhere.
You
can
also
reach
out
to
me
via
email,
andrew.sullivan
redhat.com.
Please
don't
hesitate
to
reach
out.
Thank
you
for
posting
the
link
chris
join
us
next
week.