►
From YouTube: Deep Dive: Helm - Taylor Thomas, Microsoft
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 - Taylor Thomas, Microsoft
Join me for a deep dive into the internal workings of the upcoming Helm version 3! The goal is for all who attend to know exactly how the new code works and provide critical feedback to the maintainers. We will dig into and discuss the new architecture/functionality and explore each new part of the code. Along the way, we will stop for any discussions, questions, and concerns. Finally, we will discuss the migration and roadmap from Helm 2 to Helm 3. Come ready to see the exciting new changes and provide needed perspectives as we near the release of Helm 3.
To learn more click here: https://sched.co/FuLZ
A
3
also
I'll
go
over
what
we're
going
to
talk
about,
but
first
an
introduction
of
myself
I'm
Taylor
Thomas
I
am
one
of
the
core
maintainer
zuv
helm
I've
been
working
on
it
for
a
while
now
and
I
wanted
to
do
this
discussion
today
and
more
about
deep,
diving
into
helm,
3
and
what
it's
going
to
be
like.
So
the
structure
is
gonna,
be
a
little
bit
different.
I
don't
want
to
just
present
to
you.
I
want
to
get
some
feedback
as
well,
and
so
I'm
gonna
show
all
the
topics.
A
I
would
like
to
mention
that
we
could
talk
about
and
then
I'll
start
through
one,
the
first
one
that
I
think
is
probably
the
biggest
question
on
people's
minds
and
then
I
will
stop
after
I
describe
that
section
and
I
will
ask
for
questions
or
feedback,
and
then
we
will
keep
progressing
so
we
might
not
get
through
all
the
slides.
However,
these
slides
are
on
the
schedule,
page
I'm.
You
can
download
them
there
and
those
have
all
the
information
that
are
in
them.
A
So
before
I
start
I'm,
just
a
couple
big
thank-yous,
first
off
to
the
rest
of
the
helm,
core,
maintainer
team
and
helm,
three
is
not
something:
that's
easily
digestible
and
there's
a
lot
of
different
components
and
things
that
we've
learned
and
so
I
am
very
grateful
to
the
rest
of
the
maintainer.
So
if
helped
put
this
together,
also
specifically
Josh
Zielinski
who's,
one
of
the
maintainer
'he's,
he
wrote
a
lot
of
this
content
and
I
was
able
to
reuse
it
and
also
to
code
fresh.
They
provided
this.
A
These
beautiful
slides
that
I
didn't
have
to
do
so,
they're,
actually
pretty
so
just
a
big
thanks
to
them.
If
you
haven't
heard
of
them
before
go
check
them
out,
I
hope
this
kind
of
shows
that
helm
3
is
a
very
much
a
bigger
effort
than
just
what
Microsoft
lets
in
so
I
work
for
Microsoft,
but
helm
is
supported
by
various
companies
who
contribute
to
it.
It
is
really
a
community
project
so
to
understand
before
we
go
into
these
different
features
that
we're
going
to
have.
A
A
You
have
a
helm.
V1
was
announced
at
the
very
first
coop
con.
It
functioned
very
differently
than
we're
on
helm,
v2
right
now
and
then
he'll
merge
some
of
the
Google
man
Google
deployment
manager
into
the
code
base
as
well,
and
then
in
2016
we
released
helm
to
dotto.
Most
people
who
have
used
helm
at
this
point
have
used
helm.
Oh,
we
had
helm
summit
at
the
beginning
of
this
year
in
Portland
Oregon.
A
A
So
just
just
to
give
a
little
bit
of
details
around
this
we're
not
giving
a
specific
like
it
will
be
released
on
January
27
2019.
We're
not
we're
not
saying
that
yet,
because
we
don't
have
a
specific
idea,
but
I
can
give
you
some
timelines.
The
Alpha
is
coming
pretty
soon.
Let's
just
say
that
so
keep
on
your
toes
for
that
that
will
be
coming
out
once
again.
It
will
be
an
alpha,
so
there'll
be
some
things
missing,
but
then
we're
hoping
to
get
home
three
out
in
the
first
part
of
next
year.
A
What's
the
first
part,
you
say
I'm
not
going
to
say
because
I'm
I
don't
want
to
make
a
commitment
on
behalf
of
everyone
else,
but
it
will
be
coming
out
we're
not
trying
to
delay
this
or
stretch
this
out
to
make
make
it
a
problem
for
anybody
we're
just
trying
to
make
sure
it
is
well
put
together
for
the
community,
because
we
learned
a
lot
of
lessons
between
November
2016
and
now.
Kubernetes
has
advanced
from
I
think
when
we
went
to
version
helm
version,
two
I
think
we
were
at
kubernetes.
A
1.4
I
might
be
wrong
on
that,
but
we
were
all
the
way
at
1.12
at
this
point,
and
so
there's
been
a
lot,
that's
changed
in
helm
in
in
kubernetes
that
we
have
to
take
into
account
with
helm
now
just
another
one
more
note
around
this
being
an
exact
date.
If
anyone's
company
is
interested
in
providing
resources
to
help
with
this,
not
financial
resources,
but
engineering
resources.
We
are
more
than
welcome
to
those
to
that
opportunity.
A
So,
if
you're,
coming
as
an
interest
in
helping
out
with
helm
just
come,
talk
to
me
and
I
will
try
to
get
you
in
touch
with
the
rest
of
the
core
maintain
errs
so
another
thing
in
just
big,
bold
letters
here.
This
is
the
helm
three
project
cord
we've
had
a
lot
of
people
express
some
confusion
at
where
it
where's
helm.
Three.
What's
going
on,
it
doesn't
look
like
anything's
going
on
so
to
make
sure
that
everyone
knows
what's
going
on,
we've
put
everything
into
this
github
project.
A
But
if
you
haven't
been
aware
of
this,
yet
we
haven't
been
allowing
one-off
contributions
to
the
version
three
branch,
because
we're
doing
a
bunch
of
refactoring
work
that
is
extremely
critical
to
make
sure
we
get
right.
If
we
don't
do
that
right,
it
will
make
contributing
to
the
codebase
harder
and
make
less
of
a
good
software
project.
A
So
we're
not
accepting
one-off
single
feature
contributions
yet,
but
if
you
want
to
dig
in
on
actually
contributing
specific
large
chunks
of
helm
fun
reality,
you
can
take
a
look
at
that
project
board
and
reach
out
to
any
of
the
maintainer
x'
and
we'll
see
if
we
can
set
that
up
for
you,
okay,
so
major
changes
to
expect
in
helm
three.
This
is
just
gonna,
be
a
quick
overview
of
what
each
one
is
I'm
not
going
to
dive
into
it,
and
then
we're
gonna
go
dive
into
each
individual
topic.
A
So
just
note
that
many
of
the
things
we
talked
about
are
still
in
flux.
Right
now,
we're
still
hammering
out
a
few
of
the
last
details
and
they
are
going
to
probably
have
some
changes
from
what
you
see
right
here
by
the
time
it's
actually
released,
as
as
we
dive
into
the
examples,
I'll
try
to
note
when
those
are
things
that
we're
pretty
sure
will
change
or
other
question.
A
So
first
off
is
the
embedded
Lua
engine,
and
that
will
be
the
thing
that
will
trigger
that
will
be
used
for
hooks
and
also
for
advanced
chart
usage.
We'll
dig
into
that.
In
a
second
next
thing,
the
removal
of
tiller
okay.
This
is
extremely
helpful
because,
if
you've
used
helm,
which,
if
you're
here
you
probably
have,
if
you've
used
helm,
then
you've
probably
run
into
problems
with
tiller
or
worried
about
the
security
of
it.
We
remove
tiller
here,
yes,
execute
cheers.
A
Now
there
is
also
the
chart
repo
off
authorization,
so
you
can
log
into
a
chart
repo
and
be
able
to
upload
charts.
So
this
is
like
helm
push
and
you
can
push
a
chart
and
then
last
there
is
a
new
version
of
the
chart,
am
Olfa
the
chart,
llamo
file
so,
and
then
also
just
to
note
we
might
get
into
these
at
the
end.
If,
for
some
reason
we
have
time,
these
are
other
major
helm,
three
changes,
so
there's
managed
hooks,
meaning
if
helm
creates
a
something
with
a
hook,
it
will
delete
it
index.
A
Tommo
will
become
index
JSON,
since
this
is
a
deep
dive.
The
reason
why,
as
Hamill
parsers
are
slow,
so
we
are
switching
it
to
JSON,
because
the
JSON
parser
I
think
was
at
least
two
times
faster.
It
might
have
been
three
times
faster
and
so
we're
moving
that
over
and
it's
going
to
be
partitioned
out
for
performance,
so
you're,
no
you're,
no
longer
gonna
have
one
big
index
file.
It's
gonna
be
partitioned
out.
Also
we'll
be
able
to
schema
ties.
A
Your
values
file,
so
you'll
be
able
to
specify
what
types
of
values
or
accept
are
acceptable
in
your
values.
File
then
helm.
Client
libraries
will
also
be
much
better
right
now.
If
you
try
to
use
helm
inside
like
a
go
project,
you
end
up
importing
like
Kate's
dot,
io
/
kubernetes,
which
is
never
a
thing
you
want
to
import.
A
So
we're
going
to
make
sure
that
the
client
libraries
are
much
better
for
for
everyone
to
use
inside
of
another
client,
okay,
first
off
the
elephant
in
the
room
that
everyone
freaks
out
about
the
embedded
Lua
engine,
so
the
whole
idea
here
is:
we
want
to
make
helm,
charts
more
robust
and
program
programmable.
How
many
of
you
are
familiar
like
really
familiar
with
at
least
one
of
the
stable
charts
and
the
stable
repository
anyone?
A
Ok,
a
few
people
hey
those
charts-
are
immensely
complex,
they're
kind
of
actually
like
their
own
programming
language
on
the
inside.
You
have
if-then-else
blocks
inside
of
there
and
you
have
a
bunch
of
stuff
going
on
so
the
this
will
make
where
the
idea
was
int.
Why
don't
we
do
something
where
you
can
actually
do
some
programming
behind
it
now
this
is
going
to
go
over
what
this
is
going
to
look
like
we,
this
API
is
not
finalized
in
any
way.
Yet
we're
still
implementing
these
details
right
now,
but
I
know
it's
been
worked
on.
A
A
A
We
can
now
intercept
those
events
and
act
on
those
events
using
an
actual
programming
language.
Now,
the
one
of
the
other
things
is
that
Lua
we
chose
after
looking
at
multiple
languages.
It
wasn't
somebody's
pet
language.
We
actually
stacked
up
different
things.
Matt
butcher
wrote
a
blog
post
on
that
he's
one
of
the
other
maintainer
zuv
helm.
A
If
you
really
want
to
look
at
the
details
of
it,
but
one
of
the
big
reasons
is
we
can
embed
it
and
go
and
it's
a
sandbox,
so
you
can
limit
access
to
the
network
or
to
specific
IO
things
which
is
good
for
security.
One
of
the
other
possibilities
here
is
that
you'll
be
able
to
develop
an
import,
reusable
library,
charts
of
some
kind.
A
I'll
show
an
example
of
that
in
just
a
second,
and
another
thing
to
note
is
any
Hjelm:
plugin
will
also
have
access
to
the
Lua
runtime,
so
you
can
trigger
events
and
and
consume
those
events
inside
of
the
Lua,
the
Lua
scripts
that
you
have
so
first
off.
This
is
what
we
currently
have
in
helm
right,
so
you
have
the
you,
have
a
few
templates
or
things
from
the
values
or
release
file,
but
in
helm,
3
how
this
is
once
again.
This
could
totally
change,
but
this
is
what
it
could
look
like
inside
of
Lua.
A
So,
in
this
case,
you're
saying
hey,
create
an
alpine
pod
and
here's
all
the
pod
things
that
you
can
do
and
so
like.
For
example,
you
can
see
a
difference
here,
so
you
can
say
Heritage
release,
dot,
service
or
helm,
so
the
defaulting
is
a
lot
better
and
cleaner
than
what
we
have
with
the
default
template
directive,
and
that
can
then
be
used
like
this.
A
So
let's
say
you
have
that
creole
pine
pod,
you
can
say,
require,
like
my
library,
my
pod
library
I
want
to
get
a
new
Alpine,
3.7
pod,
and
so
now
you
have
this
pod
object.
I'm,
gonna
change
that
restart
policy.
To
always
and
add
it
into
my
manifests
once
again,
that
is
not
the
stable
API
that
could
look
completely
different,
but
that
is
something
that's
much
easier
to
use.
Then
even
the
current,
like
reusable
chart
stuff
we
can
pull
in
for
like
deployments
like
the
common
chart,
is
what
that's
called.
A
A
Yes
and
then
helm
will
install
it.
So
what
will
happen
is
when
you
call
that
create
alpine
pod
method.
It's
going
to
come
into
here.
It's
going
to
pull
out
all
of
these.
Basically,
this
pod,
which
is
like
a
generic
pod
definition
with
the
name
of
the
container
that
you've
passed
in,
and
so
then,
instead
of
having
to
manually
copy
paste
this
every
single
time.
A
A
A
The
question
was:
can
you
mix
the
two?
Can
you
mix
gamal
and
Lua?
The
answer
is
yes,
that
is
the
current
plan.
I,
don't
think
that
would
change,
but
we
want
to
make
sure
that
you
can
start
if
you,
for
example,
if
you
are
an
owner
of
a
chart,
you
could
start
adding
in
new
things
without
wholesale
having
to
replace
it
all
with
Lua.
A
A
So
the
question
was:
do
we
have
plans
to
make
it
pluggable?
Can
you
change
out
which
scripting
engine
I
can't
remember
the
official
thing
that
we
decided
on,
but
I'm
pretty
sure
we're
leaning
towards
that
will
be
possible
even
right?
Now
you
could
implement
a
separate
templating
engine
for
helm
two
there.
The
thing
is
there
nobody's
ever
done
it
so
I
I,
believe
that
will
be
available,
I'm,
not
sure
if
it
how
what
that
plug-in
model
will
look
like,
though,
if
we
go
that
way,
yeah.
A
So
the
question
is:
are
we
gonna
provide
tools
to
convert
for
the
helm
to
to
helm?
Three
I
am
pretty
sure
when
we
creating
a
tool
to
help
migrate,
anything
that
needs
to
be
migrated,
but
I,
don't
think
we're.
Gonna
have
anything
that
will
like
just
take
your
helm
to
chart
amal
and
turn
it
into
lua.
For
you,
I
don't
think,
there's
a
plan
to
have
that,
because
that
would
be
that
that
could
be
pretty
dangerous
because
right
now
you
have
like
I
said
in
the
charts
that
are
fairly
large.
A
You
have
big
logic
blocks
and
that's
really
hard
to
parse
out
and
turn
into
another
language,
and
so
we
don't
want
to
accidentally
like
mess
up
something
that
way
so
I
think
it's
easier
to
just
let
whoever
is
maintaining
the
chart,
move
that
over
okay,
we'll
move
on
to
the
next
thing,
then
so
yeh,
no
more
tiller.
So
the
the
big
thing
here
is
that
we're
improving
the
security
of
this
by
just
moving
our
authorization
to
kubernetes.
A
A
Now
when,
once
again,
that's
why
understanding
where
we
came
from
with
this,
when
we
created
helm
2,
we
didn't
know
that
things
like
C
RDS
would
be
created
in
the
way
that
they
were,
and
things
have
really
evolved
and
different
paradigms
have
come
around
because
of
it.
So
now
we
know
that
the
better
option
is
to
move
all
this
client-side
and
just
basically
talk
to
the
kubernetes
api.
So
all
the
rendering
and
everything
is
done
through
the
helm,
client
now
and
there's
no
tiller
what
that
does
for
us.
A
Besides,
the
auth
is
now
you
have
a
different
way
of
storing
the
releases.
This
is
one
of
those
things
that
is
in
flux
right
now,
we're
finalizing
the
final
spec
on
what
the
storage
will
look
like,
but
right
now
what
happens
is
when
you
store
a
release.
It's
a
config
map
that
has
basically
the
whole
release,
object,
kind
of
compressed
down
and
stored
inside
of
it
in
kubernetes,
but
now
it's
we're.
A
Gonna
have
a
release
and
a
release
version
object
that
will
contain
the
what
is
the
release,
name
and
basic
data
about
it
and
then
specific
versions,
so
that
keep
track
of
so
you
can
still
have
that
helm,
rollback,
functionality
or,
and
you
can
roll
back
to
a
specific
version.
So
that's
going
to
be
the
main
difference
there.
A
So
what
this
looks
like
now,
so
here's
there's
the
current
helm
to
model,
so
we
have
to
have
G
RPC
set
up
and
as
we've
known,
if
you've
followed
the
helm
project
at
all,
we've
had
plenty
of
problems
whenever
we
try
to
upgrade
G
RPC
or
do
anything
around
it,
and
so
getting
rid
of
that
will
really
help.
So
then,
you
have
tiller
and
tiller
talks
to
the
kubernetes
api
and
stores
things
and
config
Maps.
What
this
now
will
look
like
is
we'll
have
the
helm
CLI.
A
It
talks
over
HTTP
to
the
kubernetes
api
and
then
that
kubernetes
api
will
have
the
CR
d
objects
that
will
keep
track
of
the
releases
and
then
it'll
install
into
into
that.
Ok,
so
there's
there's
the
removing
till
of
tiller.
Does
anyone
have
any
questions
with
that
that
one's
big,
but
I
don't
think
there's
gonna
be
too
many
around
this.
A
A
A
Anyone
want
to
correct
me:
okay,
1.7,
okay,
so
in
1.7,
so
as
long
as
your
cluster
is
is
newer
than
1.7,
which
I
think
if
you're
using
any
of
the
cloud
providers
I,
don't
think
any
of
them
support
1.7
anymore,
if
you're
doing
your
own
and
you
don't
have
1.7,
you
might
have
to
upgrade.
But
as
long
as
you
have
the
support
for
CR
DS
in
there,
then
you'll
be
able
to
to
do
this.
A
A
Yeah,
so
the
question
is:
does
it
change
how
you
pass
authorization
authorize
with
kubernetes
it,
the
answer's
no
you're
using
underneath
it's
just
using
the
kto,
slash
client
go
library,
so
the
normal
kubernetes
go
client
underneath.
So
it's
going
to
be
using
the
same
authorization
mechanisms,
so
a
coop
config
that
it
reads
and
uses
the
token
and
then
authenticates
with
the
kubernetes
api,
and
so,
whichever
user
is
running
it
it's
going
to
be
running
as
that
user
and
the
are
back
roles
for
that
user
will
apply.
A
A
A
The
question
is:
are
there
any
problems
with
working
with
Kubb
fed
version
to
the
truthful
answer?
For
me?
Is
I,
don't
know
because
I
haven't
looked
at
the
version
2
stuff,
yet
I'd.
Imagine
that
it
wouldn't
just
based
on
line
as
long
as
you
have
like
the
the
same,
like
you're.
Normally,
if
I
remember
the
version
1,
which
is
what
I'm
used
to
you're
logging
in
through
that
Federation
control
plane.
A
A
Okay
of
releases
that
are
already
there.
Yes,
the
plan
is
we're
trying
Everest
we're
trying
to
make
sure
that
that
is
backwards,
or
we
have
some
sort
of
way
for
you
to
like
run
a
migration
pass.
I,
don't
know
if
we
finalized.
If
we're
gonna
like
give
a
tool
to
migrate,
all
your
current
things
over
to
a
helm,
three
and
then
you
install
home
three
or
if
it
is
going
to
be
a
run
of
Shem,
and
then
it
talks
through
that
Shem
or
whatever
it
might
be.
A
A
A
A
Oh,
okay,
sensitive
data,
okay.
How
so
the
question
is
how
to
store
sensitive
data
in
the
API
I.
Believe,
that's
what
we're
addressing
with
the
new
spec
that's
going
to
come
out,
so
we
want
to
address
like
how
we're
storing
like
this
things
that
are
secret,
and
what
and
all
those
details
around
that
so
I
would
have
to
check
with
the
final
spec
when
it's
done.
I
was
warned
before.
I
gave
this
talk
that
that's
one
of
the
things
that's
going
to
change
that
they're
finishing
up,
so
I
am
NOT
certain.
A
What
exactly
they're
going
to
do
with
it,
but
I
know
that's
one
of
the
considerations
that
they
brought
into
the
final
spec
for
it
anything
else
around
this.
Okay,
awesome!
Sorry,
it
is
getting
hot
in
here.
I
hope
nobody
falls
asleep,
but
whoo,
okay!
So
next
thing
this
is
a
pretty
big
one.
So
this
is
a
chart,
repo
authorization
and
upload.
So
there
are
new
commands
and
an
API
spec
for
working
with
chart
repositories.
This
is
another
thing
where
actually,
someone
came
in
with
another
idea
for
this.
A
That's
really
compelling
and
they're
having
some
final
debates
around
it.
Right
now
about
where,
where
charts
can
be
stored,
for
example,
alongs
like
inside
of
an
of
an
image
repository,
sometimes
alongside
with
the
same
image,
that's
generally
run
so,
but
that's
not
a
final
thing.
This
is
something
of
they're
debating,
but
no
matter
what
we
we
go
with
we're
going
to
have
a
helm
command
that
uploads
the
chart
to
a
repo.
So
instead
of
having
this
like
manually,
have
to
upload
or
as
chart
museum
made
it
easier,
you
could
submit
it
to
that
API.
A
A
We
can
also
have
plugins
that
are
there
and
can
specify
custom
protocols.
One
of
the
common
ones
is
like
with
an
s3
bucket
or
with
an
azure
storage
container,
so
that
you
can
push
to
some
to
a
specific
storage
back-end.
We
also
want
to
add
a
helm
logging
or
we
not
just
we
want
to.
We
are
going
to
add
a
helm,
login
command
to
authenticate
against
a
repository
just
like
how
you
have
dr.
login
to
log
into
a
container
repository.
A
The
plan
is
for
that
to
be
an
OAuth
2
authorization
flow,
so
you
have
a
bearer
and
token
authorization
and
you'll
be
able
to
do
things
like
limit,
which
users
can
upload
and
install
which
charts
I
know.
That's
one
of
the
big
things
inside
of
a
company
is
everyone's
like
wait.
I
don't
want
these
users
to
be
able
to
install
these
like
it
really
important
charts
or
that
are
special
for
this
group
or
whatever
I've
heard
so
many
stories
about
them.
A
So
this
is
going
to
address
that
by
allowing
people
to
limit
who
uploads
and
downloads
those
charts.
So
just
if
you
want
to
know
where
that
HTTP
spec
is
coming
from,
it's
the
it's
based
on
what
chart
museum
is
right.
Now
it's
using
that
as
kind
of
the
base
protocol
for
it.
You
can
follow
that
discussion
through
the
community,
repo,
github,
comm,
slash
home,
slash,
community
and
I
think
there's
some
discussion
in
there.
A
A
Through
your
repository,
you
have
to
package
up
the
chart
and
then
you
generally
have
some
script
that
has
your
chart
and
can
upload
it
to
the
right
repository,
and
then
you
can
update
your
app
to
your
information
about
it
and
then
you
can
install
the
that
chart
and
generally
this
custom
uploader
involved,
like
making
an
index
file
you'd
have
to
re
index
for
your
repository.
But
the
idea
in
helm,
3
is
that
this
becomes
helm
login
and
it
will
do
the
whole
flow
for
you.
A
I
want
to
add
whatever
repo
I
just
logged
into
I'm
gonna
push
that
chart
to
a
repository,
and
then
you
can
pull
it
down.
So
there's
no
more.
This
custom
uploader
logic
that
you
have
to
do
yourself,
I'm
happy
about
this,
because
every
company
I've
been
at
I've
generally
implemented
some
sort
of
custom
chart
posit
or
e.
So
this
will
make
it
much
easier
from
that
perspective.
Ok,
questions
about
this.
Yes,.
A
You
so
the
question
is:
where
are
the
rolls
coming
from
for
the
repositories?
These
rolls
are
part
of
the
API
spec
they're
not
going
to,
because
you
don't
have
to
host
your
charts
on
a
kubernetes
cluster,
so
it's
going
to
be
its
own
spec.
That's
that's
delving
into
some
of
the
details
that
I
don't
know.
That's
where
actually
Josh
de
litski
and
Matt
Farina
are
the
two
maintained
errs
who
are
working
on
that
very
directly
and
they'll
know
this
very
specific
details,
but
I
know
that
it's
part
of
the
actual
spec
they
are
writing.
A
A
A
A
A
A
The
question
is
so:
with
this
new
push
mechanism
and
because
it's
based
on
chart
museum,
are
we
required
to
use
chart
museum
that
a
good
way
to
say?
Okay
and
the
answer
to
that
is
no,
you
do
it's
based
on
what
we
learned
from
chart
museum.
It
isn't
you
don't
chart
museum
is
a
great
option
like
right
now,
if
you
need
a
solution,
it's
a
good
option,
but
it's
not
the
requirement
for
this.
This
is
just
giving
it
the
ability
to
have
a
spec
that
can
be
implemented
by
by
anything.
A
A
So
this
new
chart
gamal
the
current
chart,
dot.
Yeah
no
files
will
not
be
broken
by
the
new
changes
here.
We're
still
are,
basically,
we
are
combining
the
requirements
tamil
file,
which
was
created
in
the
first
place.
To
for
backwards
compatibility.
We
didn't
want
to
break
certain
workflows,
but
the
requirements
file
will
no
longer
exist,
and
so
what
this
looks
like
is
right
here,
the
helm.
A
You
have
your
requirements
yeah
mo
up
here
and
then
your
chart
UML
and
instead
of
these
being
separate
files,
then
I'll
be
combined
into
a
single
chart,
Yama
file
that
specifies
your
dependencies
for
that
project.
This
is
something
that
just
changed
before
I
wrote.
This
talk
so
once
again
the
final
spec
document
documentation
is
coming,
but
it's
not
there.
Yet.
This
is
just
a
very
recent
change
that
was
decided
up
on
any
questions
about
this
part.
A
Okay,
that's
good
just
last
things
here.
If
you
want
to
know
more
about
helm,
three,
the
main
design
proposal
is
that
the
master
helm
v3
we're
starting
final
documentation
of
the
helm
specs
right
now,
so
that
could
update
soon.
We'll
try
to
put
a
note
in
there
that
points
to
the
new
the
final
specification.
This
was
what
we're
the
design
proposal
was
where
we
were
working
on
it
as
we
kind
of
fleshed
out
the
ideas
and
now
work
to
the
point
where
it's
like
finalize
specs.
A
If
you
want
to
see
what
is
going
on,
all
of
this
is
public.
You
just
have
to
go
to
the
dev
v3
branch
inside
of
helm,
and
that
has
all
of
the
things
we've
done
thus
far.
So,
for
example,
I
know,
tillers
all
the
way
out,
I
think
we're
getting
close
on
the
Lua
engine.
It's
not
all
the
way
there,
but
that's
all
in
place.
So
any
of
that
we
have
like
two
minutes.
If
there's
any
other
burning
questions,
people
have
one
more
in
the
corner.
Yes,.
A
So
I
think
you
came
in
after
I
talked
about
this.
So
the
a
reminder
for
those
who
did
come
in
late.
The
Alpha
is
coming
soon
pretty
soon
and
we're
hoping
to
release
by
the
first
part
of
next
year
were
once
we
get
these
final
things
in
place,
we'll
be
in
a
good
place
for
an
alpha,
yes,
release,
alpha
yeah
release
alpha.
It
is
like
very
soon,
and
the
next
year
will
be
like
the
GA
will
move
to
like
a
beta
and
a
ga.