►
From YouTube: Webinar: A Conversation About Helm 3
Description
Helm 3 is here! Sounds exciting, but what does it mean for you? Join us for a conversation with Helm maintainers; we’ll talk through the biggest changes, discuss the most useful new features, and help you avoid operational surprises as you benefit from improvements to Helm.ext
Presenters:
Bridget Kromhout, Principal Program Manager @Microsoft
Matt Butcher, Principal Software Engineer @Microsoft
Matt Fisher, Software Engineer @Microsoft
Taylor Thomas, Senior Software Engineer @Microsoft
Moderator:
Karen Chu, Community Program Manager @Microsoft
A
Let's
go
ahead
and
get
started,
I'd
like
to
thank
everybody.
Who's
joining
us
today.
Welcome
to
today's
CN
CF
webinar,
a
conversation
about
how
three
I'm
Kara
Chu
community
program
manager
at
Microsoft
and
cloud
native
ambassador
I'll
be
moderating.
Today's
webinar
I'd
like
to
welcome
our
presenters.
We
have
Bridget
cream
out
principal
program
manager
at
Microsoft.
We
have
Matt
butcher
principal
software
engineer
at
Microsoft.
A
We
have
Matt
Fisher
software
giant
Microsoft
and
then
Taylor
Thomas
senior
software
engineer
at
Microsoft
as
well
and
before
we
get
started
just
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
resume
screen.
Please
feel
free
to
drop
in
your
questions
there
and
we
will
get
to
as
many
as
we
can
throughout
the
webinar
session.
This
is
an
official
webinar
of
the
CNCs
and,
as
such
is
subject
to
the
CNC.
Have
the
code
of
conduct.
A
A
B
Thank
you
so
much
Karen
right.
This
is
very
exciting.
I
feel
like
if
you're
joining
about
webinar
about
helm.
Maybe
you
think
I
want
to
know
all
the
latest
and
greatest
and
I
already
know
a
lot
about
home,
but
maybe
those
of
us
who
are
joining
we're
new
to
home
would
like
the
elevator
pitch
if
like
what
even
is
home.
So
let's
get
started
with
Matt
Fisher.
Kick
us
off
tell
us
something
about
how.
C
C
B
So
in
terms
of
this
package,
management
for
kubernetes
I
mean
that
sounds
exciting,
and
then
we
look
at
some
of
the
numbers.
We
think
all
right,
it's
a
the
third
most
popular
since
you
have
project
right
now,
there's
over
a
million
downloads
a
month.
But
what
does
this
mean
in
terms
of
what
people
are
using
this
for
I
think
that
I,
probably
I
would
say
Taylor
butcher,
one
of
you
folks
can
jump
in
and
tell
us
what
exactly
does
helm
solve
for
people.
C
And
one
of
the
things
that
we
were
finding
out
is
that
during
the
first
consultations,
they
were
basically
having
to
maintain
a
whole
bunch
of
different
files
and
state
in
order
to
upgrade
to
the
next
version
or
upgrade
to
the
next
release.
So
for
software
engineers
or
even
for
operations,
people
who
just
wanted
a
way
to
install
the
package
and
just
wanted
the
latest
version
of
that
software
ready
and
to
go
for
them.
That's
where
helm
really
came
in
and
that
became
that
solution.
D
C
Is
doing
an
upgrade
and
then
doing
roll
backs,
or
things
like
that,
so
that's
really
where
the
user
story
originally
came
from
and
then
going
forward
from
that
it's
been
about
continuing
with
kubernetes
as
user
stories
and
continuing
with
changes
in
advancements
that
have
happened
in
your
viennese
ecosystem.
So
that's
really.
The
core
story
about
helm
has
been
about
being
able
to
manage
that
state,
upgrading
installing
and
making
it
easier
for
people
to
package
and
ship
their
applications
to
other
people.
Yeah.
E
That
first
version
of
helm,
which
which
sometimes
referred
to
as
helm,
classic
because
it
never
technically
made
it
to
1.0
it
didn't
even
have
a
template
engine
built
in.
We
were
just
completely
focused
on
the
idea
that
what
we
wanted
was
to
be
able
to
ship
aboard
of
kubernetes
manifest
so
that
we
can
repeatedly
install
it
in
different
places
and
kind
of
midway
through
that
development
cycle.
We
discovered
that
templates
were
something
that
we're
really
necessary
if
we're
gonna
make
that
work
long
term,
some
way
of
dynamically
reacting
to
individual
clusters.
E
B
Yeah,
absolutely
that
is
really
fascinating,
because
this
is
kind
of
the
evolution
over
time
that,
and
we
have
a
question
too,
that
I
think
is
really
germane
to
this,
which
is
wait
a
minute.
What's
the
difference
between
something
like
helm
and
say,
CloudFormation
or
arm,
you
know
templates
like
what
what
is
templating
your
infrastructure
versus
your
applications,
I'm,
not
sure
if
I
maybe
Taylor
wants
to
weigh
in
on
that
kind
of
say
what
is
the
difference
between
when
you
would
use
helm
versus
anything
else?
B
D
For
using
helm,
it's
actually
people
have
used
it
in
really
creative
ways,
I
think.
Initially,
it
was
intended
to
be
for
application.
So
many
people,
if
you
have
used
helm,
have
done
something
like
installed.
The
nginx
ingress
chart
or
our
favorite
one
that
we
used
for
testing
and
a
lot
of
people
use
in
production.
Wordpress.
You
install
these
like
these.
D
The
latest
version
that
we
released
a
few
months
ago
was
just
how
how
different
people
are
using
helm
and
how
they
found
it
incredibly
helpful
and
an
incredibly
helpful
tool
in
their
different
projects
and
businesses,
with
whatever
they're
doing
so.
Really
it's
it's
kind
of
used
for
a
lot
of
different
things,
but
the
majority
of
it
that
people
packed
it
up
for
our
applications.
But
there
are
a
lot
of
infrastructure
uses
that
I
have
seen
as
well
from
various
members
of
the
community
yeah.
E
And
I
think
one
way:
we've
kind
of
differentiated
between
layers
like
we're
cloud
formation,
arm
work
and
Millea
where
their
homeworks.
Initially
it
was
fairly
easy
right.
Helm
really
does
only
do
the
kubernetes
part,
but
sort
of
the
mental
model
we've
used
is
that
you
know
there's
a
layer
of
infrastructure
that
you
set
down.
E
Kubernetes
is
like
the
top
layer
of
that
infrastructure
in
our
sort
of
mental
model
and
kubernetes
then
becomes
the
kubernetes
api
becomes
the
interface
between
the
infrastructure
that
the
operations
team
has
chosen
to
lay
down,
and
you
know
the
development
teams
application
so
which
basically
exactly
the
kind
of
thing
Taylor
was
talking
about.
So
we
had
envisioned
applications
as
being
the
prime
thing,
as
kubernetes
is
matured.
A
lot
of
infrastructure
concepts
have
bubbled
their
way
up.
E
But
again
you
still
have
that
same
division
like
consider
a
horizontal
pod,
autoscaler
or
even
the
volume
system
in
Cooper
Nettie's
right.
The
infrastructure
team
will
still
select
what
kinds
of
volumes
can
be
mounted
in
a
kubernetes
cluster.
What
kinds
of
Auto
scalars
fulfill
the
contract
or
is
on
Bellefonte
autoscaler
and
then
there's
another
a
DevOps
and
a
developer
team?
You
choose
from
a
pre-existing
menu
which
ones
they're
gonna
use,
so
we've
used
that
mental
model
for
helm.
It's
why
we
have
never
tried
to
take
home
from
kubernetes
into
the
infrastructure
operations
team
concept.
E
It's
also
why,
when
you
look
at
other
technologies
that
this
team
in
here
has
built,
you'll
see
things
like
scene,
AB
and
you'll
see
things
like
Oh
om.
They
both
make
those
same
distinctions
at
the
same
level
so
that
we
did
kind
of
conceptual
purity
but
which
are
targeted
toward
handling
different
things
so
scene
AB,
for
example.
Another
open
source
project
is
able
to
install
things,
something
you
know,
lay
down
one
layer
with
arm
and
then
lay
it
down
another
layer
with
helm
or
something
like
that.
B
So
it
seems
like
the
answer
to
just
about
every
question
out.
There
is
well,
it
depends,
I
mean
well,
it's
configurable
and
I.
Think
that's
true
here,
but
I
think
Taylor
alluded
to
something:
I
want
to
dive
more
into,
which
is
how
3
and
I've
been
out
there
as
a
as
a
PM
myself
in
the
space
I've
been
giving
a
lot
of
talks
talking
to
a
lot
of
customers
about
how
3
I
think
there's
a
lot
of
excitement
in
this
space,
but
I
think
con
3
is
also
I.
Don't
even
just
think.
B
D
Can
kick
that
off?
So
sometimes,
when
you
look
at
it
does
he
might
be
changed
everything
if
you
have
paid
attention
at
all
in
the
code,
if
you're,
if
you're,
if
you've
been
looking
around
the
code,
all
there's
actually
a
lot,
that's
still
the
same,
but
what
we
really
tried
to
do
as
we
as
we
came
in
to
help
3
was
address
all
the
different
changes
that
had
happened
in
kubernetes,
one
of
one
of
the
main
things
that
that
people
asked.
D
We
even
have
the
question
the
QA
was
about
like
Humphrey
and
tiller
tiller,
we
removed
it
and
I
mean
it
was
amazing
how
many
times
we
got
people
to
cheer
for
that
at
various
events
and
things
and
and
we
get
it,
we
get
it.
We
understand
why,
because
he
because
of
how
the
security
model
evolved
with
kubernetes
of
having
our
back
and
CR
DS,
and
all
these
other
things
that
are
that
are
out
there,
like
it
just
kind
of
became
out
of
date.
D
It
was
an
assumption
that
we
made
the
butcher
explained,
but
then,
as
time
of
time
went
on
and
kubernetes
evolved,
then
we
realized
that
it
had
to
go,
and
so
it
no
longer
has
that
client-server
model,
which
serves
two
important
purposes
number
one.
It
simplifies
the
security
model
also,
it
simplifies
users
interactions
with
helm,
so
instead
of
debugging,
whether
it
happened
on
the
home
side
or
the
tiller
side.
D
Now
it's
just
one
single
one
single
application
and
it
also
helped
with
when
we
refactored
the
sdk
they
can
be
used
in
and
go
it
made
that
so
we
had
a
more
simple
interface
for
everybody
to
use
to
get
it.
So
we
didn't
change
necessarily
everything,
but
we
really
streamlined
from
basically
a
couple
years
now
of
people
using
helm
and
production
to
do
some
pretty
crazy
things.
Yeah.
B
And
I
would
definitely
say
that
it's
a
sign
of
maturity
in
any
project
open
source
or
otherwise.
If
you
can
remove
a
major
component,
because
it's
we've
all
been
there
with
the
user
stories
that
say
more
and
more
more
and
add
add,
add,
and
then
we
end
up
with
you
know,
Frankenstein
that
we
get
to
add
more
to
and
I'm
really
excited
that
the
home
community
decided
that
removing
a
major
component
was
something
that
they
butcher
Joanna
hood.
You
want
to
address
a
little
bit
of
how
we
decided
that
that
was
the
right
direction.
Yeah.
E
E
3
are
things
that
are
practical,
problem-solving
tools
that
don't
change
a
lot
of
the
philosophy
behind
helm,
but
change
some
of
the
ways
you
can
do
things
and
and
gives
you
a
little
more
flexibility
in
dealing
with
one
example
of
that
is
library
charts.
So
one
thing
we
noticed
fairly
early
on
is
that
helm
worked
well
for
small,
small
and
discreet
charts,
but
I
think
OpenStack
was
really
the
first
one
that
started
to
push
us
in
directions.
E
And
that's
where
we
try
to
address
this
problem
in
helm,
3
by
adding
a
concept
called
library
charts
where
the
chart
itself
can't
be
installed.
There's
nothing
there
to
install,
but
it
provides
a
number
of
features
and
templates
that
can
be
reused
by
other
things,
so
that
you
can
get
kind
of
common
layer.
Scaffolding.
So
that
was
one
of
my
favorite
features
that
we
added
in.
C
Yeah
I
think
actually,
the
the
removal
of
tiller
was
one
of
the
largest
things
that
I
think
was
a
big
undertaking.
It
was
a
big
understanding
and
it
was
a
huge
collaborative
effort.
I
think
understanding
those
use
cases,
I
recall
the
first
helm
summit,
actually
I
was
hosted
over
in
North
America
in
Portland
was
a
fantastic
kickoff
for
a
lot
of
those
design
discussions.
So
I
really
enjoyed
those
conversations
and
having
those
design
discussions
with
the
community
on
what
but
they're
having
with
helm.
What
are
their
use
cases?
C
What
are
some
of
the
issues
that
they're
coming
up
with
and
how
we
can
help
that
address
those
that
was
one
of
the
fantastic
things
I
think
another
part
of
the
story
that
I'm
really
proud
of
that.
We
took
some
effort
in
this
time
around
was
refactoring
the
the
actual
go
API,
that's
inside
of
helm
itself
to
be
able
to
be
consumed
and
used
in
a
way.
So
we
were
able
to
basically
refactor
the
internals
of
helm
in
such
a
way
that
you
could
use
it
and
consume
it
as
a
go
client.
C
Whatever
happened
to
be
your
language
of
choice
in
helm,
3
that
has
been
like
vastly
it's
been
simplified
such
that
you
can
actually
build
a
go
client,
quite
simply
with
a
few
packages,
and
you
can
even
pull
out
some
parts
like
you
can
unpackage
the
chart
and
inspect
it
or
you
can
do
different
things
with
that.
So
certain
use
cases
with
the
go
SDK
has
been
improved
there.
So
I'm
I'm
really
excited
about
that
feature
and
I'm
I've
been
continuing
to
monitor
how
other
people
are
using
it
today.
B
C
Yeah
I
can
talk
about
that.
One
for
a
second
here,
I
really
wish
Martin
Hickey
was
here
on
the
call
with
us
as
well.
He
was
someone
who
was
working
on
some
of
the
library
chart
stuff
and
then
also
Josh
Dallas
key,
who
is
really
pioneering
a
lot
of
the
chart,
repository
API
stuff
so
originally
when
we
were
going
into
helm
3.
One
of
the
things
that
we
were
really
interested
in
was
like
a
better
security
story
for
everything.
C
So
that
was
a
better
security
story
in
regards
to
tiller,
but
that
also
talks
about
the
entire
deployment
pipeline
from
the
time
that
you
have
the
artifact
fetching
it
down,
rendering
it
and
sending
it
off
to
the
kubernetes
cluster.
It
doesn't
stop
at
tiller,
there's
the
whole
pipeline
before
that,
and
all
that
preamble
that
you
have
to
kind
of
figure
out.
C
C
C
The
open
container
initiative
is
actually
the
group
that
opens
the
distribution
specification
and
all
that,
so
we
were
taking
a
look
at
that
on
how
to
expand
upon
that
project
and
how
we
could
actually
experiment
with
that.
So
what
we
have
right
now
inside
of
helm
3
is
we
continue
to
support
the
existing
jar
repository
API
as
it
stands
for
helm,
2
and
that
continues
to
work
in
helm,
3.
C
C
We
can
talk
about
better
signing
strategies
for
charts
and
all
those
different
things,
nothing
these
things
already
exist
in
there,
but
because
that
there's
already
an
API
and
a
standard
that
is
established
that
helps
us
where
we
can
just
build
upon
that,
and
we
can
create
that
value
without
having
to
talk
about
the
nitty-gritty.
We
can
just
build
upon
what's
already
out
there,
so
I.
B
D
So
I
think
what
we
got
out.
There's
been
a
couple
questions
related
to
migrations
and
the
differences
between
Elm
2
&
3.
One
of
the
questions
about
the
differences
I
actually
sent
a
link
to
a
blog
post
that
goes
into
a
full
list
of
all
the
major
changes
if
you're
curious
about
every
single
one,
but
coming
into
this
and
just
answer
the
question
of
converting
from
Elm
to
to
hell
3
and
what
that
looks
like.
So
as
we
approach
town
3,
one
of
our
biggest
our
biggest
goals,
is
to
make
it
as
painless
as
possible.
D
People
have
put
a
lot
of
work
into
putting
the
other
charts
and
making
sure
that
they
did
build.
Lay
people
have
built
up
huge
infrastructures
around
having
these
charts
and
deploying
their
application.
So
we
wanted
to
make
it
as
easy
as
possible
and
so
for
the
most
part,
charts
are
backwards,
compatible
with
a
few
exceptions.
D
There's
a
there
was
I
mean
I
guess
the
biggest
one
of
all
of
it
is
that
you
have
a
the
CR
D
changes,
so
CR
D
changes
are
no
longer
done
in
a
hook,
they're
done
as
a
as
a
pre
install
step
that
is
performed
before
any
other
templating
or
anything
else
is
done
and
there's
a
whole
bunch
of
technical
reasons.
For
that
we
can
go
in
more
in-depth
if
people
are
are
interested
in
that,
but
basically
that
happens
beforehand
and
they're
no
longer
templated.
D
It
comes
with
full
documentation.
The
help
text
is
fairly
well
detailed,
and
so
it
becomes
the
most
part
of
today
2
to
3
the
name
of
the
release,
and
it
will
move
that
release
to
be
a
hound
3
compatible
lease,
because
on
the
back
end
the
releases
are
no
longer
stored
in
one
single
namespace
and
their
structure
has
changed,
and
so
this
plug-in
will
go.
Read
all
that
data.
It
won't
mess
with
your
kubernetes
resources
at
all.
It's
just
going
to
modify
the
helm
release
and
then
move
it
over
for
you.
D
B
Awesome
so
we've
had
some
questions
also
about
a
lot
of
people,
thinking
about
their
migration
from
2
to
3,
and
they
want
to
avoid.
You
know
operational
surprises.
We
talked
about
the
backwards
compatibility
and
then
a
number
of
the
CLI
options
have
changed
to
make
them
more
similar
to
what
kubernetes
uses
like
helm,
delete
becomes
helm
uninstall,
but
home
delete
still
works
as
an
alias.
There
are
a
few
other
things
people
can
run
into,
though,
like
do
we
want
to
talk
about
chart
dependency.
C
Yeah
I
think
so
some
of
the
things
that
we
have
talked
about
it
has
been
largely
backwards
compatibility.
One
of
the
things
that
was
the
big
target
was,
of
course,
I.
Think
Taylor
had
mentioned
before
was
that
one
of
the
big
things
that
we
wanted
to
do
is
not
basically
break
the
entire
world
and
make
it
such
that
when
people
were
migrating
over
from
helm
to
to
helm
3
that
they
would
have
to
rewrite
their
infrastructure
from
scratch.
C
If
we
would
have
taken
the
entire
stable
chart
repository
and
said,
I'm,
sorry,
when
you
have
to
upgrade
to
helm
3,
you
have
to
rewrite
every
single
chart
in
existence
that
you've
ever
written.
That
makes
it
a
really
big
barrier
to
entry
for
people
to
migrate
over.
So
one
of
the
biggest
goals
was
that
backwards
compatibility
now.
C
One
of
the
things,
however,
is
that
at
the
same
time
that
we're
trying
to
maintain
that
backwards
compatibility,
we
are
trying
to
move
things
forward
in
a
way
that
made
sense
for
making
it
easier
and
making
it
more
making
more
sense
of
some
of
the
packaging
api's
that
have
changed.
So
one
of
the
things
that
we
may
have
changed
for
was
that
there
is
now
a
new.
It's
called
an
API
version
bump.
C
So
inside
of
your
chart,
EML,
when
you
declare
a
chart
with
a
helm,
create
or
something
like
that,
there's
a
little
field
in
there
called
API
version
and
if
you
use
API
version
v1,
that
is,
that
signifies
that
it
was
created
with
helm.
Essentially,
that
was
the
old
packaging
format
that
was
used
before,
with
that
in
helm,
three
were
able
to
basically
make
a
new
API
version,
2
API
version
v2,
and
that
allows
us
to
introduce
some
new
features
that
are
additional
to
the
existing
feature
set.
C
C
When
we
were
first
introducing
chart
dependencies
as
you
can
declare
dependencies
install
them
and
then
you
would
have
two
packages
of
a
chart
installed
in,
what's
called
an
umbrella
chart
or
even
just
a
dependency
being
declared,
those
would
be
declared
inside
of
her
requirements,
yamo
file,
and
so
you
would
do
a
helm
repository
update
and
you
would
do
a
helm
dependency
update
eventually
and
that
would
update
the
dependencies
in
your
chart.
You
can
install
it.
C
We
had
to
introduce
that
to
a
new
file
because
of
some
backwards
compatibility
concerns
for
helm
two,
but
one
of
the
things
that
we
were
looking
to
do
is
to
consolidate
that
and
make
the
packaging
format
a
little
bit
simpler,
so
in
home
3.
What
we've
done
is
both
different
types
of
formats
or
accepted
there's
the
requirements
gamma
file
that
can
be
used,
but
inside
of
the
chart
camel.
C
B
D
So
the
answer
on
those
right
now
we
I've
been
thinking
a
lot
about
this
at
the
latest
health
summit
in
the
EU
we
have
in
Amsterdam,
we
had
a
great
talk
from
some
of
the
folks
over
replicated
and
their
startup
in
the
kubernetes
space,
and
they
had
talked
about
this
kind
of
difficulty,
which
I
think
we've
all
ran
into
where
it's
like.
Oh
I
need
to
tweak
that
one
little
thing,
but
it's
not
exposed
as
a
value
and
it
shouldn't
be
exposed
as
a
value.
So
what
do
I
do
so?
D
D
You
would
like
to
that
can
accept
all
the
manifest
Sun
standard
out
and
I
mean
standard
in,
and
it
will
expect
value.
Kubernetes
manifests
on
the
layout,
and
so
it
will
allow
you
to
do
things
like
customize,
because
some
people
always
ask
like
customizing
helm
could
be
competing.
Customizing
helm
are
not
meant
to
compete
and
in
fact
like
because
so
many
people
have
found
a
lot
of
value
customized.
That
was
one
of
the
driving
factors
around
doing
this
post
render,
because
so
many
people
use
that
for
those
little
tweaks
and
last
mile
configurations.
D
And
so,
if
you
look
in
that
proposal
and
in
the
PR,
you
can
see
the
code
and
a
simple
example
that
you
could
adapt
to
something
more
complex
about
how
to
use
it
with
customize.
And
this
is
specifically
to
to
address
some
of
these
things
that
people
have
asked
about
where,
like
it's,
really
frustrating
to
have
to
copy
the
chart
or
like
how
do
we
use
customize
with
with
these
charts
that
we're
doing
but
still
get
all
the
benefits
of
using
it
inside
of
help.
D
So
with
this,
your
release
will
still
be
managed
by
by
helm,
but
you'll
be
able
to
essentially
shell
out
to
another
process
and
if
you're
doing
it
in
the
DK
is
even
more
flexible
because
you
just
have
to
implement
an
interface
and
you
can
make
anything
be
a
post
render
as
long
as
it
implements
that.
So
that's
where
we're,
where
we've
gone
and
we're
hoping
to
get
that
merge
and
should
hopefully
be
out
for
3.1,
provided
there's
no
big
pickups.
As
we
go
through
the
PR
review
of
the
proposal,
yeah.
E
I
think
one
of
the
important
things
to
point
out
there
is
the
kind
of
the
way
we
view
the
templating
system
and
all
of
that
in
helm.
Is
that
we're
trying
to
give
the
people
who
maintain
the
charts
the
tools
they
need
to
expose,
what
they
think
should
be
configured
to
the
to
the
people
who
use
the
charts
and
largely
that
has
been
a
fairly
good
assumption
for
us
to
make.
E
Well,
we
had
stuff
that
was
in
the
code
for
years
that
never
got
used
that
was
removed
in
help
too,
and
nobody
has
even
noticed,
because
it
was
just
too
complex
and
too
convoluted
to
be
usable.
The
solution
that
tailors
new
PR
will
introduce
I'm
really
excited
about,
because
I
feel
like
this
is
one
that
makes
it.
You
know,
keeps
it
simple
for
all
the
simple
use
cases,
but
introduces
just
the
right
layer
of
flexibility
for
someone
who
wants
to
take
their
chart
using
to
the
to
the
next
level.
B
I
think
it's
amusing,
that
there's
a
question.
That's
a
mentioning
service
mesh
just
because
before
preparing
for
this
I
was
spending
a
bunch
of
time
on
some
service
mesh
related
stuff.
It
turns
out
it
is
the
same
people
working
on
this
stuff
and
one
of
the
things
that
I
this
this
team
has
worked
on
is
called
SMI
service,
mesh
interface
and
the
idea
is
just
to
make
all
the
service
meshes
that
you
know
and
love
interoperable,
get
everyone
to
play
well
together,
and
so
yes,
that
is
something
that
we're
not
covering
in
this
webinar.
B
E
D
E
Service
mesh
interface
is
a
defines
a
particular
kubernetes
y
ml
format
that
you
can
use
to
declare
how
you
want
to
use
service
meshes
all
those
work
inside
of
helm,
the
own
open
application
model
stuff
that
it
was
released
around
coop
con
time.
All
of
that
works
in
helm,
Sto.
You
can
configure
in
helm
and
that's
been
kind
of
our
philosophy.
As
long
as
the
kubernetes
api
will
expose
it,
and
we
can
use
that
same
y
ml
or
json
format
to
load
things
into
the
kubernetes
api.
It
should
be
capturable
and
configurable
inside
of
charts.
B
B
C
I'm
happy
to
answer
that
question.
So
one
of
the
things
that
when
we
were
initially
discussing
this,
this
was
about
I,
would
say
four
months
before
helm,
threes,
official
announcement
we
started
discussing.
How
long
do
we
want
to
start
supporting
helm
two,
and
how
do
we
want
to
start?
How
do
we
support
that?
So
we
were
discussing
with
people
from
the
community
discussing
how
they
were
using
it.
C
We
even
have
people
who
are
migrating
into
the
Alfa's,
which
was
very
interesting
to
see
because
we
were
not
guaranteeing
backwards
compatibility.
That
being
said,
a
lot
of
people
are
really
excited
about
that.
However,
there
is
a
large
subset
of
unspoken
users
who
either
work
an
enterprise
who
are
currently
visiting
with
other
work
that
we
had
to
also
discuss
and
talk
to
it
as
well
and,
as
many
people
know,
they're
not
necessarily
prone
to
making
massive
breaking
changes
or
moving
on
to
the
next
major
release
any
time
soon.
C
They
want
to
make
sure
that
the
product
has
tested
out
and
made
sure
that
it
goes
with
security.
Compliances
it
makes
sure
is
that
it's
okay
to
migrate
forward
without
like
breaking
their
entire
workflow
or
their
product.
So
we
were
discussing
initially
I
think
it
was
a
six
month
window.
Well,
then,
we
eventually
had
a
good
discussion
and
actually
Bridget.
You
brought
up
the
use
case
really
fantastically
in
a
development
call
and
that
we
should
expand
it
for
one
year,
because
at
the
timeline
of
one
Humphrey
was
being
released
there
from
the
six-month
window.
C
That
was
in
a
if
I
remember
it
was
in
early.
Mid-October
was
when
we
released
helm
three
six
months
from
that
timeframe,
it
would
have
been
November,
January,
February,
March,
April,
May
and
three
months
of
that
time
was
set
up
for
the
Christmas
holidays,
a
lot
of
enterprises.
A
lot
of
companies
decide
to
go
out
of
business
or
not
go
out
of
business.
They
decide
to
then
shut
down
their
for
the
offices.
C
Basically,
everyone
goes
on
vacation
and
then
they
have
the
huge
like
Christmas
rush
for
sales
and
things
like
that
which
reasonably
would
give
them
until
mid
January
until
the
end
of
the
timeframe
to
migrate
over
that's
a
really
short
window
time
frame
for
them
to
migrate.
So
what
we
decided
to
do
was
we
would
be
giving
a
twelvemonth
from
her
time
frame
on.
We
would
actually
go
for
the
migration
or
the
support
window
for
helm.
So
what
that
entails
exactly
is
there's
a
couple
of
different
stages
in
this
support
timeframe.
C
So
moving
forward
from
it
was
helm
215,
but
it
actually
turned
into
helm.
216
I
won't
really
discuss
about
that,
but
it's
mostly
about
kubernetes
backwards.
Compatibility
stuff,
but
the
helm
216
was
essentially
the
final
feature
release
for
helm.
So
what
that
means
is,
as
Court
maintain
errs
when
we're
looking
at
new
features
and
new
pull
requests,
we're
not
looking
to
introduce
any
new
feature
or
new
feature
additions
to
helm.
If
you
have
new
features
or
new
things
that
you
want
to
introduce
helm,
3
is
a
fantastic
place
to
go
forward
with
that
4
helm.
C
Our
support
story
has
been
from
six
months
from
the
time
that
we
released
home.
It
would
be
when
we're
taking
a
look
at
just
general
bug,
fixes
merging
those
and
continuing
to
do
patch
releases.
So,
for
example,
right
now
we're
up
to
sixteen
one
right
now,
I
believe
so
the
next
release
will
be
16
or
is
it
16,
3
I
can't
recall
exactly
which
version
we're
on
there's
so
many
numbers
in
my
head,
but
we're
maintaining
and
going
for
the
next
patch
release
and
that
will
continue
on
until
the
last
six
months.
C
C
We
can
take
a
look
at
those
and
address
those
and
we
come
back
or
any
fixes
both
to
helm,
2
and
to
helm
3
depending
on
their
relevance,
but
after
the
12
month
time
frame
window,
that's
basically
when
helm
2
has
become
end-of-life
support,
we're
no
longer
accepting
security
fixes
or
bug
fixes
everything.
Just
all
our
development
moves
forward
to
words
how
free
so
and.
B
E
Sure
and
and
I'll
talk
about
that
in
kind
of
a
large
context.
So
the
main
question
was
in
the
current
CRT
solution:
how
come
we
don't
allow
templating
of
the
CR
D,
so
I'm
gonna
back
up
a
little
bit
and
give
you
a
little
bit
of
a
historical
explanation
for
what
we've
been
trying
to
figure
out
how
to
do
and
do
well
and
then
go
right
down
into
that
particular
question.
E
So
we
were
very
careful
initially
with
how
we
dealt
with
namespaces
and
we
thought
we
had
done
a
pretty
good
job
of
handling
those
kinds
of
top-level
objects.
Until
third
party
resources
came
and
then
went,
and
then
CRTs
came
so
for
those
of
you
who
don't
have
a
long,
kubernetes
history.
Originally
there
was
a
thing
called
third-party
GPRS
third-party
resources.
They,
the
spec,
wasn't
quite
flexible
enough,
so
they
reintroduced
a
new
version
of
the
spec
and
called
them
custom
resource
definition,
CR
DS,
but
both
of
them
essentially
did
the
same
thing.
E
So
if
you've
got
a
background
in
say,
relational
databases
or
something
like
that,
you're
familiar
with
this
idea
that
you
lay
down
a
schema
and
then
you
use
that
schema
to
create
instances
of
things
right,
I,
create
a
table
and
then
I
can
insert
and
delete
rows
out
of
that
table.
Crts
are
essentially
like
the
schema
language
for
the
kubernetes
api,
so
you
can
say:
I
want
a
new
kubernetes
type,
that's
going
to
be
available
over
the
kubernetes
api,
and
I
want
it
to
have
these
properties.
E
Schema
languages
are
difficult
because
the
way
you
manage
a
schema
has
deep
deep
implications
for
all
the
rest
of
the
things
on
the
cluster.
If
I
create
a
new
schema
and
call
it
say,
SSL
certificate,
then
suddenly
I've
made
it
possible
for
all
the
different
cluster
users
to
begin
creating
things
called
SSL
certificates
and
storing
them
in
the
cluster
when
I
alter
that
schema.
What
does
that
mean
for
all
those
existing
instances
when
I
delete
the
schema?
What
does
that
mean
for
all
those
existing
instances?
E
E
You
know
well,
I
know
people
would
like
more
active
management
of
them.
We've
tended
to
go
with
the
most
conservative
possible
way
of
dealing
with
it.
So
when
we
did
home
2,
we
use
the
hook
system
because
our
backward
compatible
guidelines
said
we
couldn't
add
the
kind
of
features
we
wanted
to
be
able
to
add.
They
would
break
the
chart
format,
so
we
waited
and
waited
and
waited
and
held.
Three
came
along
and
we
introduced
to
see
Arnie's
director
and
so
in
this
new
he'll
in
three
style
charts.
E
You
can
add
a
CR
D
declaration
there
and
it'll
loaded
in
your
cluster,
but
it
won't
allow
you
to
do
things
like
automatically
delete
that
C
or
D.
You
have
to
manually
delete
them,
and
all
of
this
is
so
that
we
can
prevent
people
from
that
SSL
style
problem
where
somebody
installs
the
chart
then
deletes
it
and
another
team
somewhere
else
gets
gets
hit
by
the
ramifications
of
that
action.
E
Templating
ended
up
being
the
most
difficult
case
here,
because
it
turns
out
that
templating
is
relatively
stateful
in
the
context
of
the
chart
rendering.
So
when
you
render
the
chart
for
the
time
that
you're
rendering
it
you
have
a
particular
state,
that's
shared
across
all
of
the
different
resources.
E
We
went
with
the
most
conservative
solution
that
we
knew
would
work
which
was
do
not
expose
CRTs
to
the
template
engine
and
consequently
you
can't
template
a
CRT.
If
we
can
figure
out,
we
that
collectively,
including
anybody,
who's
listening
and
wants
to
open
some
issues
and
PRS
and
stuff
like
that.
E
If
we
can
figure
out
a
good
way
to
do
that,
without
introducing
this
interesting
case,
where
CRTs
have
only
access
to
a
subset
of
the
features
or
something
like
that,
then
I
would
be
I
think
we
would
all
be
happy
to
entertain
that
and
be
able
to
push
that
forward.
We
figured
if
we
started
without
templating,
then
we
left
it
left
the
possibility
open
that
we
can
introduce
templating
as
a
non-breaking
feature
addition
later
in
the
hell
three
life
cycle.
E
D
Important,
oh,
go
ahead!
Okay,
sorry!
Something
to
add
on
to
what
Butchart
said.
Is
that
really
it's
always
easier
to
add
later
than
remove,
because
we're
very
very
serious
about
our
backwards
compatibility
guarantees?
We've
only
had
to
do
we
had
to
do
it
breaking
I.
Think,
though,
API
changed
once
in
the
DOS
or
in
the
two
series-
and
it
wasn't
nice
but
like
it
was
one
change.
D
Oh
no,
that
was
really
bad,
so
we're
trying
to
avoid
doing
that
that
again-
and
so
just
just
keep
that
in
mind
as
we're
doing
this
like
when
we
take
away
something
like
that,
it's
not
like
whoo-hoo-hoo
we're
gonna
make
all
everybody
suffer
it's
more
of
it.
You
want
to
make
sure
that
we're
not
assuming
something
that
hasn't
even
been
decided
on
by
the
community.
Yet
yeah.
B
And
it
what
I
was
gonna
say,
and
that
goes
right
along
with
what
Taylor
is
saying,
is
it's
easy
for
us
to
say
home
installation,
and
it
sounds
like
something
that
you
couldn't
make
changes
to
or
make
decisions
about,
but
the
reality
is
you
know
if
a
bank
or
a
government
or
an
airline
is
using
this,
we
all
care
a
lot
about
it
working.
So
we
want
to
make
sure
that
we,
the
open
source
software,
maintainer
x',
aren't
going
to
make
decisions
that
then
have
knock-on
effects
that
are
completely
unanticipated
and
really
negative.
B
C
For
sure
the
best
thing
about
being
originally
a
helm
user
and
then
becoming
a
helm
core
maintainer
is
that
I
was
able
to
go
this
whole
ramping
up
story.
So
I
can
also
give
my
personal
perspective
on
how
we
ramped
up
so
way
way
way
back
even
before
helm
classic.
Actually,
when
we
were
first
working
on
this
product
that
would
eventually
be
deployed
to
clients
was,
we
were
originally
using
something
called
a
container
scheduler
called
fleet.
For
those
of
you
who
don't
know.
C
Fleet
was
a
container
scheduler
based
on
system
D
that
was
written
by
the
fine
people
over
at
core
OS
and
essentially,
what
it
did
was
you
could
schedule
a
docker
container
on
one
of
many
different
machines,
and
essentially
it
was
a
very
rudimentary
version.
I
wouldn't
say
it's
a
rudimentary
version
of
kubernetes,
but
it
was
basically
a
distributed
version
of
system
D
that
you
could
use
across
multiple
different
machines.
C
It
had
its
flaws,
but
it
worked
and
it
was
fantastic
for
what
we
needed
at
the
time
now
when
we
were
evaluating
different
container
schedulers,
the
things
we
were
looking
at
I
think
were,
oh
goodness,
I
can't
even
remember
the
names
right
now,
but
there
was
kubernetes,
there
was
docker
swarm
and
then
there
was
mazes
marathons
that
was
it.
It
was
marathon
was
the
third
Nomad
baby.
B
E
C
Nomad
came
into
the
story
late
after
we
were
doing
the
evaluation,
I
think
the
hashey
call
about
six
months
after
we
were
doing
the
evaluation
they
announced
Nomad.
So
this
was
like
way
way
back
when
we
were
first
doing
the
ramp
up.
There
was
no
concept
of
a
service
mesh.
There
was
no
concept
thing,
so
the
story
now
is
a
lot
more
of
a
bigger
ramp
up,
but
for
us
it
was
really
aligning
our
existing
development
story
with
what
we
were
going
to
do.
C
We
were
deploying
a
product
and
the
thing
that
needed
to
be
deployed
across
multiple
different
machines,
and
we
were
looking
at
different
solutions
at
the
time.
Fleet
was
the
first
one,
but
then
kubernetes
actually
became
that
solution.
So
it
wasn't
looking
at
communities
necessarily
as
a
thing
we
were
going
to
adopt,
regardless
of
what
our
architecture
was.
Our
architecture
for
our
product
was
looking
for
a
solution
like
kubernetes
and
it
just
fit
the
bill
perfectly
for
what
we
were
looking
to
do.
C
So
that's
where
our
on-ramp
story
came
from
is
that
we
were
understanding
the
concepts
we
knew
the
problems
that
we
were
trying
to
solve
and
then,
when
we
were
looking
at
kubernetes,
we
actually
went
to
a
whole
bunch
of
training
sessions.
Kelsey
Hightower
a
long
time
ago
when
he
was
working
for
Korolev's,
would
do
these
kubernetes
from
the
grep
or
kubernetes.
The
hard
way
was
some
of
his
sessions.
C
We
would
go
to
his
to
the
core
OS
office
over
in
California
and
we
go
and
see
these
sessions
live
as
he
was
kind
of
doing
them
and
demonstrating.
That
was
one
of
the
most
helpful
resources
that
we
got
at
that
time
and
then
as
well,
just
having
some
basically
throwing
ourselves
at
the
wall
figuring
out.
How
kubernetes
worked
was
the
big
thing
and
that's
how
helm
came
to
be
really
was
like.
We
were
understanding
from
my
perspective.
C
As
a
user,
we
were
able
to
give
a
really
good,
in-depth
knowledge
of
how
certain
things
work
like
how
you
had
to
create
a
secret
before
he
could
create
a
deployment,
because
then
the
secrets,
the
environment
variables,
we
populated
the
deployment.
So
certain
nuances
in
little
use
cases,
there
became
things
that
we
understood
over
time
as
we
were
understanding
and
using
the
tool
day-to-day.
So
that
was
our.
That
was
our
unwrapping
story
and
so
to
really
to
make
it
less
scary
and
to
do
those
things.
C
I
would
highly
suggest
going
to
cube
con
going
to
take
a
look
at
some
of
the
sessions
looking
at
other
people's
case
studies
and
how
they
were
on
ramping
and
seeing
if
that
story
really
aligns
with
what
your
organization
is
taking
a
look
at
and
if
kubernetes
really
is
the
solution
for
your
problem
and
I.
Think
that's
really
the
right
way
to
go
about
it.
There's
probably
millions
of
different
ways
to
go
about
the
problem,
but
that
was
that
was
our
use
case,
and
that
was
our.
That
was
our
story.
Yeah.
E
We
wanted
home
to
be
very
similar
to
that,
and
so
one
of
the
ways
we
had
always
kind
of
hoped
people
would
use
helm
was
to
go
out
there
and
find
a
chart
that
did
something
they
felt
comfortable
with
like
WordPress
and
they'd,
install
it
and
then
like
you're,
like
your
high
school
biology
class,
go
dissect
the
helm,
chart
and
see.
Oh,
so
this
service
thing
here
is
where
I
got
a
static,
IP
address
and
oh.
E
So
this
deployment
thing
here
is
what
decides
which
images
to
run,
and
so
we
do
hope
that
that's
the
way
that
people
find
kubernetes
to
be
slightly
more
approachable
by
being
able
to
have
that
rails.
Experience
of
getting
the
WordPress
up
and
running
in
five
minutes
and
then
going
back
and
figuring
out
how
everything
worked.
Love.
D
Been
really
excited
to
see
some
renewed
contributions
from
the
community
around
long-standing
features.
We
have
the
all
the
ideas
that
came
to
surrender
thing.
We
have
the
the
lookup
function,
that's
coming
where
you
can
look
up,
kubernetes
resources,
resource
things
and
inject
them
into
a
template,
and
that
should
be
landing
soon.
So
I
mean
it's
really
cool
to
see
all
these
coming
up
again,
so
it's
just
been
really
fun
to
see
that
and
how
helmet
and
how,
having
like
a
a
better
factor,
better
refactored,
sdk
and
CLI,
has
helped
people
with
more
advanced
new
spaces.
D
C
From
my
perspective,
I'm
really
excited
to
see
what
the
community
comes
up
with
I,
really
like
to
see
the
use
cases
and
what
people
have
come
through.
So
a
lot
of
the
hallway
tracks
that
I
go
to
at
conferences
or
like
the
helm,
summits
that
we've
been
hosting.
It's
been
really
fantastic
to
hear
community
members
or
maintainer
x'
or
people
who
are
advanced
users
or
even
people
who
are
first
getting
started
with
kubernetes
in
helm.
It's
always
awesome
to
hear
their
use
cases
stories.
C
E
The
thing
I'm
most
looking
forward
to
right
now
is
wrapping
up
the
graduation
process
for
him
to
make
its
way
as
a
full
graduated
project
in
CNC
F.
We
probably
could
have
done
that
a
while
ago,
but
we
were
far
more
interested
in
getting
helm,
3
out
the
door
and
in
the
process
of
doing
that,
we
made
sure
we
checked
all
the
check
boxes.
The
security
release,
the
the
security
review
for
helm
3
was
excellent.
B
A
All
right
guys
needed.
Thank
you
all.
Thank
you
to
the
home
team
for
a
great
presentation.
That
is
all
the
time
we
have
for
today.
Thanks
for
joining
us
and
the
webinar
recordings
and
slides
will
learn
Oh
slides
of
the
conversation
further
weber,
webinar
recording
will
be
online
later
today,
and
we
are
looking
forward
to
seeing
you
at
a
feature.
Cn
CF
webinar
have
a
great
day
everyone.
Thank
you.