►
From YouTube: Migrating from Helm v2 to v3 - Martin Hickey, IBM
Description
You want to try Helm v3, but perhaps you already have Helm v2 and need to migrate. We’ll look at a migration from Helm v2 to v3 using the helm-2to3 plugin. We’ll cover migration of config and data (chart starters, repositories, and plugins), in-place migration of releases, and cleanup.
A
All
right,
so
it's
probably
a
good
time
to
hand
on
hand
over
to
martin,
then
so
martin
has
been
a
long
time.
Helm
maintainer
works
for
ibm,
wrote.
You
know
a
lot
of
the
did.
A
lot
of
work
on
helm3
has
done.
A
lot
of
work
on
documentation
has
been
one
of
the
he's,
probably
at
this
point
either
the
number
one
or
number
two
most
frequent
answer
of
questions
in
the
issue:
queue
and
also
the
author
of
the
helm,
two
to
three
or
co-author
of
the
helm,
2-3
migration
plug-in.
A
B
Okay,
yeah
thanks
very
much
for
that
bridgette
so,
and-
and
thank
you
matt
as
well
for
for
the
introduction.
So
what
I'd
like
to
speak
to
you
about
today
is,
I
suppose,
really
it's
a
follow-on
from
the
great
background
and
breakdown
that
matt
has
done
around
between
helen
helm,
v1
right
over
to
v3
now
and
the
different
changes
that
there
are
and
the
reason
why
we,
why?
If
you
have
helm2
releases,
why
you'll
need
to
migrate
over
to
nv3?
B
B
So
I
suppose
one
of
the
questions
that
often
come
in
is
do
I
need
to
migrate
to
head
and
v3
and
this
this
is
always
a
few
interesting
questions
around
this
and
why
you'd
need
to
migrate,
etc.
I
suppose
I'll
jump
down
a
second
one
of
them
is:
if
you
haven't
used
10v2
or
you
don't
have
any
existing
nv2
releases,
then
you
can
just
use
helm
v3,
it's
like
starting
off
new,
so
there's
just
it's
not
necessary
for
you
to
to
look
into
migration.
B
If
you
do,
then,
then
this
is
for
you,
so
matt
mentioned
it
earlier.
One
of
the
reasons
why?
Because
v2
has
gone
end
of
life
in
in
the
middle
of
november,
so
the
support
will
be
gone
and
hen.
Victory
is
now
the
current
supported
release
and
has
been
out
for
the
last
close
on
a
year
now
in
in
november.
B
B
Looking
at
your
charts,
helm
v3
will
still
be
able
to
render
the
api
version
v1
charts,
except
for
what
we
mentioned
a
few
minutes
ago
around
the
crd,
install
hooks
and
default
name
creation,
but
you
can
give
it
a
flag
now
to
to
create
the
namespace
on
the
fly.
If
you
want,
and
around
the
crd
install
hooks,
it's
a
matter
of
you
were
updating
to
use
the
newer
version
of
crds.
B
If
you
want
your
crds
installed
in
that
way,
and
the
financing
is
why
the
migration
is
here,
I
think
matt
wintrow
really
really
well
on.
That
is
the
whole
idea
of
the
changes
underneath
the
hood
and
it's
mostly
around
the
release
metadata
and
how
that
format
has
changed
and
the
way
we
store
it
inside
into
cluster
and
also,
I
suppose,
around
the
local
configuration
as
well.
That
has
changed.
B
So
so
what
are
your
two
options
when,
when
you
want
when
you're
looking
at
migration?
So
if
any
of
the
criteria
has
touched
you
earlier
on
that,
you
want
to
to
that
you
that
you
need
to
use
some
of
the
releases
that
you've
deployed
using
nv2.
How
do
you
work
around
that
then?
So
there's
there's
two
patterns
we
can
look
at
and
the
first
one.
The
strangler
pattern
is
really
looking
at
gradually
phasing
out
your
helm,
v2
deployment.
B
The
other
approach-
and
it's
the
one
we're
going
to
talk
about
today
in
in
in
the
talk
here,
is
the
in
situ
or
when
you
want
to
migrate
to
straight
over
from
your
your.
You
want
to
bring
your
helm
v2
releases
over
to
helm,
v3
and
let
mv3
manage
them
so
that
you
can
do
rollbacks
or
upgrades
afterwards.
So
that's
what
we're
going
to
look
at
in
in
the
demo
and
what
we're
talking
about
here.
B
So
why
would
you
choose
this?
I
suppose
the
key
one
here
is,
as
I've
been
saying,
is
if
you
want
to
reuse
the
existing
resources
from
nv2,
be
that
your
configuration
local
configuration,
for
example,
right
plugins,
you've,
you've
installed
what
repositories
you've
installed
or
any
maybe
chart
starters
that
you
use
and
primarily
as
opposed
to
releases
that
you
have
so,
for
example,
if
you've
deployed
versions
of
I
don't
know,
redis,
mongodb,
etc,
and
you
want
to
keep
maintaining
them
and
managing
them
from
helm.
B
So
what
what
am
I
going
to
cover
in
the
demo?
So
we're
going
to
start
off
having
the
two
versions
of
helm,
sitting
by
side
by
side
and
they're,
going
to
point
to
a
particular
cluster
and
what
I
love
is
pre-prepared.
Some
some
releases
that
have
been
deployed
using
helm,
v2
and
it'll
also
have
plugins
and
and
repos
already
configured.
B
We
will
look
at
also
the
cleanup
of
those
particular
releases
and
we'll
also
look
again
then
at
doing
that.
We're
releasing
different
namespace
to
show
that
how
the
data
is
going
to
be
stored,
then
in
hand
v3
in
the
different
name
spaces,
as
opposed
to
in
v2,
when
it's
stored
in
the
taylor,
namespace
and
then
we'll
also
look
at
which
happens
for
a
lot
of
people,
I
suppose
is
they
might
have
different
versions
of
clusters
that
they're
using
from
you
know
from
a
particular
system.
B
So
we
look
at
here
using
q
config
how
helm
and
also
the
plug-in,
connects
across
to
the
different
systems
and
basically
different
clusters,
and
then
we
can
see
here
that
we
can
make
the
changes
in
there
as
well
and
then.
Finally,
we
look
at
full
cleanup
so
in
between
we
probably
do
one
by
one
release:
cleanups
and
then
we'll
we'll
look
at
a
full
cleanup
at
the
end
of
that.
So,
okay,
let's
swap
over
to
the
demo.
B
B
You
can
see
here
that
it's
got
the
client
and
the
server
part
the
server
part
being
tiller.
And
then,
if
we
look
at
helen
tree,
which
I
call
it
entry,
you
can
see
here
that
it's
just
got
the
client
version
and
what
I'm
using
here
3.1.3
for
some
reason.
Okay,
so
that's
great!
So,
first
of
all,
let's
have
a
look
at.
B
I've
known
installed
either.
So
what
we're
going
to
do
from
here
is
we're
going
to
look
at
and-
and
let's
have
a
look
at
just
what
okay,
so
I
have
three
releases
deployed
example:
nginx
and
redis.
So
what
we're
going
to
look
at
here
is
first
of
all
we're
going
to
look
at
the
configuration
so
moving
over
the
the
repos
and
the
plugins
and
merging
with
any
plugins
or
repos
that
I
might
put
into
helm3.
B
B
B
So
what
the
move
command
does
is
it's
for
the
moving
or
the
copying
oven
over
of
configuration
from
helm2
to
helm3.
So,
for
example,
what
we
said
there,
the
plugins
list,
the
repo
list-
and
if
you
have
any
starter
charts,
are
copied
over
so
that
helm
tree
can
now
use
them
in
the
convert.
It'll
be
for
the
conversion
of
releases.
B
So
you
can
see
here,
there's
not
very
many
flags
to
it
and
it
does
what
it
says
on
the
tin.
It's
the
migrating
of
the
configuration
over
to
helm3,
so
I
think
we're
going
to
give
that
a
go
now.
Each
one
of
these
commands
has
a
flag
dry
run
and
that
enables
you
to
see
what
the
commands
going
to
be
going
to
be
going
to
do,
or
what's
it
going
to
run
and
the
different
operations
it
will
do
before
you
actually
hit
hit
run
before
you
actually
decide
to
go
with
the
command.
B
B
B
So
you
can
see
here.
What's
going
to
happen,
is
it's
going
to
move
over
the
config
and
the
data
and
some
of
the
cache
form
the
from
the
setup
in
helm,
v2,
which
was
stored,
usually
in
your
home
dot,
helm,
pat
in
no
into
using
more
standard
format
for
different
os's,
for
example,
for
for
linux,
it's
using
the
xdg
specifications,
so
things
like
using
that
cache
and
that
local
share
and
and
config
and
then
using
probably
user
accounts
on
windows
etc.
B
B
B
B
Are
you
just
going
to
add
your
own
configuration
from
new,
for
example,
because
when
you
install,
as
we
showed
a
helm
tree
out
of
the
box,
it's
there
are
no
repos
added,
so
it
basically
it's
up
to
you,
then
what
repos
you
want
to
add
after
that.
But
if
I
suppose,
if
you
want
to
maintain
some
of
the
reapers
from
before,
then
it's
a
good
idea
to
to
to
copy
them
over.
B
What
differs
here
as
well
is
that
we
no
need
to
give
it
the
all
name
spaces,
because
if
we
don't
and
we
just
go
lmls
then
we'll
just
see
any
of
releases
that
have
been
deployed
into
the
current
namespace,
whatever
your
current
namespace
may
be
in
this
situation,
I'm
using
a
kind
cluster,
so
I
think
at
the
moment
it's
the
default.
Namespace
that's
been
used,
okay,
so
you
can
see
here,
we've
no
releases
for
him
tree.
B
B
B
B
It
then
maps
that
data
from
the
helm,
v2
format
into
the
helm,
v3
format,
and
it
then
stores
those
release
versions
in
the
namespace
of
the
release.
So
two
big
things:
there
is
the
mapping
of
the
release,
format
and
no
they're
going
to
be
stored
in
the
namespace
of
that
the
release
was
deployed
in
and
not
in
the
namespace
of
tiller,
which,
if
it's
by
default,
it's
cube
system.
B
So
somebody
the
flags
that
that
might
be
of
interest
to
you
here
is
you.
Can
you
can
specify
the
space
of
your
tiller?
So
if
your
tailor
is
in
a
different
name,
space
outside
of
the
cube
system
and
as
matt
said,
some
people
use
one-to-many
tillers
if
they
wanted
the
ability
to
try
and
provide
some
multi-tenancy
there's.
Also
people
that
wanted
to
use
an
alternative
to
having
tailor
in
the
cluster
are
running
outside
of
the
cluster
they
use
tillerless.
So
you
can
also
put
in
a
flag
for
that.
B
If
your
your
tiller
is
not
in
the
cluster
and
also
is
the
ability
to
well,
I
thought
what
we're
touching
in
a
while
is
to
use
cool
configuration
to
point
to
different
clusters
and
different
contexts
of
clusters,
so
helm
by
default
uses
disability
to
point
to
clusters.
So
whatever
your
queue
configuration
is
or
what
context
it
is.
That's
the
particular
that's
the
particular
cluster
that
it
will
that
it
would
point
to
and
the
same
here
with
the
with
the
plugin.
B
C
B
C
B
Okay,
that's
a
very
good
question:
thanks
bridget
yeah
I'll
just
stay
on
this
for
a
moment
and
we
we
can
come
back
afterwards
because
I
I
I
want
to
be
more
aligned
on
what
what's
the
to
better
describe
around
the
the
stable
etc.
If
that's,
okay,
so
yeah,
that's
a
very
good
question.
So
the
configuration
is
your
local
configuration.
That's
on
your
system.
C
B
Yes,
so
your
configuration
is
per
your
helm,
binary,
so
the
helm,
binary
or
the
helm
command
that
you
run
dash
accesses
its
configuration
from
where
it's
run
from
the
system.
It's
run
on,
so
it
it
stores
its
configuration
on
that
particular
system.
So
if
you
have
a
different
helm
binary
in
another
system
or
you
have
a
different
ins,
if
you
have
it
on
another
system,
then
you
need
to
update
the
configuration
in
that
other
system
as
well.
B
B
How
do
we,
that
is
a
charts
issue
that
I
mentioned
earlier,
isn't
really
anything
to
do
with
migration
as
such,
so
that's
to
do
with
so
what
you
can
do
is
and
that'll
be
to
do
with
the,
if
you're,
the
maintainer
of
your
charts
or,
if
you're,
using
charts
that
are
maintained
by
somebody
else.
The
way
you
can
test
is
that
api
version
is
v2
in
the
chart.yaml.
C
B
B
B
C
B
C
B
B
B
B
Now,
isn't
it
yeah?
Okay,
all
right,
let's
get
let's
get
back
to
them
on
this,
so
here
what
I
mentioned
earlier
is
just
before
the
questions
is
that
we
talked
about.
We
want
to
bring
over
the
metadata,
so
picking
up
the
release,
metadata
mapping
it
into
new
farmers
and
storing
it
into
the
particular
namespace.
So
if
we
take
a
look
at
enginex
to
start
with.
B
And
you
can
see
here
that
what
it's
going
to
do
here
is
it's
going
to
create
a
new
release,
version
v1
and
v2
and
in
the
particular
format
for
v3,
but
it's
not
going
to
touch
the
the
helm
v2.
Unless
we
ask
it
to
delete
it,
you
can
give
it
the
flag,
dash,
delete
v2
that
releases
or
you
can
wait
and
delete
it
yourself
manually
now.
B
B
B
We
can
see
here
that
we
have
the
particular
deployment
still
running
it's
a
basic
nginx
server
and
we
also
have
a
particular
example
chart
which
we
showed
earlier.
That's
running,
okay,
so
when
we
talked
earlier
about
and
met
talked
earlier
about
the
data
that
was
there
for
v2
and
the
data,
that's
now
there
for
v3.
B
We
can
see
here
when
we
have
a
look
in
here
and
what
we're
doing
in
this
situation
is
it's
using
a
particular
label
all
on
taylor
and
all
different
name
spaces?
So
if
you've
different
instances
of
tiller
running,
then
you
would
see
data
like
this
stored
for
in
different
name
spaces
or
if
you
change
the
particular
label
of
of
who
the
owner
is
then
possibly
you'll
have
to
change
the
label
here
as
well.
B
You
want
to
do
of
your
particular
release.
Now
when
we
look
at
it
for
v3,
you
can
see
this
time.
We're
looking
at
the
owner
by
default,
is
going
to
be.
The
owner
is
going
to
be
owner
equal
to
helm
in
small
letters,
and
you
can
see
here
that
we
have
two
versions
of
of
an
engine
x
and
that's
what
we've
converted
over
at
the
moment.
So
that
shows
you
what
happens
when
you
do
the
migration?
Over
of
the
release,
data
from
hand
to
head
to
from
helm
v2
to
helm
v3.
B
The
next
part,
probably
part
of
this,
is
so
just
I
just
want
to
touch
on
the
cleanup,
and
this
is
something
that,
as
the
plugin
has
evolved
from
users
have
looked
for
this
capability
and
push.
This
capability
is
around
the
ide
that
okay,
instead
of
when
we
first
looked
at
the
design
of
the
plugin,
we
say
all
right,
we're
going
to
provide
cleanup
people
will
do
their
their
migrations
over
to
different
releases
and
then
they'll
want
to
clean
up
everything.
But
what
we
found
over
time
is
people
want
the
capability
of
actually.
B
B
So
when
I
go
to
upgrade
that,
I
then
end
up
with
an
error
in
this
situation.
So
the
error
here
is
the
hint
here.
Is
it's
telling
you
you
need
to
run
the
repo
update?
So
that's
one
thing
with
the
configuration
that
we
found
and
we
haven't
found
a
very
nice
solution
to
it-
was
that
there's
problems
with
the
cache
that's
stored,
so
between
v2
and
v3,
and
we
just
found
that
the
solutions
to
it
that
putting
it
into
the
helm
core
or
into
the
plug-in
weren't
we're
just
going
to
be
too
complicated.
B
B
B
So
these
are
some
of
the
ways
that
people
are
starting
to
use
the
plug-in.
We
would
be
saying
to
move
along
and
do
your
migrations
as
much
as
possible
for
the
one
reason
here
that
that
if
you
try
working
with
helm2
and
helm,
3,
simultaneously
I.e
making
changes
or
upgrades
with
helm
two
while
you've
helmed
three,
you
could
end
up
with
clashes
in
the
cluster
where
you
have
cluster-wide
resources.
So
to
be
just
aware,
aware
of
that.
So
now
what
I
talked
about
is
having
a
look
at
the
the
cleanup.
B
So
you
can
see
with
the
cleanup
there's
a
lot
of
similar
flags
that
we
had
with
the
with
the
migration
of
the
the
release
data,
and
you
can
see
also
there's
a
couple
of
ones
down
here
where
you
can
do.
Individuals
like
do
clean
up
of
releases
like
using
dot,
dot,
release
cleanup
or
you
can
do
tiller
clean
up
or
you
can
also
use
the
dot
dot
name
flag,
which
is
where
you
want
to
just
remove
the
release
data
from
v2
for
a
particular
release.
B
B
B
Okay,
now
we
can
see
that
we
have
the
the
two
two
releases
have
been
deleted
and
if
we
go
to
lmls,
we
can
now
see
when
we
do
a
list.
We
can
now
see
that
that
the
engine
x
release
has
now
been
removed,
it's
no
longer
in
in
in
v2,
and
if
we
look
at
the
config
maps,
it's
gone
out
of
the
cluster
and
then,
if
we
have
a
look
at
a
listen
on
helm
tree,
we
can
see
that
nginx
is
there.
And
if
we
look
at.
B
We
can
see
here
that
the
kubernetes
resources
that
were
to
be
deployed,
as
defined
in
the
chart,
are
still
running.
So
that's
one
thing
to
note
here:
is
that
and
I'll
say
it
again
is
that
the
plugin
does
not
go
near
the
deployed
resources.
It's
the
release,
data
that
it's
going
to
do
the
the
mapping
in
helm,
v3,
okay,
so
I'm
just
going
to
have
one
quick
go
at
doing
the
the
redis
I'm
going
to
do
a
migration
of
redis,
because
it's
in
a
different
name
space.
B
You
can
see
here
it's
been
deployed
in
the
redis
namespace,
so
I
won't
look
at
the
the
do
a
dry
run,
etc.
On
this,
I'm
just
going
to
go
over
it
and
run
it.
Okay,
so
that's
migrated
over
and
if
we
go
ahead
and
tree
ls,
okay,
we
see
nothing
because,
as
I
say,
the
listing
now
for
entry,
the
commands
now
are
based
on
the
on
the
namespace
that
you're
running
as
a
user.
So
whatever
your
current
namespace
context
is
that's
what
it's
going
to
run
your
command
against.
B
B
B
B
We
can
see
here
when
we
check
in
the
cluster.
We
can
see
here
that
the
redis
service
is
still
running
in
the
cluster
okay.
So
that's
looking
at
you
know
the
configuration
force,
the
local
configuration
and
then
looking
at.
How
do
we
map
our
our
different?
How
do
we
map
our
different
release
information
over
to
to
v2,
okay,
so
just
going
to
change
gears
slightly
a
minute?
B
Okay,
lovely:
let's
try
this
okay!
That
worked!
That's
good!
So
this
time,
what
we're
doing
is
we've
just
swapped
the
context
of
the
cluster
that
we're
we're
looking
at
so
the
previous
thruster
was
a
kind
cluster
of
17.,
I'm
looking
at
a
clan
customer
16
here
and
when
I,
when
I
do
an
handmade
ls
this
time,
you
can
see
here
that
there's
a
different
release
and
if
we
do
hem
3
ls,
you
can
see
that
it
has
no
releases,
even
if
I
put
in
the
namespace.
B
B
So
you
can
see
this
when
we
look
in
the
cluster
this
time
we're
looking
at
basically
just
one
deployment
which
is
demo
my
chart,
okay.
So
what
we're
going
to
do
this
time
is
we
will
we
will
migrate
over
this
release
information
and
then
we'll
do
some
cleanup
after
that.
So
I
think
someone
asked
that
about
what
we
have
here
is
we've
two
versions:
we've
two
we've,
the
binaries
nv2
and
v3
binaries
that
basically
the
clients
can
point
to
different
clusters
and
work
off
those
different
clusters
in
this
situation.
B
B
Do
we
do
convert
demo,
and
now
we
look
at
the
listing
of
that.
We
can
see
now
that
we
have
that
particular
that
particular
release
no
been
managed
also
by
v3.
Now
what
we
can
do
look
at
then,
is
one
of
the
flags
I
talked
about
a
minute
ago.
If
you
wanted
to
you're
happy
enough
with
you've
made
all
the
conversion
of
your
releases
over
and
and
you're
happy
that
you
want
to
please
clean
up
the
release
information,
you
can
use
the
release
cleanup
flag.
B
Okay,
so
when
you
go
home,
ls
then
you'll
find
not
in,
and
when
you
look
at
the
config
map.
Okay,
there's
there's
no
release
information
stored
in
the
cluster
there,
so
the
final
part
of
that
is
on
this
cluster.
Only
you
might
say.
Okay,
I
no
longer
have
any
more
release
information
in
here.
I
will
no
longer
be
using
helm
v2
to
man
to
use
this
cluster
anymore,
to
do
my
deployments,
etc.
So
I
can
get
rid
of.
I
can
get
rid
of
taylor.
B
B
B
B
Okay-
and
we
look
here
again-
we
can
see
here,
okay
and
if
I
use
the
oil
namespace
I'll
say
that
redis
is
there
as
well,
so
we
we've
now
come
to.
I
suppose
you
you've
come
to
the
stage
where
this
you
want
to
get
rid
of
the
the
tiller
instance
in
here
and
any
release
information.
That's
left,
you're,
happy,
you've
done
all
your
conversions
over
and
you've.
Also
you're,
you
don't
need
helmet
or
helm
v2
anymore,
so
you
don't
need
the
configuration.
B
So
you
want
everything
deleted
in
one
in
one
go
so
first
things
on
that.
If
there's
any
releases
you
haven't
migrated
over,
you
need
to
delete
those
releases
first,
and
the
reason
for
that
is,
the
plugin
does
not
touch
any
of
the
objects
that
have
been
deployed
into
kubernetes
as
defined
in
the
chart.
So
it's
just
looking
after
the
release
metadata
in
the
cluster.
So
if
you
don't
delete
beforehand,
the
release
metadata
will
be
gone
and
the
objects
that
have
been
deployed,
but
I
release
will
then
be
orphaned.
B
So
what
I'll
do
first
in
that
is.
I
go
helm
delete
example
because
it
was
just
an
example
release
that
I
was
using.
I
don't
need
to
manage
overhead
v3,
so
I
just
get
rid
of
it.
Now
you
can
use
purge
if
you
want
it
doesn't
really
matter
because
we're
going
to
be
deleting
the
release
metadata
afterwards.
B
B
We
can
now
run
clean
up
without
any
flags.
No,
obviously
we'll
have
a
look
at
the
dry
run
on
this
to
see
what
it's
going
to
do.
All
right
and
you've
been
warned.
There's
a
warning
here
saying
to
you
that,
basically
you
may
you,
you
may
not
be
able
to
use
any
release
information
afterwards
with
with
nv2.
So
it's
telling
you
the
fact
here
that
all
the
release
metadata
all
the
release,
data
tiller
and
all
your
configuration
are
going
to
be
removed,
so
helm
v2
will
no
longer
be
usable.
B
B
B
We
can
see
here
that
we
have
the
plugins
that
were
migrated
over
for
us,
the
two
here
and
then
also
the
two
to
three
plugin
that
we
have
there.
So
that's
pretty
much
it
when
you're,
when
you're
going
through
your
migrations.
It's
it's
really
do
you
need
any
of
the
configurations
if
you
do
bring
them
over
and
then
which
releases
do
you
want
to
keep
you
want
to
keep
and
bring
with
you?
B
B
Flag
here
release
first
versions
max,
so
if
you
give
it
that
value,
it
will
take
the
last
number
of
release,
versions
and
drop
the
rest
of
it.
So
it
will
only
convert
over
that
many.
So
if
you
say,
10
it'll
take
10
of
the
latest
release
versions
that
are
there,
okay,
so
that
there
are
a
few
things
to
to
look
out
for
and
once
I
suppose
the
great
thing
about
this
plugin
is
once
you've
done.
Your
migrations
over
you're
finished,
with
your
different
instances
of
nv2,
your
different
tailor,
instances,
etc.
B
C
B
You
put
me
on
the
spot
today:
bridget
you're
really
really
catching
me
out.
I've
migration
in
my
head.
What
are
the
ones
so
delete
has
now
become
uninstall.
The
repo
searches
have
changed.
If
I
can
remember
as
well,
I
think
yeah
have
a
look
at
the
fact
actually,
because
you
put
me
on
the
spot
or
is
matt
butcher
going
to
help
me
out
here.
My
butcher's
been
looking
vigorously
in
the
background
with
this
question.
C
B
B
We
wanted
the
decline
to
be
more
like
q
control
or
whatever
you
want
to
call
cube
control
cue,
cutler
whatever,
so
we
wanted
it
to
be
similar
to
that
and
and
one
of
those
ones
that
really
really
kind
of
caused
reconciliation
was
the
removal
of
the
ability
to
create
a
namespace
on
the
fly
when
you
were
doing
a
deployment
or
an
installation
or
an
upgrade,
and
the
reason
behind
that
was
you
can't
do
that
with
cube
cube
control.
So
we
we
said:
well,
you
shouldn't
be
able
to
do
with
helm
as
well.
B
The
other
thing
as
well-
and
it's
something
we
didn't
mention
it's
just
coming
to
my
head-
is
hellman
knit
you
no
longer
need
to
init
okay,
so
the
initialization
was
for
the
ability
to
you
know,
put
taylor
into
the
cluster
and
set
up
configuration
that
needed
to
be
set
up
out
of
the
box
with
helm
3.
The
nice
part
of
this
is
the
anti-configuration
can
be
set
up
on
the
fly
or
can
be
lazy,
lazy
created
and
we
don't
need
it
straight
out
of
the
box.
B
B
Yeah,
so
just
to
to
recap
on
it
is
look
can
be:
two
is
going
into
life
and
the
middle
of
next
month.
Our
recommendation
and
suggestion
strong
suggestion
is:
please
try
and
move
over
to
helm
victory
as
soon
as
possible,
because
there
will
be
no
more
updates
to
help
v2
and
we
really
think
mv3
definitely
brings
you
more
simplicity
and
more
securely
and
just
around.
I
suppose,
maybe
that
bit
more
robustness
from
stuff
that
has
been
learned.
B
B
So
we
want
the
ability
for
you
to
move
it
over.
You
do
not
really
look
if
you
want
to
go
in,
have
a
look
at
the
internal
informants
of
the
data,
but
you
know
it's
better
that
the
tool
does
it
for
you,
because
it's
you
know
it
makes
it
much
easier.
So
these
are
the
reasons
why
you
you
you
want
to
do
that
migration
over
so
yeah.
I
think
I
think
that's
about
it
and
a
few
resources
there.
B
B
C
Thank
you
so
much,
let's
see
one
more
question
and
you
may
be
able
to
put
butcher
on
the
spot
to
answer
this.
One
which
is
will
humvee2
be
able
to
access
charts
that
were
stored
by
v.
Sorry,
will
home
v3
be
able
to
access
charts
stored
by
helm
v2
in
a
private
repo
possible
problems
in
the
past
and
wondering
will
v3
be
able
to
use
existing
charts
out
of
a
private
repo
in
this
case
acr?
But
the
question
I
suppose
applies
to
any
private
repository.
B
This
is
the
one
chance
I've
got
to
joke
as
well
bridget.
I
got
really
serious
there
on
the
command
and
I
think,
but
no
on
a
serious
answer.
Yes,
you
should
be
still
able
to
use
that
repo,
so
we
have
added
a
lot
of
capabilities
and-
and
some
brilliant
capability
was
added
by
josh
jolisky,
with
the
ability
to
use
oci
registries.
B
But
the
idea
here
is
that
you're
still
able
to
get
your
repos
and
that
you
can
touch
repos
now,
like
an
oci
registry
like
like
docker
for,
for
instance,
and
you
can
get
your
charts
out
of
that.
So
that's
still
that
experimental,
but
I
wouldn't,
I
would
imagine,
in
the
not
too
distant
future
that
will
go
to
a
full
scale
feature
because
of
the
fact
that
it's
getting
nearer
or
near
to
completion
the
work
that
it's
been
done
on
us.
But,
yes,
you,
you
can
get
at
your
reapers
still.
A
A
B
A
B
I
don't
appreciate
that
either
and
I
have
to
say
I
have
to
say
I
did
said
bridget
just
get
in
there
and
ask
me
questions
in
the
middle
of
it
and
I
was
on
a
flow
about
you
know
where
I
moved
to
migration
and
it's
not
one
of
those
things
where
you
go.
I
regret
saying
to
bridgette,
ask
me
the
questions
in
the
middle
of
it,
but
no
questions
are
always
good.
So.
A
Yeah,
so
so
so
I
did
briefly
in
in
the
november
13th
2020
doom
and
gloom
slides
talk
about
needing
to
move
repositories.
So
let
me
just
explain
briefly:
what's
going
on
so
the
chart
repositories,
the
code
that
we
work
on
for
the
charts
lives
in
github.com
charts,
then
the
ci
pipeline
builds
them
and
puts
them
into
a
helm.
Chart
repository
and
the
helm
chart
repository
has
been
hosted
for
years
out
of
a
google
storage
bucket.
A
That
bucket
is
going
to
go
away
on
november
13th,
so
we
have
a
backup
that
will
be
hosted
by
github
by
github
itself,
that'll
be
charts.github.com,
stable
and
slash
incubator
for
the
two
different
ones.
So
I
have,
I
wrote
the
documentation
for
all
of
this
and
I
dropped
it
in
the
yeah.
Bridgette
just
dropped
the
blog
post
and
there's
some
documentation
in
the
helm
faq
for
helm3.
That
explains
how
to
move
from
one
repo
to
the
other
helm.
A
2.17
will
attempt
to
do
some
of
this
for
you,
but
not
all
of
it,
because
we
don't
break
anybody,
but
the
the
short
version
is
on
november.
13Th
you'll
need
to
be
pointing
at
the
new,
stable
and
incubator
repos.
If
you
want
to
keep
using
those
now
keep
in
mind
again,
those
repos
aren't
going
to
be
getting
any
new
updates
or
patches
or
anything
like
that.
Those
repos
will
be
in
maintenance.
A
It
will
be
in
archive
mode
from
that
point
on,
but
if
you
have
an
automatic
ci
system
or
if
you're
frequent
users
of
the
stabler
incubator
repository,
it's
probably
a
good
idea
to
switch
over
to
those
new
ones
anyway,
so
the
the
faq
is
out
in
the
documentation.
We
talked
about
it
a
little
bit
on
the
helm,
five-year
birthday,
blog
post,
matt
farino,
one
of
the
other
core
maintainers,
has
written
a
blog
post
that
will
get
published
soon.