►
Description
Chairs: Diane Mueller & Rob Szumski
Updates on:
OperatorHub.io - Daniel Messer
Python Operator SDK - Shawn Hurley
Helm 3 Update - Joe Lanford
Meeting notes: https://gist.github.com/dmueller2001/85f0890cb6cc528f458842e52993ca71
A
A
B
A
B
B
Okay,
all
right
so
for
those
of
you
who
don't
know
me
on
a
call
and
those
who
see
the
recording
later
and
Danny,
Messer
I'm
a
product
manager
in
the
old
shift
business
unit
at
Red,
Hat
and
I'm,
looking
over
parts
of
the
operator
framework,
specifically
the
SDK
and
the
operator
lifecycle
manager,
so
also
as
a
little
side.
Project
of
mine
I
do
see
and
look
after
operator
hub
that
IO,
which
is
our
community
registry
for
operators
targeting
the
water
cabinet,
is
audience
and
we've
seen
quite
some
traction.
B
Actually,
since
we
flaunt
this
just
as
of
today,
we
actually
crossed
50
operators
on
that
particular
website,
which
is
pretty
amazing,
and
we
got
a
couple
of
new
additions
which
I'm
gonna
share
with
you
here
in
a
second.
We
are
also
going
to
talk
about
a
couple
of
new
features
that
we
have
already
released
on
the
side
and
that
we
are
planning
to
publish
in
the
next
one
or
two
months,
which
should
hopefully
make
the
process
of
packaging.
Your
operator
should
you've
already
started
to
write
one
or
like
updating
your
system
operate
on
much
easier.
B
Parts
of
the
slide
did
not
try
any
loading
or
show
anyway.
Sometimes
Google
doesn't
like
me,
so
yeah,
no
icons
for
us
today,
that's
kind
of
weird,
but
that
totally
looked
different
in
Google
slides
when
I
edited
it,
but
we
can
just
take
a
look
at
the
site
itself
right.
So
now
we
have.
We
have
a
couple
of
new
interesting
additions
from
across
the
board.
One,
a
couple
of
ones
that
I
wanted
to
pick
out.
Not
all
of
them
is
definitely
Luke.
Luke
is
like
an
overarching
storage
project
on
kubernetes.
B
So
that's
basically
running
your
software-defined
storage
on
kubernetes
itself,
and
there
are
multiple
flavors.
If
you
will,
one
of
which
is,
and
probably
the
most
widely
known
so
far
is
Rufus
F.
So
if
ever
group
self
to
operate
a
hub,
that
IO
has
been
packaged
and
has
been
tested
with
or
operating,
lifecycle
manager
and
mini
cube
and
various
other
kubernetes
flavors,
and
you
also
see
next
to
it,
root
H
of
S,
which
is
another
flavor
of
rope.
B
Right
of
having
the
all
the
logic
that
you
were,
that
you
are
required
to
operate,
such
a
platform
in
a
consistent
and
yeah
production
grade
fashion
has
has
that
built
in
so
for
some
who
have
maybe
been
around
a
bit
longer.
You
probably
have
heard
around
container
native
storage
in
the
freedom
for
free
top,
five
time
frame
where
we
had
this
like
little
component
called
heck
Eddie.
That
would
usually
sit
outside
on.
Sometimes
inside
of
the
cursor,
and
would
you
know
do
that?
B
Do
that
sort
for
reasoning
for
you,
given
that
you
had
already
set
up
a
in
this
case,
cluster
deployment
right,
and
that
was
basically
what
it
did.
It
didn't
quite
look
after
the
lifecycle
of
the
cluster
installation
itself,
so
you
still
need
to
know.
You
know
how
cluster
works
and
you
know
all
the
kings
and
details
around
how
to
do
that
on
kubernetes
and
openshift
and
heck
any
would
be
there
to
basically
provide
an
API
for
cluster.
B
Now
ruk
completes
that
picture
in
a
much
more
realistic
sense
and
basically
provides
storage,
lifecycle,
management
and
storage
management
on
the
on
the
platform,
and
it
does
it
in
a
generic
enough
way
so
that
it's
not
mostly
it's
not
only
safe.
Who
is
able
to
use,
make
use
of
that,
but
also
HFS,
which
is
another
highly
efficient,
distributed
storage
layer
on
kubernetes.
We
have
another
storage
solution.
B
Uc
storage
is
kind
of
a
reoccurring
theme
here
in
there,
which
is
port
works
which,
which
has
been
out
there
for
quite
a
while,
but
nowadays
at
least
a
operator
and
they've
actually
also
tested
and
certified
it
with
with
OpenShift
and
as
part
of
that,
they
also
provided
an
upstream
version
of
that
for
penguin
and
its
usage.
So
port
works
very
similar
to
to
Brooks
F.
Basically,
containerized
is
the
storage.
B
Another
thing
there
point
out
is
is
down
here:
it's
a
spinning
core
operator,
bye-bye
option
X.
So
there
are
there's
actually
an
existing
spinning
operator.
That's
the
opposite
mixed
version
that
provides
some
added
value
and
some
additional
features
that
you
don't
get
with
the
you
know
open
the
distribution
of
spinnaker
itself,
but
spinning
is
quite
a
popular
CSD
or
a
specifically
seedy
solution
for
for
kubernetes,
because
it
has
been
written
with
kubernetes
in
mind.
So
it's
very
easy
to
you
know:
implement
continuous
delivery
on
on
the
cluster.
B
With
that
and
with
the
offering
you
now
have
the
ability
to
run
the
spinning
or
operator
on
the
cluster
itself,
and
you
don't
need
to
be
an
expert
in
how
to
set
up
spinnaker,
which
can
be
quite
involved,
especially
given
all
the
configuration
options
that
you
are
allowed
to
choose
from.
You
would
just
use
the
operator
to
do
that
and
you
get
a
fully
featured.
Could
this
delivery
version
a
continuous
delivery
solution
on
kubernetes,
which
would
allow
you
to
do
things
like
cannery
deployments
and
automated
cannery
deployment
so
pretty
exciting?
B
One
thing
we
were
particularly
proud
of
because
we
work
together
on
this
is
still
Verdes
of
the
elastic
cloud
operator
on
both
openshift
and
kubernetes.
So
you
are
now
able
to
basically
get
your
elasticsearch
and
Cabana
instances
out
as
a
matter
of
just
you
know,
creating
another
object,
so
the
elasticsearch
or
programs.
Now
one
operator
hop
that
I/o
as
well,
is
packaged
and
ready
to
go
wherever
operate,
a
lifecycle
manager
is
as
present,
there
are
some
more
exciting
ones
that
I
didn't
even
know
existed
before.
B
So
there
is
something
called
FF
DL,
which
is
an
operator
done
by
IBM,
which
is
a
fabric
for
deep
learning.
So
that's
something
that
I've
been
meaning
to
try
for
some
time
now,
but
it
didn't
quite
find
the
slots
in
light
and
I
had
my
dad
looks
very
promising
on
how
to
orchestrate
and
install
FF
DL
on
kubernetes.
So
that's
like
a
collection
of
deep
learning
frameworks
right
there
for
you
to
leverage
kubernetes
ability
to
you
know
quickly
schedule
work.
B
Lots
of
critics
cannot
work
notes
as
part
of
the
Met
model
training
and
then
also
later
on.
Serving
one
thing
that
was
featured
at
Q
corn
in
its
own
session
was
actually
aqua
security.
So
if
you
ever
wanted
to,
like
you
know,
do
a
little
pen
testing
on
your
own
cluster.
So
don't
do
this
with
your
coworkers
cluster
or
your
production
cluster.
But
if
you
wanted
to
do
pen
testing
against
the
kubernetes
cluster
and
test
it
against
a
variety
of
known
best
practices
and
and.
B
Security
precautions,
you
could
do
that
so
aqua
basically
gives
you
a
set
of
tests
that
it
will
run
against
your
cluster
and
it
will
check
for
API
availability.
You
know
unsecured
end
points
on
authenticated,
endpoints,
missing,
SSL
encryption,
all
these
kind
of
things
and
yeah
it's
it's
available
as
an
operator,
and
you
can
quickly
install
that
on
your
cluster
and
get
a
report
of
which
kind
of
security
vulnerabilities
or
like
missing
best
practices
or
the
same
were
found
on
your
cluster.
So
pretty
exciting.
B
I
think
the
last
one
I
wanted
to
quickly
highlight
was
also
stream,
Z,
Kafka
I.
Think
since
we
last
spoke,
it
was
already
in
the
queue
and
was
already
available
on
auto-ship,
but
not
on
operator
half
so
stream.
Z
is
an
opinionated
way
to
run
Kafka
clusters
on
kubernetes
or
opensci,
and
that
operator
basically
gives
you
the
plain,
vanilla,
patchy
version
available
on
your
site
or
on
your
on
your
cluster
and
as
you
can
see,
you
can
be
pretty
granular
of
the
resources
that
you
wanted
to
control
right.
B
This
is
what
a
wanted
to
highlight
as
stuff
that
has
come
in
we
either
recently
or
some
time
ago.
Already.
Fortunately,
we
have
seen
a
quite
an
amount
of
uptake
in
terms
of
two
submissions.
On
the
other
hand,
we
weren't
quite
always
able
to
you,
know,
process
and
review
them
in
time,
which
is
why
we
spent
some
effort
actually
on
streamlining
this
particular
process
a
little
bit.
B
So
if
you
now
open
a
pull
request
on
your
on
operate
up
at
I/o,
you
would
actually
get
to
see
like
a
little
checklist
of
things
that
you
should
consider
and
think
about
and
check
off
before
you
kind
of
submit
your
PR.
So
these
are
basically
general
things
of
like
reading
our
contribution
guidelines,
which
we
have
now
put
in
place
where
we
basically
explain
to
you
where
to
contribute.
B
C
I
ask
a
quick
question
on
this
is
Andre,
so
one
thing
we
were
discussing
actually
just
this
morning
is
what,
if
there's
just
document
changes.
So
what
if
we
find
a
typo
in
the
description
or
something
want
to
fix
that
real
quick
I
mean
that
would
that
run
through
very
quickly,
I
guess,
because
that
wouldn't
necessarily
require
a
retest
of
any
of
the
code,
because
the
code
wouldn't
actually
changes
just
documentation.
Oh
for.
B
Sure
yeah,
we
would
loved
you
it
for
you
to
find
PRS
against
any.
You
know
things
that
you
find
missing
or
like
wrong
there
so
yeah.
Definitely
this
is
you
know
by
no
means
just
owned
by
a
couple
of
people.
This
is
really
out
there
for
the
community
to
embrace
and
to
to
refine.
So
if
you
find
stuff,
you
know
just
give
us
a
PR
I.
Look
at
the
PR
list
daily
on
the
operator.
B
Tracker
team
looks
at
the
par
this
daily
and
if
you
see
a
doc
enhancement,
that's
very
much
lying
in
fruit,
usually
so
yeah,
but
all
means
keep
those
coming.
Okay
and
yeah
use
this
checklist.
If
you
want
to
submit
or
update
you
operator,
just
to
be
sure
that
you
have
like
I'm
done
for
all
the
things
we
do
all
tests,
we
test
all
this
as
part
of
the
CI,
so
you
might
have
seen
some
changes
in
the
CI.
Actually,
that
is
executing
now
much
much
more
tests,
so
you
see
here
does
actually
no.
B
B
Rigorous
set
of
checks
and
in
place
that
will
basically
you
know,
do
the
linting
make
sure
you're
not
colliding
with
any
kind
of
you
know,
operators
that
are
already
in
your
open
ship
catalog
they
will
deploy
before
all
them.
They
will
check
your
metadata.
They
will
check
that
you
haven't
modified
more
than
one
operator
at
the
time
and
as
part
of
the
new
PR
guidelines.
B
You
know
right
all
the
scripting
logic,
to
figure
that
out
one
thing:
we've
actually
added
to
decide
itself
and
to
help
you
a
little
bit
with
you
know
did
I
include
all
the
things
that
I
wanted
to
include
is.
If
you
go
here
on
the
side,
the
upper
right
hand
corner
and
you
go
to
the
contribute
button.
There's
now
a
new
menu
item
that
says
preview,
your
operator
and
what
we
mean
by
that
is.
You
can
basically
upload
your
CSV
and
you
would
basically
see
how
these
how
this
will
pop
up
at
the
side.
B
So
I
can
just
do
that
here:
real
quick
and
upload.
Yes,
rogue
chef
CSV
there
and
you
would
see
how
that
would
look
on
the
side
right.
You
see
that
tile
view
here.
The
list
view
here
and
you
would
also
see
how
the
descriptor
page
would
be
rendered
right.
So
that's
a
nice
way
to
kind
of
spot
any
kind
of
markdown
errors
or
anything
that
you
have
forgotten
in
here,
as
well
as
if
and
how
your
custom
business
definitions
pop
up.
B
If
they
have
proper
examples,
so
that's
not
only
valuable
for
pretty
hot
that
I
know,
but
can
also
be
used
for
shift,
because
the
operator
hub
in
OPA
shirome
shift
is
visually
very
close
to
to
what
we
have
here
on
operator
after
I/o.
It
doesn't
display
all
the
data
but
displays
most
of
it.
So
you
said
as
a
low-hanging
fruit
as
a
check
to
see
if
your
CSV
is
correctly,
this
will
also
yield
any
kind
of
beard:
llamo,
gacho's,
formatting
errors,
indent
errors
and
whatnot
right.
B
B
Another
thing
that
we
have
starting
to
put
in
place
and
are
looking
to
goodies
fairly
soon
as
a
baton
would
really
love
your
feedback
on.
This
is
a
way
to
visually
edit,
your
CSV,
basically
starting
from
scratch
right.
So
we
all
know
that
you
know
coming
up
with
the
CSV
can
be
a
little
bit
of
a
steep
hill,
even
with
the
examples,
because
there
are
so
many
feels
like,
and
you
probably
already
have.
Your
existing
kubernetes
manifests
like
deployments.
Service
accounts
are
back
and
so
on.
B
So
what
we
can
do
in
a
and
the
next
release
of
operator,
half
that
IO
is
basically
on
going
to
contribute
menu
again
and
there's
another
item
that
says
package
to
operator
and
that
will
give
you
a
visual,
a
visual
CSV
editor.
So
you've
seen
I've
already
uploaded
some
stuff
here,
so
we
can
kind
of
start
from
scratch
and
yeah
bear
with
me.
This
is
a
beta
version
right,
so
that
might
just
as
well
be
back
here,
but
one
thing
you
can
do
here
is
basically
upload
your
existing
CSV.
B
Let's
take
this
one
and
it
would
start
to
pre
populate
all
the
fields
in
the
editor
which
are
down
here.
So
we
basically
walk
you
through
all
the
steps
to
create
a
complete
and
high-quality
CSV,
and
this,
in
this
view,
I
and
there's
validation
on
each
step
as
you
go.
So
you
see,
for
instance,
here
is
the
cluster
service
version
of
Luke's
F
referenced
a
couple
of
CDs
right
and
in
order
to
you
know,
build
a
valid
bundle
that
you
can
then
submit
as
a
TR.
We
would
also
need
to
see
our
D
files
right.
B
So
that's
already
telling
me
I'm
missing
something
so
I
can
basically
upload
that
right
away,
don't
need
to
upload
this
package
mo
or
the
old
o
CSV,
and
you
see
it.
It
validates
that
automatically
and
it
basically
also
pre-populates
ID
editor
with
that.
So
I
can
now
start
to
go
into
the
editor,
look
at
all
the
things
and
that
I
can
input
there.
Maybe
I
want
to
change
this
play.
Name
change
the
description,
the
one-liner,
as
well
as
the
more
elaborate
description
on
the
main
page.
So
you
see
here
we
have
a
markdown
editor.
B
We
give
you
a
visual
Lee
which
previews
just
to
make
sure
you
are.
You
have
two
right
tools
at
hand
to
really
make
sure
operator
look
good
on
both
operator
house,
and
all
of
this
contains
validation
right.
So
it's
it's
much
harder
to
to
do
mistakes
here
or
to
miss
something
you
have
visual
inputs
for
almost
every
aspect
of
the
CSV.
You
know
you
can
set
your
capabilities
level.
You
get
an
explanation
of
what
it
is.
B
So
I
personally
find
this
much
more
satisfying,
much
more
guiding
than
you
know,
sitting
in
front
of
the
Apple
editor
and
trying
to
think
of
anything
that
I
could
add
there,
and
you
know
when
you're
done
with
this
kind
of
stuff,
you
always
click
all
set
with
operator
metadata,
and
then
this
is
kind
of
the
first
section
that
you've
completed
and
as
such
you
would
walk
through
the
rest
of
the
editor.
So
here
we
would
ask
you
to
specify
all
the
CR
DS
that
you
operator
owns.
You
would
be
able
to.
B
You
know
this
tour
series
edit.
Those
mom
give
us
the
list
of
resources
that
are
behind,
so
we
are
able
to
populate
DUI
in
overshift
correctly.
With
this,
you
would
be
able
to
provide
us
with
examples
or
even
spec
descriptors,
to
make
a
custom
UI
for
your
operator.
So
all
of
this
is
now
much
better
documented
in
a
much
more
centralized
place
and
also
always
paired
with
a
visual
preview
of
what
you're
gonna
get
when
you
submit
this.
So
if
I,
for
instance,
miss
something
here
right,
let's
say
I'm
busy,
not
specifying
a
name.
B
That
would
be
an
error
right
and,
if
I,
if
I,
try
to
run
with
that,
that
would
also
be
you
know,
kind
of
sticky
in
the
editor,
and
it
would
stubbornly
refuse
to
generate
about
a
lot
of
this.
So
hopefully
it's
much
easier
and
much
more
straightforward
in
the
future
to
create
a
vetted
CSV
bundle
and
basically
package
you
already
existing
operator.
Now
we
don't
want
you
to
start
from
scratch,
though
right
and
when
you
don't
have
a
CSV.
So
what
you're
going
to
do
then?
B
So
one
thing
we
are
currently
working
on
is
to
make
this
upload
feature
of
the
editor
also
process.
Regular
kubernetes
comments
rolls
go
binding
service
accounts
and
and
and
CR
DS,
and
we
do.
It
actually
already
supports
your
DS,
but
what
we
really
want
to
do
is
you
want
to
take
these
standard
manifest
herbs?
Probably
every
operator
developer
has
already
because
they
tested
it
on
their
local
cluster
and
also
the
standard
manifests
that
the
SDK
will
output
and
we
will
convert
as
much
of
that
as
possible
into
a
CSV.
B
B
This
is
a
fully
fledged
amble
editor,
so
this
will
contain
syntax,
highlighting
syntax
check
so
hopefully
much
harder
to
do
too
to
have
arrows
and
in
this
is
V
and
yeah.
That's
that's
pretty
much.
What
we're
working
on
right
now
and
hopefully
be
able
to
release
that
pretty
soon
as
a
beta
and
yeah
keep
Q
keep
being
tuned
in
for
that
I
think.
That's
all
I
had
any
any
questions
so
far.
A
D
D
What
we
found
is
a
project
by
a
different
company
and
team
called
Kop,
Kop
F,
and
this
project
seems
really
promising
and
we're
looking
at
you
using
kind
of
the
work
that
they've
put
in,
do
leverage
it
and
to
make
that
a
first-class
to
the
Sun
so
we're
currently
in
talked
with
them
and
we're
starting
down
that
path.
But
to
get
started
on
on
that.
B
What
I,
personally
like
about
coffe
quite
a
bit,
is
you
know
the
simplicity
that
introduces
it's
it's
basically,
a
single
decorator
that
you,
you
know
put
above
your
function,
and
that
makes
the
connection
to
your
CD
and
then
and
basically
scaffolds
enough
code,
so
that
your
function
is
executed.
Whenever
that
events
that
you
described
in
the
decorator
appear.
So
it's
it's
very
slick
and
a
very
elegant
way
to
basically,
you
know,
write
custom
code
in
an
operator.
D
Know
that
the
team
that
made
the
library
they
created
a
couple
of
internal
ones
themselves,
I,
don't
think
anything
has
been
published
externally
and
I.
Don't
know
about
anybody
else.
Writing
anything
right.
You
had
to
basically
build
out
the
framework
like
they
end
up
doing.
If
you
wanted
to
write
one
in
Python
today,
they've
come
challenging
with
the
I
ain't
coming
from
kubernetes,
for
lots
of
different
reasons.
E
A
E
B
A
F
E
F
F
A
E
So,
as
some
of
you
may
know,
the
operator
SDK
supports
scaffolding,
home
operators.
So
right
now
the
underlying
libraries
that
the
elm
operator
uses
is
all
based
on
come
to
so
we've
we,
we
noticed,
obviously
the
announcement
of
helm
3
from
the
home
guys
this
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.
E
So
they
remove
that
so
that
I
guess
cluster,
add
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
l3.
E
E
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
library.
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
of
insulin
like
doing
the
install
the
upgrade
the
uninstall.
E
So
there
will
be
a
pretty
big
refactoring
there
from
the
helm
operator
perspective
to
support
helm
threes,
life
cycle
events,
probably
less
related
to
the
helm
operator,
but
more
related
to
packaging
column,
charts,
so
they've,
consolidated
requirements
tie
em
all
into
the
chart
Campbell
file.
So
that's
part
of
like
that.
A
chart
metadata
the
requirements,
DM
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.
E
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.
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
our
default
like
when
you're
using
the
helm,
CLI.
E
E
So
far,
so
they've
introduced
chart
values,
validation
using
JSON,
schema,
so
I
think
that'll
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.
E
But
we
could
potentially
look
at
including
that
JSON
schema
validation
as
part
of
an
admission,
validating
webhook,
which
would
be
pretty
cool,
so
would
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.
C
Quick
thing
on
the
on
the
chart,
values,
validation
and
we
had
a
bit
of
a
thread
going
there
on
the
group.
Google
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
C
or
D
so
to
have
kind
of
that
schema
validation
even
outside
of
before
it
even
hits
home
yeah.
E
E
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
I?
E
We
haven't
been
able
to
try
it
out
with
how
this
would
look
in
the
helm
operator
right
now.
The
how
the
two
operator
is
using
kind
of
a
customized
version
of
the
of
Helm's
really
storage.
So
we
we
probably
take
a
look
at
seeing
whether
we
could
use
to
do
a
similar
thing
for
if
they
switch
to
see
our
DS
for
their
back
end.
So
so,
luckily,
we
were
able
to
basically
just
inherit
a
lot
of
what
the
hell
guys
are
doing
for
the
release
storage.
So
the
idea
would
be
to
just
keep
doing
that.
E
Let's
see
so
we
had
a
discussion
with
the
some
of
the
home
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.
So
this
idea
of
like
fixing
a
release.
E
So
if
a
release
changes,
if
the
release,
resources
or
release
change
without
the
actual
or
at
least
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
deploy
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.
E
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.
We're
talking
about
creating
a
plugin
that
is
called
like
home,
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.
C
We
get
the
benefit
so
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
did
do
an
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.
C
Right,
where's,
the
operator
just
like
we
described
we'll,
watch
all
the
resources,
resources
and
we'll
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,.
E
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
home
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,
though
it
seems
like
it's
a
problem
that
that
users
of
both
hello
operator
and
the
Helen
CL
I
would
like
to
see
salt
and
the
hell.
E
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.
You
know
make
sure
it
works
well
and
does
what
everyone
expects,
and
whenever
that
gets
to
a
point
of
maturity
that
the
helm
maintainer
is
are
comfortable.
Then
we
could
introduce
that
as
a
built-in
sucker
yeah.
That
seems
like
there
was
a
lot
of
consensus
during
our
discussion
about
something.
E
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.
E
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
l3
progresses
and
then
also
it's
hard.
It's
a
little
bit
harder
with
the
rep
of
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.
So
there's
this
migration
step
that
we
need
to
happen
potentially.
E
So
that's
something
we'll
have
to
look
at
when
we
make
the
upgrade
from
l2
2
&
3
for
the
helm
operator,
like
I,
said.
We
need
to
consider
the
release
name
configurability
so
because
some
3
now
also
require
at
least
name
and
B.
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
also
have
this
other
kind
of
orthogonal
tasks
to
be
able
to
make
improvements
to
for
helm
operator
or
hybrid
operator
developers.
E
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.
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.
E
How
can
we
open
that
up
make
more
of
a
library
out
of
the
helm,
operator
controller
and
then
giving
go
up
cooperate?
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.
E
So
there's
a
question
like
can
I
have
like
a
mapping
function
that
converts
my
CR
spec,
do
a
separate
set
of
held
values
and
kind
of
a
use
case.
There
is
I've
got
three
different
charts
that
I
want
to
create.
Basically,
I've
got
parent
charm
with
like
two
or
three
sub
charts,
and
they
all
need
like
one
value
to
be
in
for
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.
E
That
makes
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
that
it's
basically
a
way
to
make
it
easy
to
use
just
one
value
that
gets
propagated
through
all
the
different
charts
and
then
in
the
way
that
it
makes
sense
for
that
value.
So
that's
an
example
of
why
we
would
want
to
improve
the
helm
hybrid
operator
experience.
E
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.
E
So
the
last
little
section
here,
there's
just
a
couple
of
issues
that
I
opened
in
the
helm,
reco
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,
3
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.
E
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
on
the
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.
E
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
where,
like
we
have
to
write
values
out
to
a
file
and
then
load
them
back
in
using
the
CLI.
C
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've
been
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
ok
for
let's
just
say,
backup
and
restore
or
something
like
that,
so
we're
thinking.
C
Ok,
how
can
I
now
add
that
in
and
I
was
thinking,
it
should
be
relatively
easy
to
capture
that
may
be
in
a
separate
CID
and
in
a
separate
controller,
but
then
and
to
the
same
operator
right
and
that
would
effectively
be
a
hybrid
operator
with
fairly
little
dependencies
between
the
two
controllers,
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.
E
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
will
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.
E
Basically,
it
calls
like
helmed
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,
dot
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.
E
C
E
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.
Here's
been,
we
haven't,
seen
any
issues
or
anything
for
people
who
combine
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
SDK
migrate
command
doesn't
make
that
super
easy
yet,
but
it
should
be
possible.
Okay,.
G
E
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
watch's
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
die
animal
file.
So
that's
if
you
have
like
multiple
CR
DS
that
you
want
to
define.
E
G
E
E
The
suggestion
I
made
was
basically,
if
you
wanted
to
do
something
like
that,
you
can
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.
There
are
some
gotchas
and
caveats
with
that,
but
depending
on
how
the
basically,
depending
on
your
use
case,
like
that's
a
way
to
do
that,.
E
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.
E
The
problem
with
that
is
that
if
each
of
those
sub
charts
has
a
different
value,
key
more
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
Helmand
hybrid
operator
and
that's
not
even
like
right
now,
I'd,
be
it's
not
really
even
supported.
E
E
A
All
right,
then,
I
think
we're
close
to
wrapping
up
here.
I
just
want
to
be
respectful
of
people's
times.
I
was
gonna
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.
C
A
Okay,
great
Andre,
so
I'll
reach
out
to
you,
Matt
Doran
who's
on
the
call
as
well
as
is
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.
Our
next
meeting
will
be
the
third
Tuesday
in
in
July.
So
if
you
have
a.
A
F
Thank
someone
for
joining
us
at
our
new
time.
We're
gonna
try
to
do
get
a
Google
invites
and
out
to
the
our
group.
We
ran
into
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.
A
A
All
right
check
out
the
helm
user
guide
in
our
github.
Alright,
thank
you.
Everybody
for
joining
I'm,
gonna
post,
the
full
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
look
for
that
in
our
YouTube
and
that's
the
end
of
our
hour.
Take
care
guys
thanks.