►
From YouTube: Deep Dive: Helm - Matt Fisher, Microsoft
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Deep Dive: Helm - Matt Fisher, Microsoft
In this session, we will cover the current status of the Helm project. We will focus on the changes to Helm's architecture in Helm 3, including the new security model, new chart features, and the Helm core libraries. We will also discuss changes that affect the chart ecosystem, including the move to store charts in OCI registries. Finally, we'll discuss how users can start trying out Helm 3 and how to get involved with the project. At the end, there will be an open discussion where Helm maintainers and contributors can come together to discuss issues that benefit from face to face conversations.
https://sched.co/N4kz
A
So
I
see
a
couple
of
people
in
the
back
they're
just
trying
to
fill
into
the
last
few
rows.
So
if
you
wouldn't
mind
just
like
raising
your
hand
in
the
back
or
wherever
just
to
make
sure
that
everyone
has
a
seat,
that
would
be
fantastic
just
so
we
all
have
a
nice
seat
to
go
sit
down
for
30
minutes,
so
I
think
we're
ready
to
get
started
here.
So
welcome
everyone.
Thank
you
for
coming
to
the
helm,
deep
dive.
A
My
name
is
Matt
Fisher
I'm,
a
software
engineer
over
at
Microsoft,
my
other
partner,
Adam,
Reese
who's,
also
a
core
maintainer
and
is
also
a
software
engineer
at
Microsoft.
He
unfortunately
has
the
flu
so
he's
not
able
to
make
it
so
we're
just
gonna
be
flying
solo
today,
but
we
wish
him
here
and
he's
here
in
spirit
with
us
all
so
before
we
quickly
go
into
this.
Who
here
is
a
helm,
core
maintainer
and
are
there
any
charts
maintained
errs
in
the
room
suite.
A
The
ambassador
wave-
yes,
so
I'm
gonna,
call
upon
you
guys
eventually,
if
we're
doing
questions,
so
what
we're
gonna
try
and
do
here
is
we're
gonna,
try
and
go
through
the
content
really
quickly.
I'm,
just
gonna
give
a
little
bit
of
a
high-level
overview
of
some
of
the
things
that
has
hepl
or
has
already
happened
in
helm,
3
and
the
alpha
1
release.
You've
already
started
hearing
a
couple
of
things
here
and
there
during
the
conference.
Some
of
the
plans
that
we're
thinking
of
getting
to
next
and
then
we're
just
gonna
go
straight
into
Q&A.
A
We
did
this
at
cube.
Con
North,
America
six
months
back,
I
think
it
was,
and
it
was
really
really
helpful
to
go
through
the
Q&A
and
just
have
this
like
face
to
face
conversation
with
the
core
maintainer
'he's
here
the
charts
maintainer
x'.
So
really.
This
is
like
helpful
for
your
time
to
get
these
kind
of
feedback
and
to
understand
these
questions
that
we're
getting
from
the
community,
so
current
state
of
helm.
So
before
we
quickly
go
into
the
state.
I
just
want
to
talk
about
the
helm
summit.
A
This
is
happening
in
September,
11th
and
12th
over
in
Amsterdam.
We
currently
have
CFP
is
currently
open.
So
if
any
things
come
and
spring
to
your
mind
as
we're
going
through
the
QA
and
you
get
like
a
thought
or
an
idea,
please
happy
to
submit
and
a
CFP
or
talk
to
me
afterwards
and
I'm
happy
to
review
your
CFPs
and
kind
of
go
through
the
process.
We're
also
open
for
sponsorships
for
the
helm
summit.
A
A
There
are
new
features
that
come
in
to
say,
client
go
or
to
cube
CTL,
and
we
have
those
libraries
imported
into
helm
to
deal
with
the
queue
config
finagling
and
all
that,
so
some
of
those
features
need
to
get
rolled
in
so
and
then
we're
also
accepting
some
feature.
Requests
with
a
few
caveats
when
we're
talking
about
new
feature,
requests
into
helm,
2
we're
really
looking
for
small
features
that
are
really
high
value,
they're
low
impact
to
the
entire
community.
But
they
do
move
the
project
forward
in
a
great
way.
A
We'd
love
to
see
you
on
the
dev
calls
just
to
make
sure
that
we're
all
up
to
synch
and
we're
all
working
together
and
PRS
are
getting
merged
and
moving
through
and
as
well
with
that,
because
the
engineering
team
is
mostly
working
on
helm,
3
we're
trying
to
not
write
any
new
features,
we're
just
working
on
active
maintenance
and
moving
through
new
things.
So
just
a
little
bit
of
a
background
story
on
the
project
and
how
we've
moved
forward
from
this
point.
A
How
many
people
in
here
have
played
with
helm,
1
or
helm,
the
classic
Wow?
Ok,
we
actually
have
few
people
in
the
room
so
for
those
online
I've
probably
saw
maybe
less
than
10,
maybe
but
basically
from
when
we
were
working
on
helm
1,
we
were
developing
in
a
closed
source.
We
were
trying
to
like
conceptualize
this
problem
of
making
a
package
manager
for
kubernetes.
We
really
had
no
use
base
front.
There
was
no
years
base
at
that
time
and
we
were
as
a
small
team
when
we
first
developed
it.
A
We
were
just
in
a
very
small
room,
kind
of
working
together,
figuring
out
kind
of
the
basic
concepts
and
then
going
forward
that
then
helm
2
was
starting
to
work
on.
We
were
getting
some
interested
parties,
Google
had
worked
on
their
deployment
manager
and
they
were
interested
because
we
were
working
on
some
of
the
similar
problems
bit.
A
Nami
was
also
interested
with
some
of
the
stuff
as
well,
so
they
kind
of
all
worked
together
working
in
a
conference
room,
so
it
was
still
a
little
bit
of
a
closed
garden,
because
really
there
was
nobody
using
helm
at
that
time.
Helm
was
first
released
and
helm.
1
was
going
on
there,
so
it
was
a
little
bit
of
an
over
closed
garden,
but
now
we
actually
have
a
lot
of
people
using
helm
in
production.
We
have
a
lot
of
feedback.
A
We
have
a
lot
of
use
cases
and
examples
and
things
that
we
can
rely
on.
So
one
of
our
goals
has
been
as
a
core
maintainer
x'
team
to
go
out
and
to
reach
out
to
the
community
and
hear
and
understand
your
use
cases
and
your
feedback
and
everything
else,
and
really
it's
trying
to
turn
those
into
proposals
that
the
entire
community
can
gain
from.
A
We
can
gather
about
and
say
is
this
the
right
way
that
we're
moving
forward
is
not
so
we're
really
moving
towards
this,
like
open
model
of
trying
to
move
the
development
to
be
more
of
an
open
process.
So
I
just
wanted
to
thank
everyone
for
all
your
use
cases,
all
your
examples
and
everything
else
that
you're
showing
off
it's
been
really
helpful
as
a
development
process
and
for
me
as
a
developer,
to
actually
understand
the
use
cases
and
problems
and
there's
so
many,
it's
great,
so
helm
3.
Where
are
we
now?
A
Some
of
the
things
that
we've
made
in
alpha
1
things
that
were
interested
in
doing
for
alpha
2
and
alpha
3.
So
last
week,
I
think
it
was
Wednesday
was
when
we
made
the
cut
for
helm,
three
zero,
zero
alpha
one
and
one
of
the
big
features,
the
simplified
client
only
architecture,
that's
actually
the
removal
of
tiller.
We
call
it
do
two
different
things,
but
really
is
the
client
only
architecture.
A
We
also
have
rolled
into
some
initial
support
for
OCI
registries.
Oci.
If
you
don't
know
the
acronym,
for
it
is
open
container
initiative,
that's
the
backing
body
behind
the
docker
registry
project
and
the
distribution
specifications
and
what
that
means
essentially
is
they're
the
governing
body
for
the
pushing
and
pulling
of
docker
images,
but
they're,
also
interested
in
hosting
more
than
just
docker
images,
they're
interested
in
arbitrary
stuff,
so
Josh
tell
its
key
who's.
Not
over
here.
A
Steve
Lasker
is
up
in
the
back
there,
and
a
bunch
of
other
people
have
been
working
with
the
open
container
initiative
to
see
what
kind
of
use
cases
we
can
solve
this
holistically,
not
just
for
helm,
but
how
we
can
store
artifacts.
On
top
of
docker
registry
M,
so
we
have
initial
support
and
help
chart
push.
A
You
can
now
schema
ties
your
values,
files
using
a
JSON
schema.
So
if
you
install
a
chart,
you
provide
values
that
does
not
validate
against
the
json
schema
it'll,
just
bonk
out,
which
can
be
really
helpful
for
people
who
are
just
like
I'm
sending
in
values
and
I,
don't
know
if
it'll
be
validated
or
its
proper
data.
So
it's
nice
for
chart
authors
to
get
that
information.
A
couple
of
the
things
I'll
just
kind
of
go
through
the
global
namespace
in
a
second
but
consolidating
charts
and
our
requirements
into
chart
gamal.
A
This
is
just
kind
of
some
refactoring
code
that
when
we
initially
released
to
our
helm
to
dotto,
we
weren't
able
to
go
and
make
this
change
when
we
first
introduced
this
feature
so
now
we're
finally
at
3.0,
so
it's
nice
to
actually
go
back
and
do
some
gardening
and
pruning
and
cleaning
up
and
then
as
well.
Some
library
chart
support.
So
how
many
people
have
did
this
error
before
as
they're
upgrading
help?
A
A
So
that
was
not
only
that,
but
there
was
many
different
reasons
why
we've
removed
tiller,
but
that
was
one
of
the
really
nice
value
ads
of
actually
removing
tiller,
as
well
as
the
greatly
improved
security
story.
Around
role
based
access
controls
that
have
been
introduced
since
1.6
I
think
is
when
it
became
GA.
All
right,
don't
quote
me
on
that,
and
then
the
upgrading
helm
liked
that
error
that
you
were
just
seeing
the
getting
started:
you're
not
having
to
do
a
hell
man
it
on
to
create
an
upgrade
tiller
or
to
do
anything
like
that.
A
So
makes
it
really
easy
to
get
started.
You
just
install
the
binary
and
off
you
go
to
the
races
and
the
error
feedback
loop
instead
of
having
to
do
a
client
connection
to
the
kubernetes
api
and
to
tiller
and
to
wait
for
a
G
RPC
response
and
to
get
that
error
feedback
loop,
because
it's
all
being
done
in-house
inside
of
the
helmet
line.
It
makes
it
radically
simplified
for
responding
to
those
errors,
make
it
easier.
A
So
this
is
the
part
that
I'd
quickly
skipped
in
the
thing,
but
one
of
the
things
was
the
namespace
management
was
changed
so
with
the
removal
of
tiller,
because
there's
no
such
thing
as
a
tiller
namespace.
What
we
did
was
we
started
to
think
about
how
can
we
think
of
releases
being
scoped
to
the
name
space
rather
than
being
globally
scoped,
as
in
scope
to
the
tiller
instance?
So
what
this
means
is
now,
when
you
do
a
helm,
install
in
a
particular
namespace.
A
Not
only
is
the
deployments
and
the
application
that
you're
deploying
on
there
is
deployed
in
that
namespace,
but
also
the
release
records
the
in
this
case.
What
used
to
be
the
config
map
that
tiller
would
store,
which
is
now
a
secret.
Those
release
objects
are
now
stored
in
the
same
namespace
as
the
release
itself.
So
now
you
can
actually
have
multiple
releases
with
the
same
name
in
the
cluster,
but
they're
scopes
at
the
namespace
level
and
there's
no
more
koop
system
usage.
A
So
there's
no
more
like
cluster
level
access
that
you
need
to
actually
go
and
finagle
in
there,
so
that
was
home
3
alpha
1.
That's
what
we
currently
have
in
the
Alpha
and
would
love
to
have
you
guys
test
it
out
and
play
with
it
and
get
that
kind
of
feedback
just
want
to
run
into
help
or
alpha
2
and
then
alpha
3.
A
So
one
of
the
things
that
we're
interested
in
playing
around
with
is
these
kind
of
advanced
use
cases
that
we're
seeing
with
some
of
the
people
like
OpenStack
and
other
projects
who
are
interested
in
doing
helm
charts.
But
they've
got
a
lot
of
really
interesting
templating
that
they're
trying
to
do
and
we'd
like
to
see
if
we
can
try
and
make
that
much
simpler
with
chart
hooks
and
with
a
proper
scripting
language.
A
One
of
the
things
as
well
I
think
Michelle
Nirali
has
been
interested
in
taking
a
look
at
a
helm
test
and
getting
that
feedback
from
users
and
seeing
what
we
can
do
to
make
that
a
better
abstraction
and
again
with
the
removal
of
tiller.
We
can
now
remove
Helmand
it,
and
one
of
the
other
things
was
just
kind
of
like
a
nice
thing.
We'd
like
to
do
is
support
the
xdg
base
directory
specification,
which
is
when
you're
creating
a
client
or
anything
else.
A
You
want
to
store
configuration
instead
of
storing
it
in
your
home,
dot
helm.
The
xcg
specification
actually
tells
you
about
the
dot
config
directory
if
you're
on
Mac,
OS,
I
think
it's
like
library,
application
support
and
then
on
Windows
I
think
it's
in
your
app
data
folder,
but
there's
some
conventions
around
the
xyg
based
directory
to
make
it
available
to
store
this
configuration
not
just
for
one
command
but
holistically.
So
it
would
be
nice
to
support
that
specification
and
then
OCI
support
for
all
helm
commands.
So
we
have
it
available
in
3.0.
A
You
can
also
specify
an
OCI
registry
and
it
would
be
able
to
pull
that
down
so
yeah,
so
the
chart
repository
is
the
sub
team
again
Josh
Zielinski
Steve
and
a
bunch
of
other
people
have
been
working
on
on
this.
So
it
won't
go
too
much
into
that
again,
alpha
3.
So
the
reason
why
we
split
it
up
into
alpha
2
and
alpha
3
is
because
we
figured
some
of
the
features
like
the
Lua
hook.
System
might
be
good
to
get
an
initial
release
and
actually
talk
about
some
of
the
feedback
and
all
of
that.
A
But
then
also
we
don't
want
to
hold
off
an
entire
release
with
a
whole
bunch
of
features
and
just
like
slog
on
forever.
So
we
thought,
maybe
we
could
chunk
off
the
Lua
CLI
plugins
stuff
that
we're
interested
in
playing
around
with
and
the
three-way
diff,
which
is
basically
a
server-side,
apply
or
doing
a
different
upgrade,
merge
patch
strategy
for
helm
and
then
also
playing
around
with
different
things
like
CR,
DS,
release,
storage
or
other
objects.
A
So
all
the
proposals
are
all
available
on
github
by
the
way
I'm
just
kind
of
giving
these
in
a
high-level
overview.
So
we
can
go
to
the
Q&A,
but
if
you
want
to
find
any
of
the
information
on
the
proposals
or
the
stuff
that
I'm
talking
about
here,
this
is
all
available
on
the
proposals
which
is
helm
community.
A
So
why
did
we
want
to
talk
about
a
better
upgrade
story
for
helm?
So
currently,
when
you
do
a
helm
upgrade
what
it
does
is
it's
called
a
to
a
merge
patch
and
what
it
does
is
it
takes
the
difference
of
your
previous
release.
The
last
time
you
did
an
install
or
an
upgrade,
and
then
it
does
the
diff
against
what
you're
currently
trying
to
install
or
upgrade
from
there,
and
it
does
not
take
into
effect
anything.
That's
live
in
the
cluster.
A
So
if
you
do
like
a
coop
CTL
edit
on
your
resources
or
live
patching
on
that
on,
like
a
zero-day
exploit
or
whatever
happens
to
be,
why
you're
doing
a
coop
detail
edit
that
doesn't
get
applied
and
a
lot
of
people
obviously
really
want
to
have
that
kind
of
thing.
So
we
early
on
in
kubernetes
1.2
when
helm
2
was
first
released.
There
really
wasn't
a
story
around
like
coop
CTL
apply
I,
don't
even
did
that
exist
back
then
I'm
a
little
bit
past.
A
At
that
time,
I
think
I
came
into
the
helm
project
around
2.4,
so
I
wasn't
there
for
that
kind
of
conversation.
But
from
what
I
understand
the
conversation
was
around
that
there
was
no
real
story
about
doing
these
patches
and
whatnot,
but
now
as
we're
going
into
like
kubernetes,
1.14
eventually
will
go
to
1.15
and
all
that
there's
now.
A
Client
has
to
pull
down
the
manifests,
do
the
dipping
and
then
tell
kubernetes
what
should
be
the
state?
So
that's
what
we
like
to
do-
and
the
other
thing
is
well
about
changing
upgrade-
is
that
we
can't
necessarily
treat
an
individual
resource
inside
of
an
application.
The
same
as
we
treat
another
resource.
A
There
are
relationships
between
all
the
different
resources
that
you
have
inside
of
your
application,
like,
for
example,
if
you
update
a
config
map
or
you
update
a
persistent
volume
or
heavens
forbid,
that
you
delete
your
persistent
volume,
a
person's
volume
claim
from
there
should
that
delete
your
entire
persistent
volume
and
all
state
from
your
application.
I
bet
most
people
in
here,
probably
don't
want
to
have
their
applications
state
deleted
when
they
do
an
upgrade.
So
that's
really.
A
What
we
have
to
do
is
that
we
have
to
have
these
discreet
relationships
between
these
different
resources
inside
of
the
cluster
and
how
we
want
to
treat
the
upgrade
compared
to
just
saying
here's,
the
state:
let's
do
the
upgrade
here
and
well,
let's
hope
for
the
best,
so
that
is
all
I
really
had
to
say.
This
is
super
short
just
wanted
to
give
a
super
high-level
overview.
A
B
Yeah.
Thank
you.
Thank
you
for
your
talk.
It
was
kind
of
super
nice,
so
it's
not
just
a
question.
Maybe
it's
just
your
kind
of
explanation
why
it's
law?
I
know
this
is
kind
of
background
story,
but
maybe
you
can
repeat
the
kind
of
all
the
speech
stuff.
Why
it's
you
law
instead
of
go
templates,
I
mean
a
lot
of
people,
really
love,
go
templates
and
kind
of
use
this
stuff,
but
film,
3e
and
Lua
together.
So
what
the
reason.
A
So
so
one
of
the
things
that
I'd
love
to
reiterate
and
talk
about
is
that
the
Luud
system
that
were
interested
in
doing
is
a
value-add
system.
It's
not
going
to
replace
anything
that
we're
existing
to
do
one
of
the
things
that
we've
really
wanted
to
make
a
success
of
goal
for
helm
or
the
upgrade
from
helm
to
to
helm.
3
is
full
helm
to
chart
support.
So
it's
not
like
we're.
Gonna
go
and
remove
go
templates
entirely,
and
we
want
to
do
that.
A
A
The
question
was
originally
so,
while
OA,
and
why
that
the
reason
really
is
going
back
to
the
question
of
there
are
a
ton
of
charts
that
are
trying
to
do
things
and
go
templates
that
really
shouldn't
be
done
in
go
templates
like,
for
example,
people
who
have
been
defining
functions
and
putting
significant
business
logic
inside
of
their
templates.
In
order
to
do
like
iterations
of
arrays
or
very
simple
things
that
the
go
template,
library
couldn't
do
or
even
sprig,
which
is
the
the
underlying
function.
Helper
library,
inside
of
go
template
or
inside
of
helm.
A
It
would
be
really
nice
in,
in
my
point
of
view,
if
we
could
have
a
way
of
having
a
full
sandbox
environment
for
getting
access
to
different
libraries
that
other
people
inside
of
the
Lua
community
has
like
solved,
for
example,
doing
like
sha
sums
of
different
things
or
just
iterating
over
arrays
or
maps,
or
things
like
that
and
just
doing
basic
string
manipulation
and
which
go
template
is
really
not
meant
to
solve.
So
it's
really
just
more
about
those
advanced
use
cases.
C
A
D
So
replacement
Adam
yeah,
sorry
I'm,
one
of
the
core
maintainer
Taylor.
So
in
ask
that
question
you
can
actually
do
that
now
with
helm,
it
was
2.13
yes,
2.13
with
the
atomic
flag.
That
was
the
atomic
flag,
requires
the
use
of
the
white
flag.
So
if
that's
out
of
your
use
case,
then
that
might
be
a
little
bit
different
story,
but
that
thing
will
automatically
roll
back
or
if
it's
the
first
install
of
a
release,
it
will
delete
it
and
then
do
a
purge
and
then
allow
you
to
reinstall
it.
A
Another
additional
context
to
put
into
that
is
the
question
of
when
you're
doing
an
upgrade.
Do
we
want
to
consider
a
failed
upgrade?
Do
we
want
to
consider
actually
doing
a
full
deletion
of
your
resources,
or
do
we
want
to
consider
that
is
a
state,
and
that
is
a
correct
State
for
users
to
say
that
if
I'm
in
a
failed
state,
this
is
a
time
where
I
maybe
want
to
intervene
and
actually
take
a
look
on
what's
available
in
there.
A
Hopefully,
though,
both
of
those
flags
will
really
be
able
to
solve
those
use
cases
and
make
that
better
for
that
particular
case.
But
at
the
same
time,
it's
when
you're
dealing
with
a
failed
instance.
Is
it
the
trade-off
that
you
actually
want
to
delete
and
start
again
or
is
it
actually?
You
want
to
go
and
inspect
the
infrastructure.
E
E
So
is
there
any
plan
to
introduce
versioning
in
the
in
the
charts
in
the
stable,
for
example,
charts
for
example,
when
my
team?
Every
time
today
we
pull
on
an
nginx
ingress
from
the
stable
repository
every
time
we
get
a
different
version
and
we're
DevOps
team.
So
we
need
to
maintain
the
same
version
every
single
time.
So
it's
been
a
challenge
so.
A
Actually,
this
has
been
a
really
interesting
question
that
I've
been
or
not
me
particular
personally,
but
when
the
OCI
registry
stuff
has
been
going
on,
one
of
the
interesting
things
that
I
actually
didn't
know
about.
Docker
images
is
that
you
can
reference
the
image
itself
by
its
digest,
so
internally,
the
OCI
which
container
D
and
all
of
that
uses
in
docker,
eventually
or
not.
Eventually
it
currently
does.
A
Is
that
not
only
can
you
reference
things
by
their
immutable
tag,
but
you
can
actually
reference
by
the
digest
at
that
point
in
time
and
when
it
was
released,
and
that
can
give
you
a
very
so
instead
of
doing
like
an
engine
X
latest
in
your
images
when
you're
packaging,
your
app
or
your
chart
at
that
point
in
time,
you
can
actually
reference
that
digest
inside
out
there,
and
that
makes
sure
that
that
content
and
you're
doing
an
upgrade
or
you're
doing
an
install
with
that
chart
version.
It
doesn't
get
mutated
necessarily
between
upgrades.
A
F
Something
so
I'm
Martin
I'm,
a
core
maintainer
as
well.
Just
one
thing
what
Taylor
and
Matt
was
saying
a
few
minutes
ago
about
some
fixes
that
might
go
in
just
bear
in
mind
that
cord
was
cut
off
possibly
about
a
year
ago,
so
there
may
be
changes
that
we'd
be
pulling
up.
So
if
you
go,
if
you
go
to
an
alpha
release
of
helm
tree
and
there
might
be
some
capability-
that's
not
there.
F
A
For
sure
I
mean
ever
since
we
did
that
fork,
or
at
least
not
a
fort,
but
actually
removing
tiller,
there's
a
significant
code
change.
So,
if
you're,
finding
a
bug
or
something
in
helm
and
you're
submitting
a
patch
for
that
we'd
love
to
see
also
it
being
ported
over.
Otherwise
we're
just
boarding
that
fix
over
as
well
so
yeah,
just
a
little
bit
of
hand.
Cleaning
I'd.
G
A
So
I
think
one
of
the
things
that
we
had
started
talking
about
was
signing
the
release.
Binaries
that's
happening
inside
of
helm
and
when
we
were
coming
up
to
this
and
realizing
that
our
releases
were
not
signed
and
we're
not
actually
doing
a
proper
attestation
with
our
release
objects,
we
started
to
kind
of
like
shift
into
where
we're
gonna
gbg
sign
all
our
releases
for
now,
because
we
need
to
do
if
we
were
to
stand
up
notary,
we
have
to
actually
have
that
infrastructure
in
place.
A
So
one
of
the
things
that
would
be
really
nice
and
to
see
to
integrate
with
helm,
3
and
our
release
pipeline
is
to
actually
like
stand
up
a
notary
instance.
So
we
can
make
sure
that
the
release
is
or
the
release
assets
that
we're
releasing
to
the
public
all
signed
and
everything
else
rather
than
myself
and
Martin's.
Also
quite
well
aware:
that's
cuz,
he
did
the
214
release.
He
had
to
GPG
sign
every
single
release
and
uploaded
it
github.
A
H
A
H
A
App
version
is
an
interesting
one,
because
that
was
I,
think
that
was
that
it
around
2.9
or
2.10
into
helm,
and
so
that
was
an
originally
core
concept
of
helm
is
just
the
chart
version
itself
and
the
app
version
was
really
about
like
making
it
visually
available
to
web
UI.
Is
that
when
you
were
installing
this
chart,
you're
actually
gonna
get
like
WordPress
at
this
certain
revision,
so
it
wasn't
like
made
part
of
the
upgrade
release
prior.
It
would
be
an
interesting
question
to
talk
about
that,
though,
because
you
could
potentially
have
well.
A
You
could
have
multiple
chart
versions
that
are
constantly
reppin
up,
but
they
reference
the
same
app
version.
So
we've
been
kind
of
saying,
like
chart
version
plus
app
version.
Is
your
neat
unique
key?
That
would
be
an
interesting
question.
Actually,
maybe,
if
you're
interested
it
could
be
an
interesting
proposal
to
talk
about
it's
like
an
issue
or
put
that
up
on
there.
So
we
haven't
actually
thought
about
that,
but
it
would
be
great
to
have
those
kind
of
like
use
cases
and
understand
that
problem.
A
G
A
I
A
You
know
this
part
of
the
architecture.
I
am
not
too
familiar
on,
like
the
cross
chart
namespace
in
the
understanding
of
those
use
cases.
I
haven't
necessarily
dealt
with
that
myself.
So
I
really
would
not
be
the
qualified
person,
probably
Adam
who's.
Unfortunately,
it
was
not
able
to
make
it
here
or
Matt
butcher
or
some
others,
so
I
would
like.
If
you
want
to
ask
that
and
like
the
helm,
Deb
channel
or
in
the
user
channel.
That
would
be
a
great
question
to
ask
in
there
I'm
sorry
I
can't
really
answer
that
question
for
you.
J
J
If
for
anyone
who
is
in
the
session
about
helm,
3
I
did
a
demo
where
I
talked
about
namespaces
and
I
kind
of
showed
different
deployments.
So
I
had
three
different
charts
in
that
demo,
one
of
which
I
also
was
a
certificate
issuer
and
then
that
certificate
issuer
was
part
of
the
jetpack,
certain
manager
or
sorry,
not
certificate
issuer
very
tired,
cert
manager,
and
that
was
actually
in
the
coop
system
namespace.
J
But
every
other
deployment
was
part
of
the
default
namespace
and
for
me
to
still
make
sure
that
I
was
issued,
TLS
certificates,
which
unfortunately
I
could
not
show
in
the
demo,
but
I
have
working.
Now.
It's
still
issues,
even
though
there's
there's
charts
across
different
namespaces,
so
I
can
tell
you
that
it
works.
J
What
I
don't
know
and
what
I
think
we'll
need
to
get
clarification
on
is,
if
you
have
security
policies
in
place
and
you
have
a
lockdown
but
from
an
open
perspective,
I
didn't
do
any
additional
configuration
I
just
deployed
as
normal
I
had
namespace
I
had
three
different
charts
in
three
different
namespaces.
They
still
were
able
to
pull
the
resources
that
they
needed
to
pull.
Even
though
there
was
cross
namespace
helm,
chart
releases.
A
K
A
Again,
like
the
whole,
go
template
in
Lua
thing
as
well,
like
I,
think
would
be
handling
it.
The
exact
same
way
with
Lua
plugins.
It's
not
necessarily
we're
gonna
replace
the
existing
plug-in
system
that
we
have,
as
is
it's
just
another
way,
to
write
plugins
in
a
different
system,
so,
instead
of
having
to
like
compile
them
down
into
binaries,
or
something
like
that,
if
we
have
the
Lua
engine
in,
we
could
potentially
just
have
a
Lua
script
and
that
make
that
as
a
plug-in
and
inject
that
into
the
CLI.
D
H
H
A
Actually
so
Jessica
and
Brigitte
did
a
talk.
It
was
about
an
hour
ago,
an
hour
and
a
half
ago,
and
one
of
the
things
that
was
really
really
could
have
been
a
really
handy
use
case
in
there
is,
for
example,
if
you
want
to
make
sure
that
all
the
charts
that
you're
deploying
in
your
organization
is
interested
in
injecting
a
pod
security
policy
and
all
your
things.
A
That
is
an
abstract,
ibill
piece
of
work
that
you
can
add
into
a
library
chart
so
backing
up
just
a
quick
pin
it
a
library
chart
from
what
we
understand
and
the
current
alpha
system
right
now
is
it's
the
exact
same
as
an
existing
chart,
except
that
when
we
actually
go
to
rendering
the
chart
and
going
to
install
it,
the
chart
itself
does
not
render
any
templates
at
all.
The
only
things
that
we're
caring
about
is
the
define
templates,
which
is
the
functions
that
it
provides.
F
Just
to
add
to
that,
what
we've
also
done
is
we've
added
a
type
into
a
chart,
so
a
chart
can
be
of
two
types:
no,
it
can
be
an
application
and
a
library
chart
and
why
we've
done.
That
is
because
the
library
chart
concept
has
been
there
for
a
while.
But
what
we
do
know
with
the
idea
of
is
that
it's
no
core
core
functionality
and
what
you
can
do
with
your
chart
is.
F
You
may
have
a
normal
application
chart
which
you
may
have
capability
and
that,
where
you
put
common
capability
in
and
you
might
want
to
use
it
in
another
chart,
so
what
you
can
then
is
defining
the
chart
as
a
library
chart,
and
none
of
the
templates
that
it
normally
be
rendered
would
be
rendered
in
that
situation.
Just
the
chart
that
you're
extending
basically
so
have
a
look
in
the
docs,
we'll
be
updating
them
more
on
that.
But
there
is
some
nice
functionality.
F
F
They
define
them
inside
and
our
helper
files,
so
that,
basically,
if
somebody
in
if
people
in
your
company
was
writing
charts
and
you
wanted
to
make
sure
that
they
put
all
the
proper,
create
labels
in
you'd
have
that
capability
forum
and
it
could
be
loaded
straight
up
into
their
chart
into
their
template
files
on
the
right
nuts.
Oh
right.