►
From YouTube: Deep Dive: Helm - Matt Butcher & Adam Reese, Microsoft The Helm Deep Dive will have two parts.
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Deep Dive: Helm - Matt Butcher & Adam Reese, Microsoft The Helm Deep Dive will have two parts.
The first half will cover the status of Helm 3, with focus on the new security model, changes to charts, federated repositories, and the Helm core library. We will talk about the impact on the user but also cover the internal architecture. The second half will be a working session where Helm maintainers and contributors can come together to discuss issues that benefit from face to face conversations.
To learn more: https://sched.co/Gre4
A
A
So
what
we're
gonna
cover
a
lot
of
material
kind
of
very
quickly
upfront
and
then
we're
gonna,
switch
and
kind
of
cover,
some
of
the
helm
three
stuff
in
detail,
and
then
at
the
end
we
have
plenty
of
time
reserved
for
are
we
officially
calling
just
QA
QA
got
a
whole
bunch
of
core
maintainer
z'
heckling
us
from
the
front
row.
So
if
anything
flies
up
from
the
front
row,
please
don't
follow
suit,
just
let
them
feel
awkward
and
alone
alright.
So
so,
let's
start
out
by
just
talking
about
the
helm
organization
as
a
whole.
A
So
early
this
year,
helm
was
promoted
out
of
the
kubernetes
project
and
up
into
a
top-level
CN
CF
organization.
Brian
grant
was
our
was
our
kind
of
mentor
through
that
whole
process.
Everything
went
very
very
well
and
we
were
very
excited
to
to
kind
of
get
promoted
through
that
particular
rigmarole.
A
We
started,
then,
with
a
giant
checklist
of
things
that
had
to
be
done,
and
these
things
went
all
over
the
place
from
you
know:
transferring
domain
names
from
one
place
to
another
and
and
and
you
know,
clearing
logos,
past
copyright
and
things
like
that
through
modifying
switching
from
a
CLA
to
a
D
Co.
So
we've
we've
gone
through
this
entire
checklist
and
we
have
just
about
reached
the
very
end
of
it.
A
On
their
own
and
what
the
helm
organization
kind
of
adds,
on
top
of
that,
as
some
of
you
who
have
have
asked
right,
there's
a
process
in
CNC
F,
where
some
projects
come
in
at
a
sandbox
stage,
others
come
in
at
an
incubator
stage
and
and
they
progress
all
the
way
up
to
graduated
state.
What's
the
official
name
of
a
graduated
project
to
a
graduated
project,
we
people
have
asked
us
when
we
plan
on
graduating.
We
are
actually
not
really.
We
haven't
chosen
that
as
a
focal
point
right
now.
A
What
we've
decided
is
that
we
want
to
spend
the
first
year
or
two
as
an
order
as
an
organization
just
trying
to
make
sure
that
the
projects
that
we
have
are
are
progressing
along
the
along
the
the
trajectory
that
we
want
them
to,
and
so
at
some
point
we
will,
you
know-
maybe
in
maybe
around
this
time
next
year,
we'll
start
talking
about
what
would
it
take
for
us
to
graduate
out
of
the
out
of
the
incubation
stage?
But
it's
not
something
we're
worried
about
right
now,
okay
and
then.
A
Finally,
one
of
the
big
things
that
we
had
to
do
in
order
to
become
a
CNC
F
project
is
we
had
to
put
in
place
our
governance
model,
so
we
do
officially
have
a
governance
model
now.
So
we
have.
The
helm
organization
has
a
of
what
we
call
orga
maintain
errs
and
the
organ
Tanners
are
responsible
for
for
handling
the
the
details
of
the
organization.
So
we
talked
to
CN
CF
once
a
month
and
do
our
check-in
with
them.
We
work
on.
A
You
know,
accepting
new
projects
into
the
hell
mark
things
like
that,
and
then
each
individual
project
retains
its
own
set
of
core
maintained
errs
and
those
core
maintained
errs
are
the
decision
makers
for
their
project.
We
have
like
a
little
lightweight
charter
about
what
happens
if
two
sub
projects
disagree
and
how
the
work
maintainer
would
would
help
facilitate,
but
we've
never
had
to
do
anything
like
that.
So
largely
it's
it's
more
like
a
formal
role,
so
I
think
that
that
kind
of
covers
the
gist
of
what
we
have
organization-wide.
A
But
we
are
working
actively
on
doing
another
helm
summit.
How
many
people
in
here
were
in
the
first
Hjelm
summit
in
portland?
It
was
a
that's
wow.
I
it
was
a
very
small
event
intentionally
and
I'm
glad
you
guys
are
here
today
we
are
going
to
do
one
next
year
in
europe,
we're
targeting
around
the
April
May
time
frame.
It
will
not
be
a
co-located.
Well,
it's
currently
slated
to
not
be
co-located
with
a
coop
con
it'll
be
a
standalone
event
and
again
we'll
try
and
target
a
fairly
small
audience.
A
We're
not
going
to
try
and
you
know,
double
or
triple
the
size.
But
the
idea
is
to
kind
of
figure
out
how
we
can
do
it
so
that
we
can
have
smaller
groups
of
people
who
can
get
together
in
one
or
two
different
rooms
and
talk
about
how
they're,
how
they're
deploying
helm
in
their
organizations
what
kind
of
pain
points
they
have.
What
kinds
of
features
they'd
like
to
see
in
hell,
Murch,
art,
museum
or
monocular,
or
anything
like
that?
So
that's
all
planning
alright.
A
Many
people
who
have
contributed
to
the
charts
repository
have
experienced
frustration,
III
know
of
jars
that
have
sat
in
the
queue
for
six
weeks
or
so
before,
getting
before
getting
reviewed
and
then
getting
merged
in
that's
a
long
time.
But
the
the
problem
is
it's
that
the
chart
maintainer
is
almost
all
of
whom
do
this
at
on
a
purely
voluntary
basis.
Just
have
so
much
material
to
go
through
that
they
they're
just
overwhelmed
for
a
while.
A
A
I
asked
first
I,
think
I
think
it's
in
the
code
of
conduct,
I
fight,
that's
a
that's
good!
Yeah,
that's
good!
Okay!
So
we
kind
of
set
out
intentionally
trying
to
focus
the
effort
on
the
chart
side,
with
building
a
set
of
tools
that
were
going
to
help
make
the
chart.
Maintainer
x'
lives
a
lot
easier,
and
so
we
started
down
a
path
by
basically
taking
tools
that
already
existed
there
and
trying
to
put
some
momentum
behind
those
tools.
The
first
one
is
chart,
museum
did
I
get
the
number
right.
A
Oh
wait
is
the
right
yeah.
It's
currently
the
the
right
way,
so
the
point
of
chart
museum
was
to
provide
a
an
official
tool
inside
of
the
hell
Marie
Poe
Josh,
by
the
way
who's
who
started
the
project
is
sitting
here
in
the
front
row
and
will
be
up
here
or
will
be
answering
questions
during
the
Q&A,
whether
he
likes
it
or
not.
A
Since
we
very
first
started,
it
actually
took
it
as
the
basis
of
their
excellent
cube
apps
product,
but
then
we
kind
of
let
it
go
just
because
everybody
got
busy
doing
other
things
and,
as
we
started
talking
about
the
chart,
maintainer
ship
stuff,
we
got
some
momentum
behind
it
again
and
the
people
who
worked
on
that
project
pushed
it
all
the
way
through
to
a
1.0
and
what's
exciting
about
that.
Is
then,
after
doing
that,
they
began
working
on
the
new
hub,
helm,
SH.
A
Try
saying
that
110
times
fast,
which
is
the
new
home
for
charts
and
it's
based
on
what
monocular
bitNami
has
done
a
fantastic
Straub
of
contributing
to
this,
along
with
several
other
companies,
are
actually
allocated
fixed
developer
hours
to
getting
everything
going
and
the
the
exciting
part
for
us
is
that
we
have
by
adopting
this
and
making
this
an
official
part
of
helm.
This
hub,
helm,
SH
we've
committed
to
kind
of
raising
the
findability
bar
for
charts,
so
you
can
go
out
there.
You
can
search
through
something
visually.
A
You
can
quickly
click
through
the
different
things
read
the
notes
on
it
find
out
where
the
repository
is
hosted
and
then
run
a
helm,
install
and
get
that
installed.
I.
Think,
as
you
can
see,
if
you
can
see
over
on
the
left
hand
side
there,
we
already
have
several
repositories
plugged
in
this.
Is
the
big
deal
for
us
in
order
to
have
this
transform
into
lower
maintainer
ship
requirements,
we
needed
a
way
to
allow
other
people
to
take
their
repositories
and
hook
them
in
to
the
helm
hub.
That
is
possible
now.
I.
A
Think,
by
pull
request
is
the
way
we're
asking
people
to
to
request
being
added
onto
this
list,
but
at
this
point
we
can
add
a
new
repository.
The
charts
that
are
in
that
repository
become
immediately
searchable
and
then,
when
your
repository
makes
it
in
the
official
one
it,
the
experience
feels
a
little
more
like
say
like
NPM,
or
something
like
that,
where
you
can
cruise
through
find
the
things
you
want
and
go
from
there.
So
one
last
thing
that
I
wanted
to
make
sure
we
made
clear.
A
Josh
asked
me
to
make
this
clear
and
so
I
made
the
dopiest
looking
happy
face.
Slide
I
can
do
which
was
not
hard,
given
my
PowerPoint
skills,
or
lack
thereof,
just
to
make
it
clear.
Monocular
is
a
front-end
tool
designed
for
discoverability.
It
is
not
a
repository
server
chart
museum
is
a
chart
repository,
so
so
monocular
can
understand
anything
that
understands
the
the
chart.
Protocol
that's
specified,
but
chart
museum
itself
is
the
thing
that
serves
and
manages
storage
and
things
like
that.
So
that
kind
of
makes
sense.
A
A
It's
almost
like
playing
bat,
so
home
to
is
still
considered
to
be
our
stable.
What
you
should
be
running
in
production
release,
and
it
will
be
like
that
for
at
least
a
few
more
months,
I
should
say
at
least
how
many
months
do
I
have
to
buy
us
in
this
presentation
at
least
five
years
now
so
helm
to
is
still
under
active
maintenance
and,
and
that
means
to
us
first,
we
are
actively
fixing
issues
as
we
find
them.
A
There
are
people
who
we,
if
you
tuned
into
the
helm,
developer
call
you
will
still
hear
somebody
had
assigned
to
triage
the
suq
that
week
we
keep
on
top
of
the
issues
we
do
our
best
to
fix
them.
We
are
still
accepting
feature
requests
with
a
few
caveats,
so
small
feature
requests
that
show
an
immediate
benefit
to
the
to
a
large
segment
of
the
community.
A
If
you're
planning,
a
large
feature,
would
be
to
show
up
to
the
dev
call
on
Thursday
and
say:
hey
I
got
this
idea
for
a
feature.
How
might
this
fit
in
with
a
home
roadmap,
and
that
might
help
you
avoid
a
couple
of
late
night
coding
sessions
and
disappointment
if
the
PR
doesn't
get
accepted.
We
have
also
committed
to
keeping
up
with
with
kubernetes
so
sometimes
depending
on
how
client
go
changes.
An
API
machinery
changes,
I'm
gonna
move
a
little
farther
away
from
Adam
in
case
you
violently
lashes
out.
A
A
A
A
In
here
right,
helm,
classic
with
helm
one
when
we
set
out
to
do
it,
they
were
basically
a
very
small
group
of
us
doing
it.
Kubernetes
was
at
one
point
one
or
one
point
two
or
something
like
that
when
we
started
and
our
development
process
was,
the
team
at
Deus,
wrote
it
in
behind
closed
doors
and
got
it
to
a
particular
point
and
then
released
it
as
an
open
source
project
and
that's
a
very
typical
way
of
starting
a
new
project.
A
Right
then
helm
two
came
along
not
too
much
later,
and
in
that
case
we
had
built
up
enough
momentum
among
some
people,
some
some
teams
that
we
had.
You
know
three
or
four
people
from
Google
three
people
from
bitNami.
You
know
we
were
getting.
We
were
gaining
contributors
from
other
places
and
we
actually
had
you
know,
meetings
and
discussed
through
the
features,
but
still
it
was.
It
was
what
I
would
call
a
closed
circle
right.
It
was
mainly
just
the
people
who
had
come
in
and
said,
I'm
very
interested
in
contributing.
A
B
And
then
so,
helm
3
was
a
much
different
project
process
for
us.
We,
the
the
entire
thing,
was
open
the
it
was
all
done
in
the
community
and
we
listened
to
feedback
and
got
input
from
various
sources.
You
know
we
started
with
the
proposal
and
a
bunch
of
user
stories.
We
collected
everything
that
we
had
learned
from
from
doing
helm
to
and
aggregated
that
talked
to
end-users
I'm
sure
Matt
actually
flew
out
to
some
groups
and
just
listen
to
do
like
the
concerns
they
had,
how
they
used
it
just
because
we
wanted
a
deep
understanding.
B
B
B
A
This
has
that
the
transparencies
actually
I
think
been
a
little
jarring
for
some
people
because
think
about
how
a
typical
project
kind
of
progresses.
You,
don't
you
don't
observe
the
the
very
early
days
of
a
project,
migration
right.
Typically,
we
start
seeing
software
roll
out
around
the
alpha
or
beta
phase.
We
did
the
proposal
way
before
we
had
ever
started
to
write
a
single
line
of
code
and
people.
B
And
major
version
bumps
are
tough
for
end-users.
So
if,
if
we're
gonna
do
this,
we
want
to
make
sure
we
do
it
correctly.
So
we
want
to
make
sure
that
you
know
we
have
a
solid
foundation
for
what
we're
building.
On
top
of
you
know,
this
is
something
that
we
don't
want
to
have
to
do
another
major
version
bump
for
a
while,
for
end-users
sake,
you
know,
helm
has
grown
to
a
point
that
I,
don't
think
any
of
us
ever
imagined,
and
you
know,
people
at
their
organizations
depend
on
helm.
B
B
Currently
tiller
is
the
one
responsible
for
installing
or
creating
resources
in
your
cluster
I
talk
to
the
API,
so
all
resources
are
created
from
a
single
source,
no
matter
which
user
is
doing
the
helm
install.
So
this
will
allow
all
resources
to
be
created
by
the
end-user
who
is
actually
running
the
command.
It
will
also
use
the
credentials
that
are
for
the
end-user,
and
so
it
will
enable
auditing
and
another
a
few
other
security
advantages
too.
Another
thing
is
just
set
up.
You
know
right
now
you
run
a
helm
in
it.
B
It
sets
up
some
directories
in
your
home
directory
and
it
also
installs
the
tiller
deployment
in
your
cluster.
With
the
new
architecture
like
on
CI.
All
you
need
is
the
ELMO
CLI.
You
don't
have
to
initialize
anything,
you
don't
have
to
initialize
your
home
directory
or
so,
if
you're
running
local
charts.
That's
all
you
need
it's
just
the
single
dependency,
no
dependencies
on
your
cluster
and
then
also
the
error
feedback
loop.
B
So
because
it's
client-server
architecture,
it's
you
give
the
server
all
the
instruction
for
I
want
to
install
this
thing,
and
then
you
just
got
to
see
if
it
passes
or
fails
as
opposed
to
if
we're
client
only,
then
we
can
actually
respond
to
errors
as
they
happen
throughout
the
process,
so
we
can
be
a
little
bit
more
intelligent
as
far
as
how
we
handle
stuff
they're,
great
refactor,
so
gardening
is
more
than
just
watering
flowers.
Sometimes
you
need
to
do
some
pruning.
I
said.
B
B
It's
just
been
incredible.
The
amount
of
features
that
we've
had
implemented
by
just
community
people
and
people
using
home.
The
disadvantage
of
that
is
you
know,
everybody's
got
different
styles.
Everybody
has
different
backgrounds,
as
you
add
stuff,
if
it
doesn't
quite
naming
convention
doesn't
quite
fit,
then
well
just
create
something
new
and
you
end
up
with
spaghetti
code,
because
we
follow
very
strict
cember.
A
B
B
So
we're
spending
a
lot
of
time
on
the
internals
and
trying
to
make
sure
we
get
that
correct.
This
is
what
majority
of
the
development
has
been
so
far
is
just
going
through
and
cleaning
stuff
up.
Looking
at
naming
conventions
trying
to
set
stuff
up
correctly
to
make
sure
we
can
scale
as
new
features
come
in.
Our
goal
is
to
have
the
helm,
client
have
a
helm
library
that
is
standalone,
so
the
helm
CLI
will
essentially
be
a
reference
implementation
for
how
you
can
implement
helm.
B
One
thing
we've
seen
is:
there's
a
lot
of
projects
now
that
are
integrating
with
helm
and
they
want
tight
integration
and
they
want
the
same
functionality
and
sometimes
it's
bits
and
pieces.
Sometimes
it's
the
whole
thing
so
we're
trying
to
make
almost
like
an
SDK
style
where
it's
choose-your-own-adventure,
where,
if
you
just
want
to
do
templating,
you
should
be
able
to
do
it
with
the
library.
If
you
want
to
do
the
whole
and
end
start
installation
and
lifecycle
management
stuff,
you
should
be
able
to
do
that.
B
B
B
Things
now
so
helm
3
is
introducing
new
idea
cells.
So
you
know
dsls
can
really
help
out
with
certain
systems
with
the
clarity,
so
one
concern
that
I
keep
getting
is
backwards.
Compatibility
and
am
I
gonna
have
to
rewrite
all
charts
in
Lua
that
this
is
a
added
feature
templates
and
everything
that
has
to
do
with
the
actual
application
that
you're
running
is
going
to
be
completely
backwards
compatible.
B
There
are
some
changes
to
the
chart
format,
but
it's
all
around
the
metadata
behind
it
and
that's
because
we've
had
new
features
added
a
lot
around
ven
during
charts
chart
dependencies
that
we
couldn't
add
to
proper
places
because
of
our
backwards
compatibility
commitment.
So
now
we
have
that
opportunity
to
make
those
changes
so
because
it's
only
metadata
changes
that
will
enable
us
to
have
like
a
preprocessor
to
be
able
to
convert
charts.
B
What
beyond
the
flower,
which,
probably
like
a
plugin
or
something
I'm
designing
stuff
has
I'm
up
here
but
or
it
could
be
like
a
standalone
thing
or
you
just
want
to
run
it
on
your
charts
and
do
it
like
well
we'll
figure
something
out
for
that.
But
we
want
to
make
sure
that
there
is
a
story
for
that
and
your
existing
charts
will
work
fine,
so
here's
an
example
of
what
we're
thinking.
That's
in
it.
This
on
the
left
here
is
like
when
you
do
a
helm,
create
and
it
scaffolds
out
a
new
chart.
B
This
is
the
the
helper.
So
what
this
does
is
it's
a
function
that
you
can
put
in
your
template.
That
will
generate
a
name
for
your
resource.
It
also
does
validation
it
strips
out
anything.
That's
not
valid
for
kubernetes,
also
truncates
it
to
what
terminators
will
accept
and
it's
a
scary
beast.
It's
not
very
readable.
Go
templates
are
a
little
difficult
to
approach
if
you're
not
totally
familiar
with
them.
They're,
not
completely
intuitive
the
documentation,
isn't
the
greatest
on
them.
There's
a
big
learning
curve,
I,
don't
like
writing
stuff.
That
looks
like
that.
B
So
on
on
the
other
side
here
we
have
an
example
of
how
you
could
do
it
in
lua,
and
this
is
an
example
that
could
go
in
a
pre
render
hook.
That's
going
to
calculate
these,
for
you
automatically
and
then
inject
it
into
your
values.
So
then,
your
template
ends
up
looking
like
just
parameter
expansion.
You
essentially
just
have
to
dump
all
the
values
you
want,
because,
like
any
templating
and
generation
happened
at
the
previous
step,
this
is
just
an
example
way
of
using
it
to
like.
B
A
A
So
chart
repositories
have
gone
through
a
very
active
design
cycle
and
we're
really
excited
about.
What's
going
on
so
essentially
a
team
of
people,
you
know
kind
of
crossing
this
boundary
between
the
people
have
been
working
in
the
charts
or
side
of
things,
and
people
have
working
on
the
helm.
Side
of
things
have
been
engaged
in
what
weekly
meetings
for
a
few
months,
at
least
now
Wednesday
at
8
a.m.
8
a.m.
Pacific
time
8
a.m.
Pacific
time
yeah.
A
Then
it's
an
ongoing
meeting
and
I
believe
it's
public
right
and
they've
been
working
through
some
of
these
things.
I
got
to
give
a
shout
out
because
Jimmy
is
sitting
in
the
front
here.
Jimmy
demoed,
something
I
think
the
first
demo
I
saw
was
at
core
OS
fest
a
year
and
a
half
ago,
basically
piloting
this
idea
that
we
could
use
helm,
that
we
could
use
OCI
repositories
to
store
Helms
arts
and,
as
they've
gone
through
a
fairly
decent
and
in-depth
design
process
and
considered
a
whole
bunch
of
different
models,
we're
basically
at
that
model.
A
Now.
So
the
current
plan
is
is
to
move
toward
OCI
registries
like
like
Dockers
of
docker
distribution
and
docker
hub
and
and
the
Quai,
and
this
will
be
where
we
can
store
charts
in
the
future
means
we're.
Leveraging
technologies
already
exists
that
are
optimized
for
the
kinds
of
cloud
services
that
we
already
want
to
build.
B
Guru
Nettie's,
since
we
released
come
to,
has
drastically
improved
the
apply
logic
when
we
were
doing
helm
there
was.
It
was
very
much
specific
towards
individual
resources,
also
like
we
as
a
community,
didn't
fully
understand
a
lot
of
what.
What
can
we
actually
update?
What
does
it
look
like
I,
remember
at
one
of
the
initial
cube
cons,
I
was
like
talking
to
Brian,
grant
and
I'm
like
what
is
it
supposed
to
do
when
you
upgrade
a
resource
like
I
was
like
I
I've
been
working
on
it
for
so
long
and
my
trying
yeah
it
was.
B
It
was
a
dark
time
for
me.
It
was
so
we
we
ended
up
implementing
our
own
diff
patching
method
that
very
closely
followed
the
apply
logic
you
know,
instead
of
injecting
at
for
metadata
into
the
resource
when
it
was
created
in
and
kubernetes.
We
were
storing
that
in
the
release,
so
we
still
had
the
full
thing
to
be
able
to
diff.
B
That's
correct,
so
a
three-way
diff
means
it
looks
up
your
live
resources
as
well
to
see
if
there
was
any
changes
that
were
made
on
the
fly
like
using
cube
control
and
you
edit
something
before
what
we
were
doing
was.
We
were
just
differing
with
the
previous
version
that
we
had
in
95
percent
of
use
cases
that
works
perfectly
fine.
Sometimes
things
can
get
a
little
weird
in
there.
B
B
E
B
We've
changed
that
to
operate
a
lot
more
like
you
would
expect,
with
deployments
with
deployments
when
you
create
a
deployment
in
a
specific
namespace,
it's
going
to
create
the
pods
and
replica
sets
in
that
same
namespace,
so
we're
moving
to
the
same
model
where
the
metadata
that
release
made
of
data
will
be
stored.
Alongside
with
the
release,
it's
just
a
pattern
that
is
closer
with
the
conventions
of
kubernetes,
so
real,
quick
to
recap,
I
just
want
to
fill
in
like
what
has
already
been
done,
the
removing
chiller
that
was
the
first
thing.
B
B
The
namespace
change
has
has
also
been
done.
A
lot
of
the
refactoring
and
cleaning
stuff
up
is
gonna,
be
a
long
process
like
I
have
spent
a
lot
of
time
going
through
that
and
cleaning
stuff
up.
So
so,
if
you
want
to
give
any
these
a
try,
any
of
these
features
feel
free
to
download
it
and
play
with
it
again.
I
wouldn't
recommend
integrating
with
it,
because
I'm
changing
stuff
very
fast
in
there
and
I.
Don't
want
you
to
be
sad.
B
A
So
I
mean
to
kind
of
summarize
all
the
all
the
big
stuff
we're
doing
on
helm,
they're
kind
of
two
big
categories
of
things
were
trying
to
do.
We've
tried
to
improve
the
usability
of
it
and
realign
it
with
the
the
patterns
that
have
emerged
in
kubernetes
right.
This
story
for
upgrade
was
great
for
1.2
and
1.3,
but
we're
way
beyond
that
now,
and
so
that's
a
major
increment
and
then
the
other
category
is
just
trying
to
add
sort
of
strategically
the
right
layer
of
features
to
allow
I
mean
the
complexity
of
applications.
A
B
B
We
already
started
treating
applications
as
that's,
but
you
know
upgrades
were
still
a
snowflake
and
we
were
very
scared
of
deleting
people's
data,
because
that
makes
people
sad
too
I've
heard.
So
we
wanted
to
be
very
careful
as
far
as
how
we
handle
the
deployment,
so
we
picked
the
safest
route
possible,
even
though
it
didn't
have
all
the
feature
set,
but
now
there's
a
lot
more
understanding
as
far
as
what
can
be
upgraded
as
far
as
resources.
A
lot
of
that
information
has
gone
into
the
API,
so
there's
validation
on
stuff.
A
So
we're
hitting
a
break
in
the
normal
schedule
at
this
point,
I
believe,
however,
this
session
was
allocated
an
extra
of
40
minutes,
so
we
could
go
through
some
Q&A
and
other
talks
like
that.
So
if
you
got
to
get
up
and
run
to
a
different
session,
that's
totally
cool.
Thank
you
very
much
for
being
here
today
and
we
hope
that
you
learned
a
little
bit.
B
Kubernetes
core
has
recommended
against
using
kubernetes
kubernetes
as
a
dependency,
so
we
are
actively
working
to
remove
that
as
a
dependency.
So
we
will
have
to
implement
our
own
until
server
side
apply
is
completed
and
it
will
not
be
completed
in
the
timeframe
that
we
want
to
have
releases
out
for
helm
3.
So
that
will
be
something
that
will
have
to
wait
until
another
release
yeah.
It
will
mirror
very
closely
what
keep
control
does.
F
B
B
Yeah,
it
will
enable
us
for
that-
oh
sorry,
he's
asking:
will
it
provide
any
safety
checks
to
know
if
you're
updating
a
resource
if
something
had
been
changed
that
helm
wasn't
expecting?
This
will
enable
us
to
be
able
to
generate
diffs
to
be
able
to
print
out
a
lot
more
information
to
do
dry
runs
also,
which
would
be
nice.
B
G
Yeah
so
yeah
so
he's
saying:
if
we
move
towards
using
registries
to
store
charts,
what
happens
to
chart
Museum
and
that's
very
much
on
the
table,
I
want
to
focus
on
making
sure
helm.
3
is
good
experience
for
people
and
less
about
chart
museum
future.
So
it
really
just
depends
what
direction
things
go.
So.
J
A
K
A
B
B
E
B
Designed
helm
to
be
as
flexible
as
possible,
if
you
want
to
wrap
tooling
around
it,
we
try
to
limit
the
the
feature
set
of
helm,
but
allow
you
to
essentially
do
stuff
like
that,
where
you
could
run
just
the
templating
side
of
things,
you
could
pipe
it
to
whatever
you
want.
So
that's
how
you
could
handle
your
post-processing.
You
could
then
pipe
it
to
keep
control.
So
if
you
only
want
the
templating
side
of
things,
then
you
could
do
it
that
way.
The
disadvantage
of
that
would
be.
B
L
A
Process
out
to
external
tools
possible,
so
yeah,
there's
and
yet
probably
seen
Vic
iglesias
is
one
of
the
chart.
Maintainer
x',
he
wrote
a
blog
post
about
using
customized
and
helmet
together,
so
I
know
of
people
who
are
doing
it.
It's
just
there's
no
there's
no
opinionated
implementation
that
we
have
of
it
or
they
were
planning
on
in
the
helm,
3
roadmap
and.
B
B
So
it's
the
same
step
that
you're
talking
about
adoption
was
just
very
low
interest,
wasn't
really
there
for,
for
that
after
we
had
developed,
it
stayed
in
an
experimental,
so
we
kind
of
phased
it
out,
but
yeah
the
plug-in
system,
you
that
would
be
the
place
to
start
looking
I
think
some
hands
were
up
over
here
before
I.
Did
you
have
a
question?
I'll
I'll
get
back
to
you
over
there.
A
B
G
J
So
look
the
question
was:
is
there
any
docs
on
using
any
of
the
repository
stuff
yet
with
existing
registries
right?
So
app
registry
is
the
POC
for
all
those
stuff
that
has
been
integrated
with
Quay,
and
you
can
use
that
today
in
Quay
and
a
bunch
of
people
use
that
in
production,
it's
not
exactly
what
it
will
end
up
being
for
helm,
but
that
is
a
plug-in
that
you
can
use
for
a
home
v2
right
now
today,
but
yeah
there's
still
no
docks
on
doing
any
of
those
stuff
outside
of
that
registry.
J
J
I
We
working
with
Josh,
we
implemented
helm,
charts
in
natural
container
registry
and
that's
like
the
beating
of
what
we've
been
trying
to
get
this
working.
So
it's
not
unique
to
a
particular
registry.
So
ACR
we
do
support
helm,
charts
now
and
we
want
to
make
it
a
more
standard
thing
so
that
it
works
across
all
of
them.
M
Sounds
great
I'm
great
at
delegating
I'm
gonna
delegate
them
to
Matt,
so
there's
also
of
one
of
the
CN
CF
projects
called
harbor
which,
like
as
your
container
registry
and
these
others,
it
can
also
store
helm,
charts,
it's
something
you
can
run
in
your
own.
It's
a
CN
CF
project.
It's
basically
a
coupling
of
things,
I
think
like
docker
distribution
and
chart
museum,
which
is
a
home
project
and
a
number
of
things
to
give
you
image.
B
M
A
B
A
It
would
enable
people
to
write
the
kind
of
helm,
specific
libraries
that
I
think
would
be
necessary
to
do
that
if
we
wanted
to
do
it
as
a
primitive
inside
of
helm,
but
without
writing
it
straight
into
the
go
code
and
consequently
locking
everybody
into
using
aes-256
or
writing
an
entire
crypto
library.
That's
exposed
in
templates.
So
that
is
one
option.
We're
not
that's
me
hedging
before
I
say
we're
not
actually
trying
to
solve
it
as
a
first-class
solution.
Inside
of
helm,
yeah.
B
I'm
gonna
cut
in
line
too
before
the
other
one
of
the
other
mats
takes
over
again,
so
we
try
to
be
as
non
opinionated
as
possible
when
dealing
with
your
specific
application.
So,
however,
you
want
to
implement
the
the
secret
thing.
We
want
to
facilitate
that
where
we
don't
want
to
force,
you
go
into
a
specific
way
of
handling
anything
around
their
application,
so
you're
gonna
say
well.
M
Team
does
something
like
that,
like
imagine
how
many
people
are
in
the
room
now
each
of
you
probably
has
at
least
one
workflow
you'd
like
to
do,
and
many
of
them
are
not
gonna
overlap.
So
how
can
we
not
get
in
the
way
of
that
right?
And
you
know
some
folks
are
gonna-
want
to
use
sauce.
Some
folks
will
want
to
use
you
know.
Kms.
M
Some
folks
may
even
want
to
get
into
backing
secrets
with
their
key
management
service,
which
is
a
new
thing
coming
in
kubernetes
right,
there's
lots
of
things
going
and
workflows,
and
so
we
don't
want
to
be
in
the
way.
But
yet
we
still
want
to
enable
you
to
do
that
and
I'm
actually
hoping
the
event
system
will.
M
Let
me
have
plugins
to
plug
in
to
do
what,
like
home
secret,
does
and
yet
make
it
a
little
bit
more
transparent
or
maybe
include
something
in
Lua
to
figure
out
those
workloads
right
now,
for
example,
on
the
hub,
we
have
to
store
the
secrets
and
solve
this
problem,
and
so
we've
had
to
work
through
those
same
kinds
of
struggles
and
we'd
like
a
better
workflow.
So
hopefully
we
can
get
in
helm
3,
but
without
being
too
opinionated
I
think.
G
N
Yeah
anyways,
something
that
could
make
it
easier
would
be
I
mean
better
access
to
CI.
So
in
the
chart
that
I
maintain
there
are
so
many
options
and
get
lost,
pull
requests
and
pull
requests
can
break
other
things
if
I
had
a
better
test.
So
a
better
way
to
test
my
charts.
That
would
be
great
I
mean
I
could
use
my
own
infrastructure
for
testing,
but
I'm
not
super
invested
in
that
either.
Like
I
know
this
prowl,
but
it
only
tests
like
the
no
values.
No
additional
values
be
cool.
N
M
Have
you
heard
of
the
chart
testing
project?
That's
a
home
project,
it's
it's
at
github,
comm,
slash
home,
slash,
chart
testing,
and
it's
designed
to
help
you
test
your
charts.
In
fact,
we
even
have
a
way
where
you
can
have
varying
different
values
files
and
it
can
walk
through
installing
and
testing
each
one.
It's
there
today.
We
also
have
things
like
static
analysis.
That'll.
Even
look
at
schemas
for,
like
your
chart,
yamo
file
make
sure
you're
following
them
right.
It
goes
way
beyond
homeland
and
it's
one
of
the
tools
we
use.
M
O
So,
with
with
the
introduction
of
the
Lua
hooks
in
helm,
3,
what
would
you
say
that
the
the
limits
of
the
functionality
you
would
in
good
conscience,
encourage
someone
to
implement
in
one
of
those
Lua
hooks?
You
know
like
I
could
stick
an
HTTP
server
in
there
if
I
wanted,
but,
like
that's,
probably
a
bad
plan
and
I'm
asking
because
I'm
interested
in
what
you
see
is
the
limit
of
people
doing
with
orchestration
in
those
hooks
like.
Would
you
see
someone
doing
something
like
a
canary
release
as
part
of
a
Lua
hook
in
a
chart?
O
M
Well,
I
guess:
I'll
feed
off
of
you
and
say
don't
mind
cryptocurrency
in
there,
but
so
so
do
does
any.
How
many
you
may
have
talked
about
this
before
I
got
here.
How
many
people
know
that
there
are
helm
charts
out
there
to
install
OpenStack
into
into
a
kubernetes
cluster?
Did
you
know
that?
Yes,
there
are
helm,
charts
out
there
and
we
have
some
very,
very
ugly
features
inside
of
helm,
that
you
will
not
find
anybody.
M
On
github,
right
or
in
public
and
I
will
not
tell
you
what
they
are
because
I
don't
know
how
they
work
they're
there
to
enable
some
of
this,
and
so
I
would
expect
those
super
complicated
applications
that
weren't
necessarily
built
to
be
in
containers
have
some
really
ugly
things
you
have
to
do,
and
Lua
is
a
great
place
to
do
that,
where
we
don't
have
to
modify
helm
for
those
special
cases
and
those
crazy
applications
will
push
those
limits.
At
least
that's
what
I'm
hoping
yeah.
B
We're
trying
to
provide
an
extra
tool
for
the
you're
trying
to
do
something
way
out
of
the
box
and
are
trying
to
beat
this
round
peg
in
a
square
hole,
and
you
just
need
something
to
work
as
a
fix
for
something
that
your
org.
So
it's
made
for
a
safety
net
for
that,
as
well
as
just
cleaning
up
some
of
the
go
template
stuff.
P
B
A
Yeah
yeah
yeah
and
that's
one
of
the
nice
things
about
Lua,
is
that
we
can
pick
which
of
the
standard
libraries
we
want
to
expose
in
which
we
don't.
We
can
also.
You
know
if
we
end
up
supporting
Lua
plugins,
specifically,
we
can
have
charts
that
run
with
one
set
of
libraries
and
plugins
that
run
with
it.
We
have
a
lot
of
options
that
that
we
otherwise
would
not
have
had.
Please
don't
write
a
web
server
in
a.
B
Q
Q
We
always
said
that
the
chart
format
is
not
going
to
become
compatible
but
I'm
thinking
more
about
the
operational
impact
of
going
to
v3
like
I,
know,
customers,
for
instance,
who,
for
instance,
fact
that
all
the
releases
are
in
the
system,
then
in
the
main
namespace
they
can
look
at
them.
I
can
tell
you
what
I
can,
in
sum
up,
what's
released,
but
suddenly
they're
all
gonna
be
an
individual
namespaces
for
instance.
Q
B
D
B
C
So
I
had
to
follow
up
to
the.
What
can
you
do
with
Lua
question,
and
this
is
more
of
a
I
guess,
a
specific
practical
thing
that
I
would
wish
as
soon
as
I
saw
that
I'm,
like
oh
great,
maybe
that's
a
way
for
me
to
pull
an
output
from
a
terraform
deployment
so
that
I
can
inject
a
value
into
a
home
chart
because
it
was,
you
know
something
that
was
done
with
me,
a
terraforming,
but
then
that
would
be
you
know
talking
to
an
external
system
or
something
like
it.
B
B
Yeah,
if
you
have
a
specific
use
case
like
that,
you
know
if
you
want
to
bring
it
up
with
any
of
the
core
people
or
drop
an
issue
and
the
proposal
I,
don't
know
if
we
mentioned
this,
but
the
proposal
is
hosted
under
helm,
slash
community
in
there.
You
can
open
issues
on
that
with
any
concerns
you
have
with
the
proposal.
That
would
be
a
good
one.
We
definitely
love
to
hear
use
cases.
M
Right
so
so
let
me
jump
on
two
things
here.
First,
the
the
Helms
specific
one
is
part
of
it.
We're
talking
about
workflow,
right
and
so
a
chart
is
a
self-contained
package.
You
can
pass
around
and
can
be
implemented
into
one
or
more
clusters.
Right
and
so
I,
don't
know
if
you're
thinking
that
terraform
gets
coupled
with
a
package
and
is
called
now,
you've
got
external
dependencies
that
you're
trying
to
ship
around
that
might
get
a
little
complicated.
M
You
know
part
of
the
actual
chart
package,
but
the
other
thing,
as
you
probably
heard
some
whisperings
over
here
and
it
came
up
in
the
sega
up
steep
dive
earlier,
it's
c
nap.
Are
you
familiar
with
that?
The
cloud
native
application
bundles
seen
a
bio?
It's
designed
to
be
able
to
tie
some
of
these
things
together
in
an
installable
package,
and
that
may
give
you
a
more
short-term
solution
for
it.
Although
it
is
very
early
alpha.
B
L
G
R
I
have
a
couple
questions,
one
related
to
the
Lua
and
scripting
and
patching
and
the
other
one
related
to
get
ops
so
I
mean
the
first
lead
of
question
to
the
little
one.
Do
you
plan
on
supporting
any
sort
of
patching
in
Lua
like
patching
any
part
of
the
chart,
or
is
it
just
kind
of
pre
pre-processing.
B
Well,
the
Lua
provides
hooks
at
various
points
in
the
process.
One
would
be
loading,
another
would
be
like
pre-render
post
render,
so
the
the
actual
resources
that
you're
working
with
I
don't
think
you
would
want
to
do
dipping
there
I
suppose
you
could
you
have
access
to
the
object,
so
you
could,
you
know,
do
whatever
you
want
with
the
objects.
If
you
wanted
to.
B
Don't
think
about
that,
for
what
you're
talking
about
you
can
do,
there's
a
post
render
step.
So
what
you're
working
with
is
the
actual
rendered
resources
and
you
can
do
whatever
you
want
with
them.
At
that
point,
you
can
edit
values.
You
can
throw
a
conditional
saying
like
if
there's
this
condition
that
got
thrown
in
from
my
original
values
then
go
in
and
swap
out
all
the
labels
with
the
the
my
corporate
policy
of
resources
that
could
get
created,
so
you
will
have
access
to
dependent
resources
and.
B
You
could
run
into
problems
depending
on
what
you're
doing,
but
without
knowing
your
specific
use
case
and
what
you're
changing
it
would
be.
It's
really
hard
for
me
to
give
you
an
answer
to
that
yeah
and
then
we're
definitely
giving
you
a
powerful
tool
set
and
you
can
shoot
your
foot
off
in
many
ways
with
a
powerful
tool
set,
so
yeah
I
mean
you'll,
be
able
to
get
yourself
in
trouble
changing
stuff
we're
not
gonna
limit
it
we're
leaving
a
lot
of
the
responsibility
up
to
the
people
using
the
rules.
Oh.
R
Cool
thanks
and
then
the
one
related
to
get
offs
was
in
home,
3
you're
gonna
be
creating
CR
DS
to
men's
releases
and
whatnot,
and
one
of
the
patterns
as
its
emerging
is
like.
Okay,
I'm
going
to
push
my
infrastructure
to
get
repository
and
then
have
some
like
operator
or
something
scan
that
get
repository
and
and
reconcile
the
state.
B
M
You
talking
things
like
the
weave
works,
how
my
operator
kind
of
style
of
things
yeah,
so
I,
yeah
I,
don't
know
that
we
are
thinking
about
building
that
ourselves,
but
others
are
more
than
welcome,
because
there's
many
different
possible
operator
get
ops
types
of
workflows
and
variations
that
people
may
want
to
do.
For
example,
how
many
clusters
are
you
running?
How
many
different
configs
do
you
have
for
those
clusters?
How
do
you
scale
that
out
and
I
know
we're
talking
about
an
operator
model?
I,
don't
know
if
you
talked
about
that.
B
M
M
M
N
G
N
I've
got
a
use
case
question
so
in
helm,
2,
you
have
support
for
track
dependencies.
Obviously
you
can
do
composability,
but
it's
pretty
limited
like
you
can
only
have
one
version
of
a
chart-
dependency,
let's
say:
you've
gone
to
micro
services
and
they
both
depend
on
different
versions
of
the
Postgres
chart.
Can't
do
that,
so
how
how
important
is
composability,
2
to
home,
3
and
being
able
to
support
that
correctly?
I
guess
the
bigger
use
case
I
have
is
like.
We
have
an
organization
that
deploys
micro
services.
A
G
A
All
this
stuff
is
very
experimental
at
this
point,
because
it's
going
to
depend
on
the
changes
that
we
can
make
in
the
implementation
of
the
engine.
It
would
be
great
to
capture
any
kind
of
use
case
like
you
have
for
that
in
an
issue
even
on
so
the
we
didn't
put
a
slide
up
here.
That
showed
where
the
proposal
is
I
assume.
A
But
the
at
Helm's
slash
community,
there's
the
the
full
proposal
is
in
there
and
that's
a
good
place
to.
We
have
a
running
set
of
use
cases
in
there.
That's
a
great
place
to
put
something
like
that,
so
that
we
can.
You
know
it's
in
the
right
context,
for
the
people
who
are
considering
what
the
proposal,
how
the
proposal
needs
to
be
modified.
M
S
S
The
problem
with
there
was
you
could
either
delete
it
and
then
have
home
recreate
it,
which
would
cause
an
outage
or
created
with
a
new
name
and
then
have
to
update
all
the
clients
in
your
cluster
so
that
serve
related
to
the
helm,
to
to
helm
three
upgrade.
So
if
there's
no
way
to
sort
of
upgrade
in
places,
there
will
be
a
way
to
sort
of
take
over
existing
resources.
M
B
M
M
So
when
the
meetings
are
with
the
zoom
information
and
all
that
stuff,
if
you're
interested
in
coming
to
be
part
of
that,
I
would
also
say
that
with
services
and
that
changing
you
right,
you
it,
you
can
end
up
in
things
like
trying
to
tie
external
DNS
into
it,
to
try
and
give
DNS
names
and
point
things.
One
of
the
easier
things
that
I
found
is
actually
put
ingress
in
front
of
it,
because
then
you
can
swap
out
your
things
and
still
keep
the
same
ingress.
If
you
install
an
ingress
controller
in
your
cluster.
M
Q
T
Some
good
stories
about
because
a
lot
of
people
have
held
to
things
installed
in
production
and
the
a
seamless
upgrade
to
move
to
helm
3.
Maybe
a
home
3
can
go
and
extract
the
release,
information
from
helm,
2
or
there's
different
there's
a
way
or
you
can.
You
can
install
but
just
kind
of
take.
If
the
thing
is
already
there
just
take
it
over
and
and
so
having.
Some
stories
are
and
they
could
be
good.
M
So
so
I
have
a
question
here
to
follow
up
on
that,
and
instance:
we've
got
a
room
of
people
here.
Helm
has
the
ability
to
have
plugins
right,
because
this
is
all
like
a
one-time
upgrade
task.
Would
this
be
something
better?
That's
part
of
a
plug-in
that
is
the
helm,
upgrade
plug-in
where
you
can
grab
that
and
run
an
upgrade.
Then
all
the
sudden,
all
your
stuff
is
moved
to
helm,
3
or
from
a
user
experience.
M
T
T
G
I
B
L
Will
just
say
like
hand
to
the
hem
tree
there?
Isn't
there
a
big
architectural
change
like
tiller
is
going,
for
example:
I
will
always
prefer
to
do
it
like
a
migration,
like
converting
all
my
hand
to
to
having
three
I
will
never
want
to
go
with
a
flag
in
I
will
be
so
scared
to
go
for
them,
because
there
will
be
a
big
architectural
change.
Am
I
missing
the
point.
What
do
you
think
about
them?.
M
You
could
have
a
tool.
The
first
step
could
be
a
dry
run.
You
actually
run
to
make
sure
everything
goes,
and
maybe
the
the
next
step
is
a
backup
where
we
can
grab
a
backup
of
all
of
those
things
into
a
directory
that
you
could
redeploy
after
the
fact.
If
you
screw
it
up,
because
you
know
if
you're
gonna
do
an
upgrade,
you
always
want
to
do
a
backup.
First
right,
maybe
you
can
grab
this
and
stick
it
into
another
cluster
and
create
a
backup
and
mirror.
M
So
you
can
actually
try
and
see
whether
your
upgrade
works
and
not
everybody's
gonna.
Do
all
of
these
and
then
finally
there's
the
actual
do
it.
But
if
we
go
through
and
have
a
lot
of
these
steps
and
talk
about
through
it,
we
can
do
things
in
ways
that
people
with
different
levels
of
safety
can
feel
safe
about
it.
At
least
that's
the
kind
of
things
that
I
would
like
real.
B
Quick
just
a
comment
on
my
college
discussion.
That's
going
on!
First
of
all,
thank
you
for
bringing
this
up
and
addressing
it
because
it's
it's
made.
It
really
clear
to
me
at
least
like
what
the
concerns
are
with
the
migration
story.
So
thank
you
for
addressing
that
and
like
we
will
definitely
figure
something
out.
You
know
like
whether
it
be
a
tool
like
you
know.
B
Let's
kick
off
a
discussion
and
let's,
let's
start
figuring
out
what
is
the
best
approach
for
this,
and
this
is
what
I
was
referring
to
earlier
about
how
we'd
love
use
cases,
because
it's
extremely
helpful
to
hear
like
in
production
what
your
requirements
are
from
moving
forward
with
this,
because
we
want
to
make
sure
that
that
there
is
a
clean
path
for
all
this.
So
we
should
definitely
have
like
a
something
in
the
community
talks.
Well,.
L
U
U
M
So
we
have
Hamlin
today,
but
we
have
this
project.
We
talked
about
a
little
while
ago.
Chart
testing,
and
one
of
the
things
we
want
to
do
is
add
that
validation
to
it
we
just
sew
chart
testing
was
originally
written
as
this
super
complicated
set
of
bash
scripts
with
functions
and
all
this
stuff
we
said
wow,
we
are
doing
way
too
much
in
bash.
So
before
we
started
adding
any
of
these
later
I.
M
Rewritten
in
go
so
we
can
continue
to
extend
it,
but
that's
one
of
the
things
we
want
and
if
we
don't
get
to
it,
quick
enough,
we
are
very
happy
to
have
a
contribution
of
something
that
does
will
even
give
guidance
on
it.
So
if
it's
something
you'd
like
to
contribute,
please
come,
let
us
know,
and
we
are
happy
to
point
to
the
way,
so
we
can
get
to
it
more
quickly.
With
your
help.
B
M
All
right,
what
are
we
gonna
do
with
it
in
home,
3
yeah
I
should
probably
answer
this
so
I'm,
one
of
the
maintainer
of
applications
here
D,
so
I
wanted
a
punt
to
see
whether
they
would
do
it
yeah
you
don't
nobody
wants
to
so
application.
Cr
D
is
not
fully
baked
yet
and
we
should
not
support
it
as
a
it.
You
can
install
it
along
with
any
other
thing
in
Hjelm
right,
any
other
CRD
based
thing
and
we're
working
to
improve
on
that
stuff,
even
in
home.
There's
a
proposal
in
writing
for
it.
M
That's
coming
I
talked
to
the
person,
then
it's
out
there
somewhere.
He
found
me
at
the
conference,
and
so
you
can
install
it
like
anything
else
today
as
far
as
treating
it
as
something
special
I'm
gonna
hold
to
it
that
we
need
to
have
that
out
and
GA
and
stable
before
we
do
that,
and
it
has
not
been
moving
at
the
speed,
we'd
hoped
and
so
we'll
just
have
to
wait
and
see.
But
right
now
a
beta
was
released
and
and
it's
kind
of
sitting
there
waiting
and
the
person
who's
been
primarily
driving
it.
M
He
is
busy
for
the
next
month
or
so
and
probably
is
gonna,
be
swamped
when
he
comes
back
so
it's
just.
We
need
some
more
contributions
to
the
app
charity
and
if
somebody
wants
to
come
help
with
that,
we
can
help
get
you
going
we're
very
happy
to
do
that.
But
let's
wait
for
that
to
be
fully
baked
and
then
have
the
conversation.
T
Last
another
upgrade
question:
is
it
already
part,
as
it
hasn't
been
part
of
the
helm?
Three
kind
of
conversation
like
the
features
and
requirements
to
change
like
if
an
upgrade
fails
to
make
it
to
rollback
or
to
change
the
behavior
when
an
upgrade
fails
right
now
on
upgrade
fails
it's
just
the
everything
it
was
done
up
to
that
point.
Is
there
helm,
doesn't
know
about
it
and
some
of
those
things.
If
there
are
new
things,
you
have
to
go
and
kind
of
clean
up
by
hand
you're.
B
It's
just
the
nature
of
running
upgrades
on
stuff
in
the
cloud
like
we're,
trying
to
get
a
lot
better
about
it
and
that's
why
we're
switching
to
the
being
able
to
reconcile
what's
actually
in
the
cluster
and
not
just
what
we
assume
is
in
the
cluster
or
what
we
last
put
into
the
cluster.
So
it's
a
huge
step
forward,
but
it's
still
not
going
to
be
perfect.
F
B
Talk
about
it,
so
so
one
thing
that
we
we
have
it
sits
in
album.
Two
is
helm
test
and
that
is
it
will
run
after
an
install
or
at
any
point
and
within
that
you
can
actually
put
whatever
you
want.
You
can
do
all
your
checks,
so
if
there's
certain
fail
conditions
that
your
application
is
prone
to,
you
can
run
checks
against
that
and
you
can
actually
program.
D
B
K
B
B
F
S
K
Both
I
guess
one
use
cases,
I
have
a
chart
that
I
wrap
chart
a
Prometheus
in
so
it
runs
an
operator
first
and
then
it
runs
the
other
and
kind
of
just.
Does
it
with
a
flag
would
be
nice?
If
that
could
just
all
happen
in
one
run
and
then
other
use
cases
would
be
like
somebody
was
talking
about
having
a
single
chart
to
manage.
You
know
a
bunch
of
different
charts
to
build
their
whole
application
stack,
and
for
that
you
know,
there's
order.
K
B
B
It
is
not
a
role
of
helm
to
be
in
the
orchestration
business.
We
want
to
focus
on
doing
a
few
things
right
and
the
things
that
we
are
doing
most
right,
I
think
are
the
chart
package
and
templating.
So
I
think
that
is
what
we
want
to
remain,
as
our
focus
orchestration
can
happen
around
helm,
but
we
do
not
really
want
to
open
that
can
of
worms
of
creating
too
big
of
a
system
for
helmets
off.