►
From YouTube: Webinar: Charting Your Voyage To Helm 3
Description
Helm, a recently graduated CNCF project, has a major new version. Changing your Helm version may sound like a large undertaking; you may wonder where to start. Join Helm maintainers Matt Farina (Samsung), Martin Hickey (IBM), Adam Reese (Microsoft), and Bridget Kromhout (Microsoft) for a tactical discussion of exactly how to manage your migration from Helm 2 to Helm 3. We’ll cover what the major differences are and how to make your change with a minimum of disruption. We aim to answer questions and help you plan for a successful migration to Helm 3.
Presenters:
Matt Farina, Senior Staff Engineer @Samsung
Martin Hickey, Senior Software Engineer @ IBM
Adam Reese, Senior Software Engineer @ Microsoft
Bridget Kromhout, Principal Program Manager @ Microsoft
A
Alright,
let's
go
ahead
and
get
started
I'd
like
to
thank
everyone.
Who's
joining
us.
Welcome
to
today's
CN
CF
webinar,
charting
in
your
voyage
to
helm,
3
I'm,
Keri,
Chu
community
manager,
a
your
container
computes
on
the
Asha
Kadena
compute
team
and
CNCs
ambassador
I'll
be
moderating
today's
webinar
and
would
like
to
thank
our
presenters.
A
Today
we
have
Matt
fraina
senior
staff
engineering
engineer
at
Samsung
or
in
Hickey
senior
software
engineer
at
IBM,
Adam
riess
senior
software
engineer
at
Microsoft
and
Bridger
come
up
principal
program
Medicare
at
Microsoft
and
just
before
we
start
we
have
a
few
housekeeping
items
during
the
webinar.
You
will
not
be
able
to
talk
as
an
attendee.
There
is
a
Q&A
box
at
the
bottom
of
your
screen.
Please
feel
free
to
drop
in
your
questions
and
we'll
get
through
as
many
as
we
can.
A
This
is
an
official
CN
CF
r,
so
it
is
subjective,
please
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
the
code
of
conduct.
Basically,
please
be
respectful
of
all
your
fellow
participants
and
presenters.
Please
also
note
that
the
recording
will
be
posted
later
today
to
the
scenes.
Yebin,
our
CN
CF
iOS
lack
of
Menards
and
that
I
will
hand
it
over
to
Matt
Martin,
Adam
and
Britt
to
kick
off
today's
presentation.
So.
B
C
Thank
you,
so
my
interest
in
the
helm
to
helm
three
move
is
well
held.
Shoe
has
its
end
of
life
coming
up
here
and
it's
really
different
from
helm,
3,
architectural
II,
and
so
it's
a
lot
of
extra
work
for
us
to
support
both
versions
and
we've
got
a
period
a
good
year
of
overlap
and
when
that
comes
to
an
end,
we're
gonna
be
supporting
a
healthy,
and
yet
we
want
everybody
to
be
supported,
get
security
updates
and
be
on
the
path.
And
so
that's
really.
C
My
big
interest
in
helm,
3
I,
do
have
a
side
interest,
though
I
do
have
a
site
interest,
so
helm
tube
is
connected
to
the
stable
repository
that
the
helm
organization
serves
up
and
the
stable
repository
has
tons
of
charts
in
it
and
moves
and
has
moved
at
such
a
fast
pace
that
in
many
ways
it
became
well
difficult
to
maintain
and
in
helm.
3.
C
We've
now
switched
to
a
distributed
model
using
the
helm
hub
and
other
things,
so
that
people
like
you
out
there
who
are
listening
can
run
your
own
repositories
and
we
get
out
of
the
way
right.
It
takes
a
long
time
sometimes
to
get
reviews
and
things
merged,
and
it
can
be
frustration
working
with
us,
maintainer
x'
of
the
charts,
repo
and
in
home
3.
C
B
D
Thanks
Bridget,
so
from
my
perspective,
I
suppose
I've
come
in
in
around
looking
at
the
helm,
tree
stuff
and
working
on
and
for
me
I
suppose.
The
big
thing
is
that
I
suppose,
because
things
have
moved
on
since
when
hellim
2
was
first
created,
I
know
we
got
helm
tree,
it
has
a
load,
the
people
from
the
community
to
work
on
this.
The
changes
have
been
made
have
been
able
to
say:
ok,
we
can
simplify
it.
We
can
take
tiller
rows.
D
We
can
talk
directly
to
the
kubernetes
api
server
and
it's
just
progress
that
has
come
along
as
matt
touched
on
earlier.
It
has
changed.
The
change
under
the
hood
between
hem
to
hem
tree
is
quite
big.
The
infrastructure
has
changed,
the
Pearlman
has
changed
in
there
and
a
quite
different
code
bases
so
to
speak.
D
So
I
think
for
me
getting
people
to
move
over
getting
them
to
see
what
the
simplification
is,
how
it
makes
your
life
a
little
bit
easier
in
in
ways
and
and
as
Matt
touch
on
as
well
is
trying
to
support
two
code
bases
like
this
is
gonna
be
quite
differ.
We
know
gone
down
the
line,
we're
going
to
be
in
the
service
or
end
of
life,
for
him
to
codebase,
so
I
think
for
a
lot
of
people.
D
You
know
if,
when
they
start
using
him
tree
when
they
see
that
the
benefits
of
it,
that's
there
I
think
you
know
it's
it's
just
getting
over.
That
fact,
can
we
migrate
across
and
so
forth?
I
think
that
may
be
the
big
big
bridge
to
jump
which
we
talk
about,
but
yeah
just
getting
people
on
there,
seeing
what's
there
and
seeing
what's
available,
yeah.
B
E
E
So
I
would
just
like
to
ease
people's
comfort
with
switching
to
helm
3.
It
is
a
much
simpler
architecture.
It's
a
lot
easier
to
debug
stuff
helm.
One
actually
had
this
architecture
and
going
to
the
client
server.
We
we
thought
we
could
improve
it
again
with
simplification
with
debugging
with
really
knowing
what's
going
on.
B
Fantastic,
so
this
is
a
different
model
than
a
lot
of
webinars
and
we
might
talk
over
each
other
and
that's
okay,
I
think
we're
all
pretty
excited
about
this
topic.
I
think,
probably,
let's
just
dive
in
you
all
kind
of
alluded
to
things
being
different
and
conceptually
architecture.
Well,
the
practical
standpoint:
what
are
people
gonna
notice.
B
C
So
I,
you
know
I'll
jump
in
here,
because
I'm,
quick
to
jump
in
on
things
so
feel
free,
Martin
Adam,
to
interrupt
talk
over
and
add
to
tiller
was
at
it
in
helm,
too.
It
was
added
with
the
merger
of
helm
version,
one
which
didn't
have
a
server
side
component
and
deployment
manager,
which
is
a
kubernetes
project
when
the
two
merge
together
and
deployment
matter
manager
had
the
server
side
component
and
it
turns
out
that
there's
there
was
a
lot
going
on
there.
One
controllers
at
the
time.
C
This
was
before
custom
controllers
and
kubernetes
and
all
of
that
stuff
and
so
tiller
acted
very
much
as
a
custom
controller,
but
that
created
lots
of
problems
because,
as
custom
controllers
became
more
mature
tiller
already
had
an
architecture
and
we
were
very,
very
big
into
backwards.
Compatibility
because
kubernetes
changes
a
lot.
C
Let's
be
honest,
there's
a
lot
of
changes
in
kubernetes,
but
we
we
want
helm
to
be
very
stable
and
in
long
use,
and
so
it
doesn't
move
out
from
underneath
you
as
you're
using
it,
and
so
we
needed
to
change
something
and
one
of
the
things
we
realized
in
helm.
3
was
we
didn't,
need
the
server
side
component
anymore.
C
We
could
do
everything
client-side
the
way
it
wasn't
done
in
the
beginning,
and
that
also
expands
the
use
cases,
because
in
order
to
install
a
modern
controller
and
do
some
of
those
things,
you
need
admin
level
permissions
in
a
cluster
and
I've
learned
that
not
every
cluster
operator,
every
organization
that
you
are
in
a
cluster
is
going
to.
Let
you
install
those
cluster
level,
things
to
install
applications,
and
so
by
also
removing
it.
E
Jump
in
with
one
everything
with
removing
tiller
as
well
in
talking
about
the
controller
model,
when
we
came
out
with
helm
to
that,
we
really
didn't
fully
understand
how
a
Cooper
identities
was
going
to
be
used
in
an
organization.
Yet
we
had
some
input,
but
we
weren't
sure
about
you
know
permissions
around
user
accounts
weren't
available.
Yet
there
was
no
such
thing
as
are
back
yet
so
there
was
limitations
with
having
internal
server
component,
create
all
the
resources,
because
then
it
was
tiller
responsible
for
creating
everything.
So
it
was
the
user
of
tiller.
C
Maybe
here's
a
way
to
think
of
it
to
write
in
in
kubernetes
terms,
helm
to
until
her
pretty
old
right,
I
was
looking
it
up,
so
tiller
was
created
and
home
to
was
released
before
secrets
were
stable.
Right.
Think
about
that,
and
some
of
some
of
you
are
listening,
may
not
have
been
doing
kubernetes
things
back
when
secrets
weren't,
stable
right.
C
Yes,
so
you
know
there
was
that
going
on,
so
you
know
you
know
another
thing,
since
we
were
able
to
do
this
and
I
think
Adam
do
you
actually
might
have
been
the
person
who
did
this
work?
Helmand
it's
gone
right
because
Helmand
it
was
there
to
install
tiller
and
when
you
don't
need
it,
you
don't
eat
home
in
it.
D
No
setup
and
I
think
that's
what
matter
said
there
and
what
you
say
as
well.
Adam
is
that
is
a
big
point
for
users
and
it's
something
that
comes
in
a
lot
about
around
helm
in
it
and
knotting
happened
the
commands
not
there
any
longer,
and
it
does
surprise
people.
So
it's
it's
that
simplification
or
on
this,
as
you
say,
one
binary,
you
know
worried
about
the
tiller
service
running
in
the
cluster
you're,
not
worried
about
connection
issues.
How
Co
often
have
we
seen
G
RPC
connection
issue.
D
You
know
those
kind
of
things,
so
it's
it.
It
is
kind
of
that
simplification
which
then
transfers
up
to
the
user
level
so
when
they
don't
have
to
deal
with
certain
things
like
that.
So
generally,
no
because
you
have
the
binary
talking
directly
to
the
API
service
that,
if
you're,
if
you
can
connect
to
your
cluster
work,
you
cuddle
or
cube
CTL,
then
basically
him
should
be
able
to
connect.
C
And
helm
uses
those
same
credentials
right.
So
when
you
log
in
with
coop
ctlr,
you
log
in
with
those
same
credentials
help
just
picks
that
up
and
use
a
server
side,
and
you
could
totally
do
that
in
helm,
v2
through
some
total
backwards
ways
and
the
developer
documentation
that
I
doubt
most
people
did.
D
Yeah,
what's
nice
as
well
as
to
that,
as
you
said,
is
that
you
can
build
on
it.
So
as
well
as
using
the
cube
config
files,
you
can
also
override
using
Eric's
on
the
command
line
as
well.
So
if
you
have
many,
if
you
have
a
lot
of
cube
contexts
and
you
want
to
use
them
on
the
fly
instead
of
changing
the
context,
the
whole
time,
you
can
just
call
it
directly
with
heaven
when
you
run
the
command
yeah.
B
I
just
wanted
to
interject
and
say
we
have
had
people
note
that
we
did
push
forward
the
amount
of
time
we
were
gonna
do
bug
fixes
due
to
the
current
code
situation,
and
we
currently,
we
still
plan
on
having
our
November
13th
date
for
being
done
with
bug,
fixes
and
security
fixes,
bug,
fixes,
I,
think
we
push
to
like
August
or
so
and
then
security
fixes
for
November.
That
is
the
current
plan.
All
plans
can
change.
We
don't
currently
plan
on
changing
it.
I.
A
D
See
a
nice
question
from
the
community:
okay,
so
I'm
gonna.
What
I'm
gonna
do
is
I'm
gonna
answer
some
of
this,
but
I
want
to
bring
it
over
to
Matt
in
because
it's
it's
radio,
Peter
he's
Ali
and
also,
you
know,
hopefully
he'd
bat
it
out
of
the
park
once
when
something
is
sorry
for
the
core
ball.
That's
coming
your
way!
So
there's
a
question
in
from
from
a
person
on
the
talk
and
I'll
just
read
the
question
real
quickly:
oh,
my
goodness.
Those
words
with
th.
D
Isn't
it
so
helm
tree
is
more
compelling
in
every
way
and
it
makes
sense
to
move
over
as
fast
as
possible.
That
being
said,
why
is
it
taking
so
long
for
official
helm,
tree
charts
to
replace
or
helm
two
versions?
I
would
think
anyone
who
is
a
product
that
rooms
a
coup
in
kubernetes
would
have
a
no
fish
at
home.
Treat
sharp
I,
know:
okay,
so
I'm
just
going
to
take
the
initial
as
part
of
this
I
think
there's
a
really
good
question.
D
Jay
and
just
to
answer
from
the
perspective
like
forced
and
foremost
helm,
two
charts
can
still
run
be
rendered
and
deployed
are
with
helm
tree.
So
there's
no
problem
that
way
and
it
will
use
the
API
version
v1
in
the
chart.
If
you
don't
have
it,
it
takes
v1
by
default
for
any
new
capabilities
we
put
in
in
charts
you
your
chart
needs
to
be
combed
in
API
version
v2,
so
your
charts
don't
have
to
get
changed
over
for
the
helm
tree
format.
They
can
be
still
used
now.
D
One
exception
on
that
are
CR
DS,
which
we
may
tackle
later
on
and
what's
happened
with
CR
DS
is
there's
a
different
way
to
install
them
no
and
we're
not
using
CR
D
hooks
anymore,
but
as
I
say,
you
can
still
can
still
run
your
charts.
Consider
in
Durham
deploying
and
that's
the
most
important
thing
so
I'm
gonna
hand
over
to
Matt
now
into
relation
of
what
you
think,
the
strategies
around
charts
moving
forward.
What
charts
do
you
think
that
need
to
become
using
hem
tree
farmers
or
API
version,
v2
and
I?
C
Okay,
but
first
I'm
gonna
let
people
in
on
one
of
our
little
inside
secrets
here.
So
yes,
Martin
shaking
his
head,
because
when
you
hear
him
say
helm
three,
one
of
the
words
because
of
his
accent.
It
sounds
kind
of
like
tree.
You
know
like
a
tree
in
your
yard
and
so
every
time
I
hear
Martin,
say
helm.
Three
I
hear
him
say:
helm
tree
and
I.
Just
laugh
inside
I
laugh
inside
it's
amusing.
To
me,
it's
one
of
our
little
inside
jokes
Martin
has
a
good
sense
of
humor
about
it.
C
But
maybe
you
can't
unhear
that
now
too.
So
what
I
think
about
the
charts
repose
and
the
reason
that
you
we
don't
have
more
helm
three
ones
is-
is
actually
because
helm,
two
charts,
with
the
exception
of
that
that
CRD
difference
can
run
in
helm
three
and
if
you're
gonna
go
ahead
and
have
if
we're
gonna,
support,
helm
and
helm
three
and
there's
lots
of
home
to
user
still
in
the
wild.
Maybe
like
many
of
you
who
are
looking
to
switch,
then
you
want
to
have
maybe
one
version
of
a
chart
that
you
support.
C
That
can
run
in
both
places,
and
so,
if
you've
got
a
chart,
you
want
to
support
both
helm,
two
and
helm.
Three.
You
use
a
Humvee
one
chart
right
with
API
version,
one
that
ran
in
helm
two
and
if
you
want
it
to
you've,
got
CR
DS,
where
you
want
it
to
work
in
both.
You
have
the
c
rd
directory
with
the
CR
DS,
and
you
have
the
c
rd
hooks.
C
You
have
to
do
a
little
dual
duty
there,
but
if
you
do
that,
then
it'll
install
in
both
versions
and
in
both
locations,
so
I
expect
to
see
a
lot
more
helm.
Three
native
charts
to
show
up
and
people
to
switch
to
those
features
once
home
to
is
no
longer
supported.
But
right
now
you
want
to
have
that
dual
layer
of
support
for
both
versions
in
both
users,
and
so
that's
when
I
expect
it.
We
are
moving
away
from
having
the
helm
project,
have
an
official
charts
repository.
We're
not
gonna.
C
Have
this
big
charts
repository
quite
frankly,
because
it
grew
to
be
mostly
unmaintainable.
We
had
lots
of
people
who
would
be
maintainer
of
the
charts
repo
who
would
burn
out
attempting
to
spend
lots
of
time
we're
never
able
to
keep
up
with
the
load,
no
matter
how
any
different
automation,
things
or
different
layers
we
put
in
and
it
just
became
hard,
and
so
our
hope
is
by
going
to
a
distributed
model.
We
we
move
all
of
that
out.
C
E
One
more
thing
on
that
topic
is:
we
charts
are
like
the
package
format,
which
is
actually
version
differently
than
helm.
Helm
is
how
you
manage
them
and
do
releases,
and
all
that
so
you'll
notice
that
the
versioning
doesn't
match
up
with
the
helm
binary,
because
right
now
we're
on
chart
version.
2
is
the
highest
with
version
3,
so
we're
going
to
try
to
remain
backwards.
Compatibility
with
charts,
moving
forward
count
3.
It
was
just
laying
the
foundation
mostly
for
feature
ads
going
forward
and
simplification
I.
B
Hey,
cool
roll
up
with
a
code
we'll
do
it
a
home
is
a
project
that's
used
by
so
many
people
in
production
for
realsies
that
we
probably
aren't
going
to
make
super
rash
decisions
like
that.
You
just
pulled
all
the
numbers
in
in
fariña
and
they're
there
in
a
blog
post
that
the
CNC
F
put
out.
So
people
can
go
read
about
these
numbers,
but
it's
a
very.
It's
used
pretty
frequently
yeah.
D
C
Was
the
yes,
they
did.
The
only
number
that
I
pulled
was
the
2
million
downloads
in
a
month,
which
is
massive
because
when
we
were
well
in
San
Diego
at
coop
Kahn's,
an
diego
cloud
native
con
san
diego,
it
was
1
million
in
a
month
and
then
fast
forward
to
helms
graduation
less
than
six
months
later
and
had
jumped
it
to
that
just
blows
my
mind.
C
Quite
frankly,
to
the
number
of
downloads
we
got
from
all
the
different
places
it's
downloaded,
but
that
was
really
the
scene
CF,
but
because
so
many
people
use
it,
we
don't
look
to
make
radical
changes.
We
want
to
make
stable,
well
tested
changes
and
we're
slow
to
make
changes,
but
because
we
know
that
there's
a
lot
of
people
who
want
to
expand
around
it,
we
do
like
it
when
people
write
rapper
programs
around
him.
So
oh
I
want
this
logic
in
these
extra
things.
C
Well,
I
can
do
it
with
two
steps
with
home
or
a
step
with
home
and
coop
control
in
my
CI
system.
Instead
of
adding
the
feature
to
helm,
sometimes
it
works
to
wrap
it
with
your
own
script
and
we
like
it.
We
also
have
plugins,
so
home
does
have
plugins
in
order
to
expand
on
things
and
those
are
engine
home,
2
and
M
3
and
just.
D
Kind
of
jumping
on
on
that
one,
what
what
Richard
was
saying
and
what
you
were
saying
there
Matt
one
thing:
I
learned
when
I
first
came
on
the
han
project
was,
you
know
we
don't
break
the
API,
we
are
backwards
compatible
and
initiate
artists
with
some
cult
kind
of
initiation
ceremony,
but
I
have
to
say
you
know:
I've
worked
on
different
software
over
the
years,
hem
abide
by
the
T,
api's
and
I.
Remember
early
on
reviewing
a
piece
of
code
and
the
code
was
was
a
grand.
D
It
was
perfect
and
then
you
know
someone
said
to
me:
well,
you
know
what
I've
break
in
the
API.
You
know
yeah
you're
right.
We
don't
break
the
API,
so
you
know
kind
of
what
Bridgette
was
saying
there
was
people
often
look
for
functionality
and
I
wonder
why
can't
I
get
that
in
there
and
we
might
say
something
like
you
know:
that'll
go
into
Henry
or
no
with
my
going
to
heaven
for
the
reason
behind
it
is
that
we
we
don't
want
to
break
that
backwards,
compatibility
and
just
keep
that.
D
E
C
Yeah
and
it's
not
that
we're
gonna
not
do
some
of
these
things
like
I.
Remember
this
one!
So
we
have
this
annoying
thing
where
this
is
one
place
where
dates
are
in
a
different
format,
one
place
and
we
really
want
to
fix
it.
But
there
are
tools
that
parse
the
output
and
use
the
date
today.
So
we
would
break
those
tools
that
are
choosing
this
date
today.
C
So
we
really
want
to
fix
it
and
we're
totally
changing
it
in
helm,
four,
but
it's
an
API
contract
because
things
consume
the
output
of
it
today
and
we're
going
to
break
them.
If
we
change
the
date
string
format
right
because
there
are
other
things
written
and
go
so
they
parse
it
in
a
certain
format
and
we're
going
to
break
them,
and
people
use
all
this
stuff
in
production.
B
And
that's
that's
actually,
a
really
good
segue
to
I.
Think
one
question
that's
in
everyone's
mind
because
they
got
to
migrate
at
some
point
and
we
talked
a
little
bit
about
this
before
but
like
this
idea
of
home
three.
What
if
I
just
take
my
home
to
release
exactly
as
it
is?
How
does
that
work?
Not
my
charts,
but
like
my
release,
what
is
that
experience
I
give.
E
C
D
Yeah
sorry
I
thought
you
would
just
see
you're
just
playing
a
game
on
me.
I
thought
you
couldn't
hear
me:
okay,
migrations,
okay,
so
I
think
I
have
made
a
very
good
point
earlier,
because
I
made
a
broad
statement
said:
look
the
action.
The
architecture
did
change
quite
a
bit
and
I'm
gonna
say
these
statements
again:
don't
worry,
I'm
an
atom
cam
down
there,
I
CPR
training,
the
architectures
changed
enhancer,
a
yes
from
him
to
the
infrastructure
under
the
hood
and
and
the
code
base
to
a
certain
degree,
but
that
is
under
the
hood.
Okay.
D
So
what
I?
What
I
said
earlier
was
your
helm
to
charts,
will
still
run
a
render
and
and
deploy
your
objects.
I
come
in
at
these
objects,
as
always?
Okay.
So
that's
that's!
That's
me
and
aspect.
So
where
does
migration
power
come
in?
So
it's
it's
really
just
it's
two
parts
put
their
key
parts
that
are
generally
hidden
away
from
users,
except
the
really
advanced
users
who
like
to
go
in
what
I
call
go
in
the
back
door
and
do
things
under
the
hood
so
years
ago.
D
If
it
was
a
database,
you
know
our
product
that
had
a
database,
it
might
be
the
person
who
goes
in
and
hacks
back
in
database
wipes
the
whole
database
and
they
can
understand
where
the
product
doesn't
work
anymore.
Those
kind
of
people
bought.
You
know
those
people
are
important
too.
So
why
we
need
is
migration.
Over
is
first
of
all,
it's
the
configuration
state
so
any
state
for
the
different
configuration
items
for
helm
that
has
changed
in
helm
tree.
D
So
that's
the
force
part
that
needs
to
be
migrated
over
and
then
the
other
part
is
how
we
store
or
release
objects.
Okay,
so
yes
we're
using
secrets
to
stills
or
objects,
and
some
people
will
say
oh
yeah,
but
you
could
configure
him
to
to
store
secrets
that
was
correct
by
default,
it
was
config
maps,
but
it's
how
we
store
the
release
object.
Knowing
the
secrets
is
the
important
aspect,
because
we've
changed
that
object,
so
we're
no
longer
using
the
because
we're
no
longer
communicating
with
Taylor
and
we
don't
need
gr,
PC
and
protobuf
objects.
D
We've
now
gone
to
have
an
object
and
that's
a
different
format.
So,
if
what
you
can
do
at
the
moment
is,
you
can
currently
run
two
versions
of
helm
and
your
own
system
managing
the
same
cluster
or
managing
same
applications
in
the
same
cluster.
So
you
as
long
as
you
change
the
name
to
the
binary,
because
both
pointer
is
a
current
helm
and
what
that
means
is
the
release.
Information
is
stored
differently,
so
hence
both
of
them
can
communicate
separately.
D
What
the
point
here
is
that
if
you
do
a
helm,
LS
to
list
your
your
your
deployed
your
different
releases,
you
will
only
see
the
releases
for
helm
tree
and
held
true
will
only
say
the
releases
for
home.
So
if
you
would
like
to
know,
manage
those
helm
two
releases
and
let
him
treat
a
Kover,
that's
when
you're
going
to
need
to
do
a
migration,
so
we
you
can
have
a
look
inside
in
the
documentation
with
documentation
or
migration.
D
Now
the
two
aspects
that
is
some
people,
I
suppose
maybe
super
advanced
users
like
to
manage
migration
themselves.
So
they
might
use
a
pattern
like
the
strangler
pattern
and
what
that
means
is
they
will
keep
using
helm
for
hem,
deployed
releases
and
phase
them
out
over
a
period
of
time
and
in
any
new
deployments
or
charts.
They
want
to
do
they'll
use
helm
tree
instead
and
what
will
eventually
happen?
D
Is
you
come
through
a
period
where
helm
twos
releases
will
be
depleted
and
then
you'll
just
stop
using
him,
and
you
continue
on
with
on
tree
for
a
lot
of
other
people.
They
would
like
a
clean
movement
where
they
say
right.
I
would
know
like
to
see
him
to
manage.
My
helm
tree
releases
that
I've,
already
deployed
or
my
helm
to
release
is
already
a
bit
right,
a
lot
of
twos
and
trees.
Here,
sorry
to.
D
Yeah
so
yeah
so
gets
confusing,
for
everyone
is
so
what
you
want
to
do,
there
is,
can
I,
know,
see
and
we
haven't
read,
can
I
see
my
hand
two
releases
and
the
answer
that
is
yes
and,
and
we
have
a
plug-in
for
that,
and
why
we,
the
plug-in,
is
because
it's
rather
complex
pulling
that
information
out
man
and
information
and
then
pushing
it
back
out
into
the
cluster.
So
there's
a
plug-in
called
a
harem
tree.
D
Last
thing,
like
our
suggestion
here,
is:
do
one
pattern
or
the
other.
Some
people
are
mixing
both,
so
what
they
might
do
is,
they
might
say
they
migrated
migrated
over,
but
they
also
keep
the
other
instance.
That
was
there
until
they're
very
sure,
and
then
they
can
delete
it
one
by
one
when
we
say
a
migration
like
this,
we
do
not
touch
the
kubernetes
resources
that
have
been
deployed.
We're
only
touching
the
release
metadata
for
hem.
D
So
that's
an
important
aspect,
so
you
can
potentially
have
the
helm
to
release
and
helm
tree
release
running
still
there.
So,
for
example,
if
you
deployed
my
charts,
my
chart
can
be
shown
by
hand
and
helm
tree,
but
what
we
did
voice
again
is
to
clean
that
up.
So
you
don't
walk
over
yourself.
So
there's
a
few
things
to
take
in
into
account
here,
have
a
look
at
the
documentation
and,
as
I
say,
we've
the
tool
on
this.
So
sorry,
if
I've
yeah,
yeah.
C
No
so
I
think
there's
there
there's
some
things
to
unpack
there,
though.
So
the
reason
we
have
it
as
a
plugin
and
not
built
right
into
helm
3
is
because
well,
you
only
need
it
when
you're
migrating
and
in
a
year
from
now
after
you've
migrated
from
helmed
2
to
3.
You
don't
need
that
sitting
in
your
code
that
you
download
all
the
time
it's
kind
of
a
one-off
thing,
which
is
a
perfect
thing
to
have
as
a
plugin.
C
C
Does
things
like
upgrades
like
one
of
the
things
that
I
forgot
his
home
does
a
three
and
one
of
the
features
of
it?
Is
it
does
a
three-way
merge?
And
so,
when
it
does
this
three-way
merge?
This
allows
us
in
helm
two.
If
you
were
using
something
like
a
service
mesh
and
it
injected
a
sidecar,
and
then
you
wouldn't
upgraded,
we
might
overwrite
your
side
car
in
helm,
three
that
doesn't
happen
anymore.
C
So
one
of
those
nice
little
features,
but
in
doing
the
comparison
we
need
some
metadata
from
different
states
and
and
there's
other
reasons
if
you're
gonna
roll
back,
which
is
a
really
handy
feature.
If
you
do
an
upgrade
and
you've
totally
screwed
up,
then
you
can
roll
back
and
you
need
to
have
that
state
to
roll
back
to,
and
you
don't
just
want
to
rerender
the
chart.
You
actually
really
want
to
roll
back
to
it.
So
I
think
there's
some
really
important
reasons
that
we
store
this,
but
basically
martin
worked
on
a
plugin.
C
C
E
E
Kubernetes
has
come
a
long
way
from
a
release
film
to,
for
example,
out
of
thing
so
helm
we
kind
of
baked
our
own
apply,
so
we
were
able
to
clean
a
lot
of
that
stuff
up,
and
in
doing
so,
we
had
to
store
a
lot
less
information
in
the
release
which
I
think
Matt.
You
were
talking
about
earlier
with
the
release
size.
C
E
D
E
Recent
changes
have
gone
in,
so
anybody
correct
me
if
I'm
wrong,
but
so
now
what
we
do
is
we
actually
look
at
in
cluster
resources
home
to
only
looked
at
previous
released.
So
that
means
we
calculated
our
gift
based
on
the
previous
release
at
one
end,
now,
there's
some
issues
with
that.
If
somebody
goes
and
edits
your
resources
under
the
fly,
then
helm
did
not
know
about
that.
E
It
would
only
be
dipping
the
previous
as
well
as
there's
service
meshes
now
and
other
things
that
lot
of
fighter
resources
when
already
in
cluster
and
performing
the
diff
and
doing
the
patch.
It
would
actually
not
take
those
into
account
so
now
we're
doing
a
three-way
diff
which
diffs
in
for
resources,
as
well
as
the
previous
release,
so
we'll
only
make
the
changes
that
we
need
to
make
there
so.
B
E
E
A
B
C
C
There
isn't
just
one
thing
so
CR
DS
are
a
cluster
scope
for
resource
that
altered
the
API
right
custom
resource
definition,
you
to
find
a
new
object
in
kubernetes
and
let's
say
you
have
multi-tenancy
and
so
you've
got
two
tenants
who
don't
know
about
each
other
and
they
both
want
to
install
something
that
uses
the
same
CRT,
and
maybe
one
of
those
two
tenants
wants
to
upgrade
to
a
newer
version,
the
CRT.
Well,
they
don't
know
about
each
other.
So
how
does
all
of
that
work?
Because
it's
not
names
scoped?
C
These
different
tenants
are
now
got
objects
where
they
walk
in
each
other
right
and
so
there's
so
many
possibilities
in
so
many
ways
that
kubernetes
is
used
that
there's
a
lot
of
ways
to
break
things
with
CRTs.
There's
lots
of
places
where
people
don't
even
have
permission
to
install
them
where
you've
got
to
extract
the
Sierra
T's
from
maybe
a
chart
and
hand
them
to
a
cluster
operator
and
say:
please
will
you
install
these
for
me?
So
I
can
install
my
application
because
you
don't
have
access
and
that
gets
into
security.
C
You
don't
somebody
who
wants
to
secure
cluster
doesn't
want
to
give
the
whole
world
who
manages
things
access
to
manage
CR
DS,
because
you
bring
security
implications
or
practical
ones
of
oh
with
this
person
did
something
that
messed
with
these
other
users
of
the
cluster.
They
didn't
even
know
about
right,
so
multi-tenant.
E
C
And
maybe
like
it's
into
one
of
the
principles
we
have
at
home
when
we're
managing
when
hell
manages
your
stuff,
we're
conservative
about
it
right
because
we
don't
want
to
accidentally
be
the
reason
that
your
production
stuff
was
deleted
and
broken.
We
want
to
be
conservative
about
anything
that
home
is
doing
and
so
like
helm
right
now
doesn't
delete
CR
DS.
We
need
to
lead
a
release
because
again
against
the
multi-tenancy
say.
Somebody
else
is
also
running
it.
C
If
you
deleted
the
CR
D,
all
the
custom
resources
would
be
deleted,
even
if
just
for
a
fraction
of
a
second
that
CR
D
is
gone,
and
that
would
be
somebody
else's
custom
resources
which
would
take
out
their
application,
and
we
don't
want
that.
So
we
are
looking
at
ways
to
help
you
manage
CR
DS
better,
but
it's
and
hopefully
we
want
to
layer
some
changes
into
the
future
of
helm,
3,
but
we're
gonna
be
very
conservative.
So
we
don't
break
things
and
match.
D
You
know
funnin
on
that
I'm
talking
a
few
DevOps
folks,
you
know
cuz,
you
know,
questions
come
in
a
lot
with
the
CR
DS,
that's
fair,
and
it's
usually
you
know,
people
bundle
the
CR
DS
inside
and
same
chart
as
the
applications
are
in
etc,
etc.
And
then,
as
you
said,
they
can
be
worn
to
multiple
apps,
using
that
particular
CR
D.
D
So
if
it
was
elite
it
out
what
I've
noticed
from
a
good
pattern,
I've
heard
from
a
couple
of
DevOps
folks
is
that
when
they
have
used
hem
for
C
or
DS,
they
literally
have
a
chart
that
has
the
particular
C
or
D
they
manage
that
deployment
of
the
CR
D.
Then,
whatever
applications
want
to
create
see
ours
from
the
c
rd,
they
the
applications
around
your
own
in
the
chart
and
then
afterwards,
if
to
getting
rid
of
the
C
or
DS
they
manage
that.
D
B
E
B
D
E
E
C
E
C
Was
gonna
say
so
I
also
do
kubernetes
a
gaps
and
I've
poked
around
in
kubernetes
over
time,
going
to
different
corners
to
come
up
with
different
management
strategies
that
the
kubernetes
community
would
think
is
appropriate.
We
ain't
got
nothing
yet
so
some
of
this
is
gonna
be
predicated
on
that
we
are
looking
for
better
tools,
but
that's
kind
of
why
CRTs
are
the
way
they
are.
C
Why
we'll
install
them
but
upgrades
you're,
upgrading
to
add
new
versions,
you're,
creating
the
same
CRT
object
right
and
since
right
there
you
can
mess
with
multi-tenancy
we're
very
conservative
and
adding
features.
Now
if
anybody
wants
to
help
with
this
feel
free
to
reach
out
to
me-
and
we
can
talk
about
it,
but
this
is
why
it's
complicated
see
your
DS
are
complicated.
Yeah.
E
One
of
the
limitation
two
is
scaredy's
have
to
be
uniquely
named
for
the
cluster.
So
if
somebody
has
a
custom
CRT
that
they're
creating
for
their
application
and
it's
installed,
then
that
name
is
taken
if
another
person
says
oh
I'm,
creating
something
similar.
Here's
my
CRT,
which
is
for
a
different
application.
That's
not
going
to
be
possible!
E
Where
you
know
Martin
was
talking
about
managing
CRT
use
outside
of
charts,
that's
really
the
safest
way
to
do
it
and
the
only
way
I
have
found
of
really
getting
away
from
all
these
limitations.
So
we've
been
working
out
ways
in
like
create
deployments
to
check
to
see
if
the
CRT
exists
and
only
install
it.
If
it's
not
there,
but
don't
manage
it
otherwise,
and
we
haven't
really
figured
out
the
best
way
of
having
help
manage
that.
D
That's
it's
the
capability
that
people
really
wanted
and
what
you
were
mentioned
they're
about
to
see
are
these
and
the
name
in
the
same
thing
happened
to
us
in
him
too,
with
tiller
and
that
basically,
our
release
names
were
against
the
tiller.
Namespace
you
system
by
default
or
whatever
tiller
was
set
up.
D
So
no
you
have
the
ability
to
define
your
releases
on
the
particular
namespace
and
that
if
you're,
if
you're
one
of
those
advanced
people
going
in
the
back
door,
if
you're
looking
for
your
release,
is
no
they're
going
to
be
stored
in
the
different
namespaces,
as
opposed
to
you
know,
put
in
the
namespace
of
your
each
hillier
instance
and
your
in
your
cluster.
So
that's
that's
a
piece
of
nice
capability
we
put
in
yes.
E
Another
big
change
is
that
you
know
we
try
to
follow
the
same
model
of
other
kubernetes
objects
where
you
create
a
deployment.
You
create
it
in
a
namespace
for
that
and
it's
it's
localized
to
that.
So
we
wanted
to
follow
that
same
pattern
where
your
chart
is
released
into
a
single
namespace
and
then
you're
naming
convention
could
be
for
that
name
sites
before
they
had
to
be
globally
unique,
just
like
CR
DS,
because
it
was
the
single
tiller
that
was
managing
them
and
then
tiller
had
access
to
all
the
various
namespaces.
E
D
Yeah
one
more
thing
actually
to
just
jump
in
Adam
is
nice
capability
pretty
in
as
well
is
around,
and
this
is
come
on
a
lot
where
they
said
holy
moly
I'm
after
seeing
I
mean
hundreds
and
thousands
of
config
maps
are
secrets
in
my
cluster.
What,
in
the
name
of
goodness,
is
this
so
the
nice
part
of
this
is
you
know
just
remember
this:
every
time
you
deploy
or
your
upgrade
or
release
it
deploys
a
secret.
Will
its
secrets
know
by
default?
D
It
applies
it
out
into
the
cluster,
so
you
can
imagine
if
you
have
a
hundred
versions
of
a
particular
release,
then
that's
a
hundred
secrets
and
that
won't
apply
soap
by
the
amount
of
releases
you
have
and
something
that
wasn't
in
home
too
was
the
default
value,
so
I
think
the
default
value
know
is
ten.
If
I
can
remember
so
what
happens
then?
Is
it
rolls
over
after
every
10
version
version?
B
Is
awesome?
Well,
so
we
are
getting
close
to
the
end
of
our
time
here,
even
though
I
feel
like
we
just
started
chatting
about
this
and
so
I'm
going
to
ask
all
of
you.
What-
and
this
is
I
have
a
have.
An
ulterior
motive
in
this
question.
I
want
you
to
tell
us
what
you're
excited
about
working
on
at
home
right
now
and
it
might
be
a
different
thing
or
the
same
thing.
B
What
you
really
want
people
to
who
want
to
look
at
the
repo
go
to
home
home,
jump
in
and
work
on,
something
what
what
you
are
gonna
be
working
on
or
excited
about,
and
what
you
think.
Other
people
who
are
getting
started
with
home
might
want
to
work
on
and
I'm
gonna
hit,
Farina
and
Martin
and
Adam.
With
this
question,
so
Farina
yeah.
C
All
right
so
so
things
that
I'm
excited
about
with
with
Helmut
and
I
want
people
to
know.
So
one
of
the
things
that
I've
been
working
on
that's
teint,
gently'
related
to
the
home,
is
the
artifact
hub,
artifact
hub
I,
oh
it's
kind
of
like
a
helm
hub,
but
it
does
more
artifacts
and
it's
another
open-source
project
and
one
of
the
things
that
I
really
want
to
expose
through
there.
C
But
not
enough
people
are
doing
is
provenance
files
now
helm
has
the
ability
to
do
signing
and
cryptographic
provenance,
checking
hash,
checking
all
this
fun
stuff
for
security
because
we
live
in
a
world.
So
one
of
the
biggest
ways
that
organizations
run
into
problems
the
users
and
have
security
issues,
and
things
like
that
is
actually
through
their
dependency
supply
chain.
C
It
turns
out,
there's
tons
of
dependency
supply
chain
problems
and
helm
has
provenance
files
and
I
would
like
to
see
more
people,
use
them
and
improvements
on
the
usability
in
helm
to
make
that
possible
and
in
different
places
where
you
have
that
to
kind
of
expose
it.
So
people
can
see
who
these
people
do
it
or
these
people?
Don't
because
your
supply
chain
is
just
a
big
deal
and
I
would
really
like
to
see
the
supply
chain
become
more
secure
for
organizations
not
getting
hacked
and
users
being
safer,
and
that
kind
of
thing.
B
That's
really
cool
and
I
think
they're,
given
that
lots
and
lots
of
enterprises
and
businesses
of
all
sorts-
and
you
know,
agencies
of
all
sorts
are
using
home,
it's
very
exciting
that
they
can
do
it
in
a
safe
and
secure
way,
all
right
Martin.
What
are
you
working
on
excited
about
wanting
to
point
people
towards.
D
It's
big
thing
for
me:
it's
not
because
I
worked
on
part
of
board
I!
Think
it's
the
migration.
If
you
know
I'm
looking
forward
to
people,
you
know
you
know
and
I
know,
because
you
know
I've
worked
in
enterprise
products,
things
take
claim
and
and
we're
not.
You
know
what
I
mean.
We
don't
have
our
heads
buried
in
the
sand.
We
know
that
people
aren't
going
to
move
or
two
hand
three
straightaway.
D
Some
people
have
some
people
were
using
it
at
alpha
and
beta,
but
you
know
a
few
of
your
production
environments
and
so,
if
you're
gonna
you're
going
to
take
your
time,
you're
gonna
be
piecemeal.
Anderson
I
saw
this
in
a
neurone
two
migrations,
because
you
know
we
we
look
to
two
migration
or
the
strangler
patran
and
then
just
in
situ
and
deliver
over
straightaway,
and
we
were
saying
yeah
people
do
it
that
way,
if
you're
doing
it
one
way
or
the
other,
but
we
found
the
in-between.
So
people
were,
you
know
they
were
taking
over.
D
Maybe
a
couple
of
releases.
They
were
testing
that
out
making
sure
it
was
okay,
making
sure
the
upgrades
unab
worked,
and
then
they
were
looking
for
capabilities.
So
we
had
a
cleanup
capability
in
the
plug-in
that
just
cleaned
everything
out
and
then
they
said.
No.
We
just
want
clean,
okay
ability
to
take
a
release
out,
so
you
could
see
requirements
coming
in
and
you
know
it's
only
a
tool
and
math
hit
on
the
terrace.
D
D
There's
Adam
and
the
rest
of
the
people
have
done
on
this
over
years
of
architect,
and
it's
seen
you
know
where
things
have
shifted
from
whatever
2050
you
know,
16
when
Helen
took
a
mold
and
no
2019-20
where
we
are
now,
we
have
entreat
you
not
to
see
those
changes
and
to
move
over
so
I
think
that's
something
that
I'm
excited
I'm
looking
forward
to
and
seeing
people
going
over
there
and
you
know,
and
also
people,
maybe
reading
the
documentation.
You
know
because
there
is
we've
good
documentation
out
there
folks.
D
So
if
you
get
a
chance,
read
that
because
why
I
laugh
at
this
is,
is
the
funny
one
that
Adam
said
earlier.
I,
don't
know
how
many
times
in
the
last
no
more.
However
many
months
Henry
is
out
hemming.
It
can't
find
a
command
anymore.
Okay,
so
we
told
you
Hellman,
it
is
gone,
have
a
look
at
those
docks,
folks,
cuz,
yeah
and
just
quarter.
B
E
D
E
B
A
I
think
talking
about
the
home
Twitter
account
at
home
pack
will
give
you
the
most
up-to-date
information.
Definitely
check
out
our
Twitter.
Our
home
site
or
held
on
Sh
also
has
a
home
blog
that
our
maintainer
is
often
used,
and
if
any
of
you
are
interested
in
contributing
as
well,
it's
definitely
something
we
can
discuss,
and
yet
we
also
have
developer
calls.
Are
we
Thursday
at
9:30
Pacific
time
in
the
morning
excellent.
B
E
A
Already
thanks
all
right,
well,
I
think
we'll
go
ahead
and
wrap
up.
Thank
you.
Everyone!
Thank
you,
Matt
Martin,
Adam
and
Bridgette
for
this
presentation.
That
is
all
the
time
we
have
for
today.
Thank
you
for
joining
us.
The
webinar
will
be
online
later
today
and
we
look
forward
to
everyone
joining
us
at
a
future.
Cnc
app
webinar
thanks
and
have
a
great
day.