►
Description
Helm3 Update for Operator Framework community
Joe Lanford (RedHat)
Operator Framework SIG June 18 2019
Presentation Notes: https://gist.github.com/dmueller2001/1c738ee6913da6c29100d4becd3ed95d
A
As
some
of
you
may
know,
the
operator
SDK
supports
scaffolding,
helm
operators.
So
right
now
the
underlying
libraries
that
the
EMA
operator
uses
is
all
based
on
come
too
so
we've
we,
we
noticed,
obviously
the
announcement
of
helm
three
from
the
helm
guys.
This
is
probably
back
in
May,
so
they
were
made
an
initial
release
of
their
first
alpha.
So
we've
started
taking
a
look
to
see
what
exactly
that
would
mean
just
in
general
for
helm
and
also
from
the
helm
operator.
A
So
they
remove
that
so
that
I
guess
Buster
had
basically
users
of
the
cluster
who
had
permissions
to
do
these
submitting.
Those
permissions
would
be
used
rather
than
tillers
permissions,
so
that
that
has
been
a
big
plus.
Then
another
thing
they've
done
is
changed
to
support
namespace
scoped
release
names.
So
in
the
past,
if
you
wanted
to
deploy
like
staging
namespace
in
a
production
namespace
and
use
the
same
name
for
your
release,
that
wasn't
possible.
So
that's
something
that's
been
fixed
in
home
3.
A
A
The
things
that
are
breaking
changes
that
will
cause
the
helm
operator
to
need
to
be
upgraded.
They
have
new
import
paths
for
their
go
libraries,
so
that's
just
a
minor
change.
They.
The
big
change,
is
the
there's
totally
new
rewritten
libraries
around
the
lifecycle,
like
the
release
life
lifecycle.
Events
like
doing
the
install
the
upgrade
the
uninstall,
so
there
will
be
a
pretty
big
during
their
from
the
hello
operator
perspective
to
support
Humphreys
lifecycle
events,
probably
less
related
to
the
helm
operator,
but
more
related
to
packaging
column,
charts.
A
So
they've
consolidated
requirements
tie
em
all
into
the
chart
gamma
file,
so
that's
part
of
like
that.
A
chart
metadata
the
requirements
well
I
think
it
kind
of
describes
the
dependencies
of
the
chart
like
what
other
charts
the
the
parent
chart
depends
on
and
that
kind
of
thing
I'm
such
a
generally
required
for
packaging
a
chart.
The
one
impact
that
might
have
on
the
helm
operator
is
when
we
so
there's
the
operator
SDK
new
dash
dash
home
chart
flag.
A
So
when
we
fetch
that
chart,
we
also
make
sure
that
we
fetch
all
the
dependencies,
so
that'll
be
a
change
and
how
that
piece
of
code
needs
to
work
and
then
the
other
change.
That
is
not
necessarily
breaking
change
for
us,
but
something
that
we
might
need
to
change
on
the
operator
side
is
that
the
release
name
is
now
art
by
default
like
when
you're
using
the
helm
CLI,
you
can
turn
that
off
on
the
fly.
A
So
far,
so
they've
introduced
chart
values,
validation
using
JSON,
schema,
so
I
think
that
will
be
built
into
the
helm.
The
chart
metadata
as
well
and
as
you
submit
values
via
the
CR
in
the
helm
operator,
will
be
able
to
actually
validate
the
values
before
we
actually
do.
The
rendering
of
the
of
the
release
manifest,
which
will
be
kind
of
a
nice
feature
in
terms
of
making
sure
that
what
you've
submitted
in
your
CR
is
valid,
and
potentially
we
can
look
at
this,
isn't
something
we've
gotten
to
yet.
A
But
we
could
potentially
look
at
including
that
JSON
schema
validation
as
part
of
an
admission,
validating
webhook,
which
would
be
pretty
cool
so
when
even
allow
you
to
create
the
CR
for
the
release
manifest
unless
that
validation
passes,
and
then
there's
also
this
new
concept
of
library
charts,
which
also
is
not
necessarily
directly
related
to
the
helm
operator.
But
the
idea
of
a
library
charge
is
a
way
to
use
shared
functionality
among
multiple
charts,
so
library
charts,
don't
define
release
resources,
but
they
can
define
like
shared
labels.
A
B
Another
quick
thing
on
the
on
the
chart,
values,
validation
and
we
had
a
bit
of
a
thread
going
there
on
the
group
about
what
a
validation
logic
can
be
generated.
Our
you
know
into
the
CR,
D
and
I
guess:
I
mean
wouldn't
be
possible
to
take
a
JSON
schema
and
kind
of
convert
it
to
an
open,
API
validation
schema
to
put
in
the
CR
D,
so
to
have
kind
of
that
schema
validation
even
outside
of
before
it
even
hits
home
yeah.
A
A
They're
also
planning,
at
least
talking
about
using
crts
for
the
release,
metadata
and
version
storage.
So
right
now
in
helm,
2
and
then
also
in
their
hell
3
alpha
they're,
using
secrets,
just
straight-up
kubernetes
secrets,
and
they
the
way
that
it
works.
Is
it
basically
encodes
the
entire
release
into
a
big
like
gzipped,
protobuf
and
then
stores
that
directly
is
like
basically
a
binary
base64
piece
of
data
and
the
release
secret.
A
We
haven't
been
able
to
try
it
out
with
how
this
would
look
in
elm
operator.
Right
now.
The
hell
operator
is
using
kind
of
a
customized
version
of
the
of
Helm's
really
storage.
So
we
would
probably
take
a
look
at
seeing
whether
we
could
use
to
do
a
similar
thing
for
if
they
switch
to
see,
are
these
for
their
back-end.
So
so,
luckily,
we're
able
to
basically
just
inherit
a
lot
what
the
hell
to
doing
for
the
release
storage.
So
the
idea
would
be
to
just
keep
doing
that.
A
Let's
see
so,
we
had
a
discussion
with
the
some
of
the
helm
guys
week
or
two
ago
around
some
of
the
thing,
basically
giving
pitching
them
like
here's.
What
the
helm
operator
is,
here's
some
of
what
our
ideas
are
and
and
one
of
the
ideas
that
we've
been
trying
to
figure
out
how
to
solve.
We've
solved
it
in
a
helm
operator,
but
there's
no
solution
for
this
in
the
helm.
Cli,
though
this
idea
of
like
fixing
a
release.
A
So
if
a
release
changes,
if
the
release,
resources
or
release
change
without
the
actual
release
being
changed
like
being
through
an
upgrade
right
now,
helm
doesn't
have
a
way
of
reconciling
those
two
things
and
making
sure
that
the
underlying
resources
they
in
sync,
with
the
deployed
release.
So
in
the
helm
operator,
we
basically
have
implemented
our
own
code.
That
does
this.
So
whenever
a
release
resource
changes,
we
reconcile
the
CR.
We
see
of
you
know
the
the
we
do
like
a
dry
run,
release
manifest.
A
If
that
hasn't
changed
from
the
actual
deployed
release,
then
everything's
good.
But
then
we
can
go
and
make
sure
that
we
basically
reapply
all
of
the
release,
manifest
resources
to
the
existing
release.
So
we
had
a
discussion
with
them
where
we're
talking
about
creating
a
plug-in
that
is
called
my
own
fix,
for
example,
that
could
basically
implement
that
same
logic
as
the
helm,
CLI
and
then
also
in
Helms
libraries,
so
the
benefit
to
us.
B
Get
the
benefit
of
don't
sorry
that
I
keep
interrupting.
This
is
a
really
important
way
because
I
mean
correct
me
if
I'm
wrong
here
and
then
there's
a
big
difference
between
elm
and
using
the
elm
operator
in
that
in
helm,
it's
kind
of
a
fire-and-forget
I
do
do
and
install,
and
then
you
can
do
an
upgrade.
But
if
anything
changes
behind
the
curtain
helmed,
it
doesn't
become
aware
of
it
and
doesn't
do
anything
about
it.
B
Right,
where's,
the
R
word
or
just
like
we
described
we'll,
watch
all
the
resources
resources
and
will
then
reconcile
as
needed
right
exactly
because
I
keep
saying
that's
a
big
big
advantage
of
having
an
operator
to
begin
with
that.
You
have
these
kind
of
this
kind
of
loop
right.
This
feedback
loop
that
helm
is
lacking.
Yes,.
A
Exactly
and-
and
it
will
change
that,
like
nope,
so
when
so,
what
we're
basically
pushing
is
this
seems
like
more
the
imperative
users
of
the
helm.
Cli
would
probably
be
pretty
interested
in
this
as
well
to
make
sure
maybe
they
could
run
helm
fix
on
some
cron
job,
whatever
it
is
to
make
sure
that
they're,
basically
getting
some
of
the
same
benefits
that
the
helm
operator
provides.
A
So
it
seems
like
it's
a
problem
that
that
users
of
both
the
helm
operator
and
the
Helen
CL
I
would
like
to
see
solved
and
the
helm
maintainer
said
the
same
thing.
So
the
plan
is
we
don't
want
to
impact
the
helm,
3
release
cycle.
So
the
plan
is
to
implement
this
as
a
plug-in
and
then
experiment
and
iterate
on
it.
A
You
know
make
sure
it
works
well
and
does
what
everyone
expects,
and
whenever
that
gets
to
a
point
of
maturity
that
he'll
maintain
as
are
comfortable,
then
we
could
introduce
that
as
a
built-in
supplement
there
yeah.
That
seems
like
there
was
a
lot
of
consensus
during
our
discussion
about
something
that
does
this
sort
of
thing.
A
So
so,
lastly,
I
kind
of
probably
already
mentioned
this
a
little
bit,
but
the
big
operator
impacts
are
the
import
paths
and
basically
having
to
re-implement
a
lot
of
the
helm
operator
reconciler
to
use
the
new
rewritten,
helm
libraries.
We
need
to
make
sure
that
we
need
to
consider
and
so
a
is
it
possible
and
B.
Should
we
maintain
backwards
compatibility
with
the
previous
versions
of
the
helm
operator
based
on
l2,
so
I
I
think
there
may
I
think
the
helm
version
3
is
making
a
pretty
good
number
of
backwards
compatibility
guarantees.
A
So
if
they
are
making
the
same
backwards
compatibility
guarantees,
then
I
think
we
should
be
able
to
as
well.
But
that's
something
we'll
have
to
kind
of
look
at
as
helm,
3
progresses
and
then
also
it's
hard.
It's
a
little
bit
harder
with
the
helm
operator
because
it'd
be
nice
to
be
able
to
basically
have
a
user
that
has
existing
customer
resources
for
a
previous
version
of
the
helm
operator
to
be
able
to
free
the
operator
without
having
to
recreate
their
existing
resources.
A
It's
something
that
we
expect
more
user
to
ask
for
since
right
now
the
helm
operator
doesn't
support
customizing
the
release
name
and
then
we're
gonna
like
so
we
we
also
have
this
other
kind
of
orthogonal
tasks
to
be
able
to
make
improvements
to
for
helm
operator
or
hybrid
operator
developers.
So
if
you're
not
sure
what
that
concept
is
that's
basically
enabling
operators
of
operator
developers
that
have
started
out
with
a
helm
operations
I
want
to
now
do
more
customizations
and
move
to
a
go
based
operator.
A
That
includes
a
lot
of
the
helm
operator,
reconcile
errs
and
functionality.
So,
right
now,
if
you
were
to
run
like
hell
migrate,
you
would
see
that
the
the
main
function
that
gets
generated
for
the
new
co
operator
that
uses
helm
basically
has
no
way
to
customize
anything.
So
we've
been
talking
about:
how
can
we
open
that
up
make
more
of
a
library
out
of
the
helm
operator
controller
and
then
giving
go
up
go
operate?
A
Basically,
these
hybrid
go
hello
operator
developers
the
ability
to
customize
more
things
about
their
helm
operators,
so
some
examples
of
that
would
be
so.
One
of
the
examples.
That's
actually
an
open
issue
right
now
in
our
github
is
I
want
to
basically
have
a
mapping
between
the
CR
deck
and
my
helm
values
so
right
now
we
basically
take
the
CR
spec
verbatim
and
put
that
directly
in
as
the
helm
values.
A
A
Basically,
I've
got
parent
charm
with
like
two
or
three
sub
charts,
and
they
all
need
like
one
value
to
be
in
four
different.
They
need
point
one
key,
let's
say
like
a
username
to
be
in
all
four
charts
in
this
and
different
that
you
use
different
names
for
that
that
value
that
make
sense
so
like
the
parent
chart
might
have
like
you
know,
database
name
and
some
of
the
sub
charts
might
have
like
you
know:
web
app,
dot,
database,
dot
name
and
that
kind
of
thing
so.
A
A
But
there's
been
users
that
have
said
can't
be
really
nice
if
I
can
run
my
own
custom
code
code
in
the
same
scenario,
which
would
make
the
helm
operator
a
lot
more
robust
in
terms
of
being
able
to
do
some
of
the
higher
level
operator.
Maturity
kind
of
things
that
the
ansible
and
go
operators
are
already
capable
of.
That
would
be
a
pretty
cool
thing
to
add
the
reason
I'm
talking
about
all
this
is
because
a
lot
of
this
will
change
depending
on
whether
we
do
it
in
hell,
2
or
M
3.
A
So
the
last
little
section
here,
there's
just
a
couple
of
issues
that
I
opened
in
the
helm,
Riko
about
things
that
I've
noticed
that
aren't
quite
supported
that
we
currently
are
able
to
do
well.
So
one
is
the
custom
rendering
engine
that's
supported
in
how
to
is
basically
not
is
is
not
supported
right
now
in
helm,
three
and
the
reason
we
use,
that
is
to
be
able
to
inject
owner
references
into
all
the
resources
that
are
created
from
like
in
the
chart
release
manifest.
A
So
that's
not
like
a
huge
deal,
because
we
still
have
this
finalizar
in
the
helm
operator
to
be
able
to
do
the
uninstall
process,
which
clears
things
out.
But
if
there's
something
that
goes
wrong
with
that
and
that
fails
for
some
reason
and
there's
a
bug
somehow
an
operator
that
prevents
the
failure
logic
to
occur.
There's
this
backup
of
having
it's
nice
to
have
a
garbage
collection,
enabled
for
all
these
things,
such
that
if
the
parent
CR
goes
away
somehow
all
the
underlying
resources
can
get
cleaned
out.
A
So
there's
a
discussion
going
on
about
whether
they'll
react
support
for
that
or
not
I.
Think
they
made
like
a
this
was
like
a
conscious
decision
that
they
made
so
I
think
they
need
to
think
about
reevaluating
that
decision,
and
maybe
they
will
maybe
they
won't
so
we'll
see
how
that
goes,
and
then
right
now,
there's
like
this
weird
situation
with
handling
values.
We're
like
we
have
to
write
values
out
to
a
file
and
then
load
them
back
in
using
the
CLI.
B
Guess
I'm
I'm
very
interested
in
there
and
where
you
talk
about
hybrid
operators
right
and-
and
we
can
take
that
offline-
maybe
in
the
Google
group-
chat
right
because
I'm
thinking
well,
we
started.
We
have
a
lot
of
hound
charts
right,
and
so
we
thought.
Ok,
we
didn't
start
with
the
helm
operator,
but
what
the
Helms
do
not
give
us
is
date
what
we
call
day
to
operation.
So
we
thought
okay
for
let's
just
say,
backup
and
restore
or
something
like
that,
so
we're
thinking.
B
Ok,
how
can
I
now
add
that
in
and
I
was
thinking,
it
should
be
relatively
easy
to
capture
it
out,
maybe
in
a
separate
CID
and
then
the
separate
controller,
but
then
add
to
the
same
operator
right
and
that
would
effectively
be
a
hybrid
operator
with
fairly
little
dependencies
between
the
two
controller,
so
to
speak.
One
could
be
home
based
on
the
helm
operator
and
one
could
be.
You
know,
written
and
go
from
scratch
or
written
in
whatever
other
language
right.
Is
there
anything
technically
that
would
make
that
hard
or
impossible
to
do.
No.
A
I,
don't
think
so,
I
think
you
could.
You
could
really
do
that
right
now,
if
you
wanted
to
the
like,
if
you
look
at
the
migrate
command,
if
your
unlike
helm
or
operator
STK
my
grade
and
an
existing
helm
project,
it'll
convert
your
product
to
a
go
project
and
then
you'll
get
like
this
main
file.
That
right
now
has
like
this
very
bare-bones.
A
Basically,
it
calls
like
helm,
dot
run.
If
you
go
and
look
at
that
home
run,
you
could
that's
basically
what
a
main
file
looks
like
for
a
normal
go
operator.
So
what
you
could
do
right
now,
in
fact,
is
take
that
take
the
contents
of
that
helm
doubt
run
and
put
it
in
your
own
main
dot
go
and
then
add
your
own
other
api's
and
controllers,
and
that
kind
of
thing
into
that
main
dot
go.
The
one
caution
I
would
have
is
right.
A
B
A
Yep,
that's
definitely
possible,
like
already
with
a
cooperator.
You
can
also
do
that
with
the
helm
operator.
Just
by
having
you
know,
multiple
charts,
but
so
far
I
haven't
heard
anyone
who's
been.
We
haven't
seen
any
issues
or
anything
for
people
who
have
combined
like
the
helm
operator
controller
with
like
their
own
custom
controller,
but
that's
definitely
possible.
You
just
have
to
go
to
a
little
bit
more
effort
to
get
all
the
code
working.
The
the
SDK
migrated
command
doesn't
make
that
super
easy
yet,
but
it
should
be
possible.
Okay,.
B
D
A
So
yes,
so
it
depends
on
what
you
mean,
but
it'll
you
can.
You
can
do
two
things
one
you
can
have
a
single
operator.
You
have
multiple.
If
you
look
at
the
watches
die
and
while
filing
its
grid,
you
can
basically
add
multiple
charts,
like
top-level
charts
into
the
helm,
charts
directory
and
then
define
multiple
watches
and
the
washes
dll
file.
So
that's
if
you
have
like
multiple
CR
DS
that
you
want
to
define,
so
that's
supported.
A
D
A
Know
so,
in
the
first
scenario
you'd
have
a
separate
each
chart
would
have
its
own
D
are
associated
with
it.
This
has
come
up
at
least
once
or
twice
as
an
issue
and
our
github
I
think
so
you
could
probably
search
for
it,
and
I
can
try.
Search
for
to
the
suggestion
I
made
was
basically
if
you
wanted
to
do
something
like
that,
you
could
basically
have
one
chart
that
basically
uses
all
of
the
other
charts
that
you
wanted
to
use
as
a
parent
chart
and
then
just
use
one
CR
via
that
parent
chart.
A
Yes,
I
think
that's
the
kind
of
the
use
case.
I
was
describing
for
the
mapping
a
CR
set
of
values
to
like
a
whole
bunch
of
different
chart
values,
and
that's
one
of
the
kind
of
caveats
that
I
was
that
I
would
mention
is,
like
you
know.
If
you
have
so,
the
way
I
would
suggest
is
like
okay,
you're
gonna
have
one
parent
chart
that
has
a
bunch
of
Sun
charts
for
all
the
actual
things
that
you
want
to
deploy
under
that
CR.
A
The
problem
with
that
is
that
if
each
of
those
sub
charts
has
a
different
value
key
for
like
a
value
that
you
want
to
define
once
in
your
CR,
like
that's,
not
possible
right
now,
so
you
have
to
define
it
in
multiple
places
for
each
sub
chart
and
that's
not
a
great
user
experience
and
it's
not
easy
to
validate,
and
that
kind
of
thing.
So
that's
definitely
one
of
the
use
cases
for
the
the
helmet
hybrid
operator
and
that's
not
even
like
right
now,
I'd,
be
it's
not
really
even
supported.
A
E
All
right,
then,
I
think
we're
close
to
wrapping
up
here.
I
just
want
to
be
respectful
of
people's
times.
I
was
going
to
mention
one
other
thing
in
the
notes.
You'll
see
I'm,
trying
to
arrange
at
Helm's
summit
in
Amsterdam
to
do
a
helm
operator,
hands-on
work
up
and
I
was
wondering
if
anyone
else
on
this
call
was
planning
on
going
to
helm
summit
or
I
had
submitted
talks
to
tell
some
it,
but
we
could
post
and
have
a
few
more
bodies
in
a
room
for
the
hands-on
workshop.
B
E
Okay,
great
Andre,
so
I'll
reach
out
to
you
I'm
at
Doren
who's
on
the
call,
as
well
as
usually
the
person
I
rope
into
doing
the
teaching
and
I
think
Daniel
Messier
also
submitted
a
talk
or
two,
so
hopefully
we
can
bring
more
people
up
to
speed
and
on
board
with
the
helm
operator
work
thanks,
Joe
for
the
update
and
I'm
looking
to
see
the
our
next
meeting
will
be
the
third
Tuesday
in
in
July.
So
if
you
have
a.
E
C
Thanks
everyone
for
joining
us
at
our
new
time,
we're
gonna
try
to
get
a
google
invite
sent
out
to
the
entire
group.
We
ran
some
issues
and
I
saw
Google.
Calendar
was
down
this
morning,
so
it
wouldn't
helped.
But
hopefully
this
time
works
out
for
everybody
and
we'll
get
some
more
participation
from
folks
where
this
typically
would
have
been
their
Friday
evening
now,
we'll
be
in
the
middle
of
their
week
at
least
and.
E
E
All
right
check
out
the
helm
user
guide
in
our
github
all
right.
Thank
you.
Everybody
for
joining
I'm,
gonna,
post,
the
rule
recording
to
the
playlist
and
YouTube
and
I
will
snip
up
the
different
updates
into
little
short
ones
for
other
people
to
read
to
so
after
that
in
our
YouTube.
That's
the
end
of
our
hour.
Take
care
guys
thanks.