►
From YouTube: Ask the Product Manager Office Hours: Operators and Helm
Description
Join us for a little one-on-one time with a Red Hat Product Manager - each session will feature a Product Manager focused on a specific product or project. We’ll start with an overview & discussion of the topic, then have time for Q&A.
A
Good
morning,
good
afternoon,
good
evening,
welcome
to
another
edition
of
ask
the
product
manager
office
hours
today
we're
discussing
operators
and
helm.
I'm
joined
by
three
of
my
fellow
red
hatters
karina.
You
know
from
other
shows
on
the
channel,
but
there's
daniel
mester
here
and
stefan
lemire
daniel
I'd
like
to
hand
it
off
to
you
to
kind
of
introduce
yourself
and
then
you
can
pass
it
off.
As
you
see
fit,.
B
A
D
And
I
guess
I'll
give
my
quick
introduction
for
those
of
you
who
don't
join
me
on
tuesdays.
I
am
a
product
manager
in
openshift
and
in
true
openshift
fashion.
I
cover
a
lot
of
areas.
B
D
B
Yeah
so
chris
today
we
are
like
looking
to
kind
of
address
a
very
common
question,
at
least
to
stefan
and
me
that
has
been
and
karina,
obviously
as
well.
That
has
been
sitting
with
us
for
quite
quite
some
time
now
that
we
have
actually
made
it
possible
for
openshift
users
to
use
operators
and
helm
in
a
first-class
way
with
openshift
yeah.
So
and
it's
it's
a
famous
question
of
oh,
my
god,
here's
this
operator
thing,
but
also
here's
this
helm
thing.
What
do
I
do.
B
Yeah,
exactly
like
I
may
that's,
and
and
like
most
people
that
ask
us,
are
either
administrators
that
have
like
both
kind
of
chains
available
and
want
to
give
them
to
their
developers.
B
And
then
the
other
audience
is
like
application
developers
that
are
looking
to
get
their
applications
out
into
people's
hands
on
openshift
and
provide
value
right
so
and
they
also
ask
themselves
yeah.
This
helm
thing
seems
to
be
really
common
right
and-
and
I
can
package
all
my
stuff
up
and
then
it
deploys.
But
then
there's
also
this
operator
thing,
which
seems
to
be
having
a
lot
of
traction,
but
it's
it
has
actually
a
a
higher
entry
bar.
B
So
what
do
I
get
in
that
in
return
right
and
and
when
should
I
actually
write
an
operator?
And
when
should
I
maybe
just
you
know,
package
my
stuff
and
that
up
in
the
hell
chart
and
who
is
the
person
who
who
writes
an
operator
and
who's
the
person
who
creates
a
home
chart
right
right?
So
stefan
and
I
are
gonna
like
try
to
walk
through
today
how
to
answer
that
question
from
the
perspective
of
the
end
user.
B
Getting
that
app,
as
well
as
from
the
person
that
owns
the
app
right
that
wants
to
make
it
available
to
to
other
people
and
karina,
has
already
covered
this
in
in
her
webinars
and
streams
and
in
the
first
bit
you
want
to
kind
of
go.
Take
a
look
at
helm,
how
it
works
in
openshift
and
like
what
kind
of
user
experience
you
can
get
from
that.
B
So
I'm
going
to
hand
it
over
to
stefan
to
kind
of
give
us
a
quick
intro
into
helmet
and
how
it's
being
used
and
how
it
feels
like
an
openshift.
These
days.
A
Staphon
before
you
do
your
quick
intro,
I
want
to
point
out
that
both
of
these
products
are
like
cloud
native
foundation,
cloud
native
computing.
C
C
So
really
interesting
and
there's
a
lot
of
things
that
are
going
on
and
I
think
the
belief
behind
helm
is
helping
the
developer
to
better
manage
all
their
kubernetes
jammers
and
all
the
kubernetes
resources
when
it's
time
to
define
how
an
application
should
be
packaged
for
kubernetes
and
how
it
should
be
configured
configurable
as
well.
So
helm
is
really
a
package
manager
which
provides
a
better
way
to
manage
all
the
kubernetes
resources,
such
as
you
can
define
exactly
how
you
want
to
package
your
application
and
how
you
want
to
make
them
configurable
daniel.
C
C
You
also
have
the
repository,
which
will
be
the
place
where
the
charts
can
be
stored
when
where
they
can
be
shared
and
distribute,
and
you
have
the
releases
which
have
a
specific
instance
of
a
chart
which
is
getting
deployed
on
your
cluster,
and
how
does
it
works?
If
you
can
go
to
the
next
slide,
so
you,
you
basically
have
the
m
chart
which
are
templates.
So
it's
take
it's
taking
all
your
your
command
test
manifest
and
inside
of
your
manifest.
C
Is
that
you
use
the
mcli,
so
you
can
take
a
chart
and
provide
the
different
values
for
all
the
configuration
option
of
your
your
application,
or
you
can
go
to
the
openshift
console
where
you
will
have
a
ui,
where
you
can
see
all
the
different
options
as
well
and
then
helm
will
create
the
resources
and
on
your
namespace
and
then
it
will
pull
the
images
from
the
different
repositories
that
you
you
have.
C
So
that's
how
elm
is
working
as
you
can
see,
it's
really
a
convenient
way
to
package
your
application
to
make
it
templatable
and
to
make
it
configurable
when
you
want
to
install
it.
So
let's
actually
give
a
look
of
how
you
can
do
that,
so
we
can
go
into
a
quick
demo.
So
I'm
going
to
share
my
screen,
and
hopefully
this
will
run
properly.
C
So
here
in
this,
in
this
demo,
I
have
created
a
very
basic
micro
service.
It's
a
stateless,
nikko
service
that
is
just
sending
an
email
from
my
smtp
server,
so
it's
a
quarkus
quarkus
application
and
it's
using
the
mailer
tool
in
order
to
help
me
sending
the
email
it's
using
some
environment
variables
so
that
it
knows
what
is
my
smtp
server
and
what
are
my
credentials
and
usually
this
is
not
something
that
I
want
to
share
with
my
micro
service.
C
So
what
I
would
like
to
do
with
this
micro
service,
once
I
have
it
running
on
my
on
my
laptop
once,
I
know
that
it
is
running
properly.
Is
that
I
want
to
package
it,
and
I
want
to
to
share
it
with
the
rest
of
my
team
so
that
if
they
want
to
use
it
or
if
they
want
to
reuse
this
micro
service
or
deploy
it,
then
they
can
do
it
in
an
easy
way
and
they
can
configure
it
the
the
way
they
need.
C
C
I
just
had
a
dependency
to
it
in
my
pub.xml
file
and
I
have
g
cube
there,
and
it
gives
me
a
wide
collection
of
build,
commands
and
and
goals
that
I
can
use
just
to
help
me
generating
the
kubernetes
resources
and
to
help
me
publishing
on
on
openshift.
C
If
I
want
so
starting
from
here,
what
I'm
going
to
do
now
is
that
I
am
just
going
to
show
you
that
the
application
is
is.
C
Okay,
so
I'm
on
this
project.
So
what
I
did
is
that
I
use
g-cube
in
order
to
generate
the
kubernetes,
the
manifest
and
the
kubernetes
deployment.
So
I
have
that
available
here
for
me
and
and
now
I'm
just
going
to
to
deploy
my
my
application,
so
you
will
see.
C
C
A
A
C
C
So
you
can
see
the
different
resources
that
have
been
create
the
roots
as
well
to
access
it,
and
I
can
click
on
it.
I
can
go
to
the
endpoint
call
the
rest
api
because
it
trusts
the
rest
api
that
I
have
been
doing
and
if
I
go
to
my
inbox.
C
So
that's
cool,
that's
working,
so
obviously
I
want
to
go
one
step
further
if
I
want
to
share
that
with
my
team.
So
what
I
did
is
that
I
create
a
gcube
folder
into
my
sources
and
here
in
my
deployment
camera
I
have
provide
some
templates
for
my
environment
variables
so
that
it
knows
when
it
will
create
the
end
chart
that
this
needs
to
be
configurable
options,
and
then
I
have
a
template.tml
which
provides
the
default
for
each
of
those.
But
here
I
just
provide
defaulting
so
yeah.
C
So
now
I
have
just
nbn
k8s
resources,
so
it
will
create
the
resources,
nka
s,
helm
and
it
will
create
my
end,
charts.
C
Yeah,
so
here
I
have
my
m
chart
and
if
I
go
into
my
yammer
I
can
actually
see
that
in
my
deployments,
which
has
all
been
generated.
I
have
a
template
variable
and
of
course
this
is
very
basic.
I
can
do
I.
I
could
do
a
much
more
advanced
thing
thanks
to
to
help,
but
here
you
you
have
an
understanding
of
what's
going
on
and
and
now,
if
I
want
I,
I
could
use
the
helm
cli
to
install
my
charts
so
before
I
do
that.
C
I
should
have
one
service
to
delete
as
well
boom
and-
and
here
from
here
I
can
do
elm
install
mailer
demo
and
I
can
take
my
the
archive
of
my
m
chart.
C
C
And
that's
it
so
now
you
can
see
even
from
here
that
my
service
has
been
cranked,
and
you
see
here
it's
a
little
bit
different
because
on
the
topology
view,
I
can
see
that
it's
an
n
chart
that
has
been
deployed.
So
I
have
some
some
more
options
related
to
my
my
my
end
chart
here
and
I
can
open
it
and
so
on
so
that's
cool.
So
I
have
my
m
chart.
C
I
am
able
to
deploy
it
onto
openshift,
but
now
I
want
to
share
it
and
I
want
to
share
it
so
that
others
can
also
consume
and
reuse
my
micro
service
cool.
So
what
I'm
going
to
do
is
that
I
I
have
created
a
m
chart
repository
it's
very
easy
to
to
create
one.
C
You
can
host
it
on
on
github
actually,
so
what
I
did
is
that
I
create
a
an
name,
charts,
repo
and
then
inside
of
it.
I
took
I
put
a
folder
for
docs,
where
I
put
the
archive
of
all
my
charts,
but
basically
the
m
chart
repository
is
just
an
index.html
file
with
a
bunch
of
metadata
that
highlights
how
and
what
are
the
the
m
charts.
C
C
Nice
cool-
it
should
be
here
here
and
I
can
go
back
into
into
open
shifts
and
I
can
actually
zoom
in
a
little
minute
and
what
I'm
going
to
do
now
is
that
I
will
add
my
m
chart
repository
onto
openshift
so
that
I
can
consume
the
m
chart
that
I
just
create,
and
I
can
share
it
as
well.
So.
C
C
Just
going
to
add
the
name
of
my
repo
and
the
url
I
create,
I
I
hit
crate
boom
and
now,
if
I
go
back
to
the
developer
catalog
and
I
go
to
the
m
charts-
and
I
can
see
my
repository
is
appearing
here-
and
I
have
my
charts,
which
is
coming
here
and
if
I
click
install,
I
will
have
a
way
to
provide
the
configuration
for
my
micro
service,
so
pretty
cool,
pretty
easy.
As
a
developer,
I
can
easily
get
going.
C
So
that's
a
little
bit
the
mindset
that
you
have
when
you
are
a
developer.
It's
really
here!
Okay!
So
I
package
my
app
my
my
application.
C
I
can
also
add,
as
part
of
my
chart,
some
part
of
the
upgrade
mechanism
for
my
application,
but
really,
if
you
start
to
to
to
switch
your
mindset
and
start
to
think
about
how
your
application
is
going
to
operate
and
how
it's
going
to
run
once
you
will
deploy
it
and
have
to
to
to
maintain
it
on
production,
then
it's
starting
to
be
a
little
bit
short
because
it
will
not
manage
the
full
life
cycle
of
your
application.
C
It's
not
exactly
the
best
thing
that
you
could
be
probably
doing
and
for
that
operators
are
providing
much
more
advanced
capability.
It
will
help
you
to
follow
the
life
cycle
of
your
application
under
the
the
backup,
the
failure
recovery.
C
You
can
also
leverage
insights
from
how
your
application
is
behaving
while
it's
running
to
to
to
define
some
some
ways
of
how
your
application
should
be
should
be
operate
in
fact,
and
you
can
automate
that
with
with
operators,
and
that's
probably
where
I
will
end
over
to
danielle,
which
will
give
you
much
more
colors
about
everything
that
you
can
do
with
with
operators.
B
B
I
think
what
you've
highlighted
is
that
that
microservice
example
was
a
really
great
fit
right,
because
when
people
ask
me
like,
when
do
I
reach
the
point
where
I
should
write
an
operator
versus
staying
with
packaging
technology
like
like
helm,
I
usually
give
sort
of
an
academic
answer
almost
where
I
say
if
your
application
life
cycle,
if
everything
your
application
needs
to
do
from
having
its
startup
be
reconfigured,
updated
and
then
eventually,
uninstalled
or
retired,
can
be
done
with
core
kubernetes
features
with
onboard
kubernetes
features
like
you
know,
deployments
stateful
sets
pvcs
services
routes
and
this
kind
of
things.
B
B
So
that's
why
this
arrow
here
and
there
and
the
graphic
from
helm
goes
a
little
bit
into
like
the
seamless
updates
lifecycle
phase
right
and
when
you
when,
when
all
that's,
when
that's
all
that's
needed
for
your
app.
B
So
in
this
sense
you
have
questions
like
how
is
my
application
updated?
How
does
it
update
and
migrate
its
database
schema?
How
is
it
backed
up?
Is
that
kind
of
some
failure
recovery
happening
right?
How
do
I
make
the
application
auto-tune
itself,
based
on
a
certain
workload
pattern
right?
So
these
are
things
that
core
kubernetes,
you
know
isn't
really
up
to
right
now
and
it
shouldn't
be
right,
because
kubernetes
has
always
been
written
to
be
a
platform
of
platforms,
and
what
that
means
is
it's
extensible?
B
D
B
Logic
right
and
make
it
something:
that's
a
first-class
citizen,
and
at
that
point
usually
people
tell
me
okay.
That
makes
sense,
but
there's
really
no
discussion
anymore
right.
You
know
they
take
away
that
knowledge
and
kind
of
go
home
and
go
go
about
their
things.
So
I
thought
we
might
need
to
add
a
little
bit
more
of
examples
right
and
tangible
inflection
points
at
which
you
should
think
about
as
the
application
owner
or
developer.
B
Maybe
I
should
write
an
operator
to
cover
that
specific
piece
of
my
operation.
Operational
needs
for
my
application
right.
So
that's
what
I'm
kind
of
trying
to
show
you
now
so
you've
probably
seen
something
like
this
slide
for
a
number
of
times.
Now
it's
kind
of
the
autonomy
of
an
operator.
I
don't
want
to
go
into
a
lot
of
details
here,
but
the
biggest
difference
between
what
we've
seen
from
stefan
and
what
you're
going
to
see
here
is
and
and
a
helm
chart,
is
a
package
way
of
your
manifest
distribution
right.
B
Deployment
and
operator
is
actually
a
piece
of
software,
and
that's
not
your
application
that
you're
looking
for
it's
a
piece
of
software,
giving
you
this
application
as
a
service
right
and
it
sits
in
the
system
on
the
cluster
itself,
and
it
watches
for
events
right
and
when
it
does
that,
and
it
sees
events
that
it's
interested
in
it
can
start
to
do
workflows
and
it
can
start
to
do
automation
and
one
use
case
of
that
is
to
model
application
deployment
in
a
way
where
an
operator
will
introduce
a
new
custom
resource
type
in
the
system.
B
So
next
to
deployments
and
parts
and
stateful
sets,
you
now
have
a
thing
called
enterprise
database,
oops,
so
enterprise
database
right.
That
is
now
a
first-class
concept
in
your
system.
It's
actually
an
api,
a
custom
resource
type
in
your
system
that
the
operator
watches.
For
so
when
it
pops
up
or
an
existing
one,
is
modified.
The
operator
starts
to
do
its
work,
and
what
this
work
looks
like
is
something
we
call
reconciliation
and
that's
basically
saying
the
operator
will
always
take
a
look
at
the
left
and
see
what's
specified
here.
B
I
want
to
have
a
database
version,
3213
size,
5.
and,
what's
on
the
right
hand,
side
what's
happening
on
the
cluster.
What
is
already
there
to
make
this
request
be
fulfilled
and
it
will
constantly
work
towards
re,
fulfilling
that
request
in
an
iterative
fashion,
just
as
kubernetes
itself
works
to
eventually
come
to
a
state
where
enough
deployment
state
full
sets
secrets,
config
maps
and
per
system
volumes
are
there
to
have
a
database
service
running
right
and
the
way
to
do
that.
Sits
in
that
operator
right
this
custom
logic.
B
Custom
to
this
specific
enterprise
database
is
codified
in
the
operator
and
that's
a
part
running
your
cluster
talking
to
kubernetes
api.
So
that's
something
different
than
a
helm
chart
right.
So
with
helm,
you
kind
of
get
the
application
yourself
with
an
operator.
You
get
a
service
that
gives
to
the
application
right.
So
the
difference
is
really.
B
How
do
I
get
the
application
up
and
running
as
quickly
as
possible,
with
some
minor
customization
versus
having
an
as
a
service
experience?
So
the
analogy
I
usually
draw
is
when
people
want
to
have
a
database
on,
say
aws
and
they
want
to
have
a
postgres
database.
So
what
do
they
do?
They
could
obviously
say:
here's
a
cloudformation
template
that
lays
out
all
resources,
virtual
machines,
easy
two
disk
storage
street
job
storage,
whatever
you
need
and
arranges
it
in
a
way
so
that
you
have
at
some
point
the
postgres
endpoint
running.
B
This
is
the
templating
approach
right.
This
is,
you
know
what
we
saw
with
helm
and
also
what
customize
and
other
templating
tools
are
doing,
but
that's
not
what
aws
users
are
using
right.
What
they
are
using
is
rds
right,
there's
a
managed
service,
the
relational
database
service,
which
gives
them
a
postgres
database
as
a
service
with
all
the
high-level
postgres
controls
that
you
would
expect
from
a
database
service.
So
an
operator
is
really
like
rds,
but
in
your
cluster
right
wherever
your
cluster
runs.
B
So
what
you
do
with
installing
an
operator
and
giving
people
an
operating
experience
is
giving
them
an
rds
like
experience,
but
on
your
cluster
right,
it's
it's
on
demand
and
it's
as
a
service
and
people
select
from
it
from
like
a
service,
catalog
type
fashion
right.
So
that's
kind
of
already
a
difference
in
the
end
user
experience
and
one
if
you
want
to
have
one
or
the
other,
you
choose
helm
or
or
operators.
B
The
other
aspect,
that's
important
to
understand,
is
like
where
do
things
run
right?
So
what
what
stefan
showed
was
basically
running?
The
helm,
client
and
creating
resources
on
the
cluster
and
the
helm.
Client
ran
on
on
stefan's
notebook
right
and
the
case
of
the
openshift
console
actually
runs
in
as
part
of
openshift,
but
normally
helm
is
kind
of
an
external
tool
that
runs
outside
of
the
cluster
and
that's
where
all
the
logic
is
right
and
the
tool
only
runs
when
it's
invoked
right.
B
So
either
user
invokes
it
or
some
sort
of
githubs
methodology
invokes
it,
and
then
it
renders
all
these
things
and
hands
out
the
resources
to
the
cluster
and
that's
when
it's
done
right.
So
it
uses
the
kubernetes
apis,
but
in
a
one-off
fashion,
a
kubernetes
operator
runs
in
the
cluster
and
it
can
be
used
by
multiple
users.
So
if
you
want
to
use
a
helm
release
among
multiple
users,
all
the
users
need
to
have
ideally
the
same
time,
client
as
well
as
the
same
chart
version
right.
Otherwise,
you're
going
to
have
conflicts
with
an
operator.
B
All
the
logic
sits
in
the
cluster.
The
binary
that
has
logic,
runs
in
the
cluster
and
can
be
used
by
multiple
users.
It
watches
the
control
plane
of
kubernetes,
so
it
can
see
all
the
events
that
are
running
and
it
can
use
this
capability
to
get
you
an
application
or
to
do
other
things.
So
it's
not
just
application
deployment
with
kubernetes
operators.
You
can
also
use
this
to
trigger
event-based
automation
or
to
even
talk
to
an
external
api
like
an
external
cloud
service
right.
B
So
if
you
want
on
openshift
to
consume
an
azure
hosted,
managed
database,
you
use
the
azure
services
operator
and
its
apis
to
get
you
an
instance
of
that,
and
the
operator
will
facilitate
that
on
your
behalf
using
the
azure
apis.
It
actually
deploys
nothing
on
your
cluster.
All
it
does
is
react
to
your
request,
which
you
place
in
the
cluster
and
responds
to
that
by
giving
you
the
credentials
on
that
request
right.
So
that's
also
a
different
nature
of
of
running
software
and.
B
Operator
can
therefore
do
more
than
application
deployment.
They
can
also
automate
stuff
on
a
system
and
can
also
use
external
systems
to
do
that
and
already
said
that
it's
actually
constantly
doing
that.
So
it
runs
in
a
loop
and
it
notices
when
things
are
changing
in
the
system.
So
when
your
application
requires
you
to
change
and
react
to
system
changes
beyond
what
kubernetes
automatically
does
with
rescheduling
parts
and
so
on,
then
you
would
write
an
operator
to
watch
these
events
and
trigger
custom
code
right.
So
this
might
be
a
little
bit
abstract.
B
But
it's
really
important
to
understand
that
the
operator
runs
all
the
time
versus
helm
only
runs
when
you
invoke
it
and
then
it's
done.
You
have
no
chance
to
do
anything
with
helm
after
that,
unless
you
have
run
the
helm
binary
again,
but
if
I
go
in
and
delete
a
part
of
stefan's
mailer
demo
deployment
like
the
service,
there's
nothing
that
notices
that
in
the
system
right
it's
only
getting
restored
when
you
run
helm
again
right
with
an
operator.
That
would
be
something
that
got
recreated
automatically
within
a
couple
of
seconds.
B
But
maybe,
let's
take
a
different
look
at
like
what
does
it
mean
to
react
to
system
events,
so
I'm
gonna
quickly
share
my
openshift
cluster
here,
in
which
I
have
a
very
interesting
operator
installed
that
I'm
really
come
to
like
it's
the
namespace
configuration
operator
and
something
that
ships
as
part
of
openshift's
community
catalog,
and
what
this
thing
does
is
help
with
onboarding
of
new
users
and
projects
and
specifically
what
it
does
it
can
watch
for
new
projects
getting
created
and
ensure
that
certain
things
happen
in
that
state.
B
In
particular,
certain
resources
are
standard
by
standard
applied
to
this
project
and
the
most
common
case
is
actually
default.
Resource
coders
right,
we
all
know
the
enemy
of
a
stable
clusters
are
all
those
projects
and
spaces
that
have
no
max
coder
at
all
right.
B
I
created
an
example
here
and
if
I
go
there,
I
can
see
that
what
it
does
it
it
lets
me
provide
a
label
selector
to
match
namespaces,
to
which
this
default
set
of
resources
should
be
applied,
and
so
the
label
selector
is
one
called
size,
equals
small,
and
there
is
a
number
of
objects
that
are
always
going
to
be
applied
when
those
resources
and
windows
name
spaces
are
created
with
that
label.
One
is
the
resource
quota
right.
B
I
want
to
limit
these
namespaces
to
max
four
parts
to
maximum
usage
of
two
cpus
and
two
gigs
of
memory
and
four
gigs
of
ephemera
storage
right,
so
that
should
be
by
there
by
default,
and
I
should
not
need
to
make
that
happen.
You
know
manually
with
the
admin
that
provisioned
the
project
for
the
developer,
for
instance,
or
trust
my
developers
that
they
will
create
reasonable
resource
codes
themselves
because
likely
they
are
going
to
throw
in
much
higher
values.
Here,
right
developers
tend
to
over
state
their
requirements
to
be.
B
Side,
the
also
the
other
thing
that
it
does.
It
actually
configures
this
namespace
with
an
egress
network
policy
to
be
agate,
so
they
cannot
reach
the
internet.
This
is
something
that
is
important
in
security,
sensitive
environments,
so
these
two
objects
based
on
the
operator
would
be
created
automatically
whenever
a
new
project
is
created.
B
So
let's
go
ahead
and
actually
try
this
real
quick.
Let
me
just
create
a
project
here.
That's
called
developer
unlimited,
and
this
is
going
to
be
just
for
illustrative
purposes
that
by
default,
no
resource,
coders
or
egress
policies
are
applied.
When
you
create
a
project
on
openshift-
something
you
should
probably
know
about.
When
you
give
openshift
to
your
tenants
and
your
colleagues
right,
because
by
default
they
can
do
anything
in
the
system
in
that
namespace
in
terms
of
requesting
resources
right.
B
So
what
we
want,
however,
is
a
more
sane
approach
where,
by
default,
they're
going
to
be
some
limits
right.
So
let's
create
another
project.
B
I'm
just
going
to
do
this
with
yaml
for
the
sake
of
the
presentation
demonstration,
but
I'm
going
to
create
a
project
called
developer
sandbox
with
this
label
right,
I'm
going
to
hit
create,
and
now
what
you
see
is
that
a
resource
coder
has
been
applied
automatically
and
that's
because
the
operator
watched
four
namespaces
being
created
in
the
system
and
when
that
happened,
and
it
also
fulfilled
the
criteria
of
that
namespace
needs
to
have
a
certain
label
called
size
small.
B
As
you
can
see
here
in
the
specification
it
limits
you
to
two
cpus
at
max
and
that
limits
to
you
to
four
parts
at
max
right
and
developers
who
might
want
to
circumvent
you
as
an
admin
can
also
not
delete
that
right.
The
operator
will
just
restore
that
as
part
of
its
reconciliation
right-
and
this
is
this
event-based
automation
that
you
can
do
with
an
operator.
This
is
not
about
deploying
an
application.
B
This
is
really
about
making
workflows
happen
automatically,
based
on
certain
things
happening
in
the
system
and
because
the
operator
is
in
the
system
running
all
the
time
running
in
the
loop.
You
can
actually
do
that
right,
so
I
could
try
to
go
ahead
and
delete
it
here.
I
didn't
try
that
before
so.
This
is
a
true
live
team.
Oh
no,
I
expect
that
thing
to
come
back
and
there
it
is
so
that
didn't
even
take
a
second.
So
this
is
really
aggressive.
B
So
as
it
should
be
right,
you
know
this
is
you
know
proper
tenant
isolation,
so
this
is
a.
This
is
one
use
case
of
an
operator
besides
just
application
deployment
right,
so
this
is
really
useful
and
and
it's
hard
to
do
when
you're
sitting
outside
of
the
system
right.
This
is
best
something
that
runs
inside
a
system
watching
over
your
cluster
at
all
times.
So
that's.
A
B
Exactly
the
dilute
nature
is
really
what
makes
it
a
different
kind
of
software
right,
and
this
is
also
different
to
you.
Writing
your
own,
like
playbooks
or
bash
scripts,
that
run
in
a
in
a
cron
job
fashion
outside
of
a
cluster
also
works
right.
It's
also
a
viable
approach,
but
this
is
a
much
more
predictable
and
versatile
experience.
B
So,
as
you
can
see
with
helm,
you
have
a
very
predictable
and
a
standardized
workflow
that
everybody
came
to
love
which
is
download
the
chart
customize,
your
values.yaml
deploy
the
app
reconfigure
it
with
helm,
upgrade
and
eventually
retire
it
right,
and
that's
why
helm
is
super
popular,
because
every
application
package
helm
kind
of
works
this
way.
So
you
learn
it
once
and
then
you
can.
You
know,
apply
that
learning
to
all
hand
shots
basically
right,
but
it
also
will
usually
not
do
much
outside
of
that
right.
B
So
on
right
hand,
side,
you
see
all
the
things
that
you
could
do
with
an
operator
which
is,
of
course,
request
the
app
or
reconfigure
it
or
update
it,
but
also
automate
these
workflows
as
you've
seen
in
the
demo
before
right
or
request
external
services.
Like
from
your
cloud
provider
or
react
to
cluster
events,
do
more.
A
B
B
So
that's
kind
of
what
I
wanted
to
see
and
show
to
you
as
part
of
different
nature,
here's
an
additional
aspect
that
gets
forgotten
and
it's
especially
important
for
maintainers
of
apps
that
want
to
give
a
great
user
experience
to
their
to
their
customers
right.
So
if,
if
you're
using
helm,
your
are
back,
the
access
that
you
currently
have
in
your
cluster
defines
what
the
helm
chart
can
do
and
what
helm
chart
can
deploy.
So
if
you
are
deploying
something
that
requires
cluster
admin,.
D
B
B
To
be
cluster
admin
right,
so
there's
no
way
you
can
give
this
to
an
unprivileged
user,
because
helm
runs
with
your
permissions
right.
So
most
of
the
things
that
are
packaged
as
hammer
shots
are
actually
therefore
scoped
down
to
be
in
the
namespace
and
for
user
and
that's
fine,
but
with
kubernetes
operators.
You
have
the
ability
to
have
a
different
set
of
permissions,
be
used
by
your
operator
versus
what
your
users
need
to
have
and
what
the
application
eventually
gets
right.
B
Remember
that
in
kubernetes
you
cannot
give
more
application
permissions
that
you
have
yourself.
So
with
an
operator.
You
can
come
around
with
that
a
little
bit
because
you
can
have
unprivileged
users
use
a
privileged
operator
that
deploys
things
in
the
cluster
so
that
these
users
don't
need
to
have
those
privileges
right.
B
So
it's
kind
of
a
privileged
delegation
mechanism
that
allows
the
operator
to
carry
out
more
privileged
tasks
without
having
you,
as
the
admin,
give
those
users
those
privileges
and
that
as
an
application
developer
is
important,
because
I
want
my
application
to
be
as
used
by
many
people
as
possible,
and
I
don't
want
people
to
be
stuck.
B
They
are
not
classed
at
them,
so
that's
why
you
have
two
choices
here
right
if
you
want
to
do
one
or
the
other,
so
how
does
it
do
its
job?
This
is
where
it
becomes
really
interesting,
because
what
you've
seen
with
helm
is
that
once
helmet
renders
the
chart,
it
essentially
throws
all
the
resources
on
the
cluster.
This
is
typical,
kubernetes
right.
It's
give
me
all
the
end
state
and
I'll
try
to
reconcile
as
long
as
possible
until
it
reaches
your
desired
state.
B
So
it's
this
eventual
consistency
right,
and
this
is
goal
seeking
nature
of
kubernetes
and
for
things
like
this
microservice
that
we
saw
or
in
general,
stateless
applications.
This
is
just
fine,
they
don't
need
anymore,
and
that's
why
helm
is
so
suitable
for
this
right.
It
runs
once
and
it
deploys
all
these
things
at
once
in
parallel
and
essentially
lets
kubernetes
do
its
thing
right.
There
is
limited
room
for
customization
how
that
works.
There
are
pre
and
post
hooks.
B
B
Wait
for
the
finish
before
you
do
the
third
thing:
if
the
outcome
is
a
or
the
fourth
thing,
if
the
outcome
is
b
right,
so
you
have
conditional
logic
in
this
operator
that
enforces
ordering
and
consistency
and
weight
states
to
ensure
the
integrity
of
the
application,
especially
over
time
right.
So
if
your
application
needs
that
ordering,
then
it's
probably
a
good
idea
to
use
the
operator
pattern
because
it's
going
to
be
at
some
point
hard
to
do
this
with
helm
and
maybe,
let's
take
a
look
at
them
at
an
example
of
an
application
stack.
B
Actually
that
has
some
of
these
requirements.
So
you
might
not
know
this,
but
but
I'm
also,
the
product
manager
for
something
called
quay
and
quay
is
a
registry
platform.
It's
a
container
registry
and
we
don't
need
to
go
into
details
on
what
it
does.
It's
suffice
to
say
it
is
a
python
application
that
has
certain
requirements
it
needs
to
have
a
redis
database
needs
to
have
a
postgres
database.
B
It
needs
to
have
some
object,
storage
and
then
it
all
comes
together
with
a
with
a
config
map
or
secret,
which
you
attach
to
your
parts
running
the
quay
python
scripts
in
a
scaled
out
way
in
order
to
get
you
an
highly
available
registry.
B
So
let's
say
I'm
the
maintainer
of
quay,
and
I
want
to
like
give
this
to
you
right.
So
what
I
need
you
to
do
in
order
to
get
this
up,
is
you
need
to
get
yourself
a
redis?
You
need
to
get
yourself
a
postgres,
an
object
storage.
B
Then
you
need
to
run
something
that
we
call
a
config
editor,
which
is
essentially
a
ui
that
generates
config
file.
You
technically
don't
need
this.
The
only
thing
that
this
thing
does
is
actually
creating.
The
initial
database
schema.
That
coin
needs
to
run.
So
when
you
have
done
all
of
that
in
order
and
waited
for
it
all
to
be
ready.
You
essentially
then
download
this
config
file
injected
into
your
parts
and
off
you
go
depending
on
what
features
of
query
you
want.
B
If
you
want
to
have
security
scanning,
you
need
to
actually
run
a
separate
thing
called
clear.
First
wait
for
that
to
be
up
in
online,
and
then
you
run
quay
and
initially
subsequently,
if
you
want
to
use
another
feature
called
repo
mirroring,
you
also
run
additional
workers
on
that,
so
not
really
important.
What
these
things
mean
just
know
that
there
needs
to
be
certain
things
that
happen
in
order
for
you
to
actually
get
the
deployment.
So
if
I
would
do
this
with
helm,
this
could
very
much
very
possibly
go
like
this
right.
B
So
the
quay
system
validates
that
it
can
actually
access
the
database
or
the
object,
storage
and
then
also
creates
database
schema.
These
things
all
need
to
run
before
you
run
quay.
So
I'm
trying
to
get
to
my
config
app
here.
Switching
screen
share
real
quick
back
to
open
shift.
Oh
the
application
isn't
available.
Well,
that's
kind
of
typical
for
helm
right
because
helm
doesn't
know
that
the
config
app
needs.
You
know
maybe
10
seconds
to
come
up.
You
know
it
doesn't
wait
for
the
part
to
be
scheduled.
B
It
just
spits
out
the
data
and
it
says:
wait
like
a
couple
of
seconds.
So
if
I
refresh
this,
it's
just
going
to
be
there,
I'm
not
going
to
see
a
ui
in
which
I
can
enter
all
the
data
right.
So
this
is
how
this
could
possibly
go
with
something
like
helm
and
for
developers.
This
is
probably
fine,
but
if
I,
if
I
ship
this
to
customers,
I
can
count
on
it
that
20
30
will
get
it
wrong.
B
We'll
use
something
unsupported
or
just
type
in
the
data
wrong
and
try
to
automate
this
and
it's
kind
of
hard,
because
extracting
all
these
credentials
from
the
helm,
charts
that
you've
just
seen
is
a
little
bit
manual
right.
You
know
doing
that
and
in
github's
fashion
on
ansible
labels,
it's
kind
of
hard,
so
maybe
there's
a
different
way
right,
and
this
different
way
could
very
much
look
like
this,
where
you
actually
have
a
an
operator
that
does
this
for
you.
B
So,
let's
switch
namespaces
here,
real
quick,
go
to
query
operator
and
go
to
the
list
of
installed
operators,
and
you
see
I
have
the
query
operator
installed
and
that
thing
knows
how
to
do
all
of
the
sequencing
and
all
of
this
provisioning
as
it's
coded
out.
So
I
just
go
in
here
and
say,
create
query
registry
and
it
gives
me
a
form
which
is
generated
by
the
ui
based
on
inputs
that
the
operator
supports,
and
if
I
switch
to
the
yellow
view,
you
see
it's
just
another
kubernetes
resource
right.
B
So,
if
you're
on
the
command
line,
you
could
also
just
do
this
with
cube
ctl,
and
this
is
how
I
tell
the
operator
to
do
something
right.
I
basically
say
these
are
the
query
components
that
I
need.
I
want
to
have
security
scanning,
the
database
object,
storage,
yada,
yada
and
the
operator
goes
off
and
deploys
all
of
that
right.
So
let's
say
I
ask
you
to
not
give
me
a
database,
because
I
want
to
have
a
external
database
right.
So
let's
just
set
this
to
off
and
say
create.
B
B
So
there
are
no,
you
know
additional
parts
here,
there's
there's
no
additional
crash,
looping
quay
parts,
it's
deploying
clear
which
comes
with
its
own
database
here,
but
there
are
no
query
parts
that
are
crash
looking
because
they
find
don't
find
a
database.
It's
because
the
logic
of
the
sequence,
I've
shown
you
in
the
slide
earlier
is
kind
of
hard
coded
in
that
operator.
B
So
now,
as
a
user,
what
I'm
actually
doing
is
I'm
going
to
the
config
app
that
the
operator
automatically
created
for
me
and
I'm
now
going
to
give
it
the
postgres
credentials
of
my
external
postgres
database.
I'm
not
going
to
do
this
now
for
the
sake
of
time
in
this
stream
right,
but
that's
how
I
would
do
this
right
so
and
that's
the
kind
of
interaction
that
makes
it
really
nice
for
users
to
discover
how
your
app
works
rather
than
fading
hard
and
creating
all
kinds
of
errors.
A
And
like
providing
that
logic
inside
the
operator
is
truly
a
gift
right,
like
you're,
giving
a
gift
to
folks
on
how
you
intend
this
operator
to
be
used.
Long
term
and
kind
of
you
know
helping
them
along
the
way
and
not
having
to
worry
about.
Maybe
those
edge
cases
that
the
operator
knows
about
and
can
then
maintain.
You
know
if
a
state
changes
or
something
it's
good
right,
like
it's
going
to
put
itself
back
into
a
good
spot,
exactly.
B
So
reconfiguring
quay
is
actually
quite
easy.
You
could
you
could
kind
of
do
this
with
helm.
Reconfiguring
query
is
just
updating
a
secret
or
config
map
and
then
bouncing
your
parts.
It
kind
of
turns
out
that
bouncing
a
pause
doesn't
happen
automatically.
So
if
you
have
a
deployment
that
mounts
a
config
map
or
secret
and
that
is
subsequently
updated,
kubernetes
does
nothing
to
your
deployment
right.
B
Applications
that
have
this
requirement,
so
this
is
kind
of
doable
in
in
helm,
but
it's
something
that
the
operator
can
just
take
care
about
in
its
internal
logic,
so
you
don't
need
to
and
now
comes
a
truly
difficult
bit
right,
which
is
how
to
update
quay
so
crazy
state,
a
scale-out
python
application
over
a
database.
So
it's
kind
of
an
application
stack
right
and
you
could
have.
B
B
What
the
operator
does
it
looks
at
all
this
thing
as
one
stack
right
so
in
order
to
update
quay
what
you
would
actually
need
to
do
is
you
need
to
scale
down
your
deployment
to
zero?
Then
you
need
to
run
exactly
one
version
of
your
new
quay
exactly
one
part,
and
what
this
will
do
it
will
create.
It
will
execute
database
migrations
so
from
one
quick
release
to
another.
We
might
actually,
you
know
change
fields
in
the
database,
create
new
tables,
rename
columns
and
so
on.
B
So
these
things
are
automatically
migrated
on
startup
when
the
first
quake
port
starts
up,
but
it
needs
to
happen
without
any
other
quay
instance
or
any
other
client
really
accessing
the
database
because
they
might
catch
some
influx
state
of
the
database
which
doesn't
make
sense
to
them.
So
you
need
to
scale
down
let
the
database
migrations
run.
This
may
take
all
the
way
from
10
seconds
to
a
minute,
and
only
then,
when
that's
finished
and
successful,
you
scale
up
the
new
crane
deployment.
B
Otherwise
you
need
to
hold
back
right
and
doing
this
with
helm
in
a
single
command
or
just
within
one
helm.
Chart
is
extremely
difficult.
You
would
need
to
write
a
script
or
some
sort
of
program
that
scales
down
your
deployment
and
runs
as
a
pre
deployment
hook
in
in
helm,
and
that
needs
to
then
finish
and
wait
for
this
stuff
to
be
scaled
down,
so
another
job
can
run
that
does
the
database
migration,
it's
not
impossible,
but
at
that
point
you
are
programming
right,
right
and
yeah.
B
If
you
are
programming,
you
might
just
as
well
program
an
operator
that
does
this
in
a
very,
very
you
know
consistent
way.
So
the
way
this
is
done
with
with
with
the
operator
is
at
least
in
the
case
of
the
quay
operator,
very
straight
forward.
What
you
do
is,
if
you
want
to
update
your
query,
so
I
have
an
another
deployment
here.
That's
already
running,
so,
if
I
go
there,
I'm
just
gonna
quickly
show
you
that
it
is
indeed
running
the
version.
B
I
tell
you,
it
runs
so
open
the
ui
here,
I'm
not
gonna
authenticate
now,
but
you
see
it
runs
version
three
for
free
right,
so
going
back
here.
What
I
want
to
do
is
updating
queer.
I
want
to
all
I
want
to
make
all
this
dance
appear
automatically.
So
the
way
I
do
this,
I
update
the
query
operator
and
I
say:
you're,
not
version
3,
4
you're,
now
version
3.5,
so
I
switch
the
operator
to
another
channel
which
is
like
channels
in
your
browser.
B
So
you
get
new
versions,
so
every
quay
version
has
a
channel
in
the
operator
in
order
to
upgrade.
I
change
the
channel
to
three
five
and
that
will
make
the
operating
life
cycle
manager
and
kubernetes
update
that
operator.
B
This
triggers
a
little
glitch
in
the
ui
where
it
will
take
like
a
couple
of
seconds
to
come
back,
but
you
will,
what
you
will
see
is
you
will
have
a
free
three
five
operator
in
a
couple
of
seconds
and
that
free
five
operator
automatically
starts
to
migrate.
All
the
crate
deployments
right.
So,
if
you
go
here,
you
can
see
the
crate
deployment
is
still
there.
B
The
ports
are
still
running,
but
they
are
starting
to
update
right.
So
this
is
your
operator
automatically
updating
your
quay.
In
order
in
that
order
that
I've
shown
you,
you
know
scale
down,
run
the
migration
scale
back
up.
I
just
had
a
single
port
because
nothing
is
going
on
in
the
system
right
now.
So
if
I
would
go
back
to
quay-
and
this
may
take
another
five
seconds
or
so
eventually,
I
would
see
a
free
five
down
there.
B
So
it's
still
not
ready,
still
updating
and
that's
probably
something
we
should
fix
new
operator
to
not
say
the
old
operator
is
gone
until
the
new
one.
B
Is
there,
but
that's
kind
of
the
in-between
state
that
you
that
you
have
to
accept
in
the
database
migration,
but
eventually
it
will
save
three
five
down
there
right
so
and
and
that's
happening
automatically
right
and
that
happens
automatically
for
all
your
customers
and
users
and
that's
how
you
get
less
support
calls
that's
how
you
make
people
run
into
less
bugs,
because
everything
is
managed
in
the
way
your
application
needs
to
be
managed
right.
So
I'm
not
going.
A
B
Wait
for
this
here
just
to
continue
and
come
to
an
end.
So
when
you
think
about
what
do
you
want.
D
B
You
have
these
two
choices.
You
also
have
other
choices,
but
let's
say
you
have
the
packaging
part
and
you
have
the
operator
route
right.
Packaging
is
very
low
effort,
as
you
have
seen,
it
literally
takes
one
command
with
that
maven
plugin
to
get
you
going
and
you
can
get
quite
quite
far
with
this
already
in
user
experience,
you.
B
Installer
breeze
and
you
can
also
do
simple,
updates
right,
so
that
is
very
low
effort
and
gives
you
gives
you
some
coverage
in
the
lifecycle
of
your
application.
So
you
have
a
good
consumption
experience
if
your
app
has
more
needs.
However,
right
if
it
it's
not
just
stateless,
if
it
has
this
kind
of
lifecycle
that
I've
shown
you
with
updates
and
reconfiguration
if
it
needs
sequencing,
ordering
orchestration
user
input
right
and
conditionals
you're
going
to
write
an
operator
and
that
initially
seems
like
a
much
higher
bar
to
meet
you
need
to.
B
Actually
you
know,
write
code,
you
know
you're
signing
up
for
maintaining
apis
and
compatibility
contracts.
So
in
order
to
do
what
helm
does
initially
it's
much
higher
effort,
but
eventually,
in
the
long
run,
if
your
application
has
those
needs-
and
you
want
to
provide
that
as
a
service
experience
that
we've
seen
before
or
you
want
to
automate
workflows
on
the
cluster,
then
the
operator
eventually
gets
you
all
the
way
there
right.
So
that
kind
of
is
some
guidance
on
how
to
you
know,
navigate
between
the
worlds.
C
B
A
B
So
meanwhile,
the
quay
has
updated
right,
so
it
took
it,
took
like
something
like
45
seconds
or
so
a
little
bit
to
a
demo,
but
eventually
succeeded
right
and
it's
doing
this
for
all
the
releases.
So
previously
it
has
been
a
pain
for
our
customers
to
do
this
because
they
needed
to
do
this
dance
themselves
and
now,
with
the
operator,
we're.
B
Any
complaints
about
this
anymore
right
wow,
so
so
so
that's
that's
something
that
you
can
get
out
of
that
ex
experience
right.
So
now
people
say
you
know.
When
do
I
use
what?
But
I
think
you
can
safely
say
when
you're
on
the
beginning
of
your
application,
and
you
don't
quite
know
how
it's
going
to
turn
out
and
how
much
it
actually
needs.
You
know
something
that
comes
just
fine
right
to
get
you
going
to
quickly
share
it
in
the
way
that
stefan
shared
the
application.
B
B
It
just
doesn't
have
any
more
logic
at
this
point,
so
that's
something
we
aim
to
do
and
allow
you
to
do
in
the
future,
where
you
will
just
be
able
to
reuse
your
existing
hand
chart
in
an
operator
to
which
you
then
add
additional
code
to
do
any
of
those
phase.
Three
and
phase
four
things
right
and
this
could
be
golden
code-
could
be
ansible
playbooks.
This
is
something
we
call
hybrid
operators,
and
this
is
something
we
plan
for
the
sdk
to
be
supporting
this
year.
B
It
allows
you
to
mix
and
match
your
existing
helm
charts,
so
your
investment
isn't
gone
there
to
a
operator
that
can
truly
do
these
more
complicated
things,
which
you
would
normally
ask
users
to
say:
oh
yeah,
don't
do
this
with
hell.
Do
these
five
cube,
cdl
commands
and
off
you
go
right,
that's
kind
of
what
we
are
planning
to
do
in
that
sense,
and
that
would
allow
you
to
do
to
use
best
of
both
worlds
right.
C
C
And
giving
the
best
of
all
the
worlds
like
the
simplicity
and
the
ease
of
access
of
helm
to
the
developers
is
also
key
for
the
adoption
and
the
adoption
of
your
cloud
native
automation
journey
as
well.
Right.
A
A
Wood
is
highly
recommended
content
right
if
you're
dealing
with
operators,
in
my
opinion,
that
book
kind
of
cracked,
my
brain
open
into
the
fact
that,
like
I
can
do
this
because
even
though
I'm
not
a
programmer,
I
know
ansible
and
I
can
make
you
know
a
whole
full-blown
operators
out
of
ansible
now
and
there's
some
even
built
into
openshift
that
are
written
in
ansible
and
that's
really
kind
of
like
heartwarming
to
me,
as
somebody
coming
from
the
op
side,
because
I
spent
years
using
ansible
and
now
coming
to
kubernetes
is
like.
A
D
Andrew
block
and
austin
dewey
that
most
of
you
know
wrote
that
one
and
then
the
helm
maintainers
also
have
a
book
out.
So
I
mean
between
the
two
of
them
and
then
all
the
other
resources
for
helm.
A
Yeah,
there's
a
lot
of
resources
available
out
there
if
you're
struggling,
feel
free
to
drop
in
on
our
discord
at
any
point
in
time,
ask
your
questions
there.
We
can
find
some
answers,
for
you
probably,
and
you
know
always
check
out
the
kubernetes
slack.
That's
a
great
place
to
go
look
for
answers
or
you
know,
find
like-minded
people
that
are
doing
similar
things
to
you.
Any
other
resources,
for
example,
that
we
want
to
like
mention.
A
B
We
have
these
two
pages
like
here
on
that
so
guys,
there's
ton
of
documentation
right,
there's,
also
a
lab
on
learn.openshift.com
also
for
operators.
This
is
really
cool
because
you
kind
of
get
access
to
to
know
open
your
cluster.
Just
in
your
browser,
nothing
else
needed
to
install.
So
I
really
like
those
interactive
labs
and
then
yeah
on
the
kubernetes
slack.
We
have
the
helm
channel.
B
A
C
A
A
A
So
thank
you
all.
Thank
you
for
tuning
in
coming
up
here
at
noon.
We're
going
to
be
talking
about
event,
driven
applications
with,
I
can't
even
say
the
name,
cogito,
serverless,
workflows
and
k
native,
so
yeah,
if
you're
interested
in
serverless
check
it
out
and
until
then
stay
safe
out
there.
Folks.
Thank
you.
Everybody.