►
From YouTube: Helm Developer Call 20180118
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).
A
Okay,
welcome
everyone
to
the
helm,
developer
call
this
is
the
developer
call
for
January
18
2018,
we'll
be
starting
off
with
the
announcements
and
I
think
everyone
here
is
a
regular
contributor,
but
in
case
you're
catching
up
after
and
follow
our
normal
structure
of
announcements,
then
stand-ups
and
then
some
points
of
discussion
right
now.
There
are
two
points
of
discussion
on
they're,
both
from
me
is
there
anyone
else
who
wants
to
add
some
discussion
items
on
or
after
stand
up.
A
A
D
A
A
I'm
glad
you
like
it
too
butcher
and
so
will
will
be
poaching
that
scene
and
then
we'll
have
all
the
details
out
for
also
for
paying
that
for
the
ticket
to
come
to
the
conference.
It's
super
cheap
at
75.
Bucks,
I
think,
is
what
we
decided
on.
So
if
your
work
cannot
pay
for
that,
my
guess
is.
They
will
not
be
paying
for
you
to
come
to
the
conference
anyway.
So
but
it's
meant
to
be
cheap,
where
it's
mostly
all
covered
by
sponsors.
A
A
I've
responded
to
a
few
issues
and
stuff
that
I
was
already
part
of
I'm
gonna
haven't
taken
anything
new
with
that
I'll
be
mostly
working
on
that
for
them
just
finalizing
some
of
those
details
this
next
week
and
then
I
might
ping
some
of
you
to
run
my
home
three
lightning
talk
idea.
Past
for
some
review
before
I
give
it
and
then
I
think
that's
it
for
me
this
week
and
I
am
going
to
still
be
online.
E
F
Hey
guys,
so
this
last
week
worked
through
with
Matt
Fisher
shadowed,
Matt
Fisher,
as
the
issues
are,
and
he
walked
me
through,
took
some
time
to
walk
me
through
how
to
do
that,
and
what
I
need
to
look
at
things
like.
That's
it
thanks
a
lot
Matt
for
doing
that.
In
addition
to
that
put
together
as
a
reminder,
I
will
be
out
next
week
making
a
trip
to
Nuremberg
to
evangelize
helm
and
let
other
Souza
teams
know
more
how
to
use
helm
and
and
kubernetes
so
was
putting
together
information
for
them.
F
So
I
have
a
slide
deck
and
some
notes-
and
things
like
that,
and
apart
from
that
I
know,
butcher
said
at
some
point
that
there
was
some
information
about
like
onboarding
in
a
document
somewhere
so
wanted
to
just
follow
up
with
him
to
see
if
I
can
find
that
document,
so
that
I
can
make
some
progress
towards
that.
That's
me
and
I
will
pass
it
on
to
butcher
since
I
mentioned
himself.
B
I
think
Fischer
was
the
last
one
who
got
on
board
with
it,
but,
and
we
should
announce
for
the
record
that
Nick
and
Matt
Farina
were
both
officially
elected
as
new
core
maintainer
x'
I
wrote
a
blog
post
about
the
three
maintained
errs
who
have
opted
to
become
emeritus,
maintainer,
x'
and
all
three
of
them
passed
on
thanks
to
everybody
here
and
and
told
me
what
a
great
time
they
had
being
part
of
this
community.
So
thing
I
wanted
to
pass
that
all
on
to
all
of
you.
B
Yeah
last
week,
I
was
gone
because
I
I
I'm
doing
more
promotional
things.
I
was
actually
with
a
customer
last
week
talking
about-
and
it's
just
been
really
exciting
on
that
friend:
I'm,
not
really
a
salesy
kind
of
person,
but
it's
kind
of
nice
to
just
get
to
tell
somebody
yeah.
We
built
something
that
can
help
you
solve
some
of
these
problems
yeah.
This
is
how
it's
going
to
go.
So
that
was
a
lot
of
fun.
B
B
We
Adam
we
spent
what
an
hour
and
a
half
hunting
for
that
and
both
of
us
know
that
code
backward
and
forward
so
yeah.
So
that
was
fun
for
us
kind
of
then
the
thing
I
will
be
working
on
a
little
bit
here
and
there
it's
kind
of
exciting.
We
will
be
hiring
helm
developers
onto
this
team
and
so
I'm
in
the
middle
of
getting
that
prepped
up.
B
D
B
C
C
If
a
deployment
went
out
after
after
a
deployment,
if
another
deployment
lamp
that
was
failed,
it
was
marking
the
previous
good
deployments
as
superseded
so
fixing
that
the
list
filter
was
actually
filtering
based
on
superseded.
So
because
we
had
two
that
were
not
superseded
anymore,
it
was
displayed
both
records,
so
it
was
very
confusing
about
to
fix,
so
we
actually
fixed
it
on
the
client
side,
so
I
think
it's
a
solid
fix.
If
you
see
anything,
come
work
around
that.
C
D
D
A
D
D
This
last
week
it
was
the
CFP
submissions
going
through
the
review
list
and
whatnot
make
sure
that
was
all
done
and
then
an
Aquila
and
I
both
were
just
carrying
on
the
issue:
queue
on
Martin
Luther,
King,
jr.,
Day
and
just
going
through
the
onboarding
stuff
somewhere
in
the
nebulous
that
onboarding
document
was
passed
to
myself
and
to
Taylor,
because
we
were
the
last
people
before
to
be
on
board
and
I
believe
so.
I'm
gonna
go
through
my
Google
Docs
and
whatnot
and
see
if
I
can
find
that
onboarding
doc.
D
D
B
D
Okay,
well,
then,
otherwise,
a
typical
week
going
through
making
sure
the
helm
that
it
really
goes
well
just
making
sure
that
the
just
kind
of
managing
the
issue
queue
and
the
community
support
and
whatnot
making
sure
that
answers
being
considered
yeah
and
then
continuing
on
this
discussion
about
customer
and
whatnot.
So
we'll
have
those
discussions,
I
think
that
passes
everyone
else
on
the
core
maintainer
team.
Last.
A
Is
there
anyone
else
who
wanted
to
report
anything
I'm
gonna
call
no
problem.
If
you
don't
just
checking
okay,
then
we
will
go
ahead
and
move
on
to
the
discussion
phase,
which
we're
doing
good.
You
almost
have
that's
like
the
earliest.
We've
ended
stand-ups
in
a
while
and
okay.
So
first
on
I'm
going
to
say
the
testing
thing
for
the
end
is
the
other.
Two
should
be
pretty
quick.
E
A
A
E
D
A
A
Along
with
this
is
the
idea
of
including
the
helm
binary
inside
of
the
tiller
image,
and
now
that
we've
kind
of
figured
out
some
of
the
stuff
around
circle
and
move
to
circle
2.
We
wanted
to
revisit
the
idea
of
allowing
this
stuff
in
there
and
finally
supporting
me.
Instead
of
having
a
thing,
is
it
Lackey,
you
always
build
the
image,
helm,
built-in
or
whatever,
and
actually
having
it
be
official.
If
we
want
to
do
that,
so
what
are
people's
thoughts?
Well,.
E
My
first
thought
I
know:
there's
an
issue
out:
there
is
to
have
helm
in
a
separate
image
from
tiller,
not
I
mean.
Is
there
a
reason
to
put
it
in
the
tiller
image?
Because
if
you
have
a
helmet,
you
could
pull
that
in
to
see
ICD
tool,
chains
and
all
kinds
of
other
stuff
like
that
or
you
don't
need
tiller
with
it,
and
so
I
would
like
helmet
an
image
separate
from
tiller
I.
A
Can
see
both
I'm
just
thinking
like
from
the
test
thing
I
do
like
if
I
wanted
to
do
some
like
integration
testing
or
like
e
to
e
testing
I'd
want
both
of
them.
I
mean
I,
guess
I
could
install
it
in
the
fake
cluster
I
spin
up,
I,
don't
know
whatever
I'm
not
like
heavily
biased
towards
one
or
the
other.
It.
B
Is
also
sometimes
useful
to
be
able
to
see
GL
exact
into
the
tiller
pod
and
run
a
hell
command
there
to
purl
in
network
connections
and
things
like
that,
but
I
don't
have
strong
feelings
one
way
or
another.
If
we
did
put
it
in
the
same
pod,
we
could
look
in
the
future,
making
it
possible
to
fetch
the
helm
client
from
the
tiller
pod,
as
in
use
a
curl
curl
bash
it
off
of
there.
Something
like
that
which
might
be
interesting
to,
but
that's
way
out.
There
feature
request,
not
I
know.
C
A
E
Because
imagine
using
something
like
drone
or
gitlab
CI,
where
your
step
is
to
bring
in
the
helm
image
and
then
say,
use
this
image
execute
these
commands
inside
of
it
to
affect
your
chart
and
then
deploy
it
right.
It
fits
nicely
into
some
of
those
workflows
and
you
don't
need
tiller
there,
but
if
they
were
in
the
same
image
I
guess
it
would
work
as
long
as
it
was
communicated
clearly
how
you
would
do
it.
A
I'm
gonna
say
just
how
I
would
think
we
go
forward.
Let's
split
it
out,
it's
easier
to
combine
it
back
together,
then
I
just
to
split
it
out
later.
Let's
split
it
out.
If
we're
gonna,
do
it,
because
anyone
can
just
spin
up
that
if
you
wanted
to
troubleshoot
like
you're
talking
about
you
just
spin
up
a
helm,
pod
inside
of
the
cube
system,
namespace
or
wherever
tiller
is
running
and
then
just
connect
to
it
from
there
and
the.
D
A
D
Or
something
that
will
also
expand
the
tiller
image
to
be
much
larger,
so
if
people
actually
just
want
to
learn
on
their
like,
if
you're
doing
a
Helmand
it
and
suddenly
you're
noticing
that
your
image
has
bumped
up
from
like
what's
the
current
size,
I
don't
know
it,
but
I'd
imagine
it
would
add
quite
a
few
megabytes
if
we're
like
bundling
not
just
the
helm,
client
but
now
we're
also
having
multiple
different
architectures
that
are
compiled
inside
the
image
or
those
might
have
to
be
involved
with
different
docker
images.
Well,.
A
I
think
we
just
need
the
normal
Linux
one
for
the
for
the
her
image,
and
then
we
compile
the
actual
binaries
for
other
stuff,
so
I
think
the
decision
on
that
is
so
we
can
move
on
to
the
testing
thing.
Yes
on
building
a
separate,
helm
image
now
and
then
the
other
thing
was
allowing
other
architectures.
Are
we
okay
with
that?
Or
do
we
not
want
a
lot
I.
E
Think
the
one
thing
is
we
use
Docs
to
do
the
cross,
compiling
and
we'd
have
to
make
sure
it
supports
it,
like
it's
arm
support
it's
kind
of
weak
at
the
moment.
The
one
pain
point,
though,
is
that
I'm
now
a
maintainer
on
that,
and
so
we
either
go
fix
it
up,
which
we
need
to
do
and
I
need
a
reason
to
go.
E
Do
that
or
we
could
go
to
something
like
go
release,
which
is
another
thing,
but
that
does
more
work
than
just
do
the
cross
compiling
there's
some
more
the
packaging
and
the
release
stuff
and
I.
Don't
know
that
we
need
it,
but
with
GOx
we
just
have
to
make
sure
the
architecture
are
supported
over
there
and
if
it's
not
just
tie
off
with
me
and
we'll
make
sure
it
all
gets,
working
and
arm
support
is
broken
over
there
and.
C
E
A
So
then
we
can
go
ahead
and
go
forward
with
that.
Pr
that's
already
opened
at
another
architecture
and
then
add
them
as
people
come
I
think
we
just
allow
those
people
to
add
it
in,
as
the
community
wants
it.
If
we
have
like
a
strong
request,
one
of
us
could
implement
it,
but
like
basically,
if
someone's
like
hey,
we
really
need
our
here's.
A
PR
I'm
sure
just
send
that
in
so
I
think
that's
how
you
could
probably
go
forward
with
that.
D
One
other
thing
that
we
should
know:
how
do
we
procure
that
second
docker
image?
Is
it
as
simple,
like
we've
already
got
full
control
over
the
kubernetes,
helm,
Google
container
registry,
and
it's
just
simply
changing
circle,
CI
to
build
and
push
a
helm
image,
or
do
we
need
to
have
someone
who
has
access
to
the
Google
container
registry
credentials
to
create
your
repository,
because
now
we
should
be
good
actively.
A
Okay,
so
now
we're
gonna
move
on
to
the
test.
Umbra
I'm
gonna
have
to
drop
at
ten,
but
I
do
think.
This
discussion
might
bleed
over
a
little
bit
essentially
and
I'll
need
to
get
the
semi-nice
into
Matt
talked
last
week
about
using
the
test
infrastructure,
and
then
I
saw
a
big
conversation
in
the
contributor
channel
that
country
contrib,
X
or
whatever
that
that
channel
is
in
slack
and
I
kind
of
piped
up
and
said
what
was
going
on
and
like
how
he
had
some
things.
A
E
E
E
You
can
see
what's
configured
for
a
specific
repo
here
you
can
have
certain
things
turned
on
per
repo
and
then
some
are
turned
on
across
the
whole
org,
and
so
you
can
see-
and
you
can
actually
so
this
URL
here
proud
K
a
test.
Io
/
plug-in
help
that
HTML,
it's
not
easy
to
find,
will
get
you
to
this
page.
You
can
actually
see
what's
enabled
today.
E
Now
you
don't
have
to
use
it
or
not
it's
up
to
you,
but
they
do
have
some
tools
that
you
can
opt
into
and
the
idea
around
this
is
there's
a
lot
of
stuff
you
want
to
do,
but
you
have
to
have
push
rights
or
write
rights
to
be
able
to
do
it,
and
you
don't
want
to
give
that
to
everybody,
and
so
most
of
this
is
targeted
around.
How
do
we
make
that
easier
or
automate?
Some
of
it?
Some
of
it's
pretty
simple,
like
CLA,
we
know
how
CLA
handling
works.
E
This
the
CLA
end
link
actually
looks
to
see
if
the
bot
passes
and
then
applies
the
label.
So
you
can
do
things
like
query
on
the
labels,
see
where
it's
not
there.
Things
like
that
and
do
some
other
work,
but
then
there's
stuff
like
a
sign,
you
know
if
you
want
to
assign
or
on
a
sign
or
CC
somebody
which
requests
a
review.
You
can
do
that
on
everything,
and
so
somebody
doesn't
have
to
have
write
access
or
any
special
powers.
They
can
go.
E
Mostly
if
you
use
the
automatic
merging,
because
that'll
tell
the
merge
box,
don't
don't
actually
merge
it
it's
on
hold,
but
it
allows
you
to
do
that
label
command.
Lets
you
control
certain
areas
for
kinds
priorities.
Things
like
that.
These
are
for
the
labels
that
are
on
there,
but
they're.
Also
for
and
you
see,
labels
it's
remove
or
you
got
area
committee
you
can
do
you
know
/
kind
bug
and
it
does
the
kind
bug
not
the
top-level
bug,
one.
E
It's
targeted
around
the
main
ones
that
are
included
across
unless
you
use
the
same
pattern,
but
it
lets
people
apply
labels
without
actually
having
right
access,
and
that
was
the
reason
that
they
did
that,
let's
see
some
of
it
is
for
from
milestones.
If
we're
gonna
manage
milestones
again,
this
is
really
targeted
for
those
two
who
don't
have
right
access
work
in
progress.
This
looks
to
see
if
something's
work
in
progress
because
it
doesn't
have
that
and
then
it
automatically
applies
a
label
to
it.
E
That
turned
out
to
be
really
useful
for
us,
because
now
we
I
don't
have
to
go
through
and
see
see
people
the
automation
doesn't
for
me
on
PRS,
they
kind
of
say:
hey
guys,
can
pick
a
look
at
this.
We
also
have
something
called
tied
turn
on
here
and
that
ends
up
using
the
looks
good
to
me,
and
so,
as
the
owners
files,
we
use
the
owners
files
to
say
hey.
E
If
you
got
an
owner
file,
you
can
merge
changes
to
your
own
chart
as
long
as
it
passes
ci,
and
then
we
use
a
whole
bunch
of
CI
now.
The
neat
thing
for
us
is
the
kubernetes
related
CI,
which
is
basically
jobs,
running
in
a
kubernetes
cluster
and
normal
kubernetes
artifacts,
and
you
basically
pull
in
an
image
and
execute
some
commands
inside
of
it.
You
know
if
you're
used
to
CI
systems
like
gitlab,
CI
or
drone
or
those
things
kinda
like
what
we
do
a
circle.
E
E
E
The
plugins
kind
of
it's,
mostly
here's
a
plug-in
and
then
here's
the
repos.
That
applies
to
that's
what
most
of
it
isn't.
So
you
can
see
the
approve,
plug-in,
here's
the
repos
it
applies
to
and
you
can
actually
see,
there's
implicit
self
approve.
That
means
you
approve
of
something
if
you're
the
author
and
you're
in
the
approvers
file,
some
of
it
like
the
kubernetes
or
actually
requires
you
to
have
an
issue
linked
to
a
PR
before
it
can
be
merged,
and
so
you
can
see
there's
some
some
different
things
here.
E
The
config
file
is
actually
we
get
into
the
detailed
config
on
everything,
and
that
is
just
massive
because
everything's
in
one
place,
this
is
all
of
the
jobs
all
the
CI.
All
of
that
in
one
place,
and
it's
more
like
old-school
Jenkins
right,
you
keep
that
separate
from
the
repos.
They
say
they
want
to
move
some
of
it
to
be
in
repo,
but
that
hasn't
happened
in
that
drawer.
E
They
really
need
more
bodies
and
more
opinions
over
on
the
test,
infrasonic
and
if
they're,
mostly
around
testing
kubernetes,
and
this
has
worked
for
kubernetes
kubernetes,
especially
as
they
break
up
repos
because
and
they
have
to
build
multiple
binary.
So
some
of
this
it
works.
What
kind
of
questions
I
did
a
really
brief,
intro
and
I
probably
have
a
whole
lot
of
contacts
that
I
didn't
share
because
I'm
trying
to
be
quick
on
time.
What
kind
of
questions
do
you
all
have
about?
What's
there
and.
B
E
No,
there
isn't-
and
everything
is
obviously
constantly
in
flux
over
here
as
well.
There
are
discussions
happening
about
how
much
of
this
should
be
opted
in
versus
passed
down
on
you,
and
that
is
for
the
there's.
A
meeting
called
contributes
we're
kind
of
defaulting
to
have
that
over
there,
because
that's
really
about
the
contributor
experience
is
what
they're
saying
but
contributes
and
tests.
Infra
are
the
two
places
that
are
having
this
kind
of
the
implementation
side
of
these
things
is
testing
for
folks,
I.
Think
the
policy
side
of
how
we
should
approach.
E
This
is
the
control
box.
Folks.
That
meeting
is
every
other,
Wednesday
and
I.
Think
next
Wednesday
is
the
next
one,
and
it's
headed
up
by
folks
like
Parris
Pittman
and
those
folks
who
are
really
concerned
with
the
community
and
the
user
experience
right,
they're,
not
the
folks
who
are
out
there
trying
to
code
this
stuff,
and
you
go.
How
do
I
figure
out
how
to
use
it?
C
Some
of
my
concern
around
this
is
for
a
home
project.
At
least
it
would
be
solving
problems
that
we
don't
have
yet
our
workflow
for
people
contributing
is
actually
very
simple
and
straightforward,
or
a
lot
of
dishonor
nation.
A
lot
of
the
automation
is
just
around
builds
and
toolchain
kind
of
stuff,
where
we
have
a
set
of
core
and
caters.
Who
can
merge
stuff
and
that's
the
process?
You
know
we
don't
need
all
this
extra
yeah.
E
E
Maybe
we
start
with
something
slim
in
small
and
instead
of
starting
with
the
most
complex
start
with
something
slim
and
small
and
then
layer
on
top
of
that
and
let
people
layer
in
what
they
need
right,
and
so
you
can
kind
of
pick
and
choose
what
will
help
you.
Kubernetes
kubernetes
will
probably
be
the
most
complicated,
but
lots
of
projects
could
be
much
simpler
and
that
was
kind
of
her
way
of
describing
maybe
a
different
approach
to
handle
this
kind
of
thing
and
that
that
goes
along
with
kind
of
the
opt-in
idea.
E
And
so
that's
what
she
was
thinking
and
I'm
hoping
that
kind
of
philosophy,
but
if
more
folks
may
be
pipe
up
in
contributes
that
would
help
them.
Look
at
that
kind
of
thinking
and
I
have
trouble
attending
control
back.
So
don't
expect
me
to
be
a
loud
voice.
There
I
have
the
app
deaf
working
group.
At
the
same
time,
you.
B
E
E
E
One
of
the
nice
things
is:
are
you
all
familiar
with
dev
stats?
Dev
stats
are
kaydessa
dev
stats
that
chance
EF
tayo.
It
helps
you
have
all
kinds
of
dashboards
on
what's
going
on
with
kubernetes
and
kubernetes
related
stuff,
it's
constantly
being
iterated
on,
but
you
could
do
something
like
look
at
the
approvers
histogram
right
and
give
you
the
history
of
who's
approve
stuff,
and
then
you
can
look
at
repo
groups
right
and
and
part
of
the
reason.
You'll
see
this
is
who's
in
the
helm
group.
E
Well,
it's
not
picking
it
up
because
you're
not
using
the
merge,
bot,
automation
and
so
you're
not
picked
up
in
this,
and
so
that
is
one
of
the
things.
I
don't
care,
but
when
you
use
the
stuff,
these
tools
are
being
kind
of
designed
around
some
of
it,
and
this
must
be
who's
been
merging
stuff
to
the
charts.
Repo
is
my
guess,.
E
E
D
B
F
D
B
B
Is
there
anything
else
we
have
to
vote
on?
Oh
the
new
core,
maintainer
x'.
You
should
open
up
PR,
to
add
your
name
to
the
owners
file,
that's
sort
of
the
rite
of
passage
for
for
that,
and
maybe
next
week
we
can
talk
about.
If
one
of
the
two
of
you
would
like
to
take
ownership
of
the
onboarding
document,
then
we
can
kind
of
turn
the.
If
you
ask
oh
into
something
positive
going
over.