►
From YouTube: Learn About Helm And Its Ecosystem - Andrew Block & Karena Angell, Matt Farina, Scott Rigby
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Learn About Helm And Its Ecosystem - Andrew Block & Karena Angell, Red Hat; Matt Farina, SUSE; Scott Rigby, Weaveworks
Speakers: Matt Farina, Karena Angell, Scott Rigby, Andrew Block
Helm, the package manager for Kubernetes, isn't just a mature graduated CNCF project. It's a package manager with an ecosystem surrounding it that makes life better for those building and using Kubernetes packages. In this session you'll get a short introduction to Helm itself. From there we'll take a journey down two paths. One path will look at the ecosystem around building packages. This will include tools and processes to help you with that. On the other path we'll look at using Helm and its packages in your clusters. This will explore Helm and the various projects around it that you may want to use. When this session is done you'll have a good grasp on what Helm is and where you can get started using it.
A
B
A
A
Of
you
so
I'll
introduce
myself
first
and
then
I'll
pass
the
mic
off
to
others:
I'm
Scott,
Rigby
I'm,
a
developer
experience
engineer
at
weaveworks
I
am
a
health
maintainer
and
I
I
work.
Let's
see,
I'm
also
a
flux.
Maintainer
I
also
am
part
of
the
get
Ops
working
group
and
co-chair
that.
So,
if
anybody's
interested
in
that
side
of
the
ecosystem
feel
free
to
come
and
find
me
no.
D
So
before
we
get
started
talking
about
the
ecosystem,
we
wanted
to
talk
about
what
is
Helm.
A
lot
of
people
have
their
own
ideas
on
what
home
is
and
where
it
fits
in,
but
we
have
an
idea
on
where
it
fits
in,
which
is
important
to
knowing
boundaries
and
what's
going
on
with
the
ecosystem
and
Helm
is
a
package
manager
right
and
what
is
a
package
manager?
We
call
it
a
package
manager,
we
say
it
and
a
package
manager
is
really
about.
D
You
know:
here's
the
definitions
from
Wikipedia,
here's
what
we
say
in
Helm
it
talks
about.
You
know
that
traditional
tool
that
thing
you
can
think
of
as
yum
or
apt
or
zipper
or
if
you're
on
Mac.
You
know
maybe
Homebrew
something
like
that
where
you
package
something
up
and-
and
so
these
are
the
definitions
and
that's
what
you
traditionally
think-
and
this
is
what
I've
put
together
right,
because
there's
more
to
this
concept
than
just
packaging,
something
up
right.
D
The
the
always
example
thing
for
WordPress
and
if
you're
going
to
go,
install
WordPress
yourself
you're
going
to
have
all
of
these
different
resources
deployments:
horizontal
pod,
Auto,
scalers,
Services,
Network
policies,
Ingress
stateful
sets
you're
gonna,
have
secrets,
along
with
WordPress
itself,
and
you're
gonna
have
more
than
one
of
these
you're
going
to
have
over
a
dozen
different
emo
files,
hundreds
and
hundreds
of
lines
of
yaml
that
somebody
needs
to
install
and
they
need
to
know
your
database.
They
need
to
know
WordPress
all
of
this
stuff
to
figure
out
how
to
do
it.
D
Well,
and
somebody
just
says:
I
just
want
to
run
it
right.
That's
a
lot
to
have
in
one
place,
but
when
you
can
package
that
up
and
then
distribute
it
for
others
to
use
and
install
or
maybe
other
people
in
your
own
organization,
that's
a
really
nice
useful
thing
and
that's
where
Helm
sits.
It
is
a
package
manager
and
we
draw
our
boundaries
there.
D
But
by
drawing
our
boundaries
and
knowing
what
our
boundaries
are,
that
means
other
projects
can
pick
up
from
and
when
we
think
about
Helm
I
like
to
break
it
into
kind
of
three
really
useful
parts.
The
first
you
have
charts
the
packages
that
you
package,
everything
up
in
and
you've
got.
You
know
your
chart
yaml,
you
may
have
your
Json
schema,
which
is
really
useful
for
for
some
things.
You've
got
your
templates,
maybe
your
crds
in
there.
Hopefully,
you've
got
to
read
me
in
notes.
D
So
people
know
what
they're
getting
into,
but
you've
got
these
kinds
of
things
and
you
package
all
of
that
up
into
a
chart.
Then
you
have
the
helm
client,
which
is
where
a
lot
of
people
use
it.
It's
that
CLI
that
you
go
run
to
install
things
right,
Helm,
install
WordPress
and
in
this
example,
I'm
grabbing
it
from
bitnami,
because
that's
where
most
of
the
demos
do
for
this,
and
it
goes
ahead
and
installs
it
into
a
cluster
from
there.
You
can
upgrade
it
do
other
things.
D
You
can
even
use
values
and
you
can
set
the
title
and
other
stuff
for
it
there,
because
you
can
encapsulate
business
logic
and
pass
that
through
the
helm
CLI
to
pass
that
along,
but
there's
another
important
piece
to
all
of
this
and
that's
the
helm,
SDK
and
the
helm.
Sdk
is
really
what
the
helm
CLI
is
built
upon.
We
took
when
Helm
version
3
was
being
created.
D
People
wanted
to
build
things
on
top
of
it
things
like
flocks
and
other
things,
and
they
said
you
know
we
wish
we
could
access
it
and
it
wasn't
just
part
of
the
main
package.
You
can't
import
and
go,
and
so
we
converted
everything
virtually
everything
into
a
package
and
then
the
helm
CLI
the
code
for
that
Imports
that
package,
so
other
things
can
then
build
upon
it
and
that
I
think
was
one
of
the
best
things
we
did,
because
it
enables
other
tools
to
build
upon
that
same
logic
that
we
have
in
Helm
client.
D
We
fix
a
bug,
they
get
the
bug
fix.
We
add
a
feature
such
as
when
we
added
oci,
you
know,
chart
Registries
to
push
and
pull
charts
from
anybody
who
picks
it
up.
Can
then
just
inherit
that
feature,
and
this
SDK
is
this
incredibly
powerful
piece
to
what
makes
Helm
possible
and
when
it
comes
to
the
ecosystem.
Somebody
sent
me
a
picture
just
like
this.
The
other
day
and-
and
this
is
next
case-
CD
graphic
and
I've
altered-
put
Helm
under
there.
D
When
you
look
at
some
of
the
things
that
they're
going
to
walk
through
in
just
a
minute
and
we're
going
to
walk
through
a
lot
of
different
things,
you
can
see,
Helm
is
an
underpinning
and
that
underpinning
is
really
important
to
making.
You
know
how
we
build
that,
how
we
treat
that
is
really
important
to
everything
that's
built
on
top
of
it.
If
we
break
that,
we
break
all
of
them
and
we
have
to
keep
those
things
in
mind.
D
So
with
that
in
mind,
Helm
is
stable
software
right
and
in
fact
we
have
a
backwards
compatibility
guarantee.
If
you
go
over
to
github.com
helm,
slash
Community,
we
have
these
Helm
Improvement
proposals
and
one
of
them
that
I've
got
up
here
is
our
backwards
compatibility
guarantee
where
we
actually
talk
about
all
of
the
things
we're
going
to
be
backwards
compatible
on
and
how
we
do
it
right.
Our
string
message
is
backwards,
compatible
or
not.
One
of
my
biggest
pet
peeves
is
dates.
D
We
have
this
one
place
where
the
date
format's
different
and
we
can't
change
that
until
Helm
version
four,
because
we'll
break
backwards,
compatibility
for
things
that
read
dates,
and
but
we
keep
that
because
we
know
stability
is
important
for
people
who
use
that
we
could
add
a
flag,
we
did
add
a
flag
yeah,
so
the
format.
So
for
this
we
follow
semantic
versioning,
because
we
think
it's
important
to
broadcast
our
guarantees
right.
Major
Breaking
Chains
only
happen
with
the
major
and
we're
going
to
be
backwards.
D
Compatibility
minor
features
come
in
minor
releases
three
times
a
year,
we're
about
a
month,
Delay
from
kubernetes
releases.
It's
very
predictable,
it's
the
second
Wednesday
of
the
month.
Unless
it
comes
just
after
the
holiday
season
in
November,
then
it's
the
third
Wednesday
and
you
can
count
on
it
unless
something
comes
up
unless
there's
something
that
throws
us
off,
that's
what
we
do
and
then
patch
releases
on
the
Wednesdays.
When
we
don't
have
minor
releases,
it's
it's
very
predictable,
because
we
know
people
build
on
it.
They
depend
on
it.
D
They
need
to
know
when
things
are
happening,
and
all
of
that
is
why
Helm
is
a
graduated
project.
You
probably
saw
this
this
morning
in
the
keynote
talks
and
Helm
is
a
graduated
project
because
we
had
to
have
that
maturity,
so
things
could
be
built
upon
it,
and
so,
with
that
I'm
going
to
hand
off
to
let
Scott
start
talking
about
our
ecosystem.
A
Thanks
Matt
yeah,
so
some
of
these
initial
images
are
are
graphs
that
expand
on
what
Matt
was
just
saying
about
about
how
to
Envision,
where
Helm
fits
within
the
boundaries
of
the
ecosystem.
So
the
very
first
one,
oh,
and
by
the
way
these
images
are,
are,
are
modified
from
a
blog
post
that
Matt
farina
actually
wrote
for
four
or
five
years
ago,
but
but
anyway,
this
is.
A
The
binaries
are,
you
know
the
applications
themselves.
So
exactly
you
know
in
the
case
that
Matt
mentioned
before
with
WordPress
or
something
like
you
know
things
that
it
relies
on
like
postgres
or
MySQL.
Those
are
the
actual
running
applications
themselves.
Those
binaries
the
config
in
this
scheme
is
the
configurations
for
those
applications
so
for
for
WordPress
or
Drupal,
or
something
like
that
there
are.
There
are
actual
config
files
for
that
app
for
its
dependencies.
A
A
You
know,
which
is
something
like
you
know,
which
actually
like
helps
you
to
determine
which
environments
you're
deploying
on
different
different
things
that
are
important
for
you
in
your
workflow
and
your
organizations,
and
so
on.
So
just
to
give
you
an
example
of
what
those
are.
This
is
just
very
general
and
vague,
but
it
kind
of
helps
to
to
to
get
more
specific
to
what
we're
doing
in
kubernetes
to
to
compare
it
to
something
like
like
a
typical
Linux
setup.
A
So
you've
got
that
that
Linux
that
Linux
layer
is
is
maps
to
the
the
OS.
In
this
case
the
the
elf
binaries,
just
like,
whatever
our
package,
those
binaries
that
are
packaged
for
your
Linux
environment,
on
whatever
architecture
and
you
know
say,
you've
got
you've,
got
your
configuration
files
and
Etc
or
or
depending
on
your
architecture
in
another
spot
right.
A
And
then
this
is
where
we
compare
with
Helen
is.
Is
the
package
manager
in
this
case
is
like
apt
what
what
Matt
was
mentioning
say?
This
was
a
Mac
environment.
It
would
be
Homebrew
Etc,
that's
actually
what
controls
and
helps
that
process,
or
it's
supposed
to
anyway,
what
controls
and
helps
that
process
for
users
right
and
then
what
your
your,
your
config
manager.
A
The
examples
here
are
like
Chef
puppet
ansible
now
get
Ops
would
fit
in
this
category.
I
probably
should
have
added
that
to
the
list,
but
but
those
are
the
examples
right
and
then
you
know
so
so
that
just
kind
of
brings
us
to
where
we
are
now.
Os
is
kubernetes
in
this
case
for
Helm
right,
the
the
images
are,
the
binaries,
the
the
configs
are
the
kubernetes
resources
and
then
there's
Helm
is
the
package
manager
and
so
basically
like
in
your
configuration
management,
there's
a
lot
of
different
options.
A
Now
today,
so
yeah
I
was
mentioning
like.
There
are
git
Ops
tools.
There
are.
There
are
various
other
ways
to
actually
manage
those
configurations
and
manage
Helm
for
you
also.
The
helm,
CLI
is
an
example
of
that
when
you're
just
doing
it
manually,
okay,
so
I
think
this
section
is
me
again:
I'm
just
going
to
go
through
a
couple
of
a
couple
of
options
that
fit
into
that
top
category
for
platform
and
App
Management
get
Ops
fits
in
here
as
well.
So
one
is,
is
flux.
I'd
mentioned
this
earlier.
A
This
is
an
example
of
flux,
architecture
not
having
to
do
with
any
of
the
uis
yet,
but
basically,
flux
draws
from
oh
boy.
I
wish
I
had
a
pointer,
but
on
the
right
flux
draws
from
things
like
GitHub
and
you
know,
chart
Museum
and
and
and
now
also
things
like
oci
Registries
and
S3
buckets
and
things
like
that
as
sources.
It
sends
that
information
to
the
kubernetes
API
and
then
there's
a
controller
in
this
diagram.
A
We're
focusing
on
Helms
or
other
controllers,
but
the
helm
controller
then
talks
to
the
cube
API
to
get
those
custom
resource
definitions
and
and
the
information
about
where
to
find
those
configs
and
packages
that
the
source
controller
pulls
into
your
cluster.
And
then
it
manages
your
Helm
releases
for
you
using
the
helm
SDK
that
Matt
mentioned
earlier
yeah.
A
So
that's
just
an
example
of
that
one
I'm
a
little
more
knowledgeable
about
that,
because
I
help
on
that
project,
there's
also
the
Argo
project,
which
does
a
similar
thing
just
in
somewhat
different
ways.
It
primarily
uses
the
helm
binary
to
to
to
template
out
your
your
resource
files
from
a
Helm
chart,
and
then
it
does
otherwise
a
relatively
similar
thing
it.
It
manages
Helm
in
an
unattended
way,
for
you
too
and
one
you
know.
A
One
of
the
other
examples
of
that
that's
been
around
for
for
many
years
now
is
Helm
file.
It's
a
bit
of
an
older
example.
It
doesn't
use
crds
to
so
there's
no
exact.
Let's
see
API
contract
for
the
structured
way
in
which
you
should
manage
your
configs
for
your
Helm
releases.
It
uses
yaml,
but
that's
I
believe
because
it
was
started
before
crds.
We're
really
we're
really
we're
really
mature
and
it's
all
it's
a
project
that
people
still
use
and
it's
still
it's
still
a
really
good
project.
A
A
There
are
pros
and
cons
to
each
of
these
I
believe
there
are
still
some
issues
with
with
wait,
time
and
hooks,
but
but
otherwise,
and
for
many
folks
it
works
really
really
well
and
it
may
just
fit
your
use
case
so
I
think
oh
I
guess
it's
me
and
this
one
as
well.
I'm
just
gonna
fly
through
chart
storage
because
I
know
we
need
to
get
on
to
the
other
folks.
But
basically
there
are
different
ways
to
store
your
charts
right.
I
had
mentioned
oci
as
well.
A
In
this
case,
all
of
the
major
ones,
except
currently
there's
work
being
done
very
hard
work
at
Docker
Hub
to
support
this,
and
it's
not
quite
there
yet
so
close
so
close,
but
but
but
that's
okay,
because
because
you
can
use
Docker
hub
for
all
of
your
other
containers
or
some
of
them
or
or
none
of
them
as
you
as
you
choose
the
other.
Let's
see
there's
information
about
how
to
do
that
in
this
case
in
the
in
the
AWS
docs.
A
But
every
single
container
registry
from
every
major
cloud
has
similar
docs,
including
GitHub,
ghcr
and,
and
all
of
that
Harbor
is,
is-
is
very
similar
in
this
way.
I'm,
actually
not
really
going
to
talk
a
whole
lot
about
Harbor
I.
Think
I
should
probably
fly
through
these
now,
but
but
you
you
basically
there's,
there's
additional
options
for
chart
storage
there.
A
D
A
Didn't
know
that
part,
that's
that's
awesome.
Okay,
so
t-I-l,
today,
I
learned
and
yeah.
So
traditionally
so
we
mentioned
I
mentioned
oci
Registries.
Of
course,
traditional
chart
repositories
that
are
in
HTTP
endpoint
with
an
index
file.
Those
are
still
supported
and
that's
not
going
away
anytime
soon.
A
You
can
also
yeah
you
can
use,
you
can
use
Health
plugins
Helm
has
a
plug-in
system,
so
you
can
store
your
charts
in
other
places.
This
is
an
example
of
a
plug-in
to
allow
you
to
store
your
charts
in
in
S3
or
S3
compatible
buckets
without
without
the
need
for
another
tool
like
I
mentioned.
Flux
allows
you
to
do
that
without
the
need
for
some
other
tool
to
help
you
with
that.
You
can
do
that
directly
with
the
home
binary
using
plugins
and
speaking
of
plugins.
A
C
B
B
No
yeah?
Sorry
exactly
now,
we
know
all
right,
so
Helm
charts
were
all
designed
to
be
shared
in
a
distributed
manner
right
and
even
when
Helm
had
its
own
charts
repo.
The
whole
system
was
designed
to
have
distributed
charts
to
repos.
So
with
the
old
Helm
Hub
yep
deprecated.
It
was
the
first
attempt
to
help
people
find
these
charts,
but
it
didn't
scale
very
well
and
instead
of
creating
a
newer
version
of
the
helm,
Hub,
a
artifact
Hub
was
created.
B
B
And
you
can
see
the
change
log
in
screenshots
too,
so
this
works
again
for
Helm
charts
and
your
hum
repos
and
your
oci
Registries.
So
if
you're
using
RCI
all
right,
so
some
of
this
information
bubbles
up
to
the
search
results
and
things
like
a
chart
being
the
official
chart
of
a
project
or
that
artifact
have
has
verified
the
owner.
You
know
that's
very
important
for
a
lot
of
Enterprises
that
are
using
it
and
security
scans.
B
Okay
and
artifact
Hub,
again
isn't
just
home
hub.
So,
as
you
can
see,
you
can
search
for
Helm
charts,
your
operators,
your
tecton
chains
and
so
many
more
things
so
go
check
out.
Artifact,
hub
and
other
things
are
also
Helm
plugins,
so
plug-in
developers
can
list
them
here
and
if
you
are
a
plug-in
developer,
please
go
list
your
plugins
and
you
can
search
for
them
here
and,
of
course,
artifact
Hub.
Isn't
the
only
place
to
discover
your
charts?
B
Now,
let's
move
to
Discovery
and
install
so
there's
more
to
all
of
this
than
just
Discovery
default
values.
Json
schemas
and
packages
means
that
you
have
enough
to
tackle
the
install
problem
in
addition
to
the
Discovery
problem,
for
example,
so
package
managers
have
been
used
to
build
app
stores
for
a
long
time,
and
this
is
an
example
of
Pop
OS
and
it
can
work
with
multiple
package
managers.
B
Here's
an
example
of
the
Rancher
charts
catalog,
where
you
can
search
for
your
charts
and
easily
install
them.
Look
at
your
chart
versions,
nice
UI
and
if
you
are
using
openshift,
go
into
the
developer
console
you
can
go
search
for
your
Helm
charts
and
you
can
deploy
them
to
your
project
and
the
wave
get
Ops
GUI
with
it.
The
installer
you
can
go
through
and
install
your
chart.
C
All
right
for
the
developers
in
the
house,
we
already
have
a
section
on
developer
tools
and
how
you
can
integrate
the
helm
ecosystem
into
your
workflows.
Let's
start
out
with
kind
of
going
back
to
what
Matt
started
earlier
was
the
SDK.
How
many
here,
who
have
actually
used
the
go
SDK
when
doing
development?
C
Okay,
there's
some
hands,
that's
pretty
good
way
for
you
to
get
involved.
If
you
have
a
PL,
if
you
want
to
create
an
integration
with
Helm
use
the
SDK
now
this
is
one
challenge
that
I
as
a
developer,
find,
especially
when
I'm
developing
my
own
Helm
charts
is
generating
Json
schema.
Well,
there
are
two
plugins
and
other
options
out
here
to
help
you
generate
your
Json
schema
resources.
There
are
two
plugins
that
you
can
go
to.
One
of
them
here
on
the
left
is
actually
deprecated.
C
C
If
you're,
a
visual
person,
you
know,
developers
aren't
necessarily
all
a
command
line.
There's
a
there's
a
react:
UI
that
can
showcases
all
the
different
values
render
appropriately
so
that
you
can
ensure
that
the
values
that
you
expect
are
available
in
a
nice
rich
user
interface,
there's
also
chart
verifier,
so
you
can
verify
certain
conditions
available
for
your
application.
So
if
you
have
consumers
who
are
producers
that
you
want
to
serve
charts,
you
can
run
it
through
a
verifier.
C
Now
some
tools
from
the
helm
project
itself,
the
chart,
testing
tool
chart
testing
is
a
fantastic
tool
because
it
can
not
only
showcase
how
you
can
verify
that
it
lends
appropriately,
but
you
can
also
test
the
chart
within
a
live
kubernetes
environment
and,
if
you're
also
developing,
you
probably
have
some
CI
around
your
your
Helm
charts.
There
are
a
couple
actions
that
are
available
from
the
helm
Community
to
help
you
there's
the
the
release,
action
that
helps
you
release
your
artifacts
and
then
there's
also
a
wrap
around
the
chart.
C
Tester
that
I
just
mentioned
a
moment
ago,
both
really
easy
to
integrate
into
your
get
out.
Github
workflow,
but
those
two
just
from
the
helm
project
are
just
the
beginning:
there's
tons
of
Hell
actions
in
the
GitHub
catalog.
So
if
you're
interested
in
leveraging
the
various
ways,
Helm
can
be
used
in
GitHub
workflows
check
out
the
different
actions
that
are
available,
but
then
there's
also
just
working
in
your
IDE.
How
do
you
go
ahead
and
work
on
your
day-to-day
life
working
with
Helm
and
Helm
development?
Well,
first,
there's
the
vs
code
extension.
C
So,
if
you
are
a
vs
coder
being
able
to
integrate
Helm
into
your
workflow
is
really
easy.
If
you
want
to
use
an
extension
great,
it's
available,
if
you
want,
if
you
want
to
just
go
ahead
and
manage
it
without
one,
we
have
options
too
and
you
don't
even
need
a
UI.
You
can
just
use
vim
and
there's
a
syntax
highlighter
on
there.
It's
not
everything's
about
the
UI
folks,
there's
always
folks
who
never
ever
want
to
look
at
a
UI
and
Vim.
C
D
All
right,
thank
you,
so
before
I
jump
into
that,
I
just
want
to
say
all
of
what
we
just
showed.
You
was
just
a
fraction
of
the
projects
that
are
out
there
that
are
built
on
top
of
Helm
and
some
of
its
developer
tools,
some
of
it's
what
you
need
for
production,
and
all
of
that
is
because
Helm
has
a
stable,
API,
a
stable
surface
area,
and
you
know
what
you're
going
to
get
and
without
that
we'd
be
breaking
folks
all
the
time
and
so
that
that
does
enable
it.
D
Now,
if
you
want
to
get
involved,
that's
great.
We
love
involvement
in
the
home
community
and
one
of
the
first
things
is:
if
you
have
your
own
project
right
built
on
top
of
Helm,
we
encourage
that
build
projects
on
top
of
home.
Get
involved.
You've
got
something
new
to
create.
There's
the
helm,
SDK,
there's
even
other
tools
you
can
use
as
intermediate
layers
get
involved,
build
something
if
you've
got
an
itch
to
scratch.
D
D
You
can
also
get
involved
in
the
helm
source
code.
We
are
always
looking
for
people
to
help
fix
bugs
answer.
You
know,
respond
to
issues
and
contribute.
You
know
new
features
and
new
ways
of
doing
things.
Even
though
we're
not
breaking
apis,
we
do
add
functionality
and
minor
releases,
all
the
time
and
so
come
contribute
if
you're
using
Helm
and
you're
looking
where's
some
place,
that
I
can
get
involved
in
the
ecosystem
and
give
back
Helm,
and
we
can
help
onboard
you
and
help
you
get
started.
D
And
if
you
want
to
know
more
about
all
this
stuff,
of
course,
there's
the
helm
website
you
can
go
over
here,
learn
about
plugins,
learn
about
the
ecosystem,
learn
about
contributing
and
getting
involved,
because
we
try
to
document
all
of
it
as
much
as
we
can,
and
you
can
also
find
more
about
the
home
community.
On
slack,
we
have
a
weekly
community
meeting
on
Thursdays
and
we
have
a
mailing
list.
You
can
do
that.
You
can
also-
and
I
didn't
I
failed
to
put
it
up
on
the
slide.
D
A
A
We
mentioned
it
in
last
talk,
so
it
won't
go
on
too
much
about
it,
but
just
as
a
reminder
again,
if
you
want
to
get
involved
in
Helm,
one
of
the
best
ways
right
now,
yes
contributing
code,
but
we
have
something
like
200
to
300,
open,
PR's,
right,
I,
think
in
the
helm
project
we
need
people
to
help
review
PRS,
and
that
might
mean
just
actually
please.
You
know,
because
hell
maintainers
only
have
so
much
time
and
we're
often
doing
a
lot
of
other
things.
A
A
So
if
you
can
open
up
an
issue,
if
you're
interested
in
getting
involved
the
path
towards
becoming
a
Helm
triage
maintainer,
if
you
would
like
you're
still
an
actual
Helm
maintainer,
it's
just
on
the
rung
towards
helping
to
maintain
other
things,
you
can
open
up
a
pull
request
or
excuse
me:
go
in
the
pull
requests
list
for
Helm,
Helm
or
actually
any
of
the
other
projects,
but
I
think
Helm
Helm.
We
need
it
the
most
open
up,
a
pull
request.
A
D
All
right,
thank
you,
Scott
yeah
and,
as
I
talked
about
this
morning
in
the
Keynotes,
it's
we're
looking
for
contributors,
the
whole
cncf
is
looking
for
contributors
and
we've
got
a
path
to
help
people
who
are
interested
in
getting
into
it,
and
you
can
learn
so
much
along
the
way
like
how
to
maintain
a
mature
project.
What
does
that
even
mean?
D
There's
so
many
little
things
to
it
and
there's
opportunities
to
learn
that
I've
learned
play
out
in
my
daily
life
in
doing
the
other
things
that
I
do
for
work
so
with
that
I
guess:
I'll,
open
it
up
to
questions
and
again
you
can
find
us
starting
at
2
30
today
in
the
booth,
we'll
also
be
down
there
tomorrow
afternoon
as
well.
Does
anybody
have
any
questions.
D
D
Certainly
so
he
asked
if
you
build
a
tool
for
the
community,
is
there
a
way
to
Showcase
that
I
would
say,
there's
a
couple
of
different
ways:
one
we
have
weekly
meetings
on
Thursdays.
We
love
demos,
the
second
thing
or
there's
more
than
why
we
have
a
tag
because
you
can
tag
repositories
up
on
GitHub
and
people
can
go
see
all
of
the
things
there,
and
so
we
have
a
a
tag
for
that:
I'm,
forgetting
what
it
is
right
now
and
then
we
also
have
a
related
page
in
the
docs.
D
D
That's
happened.
That's
where
Helm
template
came
from,
so
he
asked.
Would
a
plug-in
ever
become
so
popular
that
we
would
pull
it
into
the
helm
Source
itself,
and
the
answer
is
yes:
we've
actually
done
that.
That's
where
Helm
template
came
from.
It
hasn't
happened
in
a
long
time,
because
one
of
the
things
we
are
encouraging
is
a
healthy
plug-in
ecosystem
around
it
and
letting
things
naturally
come
and
go
that
way.
But
if
there
is
really
high
demand,
it
is
a
possibility.