►
From YouTube: OpenShift Commons Operator Framework SIG Mtg Rob Szumski How to Add Operator to Operator Hub 2019
Description
OpenShift Commons Operator Framework
SIG Mtg
Rob Szumski
How to Add Operator to Operator Hub
2019
A
B
Right
so
I
wanted
to
talk
through
how
to
add
operators
to
some
of
the
art
community
repo
here
which
I'm
looking
at,
but
I
wanted
to
first
kind
of
talk
about.
So
we
have
this
awesome
operators,
repo
and
some
of
you
I.
Think.
Probably
many
of
you
have
this
list.
What
this
gun
represents
is
just
kind
of
like
a
collection
of
operators
that
exist
out
there
with
no
information
kind
of
about
their
quality,
which
versions
of
trooper
Eddy's
they
work
with.
B
You
know
how
to
get
them
installed
other
than
you
know,
hopefully,
there's
a
readme
going
on,
and
so
this
kind
of,
if
you
think
about
this
and
contrast
it
with
what
it
would
look
like
to
install
a
binary
from
somebody's
git
project,
it's
kind
of
like
you're
running
make
and
to
get
a
binary,
and
you
have
it
locally
on
your
machine
really
not
great
for
like
actually
sharing
these
out.
So
what
we
want
to
do
is
kind
of
to
further.
B
That
analogy
is
have
the
operator
version
of
rpms
or
actually
packaging,
this
stuff
out,
versioning
it
strongly,
and
so
that
is
what
we
have
a
new
effort
under
this
community
operators
repo.
This
is
a
set
of
manifests
of
operators
that
have
been
bundled
up
to
work
with
our
operator,
lifecycle
manager,
and
this
really
means
that
there,
you
have
a
better
experience
for
shipping
these
operators.
B
If
you
do
get
a
new
version
of
an
operator,
the
cluster
knows
how
to
upgrade
that
with
a
rolling
deployment
to
the
new
version,
so
that,
as
folks
are
putting
out
bug,
fixes
new
releases
that
you
have
a
stable
sane
way
of
getting
that
just
like
you
would
do
with
an
RPM
today
on.
One
of
your
servers
so
documented
in
this
repo
is
a
sort
of
early
steps
to
accomplish
this
and
what
it
really
comes
down
to
is
following
this
guide
right
here
to
make
a
cluster
service
version
file
for
your
operator.
B
B
Another
section
of
this
guide
is
about
not
CRTs
that
you
own,
but
CR,
DS,
that
you
depend
on,
and
so
these
are
the
required
CR
DS.
So
if
you
have
a
database
operator
that
wants
to
cooperate
with
the
Prometheus
operator,
for
example,
to
set
up
service
monitors
to
monitor
the
database,
that
you're
running,
you
can
start
expressing
all
that
inside
of
this
file.
B
Other
things
that
are
in
here
are
just
a
bunch
of
other
things
about
the
API.
Is
that
you
require,
and
then
some
metadata
about
minimum
versions
of
kubernetes
that
you
work
on,
for
example,
this
mini
coop
version
here
the
maturity
level
of
your
operators
that
you
can
kind
of
signal
that
out
to
folks,
and
then
you
know,
icons
in
that
kind
of
stuff.
What
we
want
to
do
as
a
community
is
then
have
a
list
of
all
these
that
are
tested
and
known
to
work.
B
Well,
so
inside
of
this
community
repo,
we
want
to
run
some
automation
against
your
operators
so
that
we
know
that
they
work
against.
You
know
an
upstream
conformant
cube
cluster,
for
example,
and
those
types
of
things
and
also
to
power.
Some
over-the-air
upgrades
that
smooth
process
of
actually
obtaining
a
new
version
of
an
operator
and
then
applying
that
to
your
cluster,
and
so
we've
got
some
more
information
about
testing
that
process,
and
so
that's
kind
of
the
the
main
part
of
it
is
to
make
sure
that
we
have
a
consistent
way
of
running.
B
All
these
operator
starts
that
folks
can
take
down
your
operator,
install
it
on
an
open
ship
cluster,
an
Amazon
Microsoft,
an
upstream
cluster
that
you
booted
with
cube
ATM
a
cops
cluster
or
whatever
it
is.
We
want
to
make
sure
that
everybody
has
a
really
great
experience
there.
So
I'll
drop
some
of
these
links
into
the
dock,
but
this
is
available
on
the
operator
framework
github
page
under
the
community
operators
section
so
we'd
love
to
take
any
questions.
B
A
Said
you
want
to
have
any
questions
comments
for
Rob
we
can
off.
You
can
always
reach
out
on
the
Google
group
and
ask
questions
as
well
on
people
are
always
lingering
around
there
or
in
the
kubernetes
operator
slack
channel
on
kubernetes
dude.
So
there's
lots
of
places
to
get
get
help
and
get
questions
answered
about
this.
Actually.
B
There's
one
more
thing:
I
want
to
cover,
which
is
just
kind
of
interesting,
is
doing
this
for
your
operator
kind
of
it
forces
you
to
think
through
some
architecture,
which
is
pretty
interesting
and
one
of
those
is
this
install
modes.
So
if
you
built
an
operator
on
the
call,
you
know
that
you
have
some
different
mechanisms
for
what
events
you're
listening
to
you're
either.
B
Looking
at
cluster
wide
events,
you
might
be
looking
at
just
a
very
specific
name
space,
and
so
what
you
can
do
is
actually
tell
other
users
of
your
operator
how
it
understands
to
listen
for
those
events,
so
you
can
run
in
your
own
namespace.
So
basically
saying
this
operator
needs
to
run
and
watch
the
same.
Namespace
this
operator
only
listens
knows
how
to
listen
to
a
single
namespace,
but
it
can
run.
You
know
in
a
different
name,
space
from
that
I
understand
how
to
watch
multiple
namespaces.
B
This
is,
if
you
had
an
operator
that
you
want
to
watch.
You
know
a
number
of
production
namespaces
and
you
can
list
those
out
and
have
comma
separated
values
and
then
I
watched
all
namespaces.
So
it's
a
bunch
of
enter
kind
of
architecture,
decisions
of
business
making
you
think
through
and
so
I
think
that's
just
kind
of
an
interesting
bonus
of
doing
this
is
you
can
start
thinking
about
how
you
want
to
best
run
your
operate
or
what
it
makes?
B
What
makes
sense,
is
it
a
namespace
all
namespaces,
for
example,
it's
I
want
to
provide
a
cluster
level
service
like
storage
to
the
entire
cluster,
or
is
this
a
very
specific
operator
where
you
want
to
run
them
a
bunch
of
them,
and
so
maybe
I
want
to
listen
on
a
single
mix
today.
So
that
talked
about
that's
all.