►
Description
How does Helm help you manage Kubernetes applications? Scott Rigby and Cornelia Davis from Weaveworks return to talk about using Helm in your GitOps workflows. If you’re just getting started with the Helm package manager and installing helm charts, this is the episode for you.
Cornelia Davis is the CTO at WeaveWorks. She is responsible for the company’s technology strategy, inclusive of open source projects, commercial products and services offerings.
Scott Rigby is a Developer Experience Engineer at Weaveworks. He co-founded the Basekamp art and research group in 1998 and the massively collaborative Plausible Artworlds international network. In technology he enjoys helping develop open source software that anyone can use, most recently projects in the cloud native landscape including co-maintaining Helm and Flux.
Follow us:
Scott Rigby https://twitter.com/r6by
Cornelia Davis https://twitter.com/cdavisafc
Weaveworks https://twitter.com/weaveworks
Christian Hernandez https://twitter.com/christianh814
Chris Short https://twitter.com/ChrisShort
What is GitOps Guide to the Galaxy?
Every other Thursday at 3am ET hosts Christian Hernandez and Chris Short sit down to discuss everything in the GitOps universe, from end-to-end CICD pipelines to creating Git workflows.
Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_c...
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
Openshift.com https://red.ht/33Fh6uV
OpenShift on github https://github.com/openshift/
OpenShift on redhat.com https://red.ht/2o4ccDk
#RedHat #GitOps #Kubernetes
A
A
A
A
A
A
Good
morning,
good
afternoon,
good
evening,
wherever
you're
hailing
from
welcome
to
another
episode
of
get
get-offs
guide
to
the
galaxy,
I
am
chris
short,
the
one
with
unstable
internet
today,
also
the
executive
producer
of
open
shift
tv.
So
it's
been
kind
of
a
stressful
day
for
me,
but
I'm
joined
by
two
of
my
friends,
christian
hernandez
and
scott
rigby,
who
both,
I
believe
were
named
to
the
open,
get
ops
group,
or
at
least
christian
was
so
congratulations
to
christian
yeah.
A
B
B
C
B
Yeah
yeah
exactly
well
I'll,
clone
and
fork
it.
We
are
we're
open
source.
So
so
what
so?
Yeah
we're
joined
today
by
scott
scott
welcome
scott
scott
is
I'll.
Let
you
introduce
yourself
here,
but
he's
he's
all
he's
part
of
part
of
a
lot
of
things
right.
He
takes
part
of
the
flux
upstream,
also
helm.
He
also
is
again,
like
chris
short
said,
the
part
of
the
open
get
ups
working
group
that
were
that
were
all
that
were
all
taken.
B
B
I'll
get
my
couches
ready,
you
guys
got
there,
so
cfps
are
open.
I'm
going
to
put
that
in
the
chat
see
if
these
are
open.
Please
submit
a
cfp.
We
got
a
lot
of
great
participation
last
time.
This
is
gonna,
be
a
co
hybrid
event
right
so
we'll
have
some
recorded
pre-recorded
stuff,
there's
gonna
be
some
live.
Some
live
events
as
well,
so
it'll
it'll
be
a
lot
of
fun.
So,
but
with
that,
scott
want
to
introduce
yourself.
A
C
Second
and
that's
very
exciting:
well
there
you
go
there
we
go.
Can
you
hear
me?
Can
you
see
me
okay,
both
here
and
see
you?
Yes,
all
right,
okay,
yeah!
So
not
that
I
necessarily
needed
this
to
outline
myself,
but
it's
not
on
my
slide
anyway.
So
yeah,
I'm
scott
rigby.
So
where
I
work
is
weaveworks
and
I
am
on
the
dx
team,
the
developer
experience
team.
It
is
an
awesome
team
for
people
who
are
interested
in
joining
that
kind
of
thing.
So
yeah
I
I
am
a
like.
C
So
yes,
I
am
a
helm,
org
maintainer
and
I'm
part
of
the
helm
team.
I
have
been
for
a
number
of
years.
I
primarily
focused
on
you,
know
the
org
side
of
thing
and
the
governance
org
side
of
thing,
as
well
as
the
I'm
on
the
charts
team.
We
used
to
manage
and
co-maintain
all
of
the
the
stable
and
incubator
community
charts,
and
now
we
maintain
that
the
charts,
tooling
automation
and
all
the
other
things
that
help
people
do
distributed
charts.
C
So
I'm
also
on
the
flux,
community
and
security
teams,
and
I'm
generally
part
of
that
team
and,
like
you
said
yes,
I
I
help
I'm
helping
to
do
co-chairing
work
and
I
helped
to
maintain
the
the
cncf
open,
get
ops,
working
group
and
also
the
open,
git
ops
project.
And
if
anyone
doesn't
know
what
that
is,
I'm
totally
happy
to
stop
sharing
my
screen
and
just
start
talking
about
that.
C
C
So
that's
that
project,
that's
a
cncf
sandbox
project,
and
why
do
we
have
both
of
those?
Because
the
the
get
ops
working
group
is
is
responsible
for
putting
together
the
information?
And
you
know
this
the
specification,
the
definition
of
what
git
ops
is
as
well
as
really
partnering
with
other
people
within
the
wider
get
ops
ecosystem
that
may
or
may
not
even
be
connected
to
the
cncf.
For
example,
the
cd
foundation
has
a
lot
of
getups
related
things.
C
C
So
open
getups
is
the
project
where
that
information
lives.
So
the
principle
so
the
docket,
the
lasting
documents,
any
lasting
programs,
such
as
forthcoming,
certifications,
conformance
related
things,
etc,
and
any
code
that
may
come
along.
The
way
which
has
been
discussed
already,
for
example,
for
interoperability
between
projects
will
all
live
in
open,
get
ops
and
the
adopts
working
group
is
a
working
group
that
lasts
as
long
as
it
needs
to
last.
Just
like
all
other
cncf
groups,.
B
C
A
B
B
B
B
I've
been
actually
recently
getting
more
into
helm
right
as
as
as
of
late,
where
they're
trying
to
well
what's
what's
funny
is
that
when
you're
you're
you're
starting
in
your
get-ups
journey-
and
you
start
doing
all
these
workflows,
I
actually
came
to
a
point
where
it's
like
you
know
what
a
lot
of
the
stuff
that
I'm
doing
helm
would
like
be
really
really
good.
That
fits
in
so
a
lot
of
people.
Don't
don't
really
understand
that
that
that
relationship
is
like?
Do
I
use
helm?
Do
I
use
get
ups?
B
C
All
right
cool
yeah,
so
let
me
share
my
screen:
full
screen
again
yeah
yep,
so
basically
like
I
just
had.
I
know
this
is
not
supposed
to
be
a
formal
forum,
for
you
know
just
like
a
long
presentation
and
then
when
it's
done,
there's
a
few
questions
and
we're
gone.
This
is
more
of
a
discussion,
but
I
thought
hey.
You
know
why
not
have
a
little
slide.
Some
slides.
You
know.
C
C
B
A
C
C
I
was
gonna
just
quickly
introduce
you
know
what
what
flux
is,
what
what
helm
is
and
the
the
flux
helm
controller,
and
then
I
wanted
to
talk
a
bit
about
my
current
favorite
helm
controller
feature
and,
at
the
end,
give
some
flux,
fun
facts
for
people
who
are
interested
in
that
and
like
even
what
the
hell
you
can
do
with
it.
So
so
yeah
all
right.
C
So,
first
of
all,
flux,
intro
first
go
to
flux,
cd.io,
and
this
is
really
just
a
screenshot
of
that
page.
So
this
is
like
the
weakest
of
all
possible
slides,
but
it
is
awesome.
It's
actually
the
coolest
slide,
because
someone
else
added
this.
I
just
mean
it's
my
favorite.
It's
the
coolest
light
on
the
deck,
but
it's
you
know
it's
still
just
a
screenshot,
so
go
there
check
it
out,
but
basically
flux
really
ultimately
is
is
for
continuous
delivery
and
progressive
delivery.
C
B
C
Cool
awesome,
yeah,
that's
that's
great
yeah.
I
was
actually,
I
think,
I'm
looking
forward
to
doing
some.
Some
specific
open
shift,
flux,
demo,
stuff
together
with
you
all
sometime
soon,
that
would
be
really
really
cool
yeah.
So
so,
basically,
flux
is
the
thing
that
lets
you.
You
know
it's
it's
one
of
it's
one
of
the
tools
in
the
github's
ecosystem.
It's
you
know
it's
the
one
that
I
I
work
on
and
it's
you
know
for
those
that
don't
really
know
what
that
means.
C
I
think,
just
at
the
highest
level,
without
even
getting
into
what
kubernetes
is
and
and
and
helm
and
and
flux,
and
all
of
that
get
ups
we
probably
should
just
mention-
is
a
set
of
principles
that
allow
that
really
says
that
users
should
or
it'll
it'll
it's
a
set
of
principles
for
operating
a
system
or
a
part
of
a
system.
So
in
short,
we
do
actually
in
the
githubs
principles
section
or
we
do
have
a
pre-release
of
the
office
principles
and
that
we
could
read
that
word
for
word,
but
I'll.
C
Just
summarize,
it
quickly
is
that,
in
short,
you
you
want
all
of
your
infrastructure
and
applications
or
really
whatever
part
of
the
system
you're
trying
to
manage,
be
declarative.
So
in
that
way,
it's
very
very
similar
to
infrastructure
as
code,
it's
not
only
infrastructure
as
code,
even
that
single
principle,
because
it
also
can
include
applications
and
other
layers
that
are
not
purely
infrastructure,
so
workloads
and
so
on.
So
so
it's
really
just
any
part
of
your
system
that
you
want
to
manage
with
git
ups
and
for
a
lot
of
people.
C
So
it's
not
just
add
a
bash
script
that
says,
could
control
apply
inside
of
your
ci
pipeline,
because
there
could
be
other
things
that
that
require
reconciling
your
desired
state
with
the
actual
state
that
didn't
start
with
a
change
that
you
made
yourself.
You
know,
for
example,
something
could
just
be
failing
in
your
cluster
or
something
could
something
some
drift
could
happen.
That
has
nothing
to
do
with
with
a
user
triggered
ci
pipeline
and
so
that
reconciliation
should
always
be
happening
on
some
type
of
interval
doesn't
mean
you
can't
also
ping.
C
You
know
like
poke
that,
with
with
a
you
know
with
a
web
hook
or
something
you
certainly
can,
but
but
that's
not
that's.
That's
not
really
the
the
main
highlight
of
git
ups.
It's
it's
very
acceptable
and
a
good
idea,
but
the
main
thing
is
that
this
is
doing
it
all
on
its
own,
so
you're,
really
just
as
an
operator
interacting
with
git.
You
know
guys
I
probably
should
have
stopped
the
share.
While
I
was
talking
about
that,
so
you
could
see
my
face
describing
it.
C
B
Yeah
the
I
actually
posted
in
the
chat,
everyone.
If
you
take
a
look,
I
posted
the
version
0.1.0
the
principles.
This
was
a
combination
of
as
scott
was
saying.
We
of
all
these
organizations
getting
together
and
to
define
these
principles-
and
this
was
a
combination
of
a
lot
of
blood,
sweat
tears
that
we
put
together
so
check
those
out
feedback.
Welcome
right
as
we
as
we
say.
B
You
know
this
is
an
open,
open
group,
so
go
ahead
and
take
a
look
at
that
and
see
what
we
actually
mean
when
we
mean
get
ops
right.
Like
you
know.
Yes,
it's
a
buzzword,
a
yes,
but
it's
also
a
real
thing
right.
Two
things
can
be
true
at
the
same
time
right.
So
this
is
it's
an
actual
real
thing
right,
so
don't
don't.
C
B
C
Yeah,
so
I
didn't
follow
my
own
instructions
for,
in
my
own
mind,
which
was
going
to
be
not
just
pasting
links,
but
also
showing
them.
So
since
I'm
sharing
my
screen
here,
you
go
so
for
folks
who
happen
to
just
be
looking
and
can't
easily
browse.
This
is
the
open
dash
for
now
open
dash,
git,
ops,
github
organization
and
the
documents
repo
and
the
documents
have
well.
They
are
all
the
lasting
documents
and
currently
it's
only
the
principles
and
licenses
and
readme
right
now
the
principles
contains
a
glossary.
C
It's
got
the
it's
got
the
version,
the
the
the
release.
Excuse
me
the
release.
It's
marked
as
a
pre-release,
so
it
doesn't
show
up
on
the
right
yet
because
it's
not
1.0.0
yet,
but
it
has
all
the
the
description
about
how
to
get
involved.
All
the
things
I
said
about
what
open,
git
ups
and
github's
working
group
are
how
they
relate
and
the
actual
all
the
authors
on
this
first
set
of
principles,
which
is
a
pretty
long
list
of
people
who
are
very
involved.
So
thanks
to
everyone.
C
Yeah
one
other
thing
I
want
to
mention
just
in
the
open
githubs
project
is
that
we
use
github
files
for
if
you
want
to
see
anything
related
to
you
know,
security
support,
how
to
contribute
and
so
on.
All
these
community
health
files
are
are
are
here,
and
you
can
check
them
out
just
the
way
github
wants
you
to
so
so
they'll
they'll
show
up
inside
of
the
ui,
so,
for
example,
in
the
security
tab,
they'll
actually
show
up
in
in
the
security
policy,
and
they
just
I'm.
B
C
B
A
B
Well,
I
mean
the
the
I
guess
I
would
need
to
know
like
what.
What
are
you?
What
what
are
the
end
goals
there
right?
If,
because
the
multi-tenant
nature
of
kubernetes
makes
it
where,
where
you
can
technically
point
argo
cd
to
only
one
name
space,
and
then
I
guess,
flux,
cd,
correct
me.
If
I'm
wrong,
you
can
point
it
to
yet
another
name
space,
and
I.
B
C
Absolutely,
and
in
fact
that's
that's
not
unlikely
at
all.
There's
there
are
times
where
there
are
certain
features
that
you
might
want
from
argo,
that
flux
doesn't
currently
have,
or
maybe
you
like
one
of
those
features
better
and
there
may
be
other
features
like
say,
let's
say
for
a
lot
of
your
project.
You
want
to
use
pure
kubernetes
are
back
instead
of
you
know,
like
a
custom,
acl
system.
C
Like
argo
has,
then
you
would
use
like
say
flux
for
those
things
and
then,
where
you,
where
you
don't
want
that
you
could,
you
could
use
argo
et
cetera
and
just
kind
of
mix
and
match
them
the
main
thing
about
conflicts.
Is
you
don't
want
both?
You
don't
want
two
different
sets
of
controllers
or
controller
systems
trying
to
reconcile
the
same.
C
Yeah,
if
you
configure
them
both
exactly
the
same
in
the
ways
that
they
make
in
the
ways
that
they
make
sense
together,
at
least
where
compatible
you
could
do
it
and
you
would
just
have
like
reconcile,
reconcile,
reconcile,
reconcile
reconcile.
But
if
you,
but
there's
a
lot
of
room
for
error
there
so
yeah,
I
think
christian's
totally
right,
name,
space,
separation
and
and
then
just
look
at
the
feature,
sets
and
talk
to
us
all
and
who
knows
man,
maybe
maybe
maybe
you'll
offer
flux
at
some
point
as
part
of
your
as
part.
A
A
C
That's
a
super
excellent
question
and
it's
one
of
those
questions
that
can
be
in
part
answered
by
get
ups,
which
is
one
of
the
one
of
the
nice
things
about
this
combination.
So
I
so
in
my
little
outline
we
started
getting
into
some
of
this
stuff,
but
I
never
even
introduced
what
helmets
for
folks,
but
I
do
do
you
mind.
B
C
It's
a
good
one,
yeah,
it's
a
good
one
yeah,
so
just
just
for
folks
who
may
be
tuning
in
and
aren't
even
sure,
really
what
helm
is
they
might
even
not
know
what
kubernetes
is.
That's.
I
tried
to
give
a
quick
explanation
of
git
ops
just
so
that
at
least
we've
level
set
for
people
who
have
some
sense
of
what
version
control.
C
Basically,
the
assumptions
so
far
are
only
you
know
what
version
control
is
you
know
what
a
system
is
and-
and
I
think
that's
it-
that's
the
only
thing
we've
really
assumed
so
far
like
really
at
least
in
the
description
of
git
ops,
so
maybe
to
really
understand
what
it
means
you'd
have
to
have
familiarity
with
certain
systems.
That's
really
all
you
need
to
know
for
that.
C
As
far
as
what
helm
is
in
general,
helm
is
a
package
man,
it
helm
is
a
package
manager
or
the
pack
trainer
or
whatever
for
kubernetes
sorry,
a
package
manager
for
kubernetes
and
kubernetes.
I
think
I'm
probably
not
going
to
describe
that
right
now,
except
for
just
saying
that
it's
a
thing
that
helps
automate
infrastructure.
B
C
C
C
You
still
need
to
do
that
if
you
live,
if
you
work
in
a
data
center,
but
you
don't
need
to
do
that
anymore
for
for
for
your
infrastructure,
automation,
so
so
yeah
so
basically
helm
allows
all
of
the
let's
say:
kubernetes
uses
manifests
to
to
declare
what
what
we
want.
Kubernetes
to
do
so
kubernetes
in
itself
is
a
is
a
very,
is
extremely
compatible
with
with
git
ops.
C
It
wasn't
always
because
there
wasn't
always
a
way
to
spin
up
kubernetes
clusters
with
with
get
with
with
declarations,
but
now
there
is
using
the
cluster
api
project
so
really
from
as
long
as
you
have
like
at
least
one
bootstrap
cluster
and
you,
and
that
cluster
has
access
to
create
other
clusters
using
some
sort
of
cloud
account.
You
can
you
know
nuts
to
bolts
you
can
you
can
really
do
everything
with
declaration,
and
so
what
helm
does
is
it
allows
you?
It
basically
allows
you
to
do
two
things.
C
C
C
Those
releases
can
be
versioned
in
the
case
of
incident
management,
even
with
git
ops,
if
your
primary
mode
of
interacting
with
your
with
your
with
your
applications
and
your
infrastructure,
is
through
your
git
repo
and
not
really
just
through,
like
manual
commands,
what
happens
when
the
one
of
your
get
provider
apis
goes
down,
you
know
what
happens
if
you
have
yeah
like
a
fire.
You
know
so,
and
you
have
to
call
in
the
troops
for
incident.
C
Yeah,
so
so
that's
one
of
the
reasons
why
it's
really
like.
Yes,
we
could.
You
know-
and
I
know
that
there
are
some
tools
and
again,
I'm
not
going
to
like
do
a
full
tool
comparison
right
now,
but
but
there
are
different
tools
that
use
helman
in
certain
ways
like,
for
example,
to
template
out
those
and
then
use
those
templates
just
raw
the
the
one
other
way
to
do
with
that
is
to
keep.
C
C
B
Thing
I
really
like
about
helm
is
the
the
templating
feature
is
essentially
you
know
you
can
you
know
like
a
lot
of
the
times.
Your
manifests
are
generally
the
same
across
multiple
clusters,
but
like
there's
like
slight
differences,
and
so
like
that
templating
is,
is
really
useful
because
you
can
essentially
just
have
one
one
set
essentially
of
manifest
that
then
you're
just
changing
on
the
fly
as
you're
installing
the
helm.
So
I
think
that's
that's
also
another
big,
a
big
plus
of
using.
C
Exactly
yeah-
and
you
know
a
common
use
case
for
people
who
may
be
asking
the
who
cares
question
super
common
would
be
you've,
got
different
values
for
the
same
application
and
dev
stage
and
prod
you
know,
or
let's
say
even
in
production,
you
use
the
same
application
for
your
company,
maybe
10
different
times
for
different
things,
different
instances
of
that
same
application
or
maybe
eight
thousand
times.
You
know,
depending
on
how
big
your
company
is
so.
B
I
have
a
customer
facing
application,
but
then
there's
an
application
inside
the
company
inside
your
organization
that
people
use
right
so
like
there's
also
developers
for
developers
right,
like
I'm
you're
building
tool
sets
for
other
developers
to
use
and
those
are
very
and
then
you
have
your
own
release
cycles
and
your
own
way
of
deploying
it.
And
sometimes
you
know
your
other
dev
engineers
or
other
developers
are
consuming
that
as
well.
So
you
know
that's.
A
B
C
Cool
yeah
totally.
I
love
that
description
yeah.
So
basically,
that
kind
of
like
leads
me
into
the
helm
controller,
the
flux,
thumb
controller,
what
its
primary
design
with
essentially
flux,
I
skip
flux,
but
I
did
say
generally
what
it
is.
I
I
I
just
didn't
give
a
whole
architectural
diagram
and
I
think
that's
probably
fine,
for
this
call
that
focuses
on
helm.
But
essentially
I
can
say
that
or
excuse
me
flux
is
a
componentized
distributed
application
that
lives
on
your
kubernetes
cluster.
C
It
runs
on
top
of
kubernetes.
It
can
control.
There
can
be
controllers
that
control
things
outside
of
kubernetes.
Currently
the
controllers
that
are
bundled
with
it
do
not.
They
control
only
things
within
the
same
cluster.
That
flex
is
running
on
or
other
clusters,
and
so
therefore,
flux
can
also
do
multi-cluster
work
in
the
sense
that
you
can
have
one
management
cluster
say
you
have
a
an
instance
of
helm,
controller
running
on
this
cluster.
C
Where
you're
you
want
to
manage
things,
but
you've
got
these
other
clusters
and
you
really
want
to
keep
them
light
super
light.
You
don't
want
any
additional
controllers
running
on
them
that
you
don't
need.
Well,
that's
great
you
just
you
have
this!
This
cl
the
controller
in
your
management
cluster,
controlling
the
home
releases
in
those
other.
In
those
other
clusters,
you
can
even
have
through
cappy
through
a
cluster
api.
You
can
even
have
that
management,
cluster,
create
and
spin
down
those
other
clusters
as
needed.
C
So
you
can
really
see
how
that
works
when
configured
properly.
You
know
you
can
manage
multiple
clusters
that
way
as
well,
but
I'm
focusing
primarily
on
the
on
the
charts.
You
know
the
helm
side
of
things
for
now,
so
that's
really
cool.
It
uses
the
the
helmet
decay
primarily
as
part
of
its
design,
so
that
it's
not
really
shelling
out
to
the
helm
binary
and
what
that
means
is
that
we
are
able
to
take
care.
C
Excuse
me
to
to
to
keep
the
the
imprint
very,
very
low,
the
the
memory
usage
very
low,
because
we're
just
pulling
in
the
package
the
go
packages.
Okay,
so
for
those
who
don't
know,
much
of
this
work
is
written
in
golang
or
the
go
language,
and
so
these
are
no
exception.
It
pulls
in
the
helm,
go
packages
and
uses
that
functionality
through
their
sdk,
and
that
is
why
we
design
that's
why
the
helm
version
three
and
above
was
designed
to
have
to
be
sdk
first
and
the
client.
C
C
I
I
will,
if
we
have
time
I
can
get
to
at
the
end,
yeah
the
the
the
quick
answer
is
that
it's
still
an
experimental
feature
and
those
packages
are
not
publicly
they're,
not
public
packages.
Yet
so,
therefore,
that's
not
pulled
into
the
flex
helm
controller,
but
there
is
work
upstream
and
helm
for
that.
Actually,
upstream
and
mci
things.
B
C
C
The
short
answer
is
this:
that
there
was
not
for
the
longest
time
there's
not
a
a
a
full,
really
a
full
release.
Spec
the
spec
was
not
solidified
so
for
tools
that
adhere
very
strictly
to
backwards.
Compatibility
such
as
helm
and
also
flux
does
as
well.
We
couldn't
provide
that
functionality
and
still
claim
for
backwards
compatibility
if,
if
I'm
talking
about
helm
now
but
like
helm,
can't
actually
open
those
packages
and
say:
oh
we're
we're
still
going
to
follow
simber
if
the
upstream
spec
itself
is
going
to
change.
C
So
that's
why
it
was
yeah.
That's
why
it's
been
behind
an
experimental
feature
flag.
You
can
still
use
it,
but
but
we
have
to
guarantee
that
backwards.
Compatibility
for
that
graduated
cncf
project.
It's
extremely
important.
It's
one
of
the
reasons
why
it's
so
widely
used
is
because
it's
so
highly
trusted
and
the
so
the
same
thing
with
flexes.
We
won't
pull
that
in
until
we
can
get
that
solidified
in
the
in
the
helm,
sdk.
C
C
C
It's
just
it's
just
because
I
I
waited
too
long
to
actually
form
a
correct
patch,
so
I,
unless
unless
I
want
to
get
in
there
and
someone
wants
some
like
you
know,
strategic
merge
patch
expert
is
wants
to
say:
oh
yeah,
let's
fix
it.
I
know
you
guys,
like
demos,
that
kind
of
fail
and
then
fix
or
fail
and
then.
C
Sorry,
my
zoom
windows
little
in
the
way
here
there
we
go
okay,
so
you've
heard
me
talk
about
this
topic
before
and
I
it
almost
seems
like
a
little
bit
of
a
broken
record,
but
I
think
it's
a
really
important
feature
and
I'll
explain
a
little
bit
more.
Why
not
just
because
it's
cool,
but
because
of
what
you
can
do
with
it.
C
So
ultimately
we
were
talking
about
how
more
close,
and
one
of
the
big
workflows
I
wanted
to
focus
on
was
was
was
what
happens
when
you're
working
with
a
chart
and
the
chart,
you
know
say
it's
a
public
chart.
It's
a
very
widely
used
public
chart.
Let's
say
you're
working
with
some
of
the
prometheus
charts
right
they're,
you
know
prometheus
community
blessed.
Let's
say
you
are
working
with
the
cert
manager
chart
that
installs
that
application.
C
That's
one
of
the
tools
that
christian
was
talking
about
everyone
that
that
developers
use
the
tools
to
build
their
tools,
so
cert
managers
help
with
tls
manage
tls
certificates
with
third
parties
and
inside
your
cluster.
So
it's
a
very
widely
used
tool
and
it's
not
really
a
good
idea
at
that
I
mean
you
can,
but
I
would
I
would
just
if
you
can
get
around
it.
C
I
would
discourage
someone
from
forking
that
just
to
add
in
their
own
configurations,
inside
of
the
go
templates
of
that
chart
and
then
using
them
within
your
company,
because
immediately
that's
pretty
fine,
but
if,
if
your
needs,
don't
hap,
even
if
you
do
follow
the
open
source
say
program
where
you
say
all
right:
well,
I'm
gonna,
I'm
gonna
upstream,
I'm
gonna
try
to
upstream
my
changes.
I'm
gonna
fork,
I'm
gonna
make
my
changes.
I
hope
they're
useful
for
the
wider
community
and
I'll
make
a
pull
request
for
that.
C
Well,
it
might
take
a
while
for
that
to
be
reviewed
depending
on
the
community
and
depending
on
the
other
priorities
in
place.
Not
only
that
I
mean
that
community
is
very
good
by
the
way.
So
definitely
that
wasn't
a
silent
dig.
They
are
absolutely
excellent
on
top
of
everything
I
mean
for
real
like,
but
but
it
may
be
that
so
some
other
charts
may
not
be
that
way.
Some
chart.
Authors
might
be
on
vacation,
you
know,
or
or
or
they
might
not
really
be
at,
they
may
be.
Very.
C
The
cadence
may
be
very
spread
out
because
it's
a
very
older
application
that
doesn't
really
need
a
lot
of
perpetual
maintenance.
So
the
second
reason
why
it
might
be
it
might
not
really
suit.
You
is
because
your
change
might
not
be
something
that
the
authors
of
that
chart
agree
with.
They
might
not
think
it's
a
good
idea
and
they
might
not
have
a
better
recommendation
for
you
because
they
might
just
say
well.
Listen,
that's
that's!
B
B
We
can
support
this
for
your
specific
use
case,
so
I
always
feel
bad
because,
like
I
understand
like
I
like,
because
I
have
snowflake
installations
as
well,
but
it's
like,
but
it's
like
you
know
it's
just
like
I
just
generally
speaking
like
there's
no
way
we
can
support
this
or
if
it
doesn't
even
make
sense
and
it
breaks
other
things.
So
sorry,
that's
right
exactly.
C
Yeah
and
say
it's
a
chart
where,
where
you,
you
know
that
we
don't
the
chart,
authors,
don't
or
maintainers,
don't
really
want
to
maintain
backwards,
compatibility
to
certain
older
api,
api
versions
of
those
kubernetes
resources,
and
otherwise
there
may
be
no
changes
in
within
your
manifest
just
instead
of
b1,
it
needs
to
say
v1,
beta
1
or
something
like
this
right,
yeah
yeah
exactly
well,
some
charts
do
that
and
they
do
it
backwards
to
a
certain
point.
It's
just
certain
versions
of
kubernetes.
C
Just
to
you
know,
maybe
like
one
or
two
versions
back
but
let's
say
you're
on
an
older
cluster,
but
you
still
want
to
use
this
and
you
know
you've
assessed
the
risk
and
you
know
that
you
just
need
to
change
that
version
that
manifest
that's
not
going
to
make
it
upstream.
You
know,
because,
because
that
chart's
not
going
to
be
backwards
compatible
forever,
you
know
even
if
you've
cleared
it,
you
know
so
so
here.
C
So
this
is
one
of
the
reasons
why
why
that
part
of
the
workflow
means
that
you
end
up
forking
that
and
then
you
kind
of
have
to
maintain
that
fork
as
all
the
new
changes
come
from
that
chart.
So
if
you
want
to
take
advantage
of
any
of
the
new
changes
too
bad,
you
know
so
so
that's
one
of
the
really
nice
things
about
not
too
bad,
but
just
you've
got
extra
work
on
your
hands,
basically
and
generally
there's
a
lot
of
speaking
of
drift.
C
You
know
you
may
not
want
to
fall
too
far
behind
in
order
to
keep
up
with
with
new
features
in
the
tool,
so
so
the
helm,
post
renderer.
This
is
built
into
helm
itself.
This
is
not
something
that
is
unique
to
flux,
but
the
fluxhome
controller
does
implement
this
well,
and
I
wanted
to
show
you
how
they
both
work
so
so
here
is.
C
Oh,
my
god
come
on
now
there
we
go
so
in
the
in
the
helm,
docs
and
we
can
post
this
link
later,
but
in
the
in
the
in
the
helm
in
the
helm,
docs
there's
a
section
under,
I
think
it's
under
advanced
helm
techniques,
yeah
boom
is,
is
post,
rendering
and
and
it'll.
Basically,
what
happens
is
of
course
you
can
all
the
other
way
you
can
do.
That
is
what
I
mentioned
before.
C
C
But
it's,
it
was
the
most
flexible
approach
and
it
solved
the
greatest
number
of
issues,
and
this
is
primarily
for
edge
cases.
So
that's
why
that
made
sense.
It
means
that
for
security
you
need
to.
You
need
to
be
really
trust
this
executable
because
it
can
just
it
can
just
point
to
any
any
any
executable.
C
So
that's
good
because
you
can
make
a
shell
script
that
just
simply
does
some
piping
to
customize
and
whatever.
In
fact,
there
is
an
example
of
that
that
taylor
thomas
wrote
linked
from
the
dots
here
an
example
using
customize.
It's
a
it's
a
nice
example,
and
in
fact
why
don't
I
show
you
generally
what
it
is
so
so
the
example
chart
is
a
very
simple
one:
it's
got,
it
was
really
just
created
using
the
helm,
create
command
at
the
time
the
customization,
here's,
the
customization
yaml
it
it
really.
C
C
C
C
Oh
I'm
sorry
yeah!
So
here's
the
patch
and
it
just
uses
it.
It
specifies
that
the
targets,
the
name
really
doesn't
matter
because
you're
just
simply
in
this
case
the
everything
yeah
yeah
you're
targeting
star
yeah,
exactly
exactly
thanks
for
remembering
that
yeah
so
you're,
targeting
that
yeah
and
and
then
you're
you're
you're,
essentially
you're
you're,
adding
a
new
security
container,
and
this
is
what
this
is,
what
you're
doing
and
then
you're
using
that
that
that
secret,
that
you're
adding.
C
Exactly
takes
standard
in
does
your
modifications
it
pipes
to
standard
out
and
since
customized
build
already
sends
out.
This
fits
the
bill,
but
you
don't
have
to
use
this,
so
this
is
just
a
really
good
example
of
of
of
adding
some
security
feature
to
helm,
charts
that
may
not
have
them,
but
they're
still
important
to
use
that's
and
that's
linked
from
the
helm,
docs.
What
how
flux
does
this
is
is
a
little
bit
different
or
no,
it's
not
different
flux.
C
Does
that
and
the
exact
implements
that
properly,
but
instead
of
using
a
binary,
you
know
it
for
security
purposes.
We
don't
want
to
run
as
of
flux
version
two
and
above
do
not
want
to
run
user
specified
binaries
inside
of
the
cluster.
Also
we
want
this
to
perform
well,
you
know,
and
we
want
it
to
be
secure
so,
and
we
all
love
that
right.
C
So
what
what
what
flux
does
is
we
implemented
the
most
the
initial
standard
post,
renderer
and
set
up
a
tooling
to
be
able
to
to
more
easily
allow
additional
post
renders
if
they
become,
if
there's
a
demand
for
them,
so
it
it
supports,
basically
supports
customized
patching
so
patches
strategic,
merge,
patches
json6902,
rather
than
calling
the
customized
binary.
It
just
uses
the
customize
sdk
the
customize
go
packages
in
order
to
add
your
patch.
C
C
There's
like
five
different
people
who
work
in
the
flux
project,
at
least
who
have
done
a
lot
of
demos
on
how
to
do
that
end
to
end,
but
this
is
really
just
focusing
on
this
feature
for
now,
but
because
I'm
not
showing
you
in
the
end,
I
just
wanted
to
tell
you
what
we're
looking
at.
This
is
a
custom.
This
is
a
custom,
an
example
of
a
custom
resource
whose
custom
resource
definition
is
controlled
by
the
the
flux
home
controller.
C
So
these
are
all.
This
is
just
an
example
of
things
that
you
may
something
that
you
might
want
to
use.
For
example,
the
metric
server
chart
and
here's
an
example
of
things
that
you
might
want
to
change
about.
The
metric
server
chart
that
that
chart
doesn't
support,
and
I
hope
that
makes
sense.
I
yeah.
B
Yeah,
so
so,
essentially
you
you
get
all
the
everything
that
you
get
with
helm,
you
get
with
helm
and
then
everything
you
know
all
the
other
patching
and
all
these
kind
of
snowflakey
things
that
you
need
to
do
you.
You
have
the
ability
to
do
it
there
as
well
right,
instead
of
doing
like
helm,
templates
raw
manifest
you
get
the
you
get,
you
get
everything
you
you
do
with
helm
exactly.
C
B
B
To
vote
for
got
their
time
from
from
from
the
users
here.
Oh
thank
you,
it
looks
like
chris
is
on
it,
so
the
so
what
I
like.
So
the
question
I
had
was
okay,
so
you
have
we
have
this
workflow
of
of
helm
right
and
in
you
know,
installing
helm,
charts
and
using
using
helm,
charts
right
and
then
we
have
the
get
ops,
and
then
we
have
the
get
ops
principles
right
where,
where
is
that
single
source
of
truth?
B
In
terms
of
like
my
values,
right,
like
I
have
a
values
file
that
I
use
is,
is
that
do
we
still
store
that
on
on
git?
Is
that
in
the
manifest
directly
directly?
What's
what's
the?
What
are
some
of
the
patterns
that
you've
seen
in
order
to
be
like?
Okay,
hey,
I
have
a
values.yaml
file
that
that
we
use
that
we
want
to
keep
as
a
source
of
truth
exactly.
C
Yeah
thanks,
that's
like
that,
is
one
of
the
biggest
questions
that
that
say
when
I
was
doing
consulting
work
and,
even
just
like,
say,
moving
into
a
team
to
help
them
set
up
their
workflows
in
a
company
which
I've
worked
in
different
companies
before,
like
big
ones,
kind
of
small
ones.
That's
the
number
one
thing,
because
that's
what
people
want
to
know
like
how
do
I
set
this
up
right
and,
if
you're
using
it
used
to
be
that
really
really
before
these
get
ups
tools
came
out
with
flux.
Support.
C
Excuse
me,
sorry,
with
helm
support,
for
example,
flux.
Again,
I'm
focusing
on
the
tool
that
I
work
on
the
most,
but
there
are
other
tools
out
there
as
well,
really
one
of
the
tools
that
would
that
allowed
people
to
like,
for
example,
argo
right.
They
they
also
integrate
with
with
helm
and
and
so
on.
C
But
one
of
the
tools
that
people
use
to
do
declarative,
helm
in
the
past
was
a
project
called
helm
file,
which
I
still
think
is
a
fantastic
project
it
it
one
could
use
that
to
do.
For
example,
one
could
write
a
flux
controller
to
do
a
helm,
file,
flux
controller,
so
you
could
still
continue
to
use
a
helm
file.
Syntax.
C
I
actually
at
first
thought
that
would
be
a
great
thing
to
do,
but
I
quickly
abandoned
that
effort
just
because,
because
you
really
can
do
everything
with
with
the
with
the
flux,
helm,
controller,
custom
resources
as
they're
defined
that
you
can
with
a
helm
file,
it's
really
just
different
syntax
and
if
you
use
a
custom
resource
syntax,
it's
actually
you're
able
to
define
that
in
a
structured
way
through
the
cube
api
and
through
the
documentation
of
those
api
resources.
So
I'm
not
saying
oh,
it
makes
helm
file
obsolete.
C
I'm
not
saying
that
at
all.
I
think
that
people
can
certainly
use
that,
and
I
could
imagine
someone
writing
a
controller
just
because
they
want
to
continue
that
syntax.
But
I
believe
that
would
be.
The
only
difference
is
that
it
would
almost
be
like
a
mapping
project,
a
mapping
tool
between
that
and
the
syntax
that
the
custom
resources
excuse
me
that
the
home
controllers,
custom
resource
resources
are
looking
for.
C
So
one
of
the
things
that
I
normally
see
is
that
you
know
with
helm,
you
can
pass
dash
dash
values
or
dash
f
to
to
to
the
helm.
Installer
helm
upgrade
commands
you
and
you
can
do
that
multiple
times.
So
you
do
that
in
layers,
and
then
you
can
also
pass
pass.
Excuse
me
a
set
command
on
the
command
line
itself,
which
will
then
even
override
those.
So
the
nice
thing
about
that
is
that
helm,
the
helm
isn't
built
this
way,
but
it
has.
C
It
has
the
capacity
it
once
you
were
allowed
to
have
multiple
values.
Files
helm
now
provides
the
capacity
for
a
concept
of
layering.
When
helm
was
first
written,
it
didn't
it
was
really
just
so.
There
was
some
string
replacement
in
there
for
your
values,
and
that
was
that
was
it
and
then
more
advanced
needs
required
more
flexibility
to
be
built
into
the
tool.
C
If
you're,
using
a
chart
that
you
own,
you
can
actually
put
those
what
your
your
normal
common
values
right
in
your
values.yaml,
but
if
you're
using
a
shared
community
chart
either
it's
shared
between
teams,
kind
of
inner
source
for
your
company
or
open
source.
Generally
speaking,
so
it's
really
just
same
defaults.
You,
you
normally
will
have
something
that
you
use
almost
all
the
time
and
that
will
be
your
like
kind
of
common
dash
values.yaml
right
for
that
application.
It
you
don't!
C
C
You
know
for
each
one
of
those
for
each
one
of
your
environments,
whatever
it
is
stage,
one
stage,
two
etc
and
for
those
specific
environments
you
may
have
specific
needs
and
overrides.
Maybe
I
want
a
lot
of
replicas
in
production
and
I
even
want
an
hpa,
a
horizontal
pod
autoscaler,
but
I
don't
want
that
in
development
say
I
want.
I
want
an
hpa
in
stage
to
make
sure
it
works,
but
I
want
fewer
replicas
because
I
don't
want
to
pay
extra
money
unnecessarily
etc
and
in
dev
I
only
want
one
replica,
no
hpa
right.
C
So
that's
just
one
example
for
a
workload
and
you'll
put
those
in
the
various
things
and
then
what
you'll
say
you
know
helm
install.
You
know
my
chart.
My
name
dash
file
common
dash
file,
my
environment,
dash
file.
My
teams
overrides
you
know,
and
if
you
really
want
to
be
super
specific,
you
can
set
additional
overrides
on
command
line.
C
B
C
I
think
the
main
one
that
I
wanted
to
highlight
before
was
that
we
do
multi
multi-cluster
flex
also
does
multi-tenancy
using
native
kubernetes
are
back.
So
that's
a
very
interesting
thing
for
folks
who
need
that.
If
you
want
to
ask
me
questions
about
that,
just
ping
me
afterwards
and
I
just
wanted
to
say
as
well
that
we're
really
looking
for
more
contributors
and
and
enter.
C
So
I
I
wanted
to
send
out
that
invite
as
well
as
well
as
the
invite
we
already
gave
yeah
for
the
get
ops
working
group,
so
so
yeah
I've
got
some
links
in
the
link
section
and
I'll
send
them
to
you
to
you,
so
you
can
pass
them
to
the
community
oops,
and
I
know
we
don't
have
any
real
time
left.
But
do
you
sometimes
go
a
few
minutes
over?
I
feel
like
yeah.
I.
B
C
C
It's
good
to
give
people
an
indicator
so
that
they're
not
wondering
if
they
should
hang
out
or
not
okay.
So
if
you've
got
five
extra
minutes,
stick
or
four
now
stick
around
so
so
basically
say
we're
not
using
git
ups
to
answer
this
question
and
you're
just
using
say,
you're,
not
even
using
version
control
at
all,
but
you
are
storing
your
coop
into
these
resources
or
sorry,
your
helm,
charts
and
the
and
those
values
files
that
I
mentioned,
that
people
often
use
for
helm,
charts
and
anything
else
related
to
your
helm
releases.
C
Shared
you
know,
I'm
just
trying
to
be
very
vague,
even
though
I
think
for
most
people,
industry
standard
is
to
use
version,
control
and
most
likely
git
and
most
likely
one
of
the
major
git
providers
or
p
or
a
pure
self-hosted
git.
To
do
your
your
version
control,
not
everyone
necessarily
does
so.
Sometimes
people
have
third-party
tools
out
there.
That
just
you
know,
maybe
keep
your
configurations
inside
of
a
database,
and
then
your
team
members
can
update
them.
C
That's
pretty
common
when
people
use
like
a
tool
like
say
the
old
school
jenkins
to
deploy
certain
kinds
of
things,
it's
not
uncommon
at
all
right.
There
might
be
some
bash
around
around
it,
but
that's
really
what
we're
talking
about,
because
that's
all
stored
in
the
database.
I
know
jenkins.
You
know
I'm
not
on
jenkins,
because
you
could
certainly
you
can
certainly
be
very
declarative
with
jenks
at
this
point
with
the
jenkins
file
and
it's
a
really
awesome
project.
Believe
me,
I
I
was
using
hudson
back
in
the
day
too
yeah.
C
Indeed,
I
was
very
excited
when
that
came
out
so
again.
This
is
no
no
shade,
it's
just
it's
an
old
monolithic
project.
That
is
just
one
example
of
how
one
could
do
that
where
I
know
people
do
in
fact
still
do
that
without
without
without
a
a
versionable
ledger
like
yet,
okay,
so
clearly,
git
is
not
the
only
answer
to
how
you
deal
with
governance,
but
even
without
get
ops.
C
If
you
are
using
a
version
control
system,
I
would
say
that's
number
one,
and
so
let's
just
assume
git
for
the
moment.
Okay,
it
could
be,
it
could
be,
it
could
be
anything
but
but
but
one
of
when
you're
talking
about
helm
specifically
the
most
important
thing
I
think
to
realize
is
that
with
helm3
and
with
the
at
least
with
the
beginning
of
helm3,
charts
are
namespaced,
so
the
nice
thing
about
that
is,
your
governance
can
be
a
one-to-one
mapping
with
your
with
your
kubernetes
are
back.
B
C
C
As
you
discover
what
you
need
as
your
as
you
move
at
the
speed
of
business,
you
know,
and
so
with
git
and
with
git
and
helm.
A
simple
example
would
be
separate
your
manifest.
You
know
if
you
have
different
resources,
that
one
team
should
be
responsible
for
and
not
another
put
them
in
separate
git,
repos,
hey,
guess
what
flux
can
handle
that
multiple
repos
easy.
I
know
other
tools
can
too
so
you
know
that's
one
simple
answer.
C
C
The
most
important
thing
I
think
to
keep
in
mind,
though,
is
is
what
are
the
helm,
charts
controlling
they're,
just
it's
just
a
templating
engine
that
allows
you
to
package,
not
just
it's
a
templating
engine
that
allows
you
to
package
resources
that
the
helm
client
then
creates
as
those
releases
that
with
versioned
releases,
like
I
mentioned
before
so
or
the
home
decay,
whichever
case
right.
So
so,
if
you
have
a
a
chart
that
really
extends
beyond
what
it
should
do
so,
for
example,
it's
managing
cluster
level
resources.
C
If
you
don't,
if
the,
if
the
agent
who's
running
those
home
commands,
don't
doesn't
have
access
correct
our
back
access,
they
can't
install
the
chart
yeah
and
that's
not
helm's
problem.
That's
that
would
be
the
same
as
if
you
had
just
plain
manifests
right,
so
you
just
have
to
yeah.
You
just
have
to
kind
of
look.
Look.
Look
at
your
basically
look
at
your
at
the
access
model.
You
want
and
then
make
sure
that
your
helm
charts
conform
to
that,
and
you
know
one
thing
about
the
post
render
feature.
C
B
Yeah,
that's
it's
cool,
so
thank
you.
There's
there
was
a
lot
of
a
lot
of
chatter
here
we
posted
some
links
right.
I
guess
to
the
next
bug
scrub.
So
thank
you
for
for
posting
that
chris
and
all
the
various
links
are
there
too,
as
well
so
yeah.
I
think
I
think
that's
it
for
this
week,
right
chris
or
scott,
unless
you
wanted
to
cover
anything
else,.