►
From YouTube: Helm Developer Call 20180111
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
C
All
of
that
out
this
week
going
forward.
There
were
some
interesting.
The
last
night
there
was
the
owners
file
thing
which
I
think
Matt
Farina
you
put
up
on
the
discussion
topics
for
that,
so
I'll
be
interested
to
talk
about
what
does
the
Cooper
daddy's
word
want
to
do
with
that,
and
then
the
other
thing
that
was
on
there
I'll.
Let
Matt
Prater
talk
about
those
stuff,
but
that's
basically
my
week
moving
forward,
Justin.
D
E
Okay,
I
mean
don't
worry,
I
was
just
taking
notes,
so
I
was
doing
the
same
thing
as
a
Fisher
was
so
reviewing
helm,
CFPs
and
doing
a
lot
of
helm
summit
stuff,
big
things
to
everyone,
who's
been
helping
out
and
Michelle
who's
been
coordinating
a
lot
of
it.
E
I
will
also
say
that
all
the
helm,
CFPs
were
quite
amazing,
so
good
job
to
all
of
you
out
there,
and
even
if
that,
even
if
your
talk
wasn't
accepted,
I
mean
I,
do
is
hard
to
decide
that
was
most
of
our
time
was
deciding
which
ones
fit
best,
not
actually
if
they
were
good
enough
to
land
or
not
so
I
think
all
of
that
is
in
place.
I'll
be
doing
more
than
honestly,
then
this
next
week,
I'll
try
to
get
back
on
any
issues.
E
Game
stuff
that
I've
been
trying
to
comment
on
github
and
if
anyone
needs
help
with
like
second
PR
reviews
or
whatever
I
can
help
out
with
that.
But
most
of
stuff
this
week
is
going
to
be
getting
together
the
schedule
and
everything
for
and
then
the
notifications
out
and
things
updated
on
the
helm
summit
landing
page
or
before
the
helm
summit.
So
that's
been
kind
of
my
a
week
and
probably
this
next
week,
let's
go
over
to
a
NIC.
F
Hey
guys
so
last
week
did
some
reviews
and
also
spend
some
time
with
butcher,
putting
together
some
material
for
teams
at
Sousa
who
are
planning
to
step
up
the
using
helm,
so
they're
kind
of
figuring
out
how
to
use
kubernetes
for
their
internal
applications
and
also
want
to
use
ohm
so
putting
together
some
material
to
tell
them
what
Helms
about
and
and
how
they
can
make
use
of.
It
better
still
want
to
figure
out
a
little
bit
more
about
the
issues.
Our
process
and
things
like
that.
So
I'll
probably
be
reaching
out
to
some.
A
After
that
things
should
die
down
a
little
bit
or
quiet
down
a
little
bit,
and
so
after
that,
I'll
jump
back
into
the
issue
in
PRQ
search
for
being
a
little
absent.
That's
it
for
me,
I
think!
Oh!
If
you're
a
core
maintainer,
there
will
be
a
little
get-together
beforehand,
so
we
can
just
get
her
stuff
together
and
or
do
a
little
organization
organization
and
prepping
for
the
home
summit.
G
Yeah
I
just
had
to
grab
the
mute
button,
just
the
stuff
that
I
already
have
in
the
discussion
topics.
I
think
the
one
nice
thing
that
got
merged
this
week
was
to
be
able
to
specify
supported
kubernetes
versions,
that
kind
of
complements
the
capability
stuff,
but
to
look
at
kubernetes
versions
and
say:
hey,
this
isn't
supported
yet,
or
this
is
supported
later.
That's
going
to
be
really
nice
over
on
the
church,
repo
side
of
things.
B
G
B
H
I,
just
posted
about
this
in
chat,
I
came
in
a
little
bit
late,
so
I
don't
know
if
this
came
before
I
got
in,
but
during
the
church
call
the
other
day
they
were.
There
were
some
discussion
of
proposed
changes
to
the
are
back
best
practices
and
I.
Remember
somebody
said
that
we
should
bring
that
up
on
the
helm.
Dev
called
the
deck
it
talked
about
already:
okay,
there's
an
issue
that
I
filed
Oh
hold
on
a
second.
We
find
it
here
and.
G
H
It's
one
of
the
more
recently
filed
issues,
I'll
I'm,
constantly
forgetting
where
all
my
tabs
are
so
bear
with
me,
but
it's
an
issue
and
the
helm
project
about.
Basically
what
happened
was
there
was
a
PR
that
renard
was
working
on
for
I,
think
another
project
for
jet
stack
to
do
a
helm
chart
and
they
said
well.
We
think
that
our
back
should
actually
be
done
this
way,
and
so
I
forget
how
I
ended
up
getting
into
that
discussion.
But
I
looked
at
it
and
I
said
you
know
they
actually
make
some
good
points.
H
Their
proposal
is
that
service
accounts
should
be
separated
out
from
our
back
and
treated
separately
and
and
independently
and
the
more
I
looked
at
it.
The
more
that
made
sense
to
me,
especially
because
that
allows
us
to
do
things
like
use,
charts
that
use
multiple
service
accounts
so
hold
on.
While
I
find
this
peer.
This
I
found.
H
In
33:20,
that's
the
one!
Yes
exactly
my
view
of
Kenzi,
remembering
that's
great,
but
yes,
that's
the
one
so
I
know
the
people
on
the
charts
call
were
asked
to
look
at
it
and
I
know.
There's
some
people
on
this
call
that
are
that
weren't
on
the
church
call.
So
that's
probably
a
good
place
to
discuss
it,
but
I
wanted
to
bring
it
up
here.
Just
in
case
anybody
had
any
quick
thoughts.
H
E
D
D
B
D
C
C
D
C
G
Yeah
in
the
charts
call
we
had
talked
about
if
our
back
was
set.
If
I
remember
right
to
false,
then
then
you
create
the
service
account.
Although
it
looks
like
there's
been
some
some
other
discussions.
Ryan
art
had
changed
it,
but
the
idea
is:
if
there
is,
you
know
you
can
it's
the
question
of?
Do
you
create
a
service
account
per
deploy
for
the
cases
you
create
them,
or
do
you
use
the
default
service
account?
G
Discussed
I
don't
really
have
an
opinion,
which
is
why
I
said:
let's
bring
it
over
here,
because
it
relates
to
home
and
maybe
getting
more
people
involved,
we'll
have
an
opinion
on
it.
This
might
be
something
we
also
want
to
bring
up
at
something
like
cig
apps
as
well.
If
you
don't
get
strong
opinions
here,
because
some
people
there
may
know
well.
E
I
know
that
from
unclear
in
any
standpoint,
most
the
time
like
I
just
think
about,
like
the
controller
manager
and
the
controller
manager,
has
a
service
account
for
each
thing.
It
does,
and
so
I
kind
of
think
that
it's
not
necessarily
a
bad
idea
to
put
in
to
put
in,
like
a
different
service
account
for
each
of
those
services
that
get
created
I'm.
Just
not
sure
where
that
logic
should
lie,
it
kind
of
feels
more
like
still.
E
H
G
You
can
actually
have
a
like.
You
can
do
that
with
a
shirt
today.
Right
so
in
the
chart,
you
could
say
service
account
name
and
if
nobody
supplies
a
service
account
name
like
it's
an
empty
field.
You
do
an
if
statement
and
if
it's
not
there,
then
you
automatically
generate
one
and
you
could
do
something
based
on
like
the
release
name,
which
is
you
know,
already
check
to
be
unique.
You
could
create
a
service
account
based
on
that
for
it,
and
then
you
could
also
know
to
clean
up
for
that
later.
G
C
E
E
The
more
I
think
about
the
more
I
would
not
want
to
put
it
in
tiller,
because
then
the
tiller
implementation
becomes
highly
coupled
to
the
chart
implementation
about
this,
like
with
how
the
service
account
will
be
generated
or
what
the
name
is
or
any
of
that
type
of
stuff
and
any
time
if
we
needed
to
make
some
change
to
the
service
guy
we'd
have
to
make
the
change
in
helm
and
not
in
the
charts
individually.
So
I
would
think
that
it's
I
think
it's
a
good
idea
to
start
supporting
that.
E
G
Right
so
the
first
one
I'll
be
quick,
I
helm
uses
labels
in
particularly
in
charts
and
the
apt
F
working
group
has
been
working
on
kind
of
a
common
label
strategy
to
try
to
make
labels
on
stuff
more
cross-cutting.
If
we
can
all
agree
in
a
bunch
of
labels,
then
other
things
like
UI
is
not
related
to
helm
or
any
other
project
can
also
pick
those
things
up
and
do
interesting
things
right.
G
There's
a
bunch
of
people
who
wanted
this,
and
so
one
of
the
things
that's
coming
out
of
the
app
dev
working
group
is
a
proposed
label
and
annotation
recommendation
that
would
go
up
as
documentation
up
on
kubernetes
docks
and
you're
gonna,
see
that
there's
some
changes
here
and
how
it
relates
to
helm.
And
so
what
we're
really
looking
for
at
this
point
is
really
final
feedback,
in
particular
from
the
helm
folks,
because
it
can
impact
you
or
us.
G
And
if
you
look
in
here,
we
actually
talked
about
because
everything's
names
based
because
you
know
and
how
helm
can
be
different
from
common
ones,
and
things
like
that
actually
use
helm
is
an
example
of
namespace,
a
particular
app
when
they
have
their
own
things
that
are
above
and
beyond
the
common
ones.
And
so,
if
you
all
could
provide
feedback
we'll
bring
it
up
again
at
stig
apps
but
I'm,
just
putting
it
out
there
and
asking
you
all
to
really
go.
G
G
So
if
that
section
of
code
is
touched,
the
tooling
can
say:
hey
a
PR
that
touches
that
go
off
and
request
review
from
two
people
who
are
in
the
reviewers
list
that
touch
those
code
pieces
of
code.
So
it
automatically
randomly
picks
reviewers
from
those
reviewers
licenses,
hey
Goff
and
poke
these
people,
because
they've
agreed
to
be
reviewers
for
this
section
of
code.
It
can
be
a
whole
code
base.
It
can
be
a
single
directory
in
all
subdirectories
of
that.
G
It's
totally
up
to
whoever's
here,
approvers
can
use
tooling
to
say
hey,
we
can
merge
for
this
section
of
code.
It
was
designed
for
the
kubernetes
monstrosity.
That's
this
huge
mega
repo
and
people
really
only
being
able
to
merge
code
for
some
small
sections
and
subdirectories,
but
it
can
apply
to
lots
of
other
things
on
charts,
we're
letting
actual
chart
owners
manage
their
own
charts
now
by
having
an
owner's
file
in
that
chart
and
the
the
two
commands
that
can
go
along
with
this
are
looks
good
to
me
and
approve.
G
What's
going
on
here
right
and
it's
tooling
for
that
and
I,
don't
know
if
it's
useful
or
not,
but
it
lets
you
in
code
enforce
who
can
go,
do
things
and
that's
the
approver
sections
and
the
reviewer
sections
in
an
owner's
file
and
owner
alias,
is
just
let
you
do
a
alias
is
on
top
of
those
four
groupings.
So
that's
what
those
our
I
don't
know
if
they
would
be
useful
here
or
if
anybody's
interested
in
them,
but
that's
kind
of
where
Aaron's
coming
at
this
is.
C
No,
that
was
very
helpful.
Honestly
I
was
missing
kind
of
a
backdrop
on
a
lot
of
this,
in
the
sense
that
that
would
I
thought
this
is
kind
of
like
being
implemented
across
the
entire
kubernetes
org,
and
it's
just
kind
of
like
being
enforced,
and
we
all
have
to
use
this
now,
which
is
kind
of
like
where
some
of
my
comments
did
stem
from
which
I
don't
necessarily
agree.
C
But
if
it's
more
of
like
a
showcase
to
say,
these
are
kind
of
cool
tools
that
are
going
on,
and
you
may
or
may
not
want
to
take
a
look
at
this
then
I'm.
All
for
that,
like
I'm
all
for
showcasing
the
tooling,
but
it
came
off
as
more
of
this
is
something
that
the
kubernetes
order
is
doing,
and
this
is
what
we're
doing
across
the
entire
repository,
as
opposed
to
being
like
hey
we're
Nettie's
people.
Well,
what
we're
doing
well.
G
It
depends
on
who
you
ask
right
right:
is
it
gonna
be
enforced
for
everybody
or
not?
There's
its
self-service
right
I.
Don't
actually
have
the
answer
to
that.
Yet
I've
started
to
push
back
and
ask
that
question,
because
a
handful
of
people
have
decided
to
start
like
you
know
this.
Your
labels
have
changed
automatically
for
you
over
time
right
and
there's
actually
talk
of
removing
the
standard
labels,
and
so
some
of
your
labels
may
disappear,
and
it's
not
going
out
to
all
the
repo
owners
for
discussion.
These
conversations
aren't
happening.
G
It's
a
small
group
of
people
are
saying
we're
gonna
go
do
this
and
then
they
implement
it
because
they
have
access
to,
but
even
when
they
did
the
last
change
for
stale
handling.
They
didn't
even
go
after
the
kubernetes
dev
list
and
just
go
announce
it.
They
didn't
go
around
and
even
start
telling
people
it
just
started
showing
up,
and
some
people
were
like
what's
going
on
here.
G
Why
did
this
happen
because
they
didn't
know
it
wasn't
communicated,
and
so
it
really
is,
and
so,
if
you
don't
like
this
handling
now
that
you
understand
how
it
works
or
saw
something
you
want
to
use,
please
let
folks
know
that
you
would
prefer
to
opt-out
of
it
and
and
give
your
reason
why?
Because
I
don't
know
that
people
get
enough
of
those
opinions
and
there
isn't
enough
of
that
broader
conversation
on
this
tooling.
So
it's
probably
useful
if
you
have
feelings
on
it
to
give
those
opinions.
C
G
Test:
okay,
so
if
you
contact
their
repo
and
file
an
issue
or
something
with
this
I
just
filed
an
issue
to
push
back
a
little
to
see
what
happens
by
suggesting
that
stale
handling
should
be
configurable,
Pro
repo
and
not
90
days
across
the
board.
For
everybody
and
in
the
proposal.
There's
a
proposal
out
right
now
for
SIG's
to
get
orgs
I've
suggested
that
maybe
the
tooling
should
be
opted
in,
so
people
can
opt
into
what
they
want,
rather
than
mandatory,
which
is
what
was
originally
in
that
proposal.
G
Cla
bot
has
to
be
mandatory
for
legal
reasons,
but
the
other
schooling
doesn't
necessarily
need
to
be,
and
so
I'm
starting
to
just
push
back.
But
you
know,
I've
had
a
number
of
people
tell
me
things
and
what
I
would
really
appreciate
is
if
other
people
have
feelings
on
this,
they
need
to
hear
from
more
voices,
particularly
those
from
a
wider
breadth
of
projects,
rather
than
people
telling
me
in
back
channels
and
me
conveying
it
so
they
see
that
it's
not
one
guy,
because
I
do
protect.
Anybody
comes
to
me
in
a
side.
G
Channel
I
don't
share
your
name
with
people
unless
you
tell
me
and
so
I'll
be
like
I'm.
Sorry,
I
can't
tell
you
who
said
this
to
me.
You
know
when
I'm
conversing
on
ideas,
so
please,
if
you
have
feelings,
share
them
and
the
reason
if
you've
got
questions
about
these
because
there's
actually
a
whole
bunch
of
tools
they
have.
Some
of
them
might
be
useful.
Some
of
them
may
not.
Some
of
them
with
a
tweet
could
be
useful
and
it's
all
open.
We
can
go
work
on
those
it's
you
know.
D
Can
discuss
the
next
week,
okay,
just
up
and
down.
Can
we
change
the
implementation
of
installed
the
validation,
install
peace
until
ur,
or
is
this
already
been
tried
over
and
we're
not
changing
anything
and
because
right
now,
there's
a
validation,
there's
an
install
pass
and
then
CR
DS?
Obviously
you
can't
add
a
namespace
while
you're
you
know
installing
everything's,
it's
a
one-shot
deal
as
far
as
like
one
big
manifest.
So
is
it
open
to
refactoring.
D
E
B
Validation,
stuff
has
some
quirks
in
it
like
where
it
isn't
the
logic
and
like
it
especially
has
some
places
that
could
use
some
work
around
updates
and
failed
deployments,
making
sure
you
don't
revalidate,
failed
stuff
and
so
yeah
I'm
it.
It
could
definitely
use
some
refactoring.
So
if,
if
there's
something
that
can
help
that
process
along
definitely
overdo
it,
yeah.
D
H
D
H
D
B
D
Right
yeah
I
mean
CR.
These
are
just
blowing
up
right.
I
know
it's
operators
everywhere.
Even
some
of
this
Cola
kubernetes
OpenStack
stuff
I
was
a
part
of
needing
it.
You
know,
yeah
it'd,
be
nice,
build
install
CR
these
very
easily.
You
know
without
having
to
do
install
the
core
of
craziness
backflips
go.
G
G
It's
the
same
test
that
it
would
run
normally,
so
it
could
run
a
test
and
then
it
could
rerun
that
right
before
it
merges
and
choose
whether
to
not
merge
it,
because
the
test
fails
and
I,
don't
know
if
that's
useful,
but
that,
having
one
last
time
on
charts,
we
use
it
to
verify
that
the
version
was
actually
incremented.
So
something
didn't
increment.
The
version
for
a
chart
in
between
we
say
is
this
charts
version
increment
still
valid.
We
can
do
things
like
that
as
well
right
before
it
merges
it.