►
From YouTube: Helm Developer Call 20180315
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
B
C
B
Say
we
have
a
couple
new
people
on,
so
the
format
is
usually
we'll
go
through
and
do
a
quick
stand-ups
by
the
hump
core
team
then
have
any
sort
of
discussion
after
that,
and
anybody
who
is
not
a
core
maintainer
feel
free
to
bring
up
anything
during
that
as
well.
Today,
we're
gonna
try
to
go
through
stand-ups,
pretty
quick,
so
we
can
talk
about
some
time
free
stuff
too.
So
we'll
jump
right
in
and
Fisher
you're
me
to
start
with
Santos
yeah.
D
A
A
C
G
So
if
there's
somebody
who
does
and
wants
to
go,
throw
in
some
feedback
in
there
about
whether
or
not
that's
intended
or
if
there's
any,
they
like
behavior,
that's
wrong
there
and
would
be
recognized
as
a
bug
that
would
be
helpful
and
then
yeah.
Just
a
few
PRS
there's
a
couple
PRS
that
I
reviewed
that
it
need
a
second
one.
If
someone
could
do
it,
Fisher
I'll
trade
with
you
since
I
have
to
review
one
that
you
reviewed
so
and
then
yeah.
That's
it
so
I'll
pass
it
on
to
see
Nick
did
you
go?
G
H
F
Yeah
so
other
than
some
minor
work
and
the
main
repo
I
haven't
done
any
big
bug,
fixes
or
anything
doesn't
PRS
and
tried
to
fix
up
the
owners
file
given
the
emeritus
stuff,
which
I
realized
I'd
forgotten
to
do
after
we
passed
all
that
the
main
thing
I've
been
doing
this
week
is
trying
to
wrangle
in
and
keep
the
home
3
proposal
going.
So
I've
spent
lots
of
time
trying
to
address
comments
and
move
things
along.
F
I
I,
through
a
suggested,
an
issue
in
asking
for
comments
on
a
suggested
best
practice.
Let
me
paste
it
in
a
chat
here.
Basically,
I'm,
writing
up
Network
best
practices
following
on
from
Elm
summit
and
as
I
was
working
my
way
through
it
I
realized
that
the
way
I
had
originally
proposed
to
do
it
had
a
couple
of
downsides
and
a
better
way
to
do.
It
might
actually
be
to
split
part
of
it
off
actually
into
a
separate
helm
chart.
So
people
have
a
minute
and
can
take
a
look
at
that
and
give
me
some
feedback.
E
A
Sakurai
go
find
that
document,
so
these
were
Humvee
3
user
stories.
They
were
emailed
out
to
lists
drop
them
into
chat
here.
This
was
a
set
of
user
stories
that
we'd
been
collecting,
I,
think
Matt
and
yeah
Matt
that
narrows
it
down
here.
Adam
and
some
folks
have
all
been
collecting.
Some
of
these,
a
bunch
of
them
came
out
of
conversations
with
people
using
how
they
came
out
of
the
helm
summit.
A
So,
but
this
here
is
an
initial
set
of
user
stories
and
they're
all
targeted
around
the
user
profiles
we
have,
and
those
user
profiles
of
course,
are
in
priority
order.
So
this
gives
us
kind
of
this
little
bit
of
direction
on
you
know
what
are
we
trying
to
do
and
for
whom,
and
in
some
cases,
for
what
reasons
like
are
we
trying
to
secure
something
down?
This
is
again
is
just
a
start
and.
B
Right
and
then
for
the
proposal
at
the
young,
it
is
awkward
yeah.
F
Right
so
I'm
gonna
drop
the
link
into
the
proposal,
as
in
its
current
working
draft
form,
so
we've
been
using
hack
MD
as
a
way
of
tracking
this
document,
which
has
been
a
nice
tool
for
us
that
the
commenting
system
is
a
little
hard
to
use
at
times.
So
what
I
was
planning
on
doing
was
just
kind
of
reading
through
the
bullet
summary
at
the
top
and
then
letting
people
yeah
pun,
intended
they're
letting
people
kind
of
delve
in
to
whatever
segments
we
want
to,
but
the
the
summary
is
in
this
design
proposal.
F
Charts
are
updated
with
a
couple
of
new
features.
Chart
ml
has
been
changed
to
a
to
something
closer
to
the
application,
CRD
direction
that
people
are
going
so
there's
kind
of
an
outline
of
how
things
would
move
from
the
old
chart,
Gamal
format
to
a
new
one
in
there
again
everything's
working
draft.
At
this
point,
right,
we've
included
the
notion
of
overlays
as
a
way
of
overlaying
one
template
file
over
another.
Basically
replacing
template
files,
I
think
there's
a
link
in
there
now
to
where
that
overlay
terminology
comes
from
and
how
it
works.
F
F
Emitter
handler
kind
of
model
internally
and
expose
life
cycle
events,
so
that
an
embedded,
lua
scripting
environment,
which
is
our
current
target
here,
would
be
able
to
react
to
particular
events
during
the
life
cycle,
and
that
would
be
the
way
that
we
would
allow
chart
developers
to
extend
some
of
the
things
they
want
to
be
able
to
do
like,
say,
run
through
a
json
engine
or
or
script
up
a
pre-install
hook,
or
something
like
that
and
these
scripts
would
end
up
being
stored
in
the
charts
state
would
be
maintained.
I
entered.
B
Just
for
some
background
on
that
I
guess
I
know:
there's
been
a
lot
of
questions
around
that
the
Lua
and
barn
thing.
So
the
thought
behind
that
was,
you
know
we
wanted
to
be
able
to
provide
it.
Some
sort
of
scripting
because
for
the
life
cycle
event
looks
it's.
It's
been
a
pretty
big
request
of
ours,
but
we
don't
really
necessarily
want
to
switch
away
from
go
because
then
we
have
to
really
implement
all
the
client
library
stuff.
B
So
this
was
a
way
of
having
some
sort
of
scripting
enabled
because
you
can't
really
script
and
go.
You
know
you
generate
a
binary
and
it's
it's
very
statically
type
thing.
So
this
was
a
way
of
coming
up
with
a
like
a
happy
medium
between
the
two
Lua
is
designed
to
be
embedded
into
other
programming
languages,
so
that
seemed
like
the
best
solution
there.
So
that's
kind
of
the
decision-
bot
not
great.
B
B
It
wasn't
six,
yet
it
was
already
five
stuff,
but
there
should
reimplemented
all
that
in
go
and
we
played
with
that
a
little
bit.
It
had
some
limitations,
though,
where
we
were
just
going
to
be
chasing
support
for
JavaScript
functionality.
Do
that
so
that's
kind
of
why
we
can
go
down
and
since
Lou
is
designed
for
that,
that's
just
kind
of
what
we
were
leaning
towards
yeah.
F
A
And
for
what
it's
worth,
there
is
more
than
one
library
we
can
import
today
that
implements
Lua
force
and
go
rather
than
having
to
deal
with
all
of
the
other
tool
chains
to
deal
with
all
the
other
cross-platform
compatibility
to
build
helm
binaries.
The
thing
that
caught
me
about
Lua
was:
it
was
the
one
that
gave
us
scripting
with
the
least
pain
for
us
to
manage
and
build
yeah.
F
B
F
Yeah
clearly
active
for
years
now,
yeah,
okay,
so
one
of
the
so
one
of
the
main
issues
we
wanted
to
make
sure
that
we
could
still
handle
adequately
was
if
two
different
developers
are
using
or
two
different
operators
are
using
helm.
At
the
same
time,
there
would
be
a
common
in
cluster
artifact
that
would
manage
the
versioning
of
those
things.
So
we
still
have
the
notion
of
a
release,
object
and
we've
split
that
into
the
notion
of
a
release.
F
Object
in
the
notion
of
a
release,
version
objects
so
that
they're
separately
queryable-
and
you
can
look
at
this
but
you're
the
proposal
for
that.
So
those
so
we
do
still
have
to
see.
We
do
have
what
are
now
two
CRTs
instead
of
storing
that
in
a
config
map
or
secret,
there's
the
release
CRD
and
the
release
version
c
rd
resources
that
are
created
by
hooks.
Actually,
this
one
may
not
be
currently
the
the
proposal
is
that
resources
that
are
created
by
hooks
will
now
be
managed,
instead
of
being
unmanaged
or
optionally
managed.
F
Instead
of
being
unmanaged,
four-pole
based
DevOps
workflows,
the
new
helm
controller
project
is
sort
of
defined
in
one
of
the
appendices,
though
it's
not
part
of
the
core
proposal
cross.
There's
a
part
of
the
proposals
suggest
that
we
also
have
a
lower
runtime.
That
would
allow
you
to
develop
plugins
as
Lua,
and
you
can
look
at
the
spec,
but
basically
this
would
argument
the
current
plug-in
system
to
allow
Lua
based
plugins
to
run
in
a
sandboxed
environment
inside
of
helm.
F
Matt
Farina
has
been
Matt,
Farina
and
I
talked
about
that
a
little
bit
this
morning,
so
that
parts
a
little
more
in
flux
than
some
of
the
others
and
then
finally,
we're
gonna,
try
and
bump
up
these.
The
support
for
a
helm
chart
repository
by
also
including
a
push
verb
so
you'd
be
able
to
push
things
in
and
Josh
who's
on.
This
yeah
josh
is
on
this
call.
F
He
and
I
have
talked
a
little
bit
about
whether
the
chart
museum
team
would
be
willing
to
take
the
lead
on
defining
sort
of
the
semantics
behind
how
this
would
work,
but
we
would
like
to
be
able
to
make
it
standardized
so
that
there's
a
way
to
do
a
Helton
chart
or
helm
repo
push
in
addition
to
the
fetch
and
pull
kinds
of
verbs
yeah.
So
those
are
the
main
aspects
of
the
proposal
that
proposals
a
little
on
the
massive
side.
There
are
currently
three
big
appendices
on
there.
F
That'll
explain
some
of
the
rationale
behind
various
decisions
that
we
made
when
trying
to
narrow
things
down.
But
with
that
link
you
should
be
able
to
read
through
the
proposal
at
your
leisure
and
either
leave
comments
in
there
or
pursue
that
discussion
elsewhere.
So
that's
kind
of
the
overview
I
would.
A
Also
like
to
jump
in
that
there
are
some
other
proposals
in
issues
on
the
helm
repository.
It
doesn't
mean
that
they
are
either
negated
or
something
else.
A
lot
of
this
is
kind
of.
In
addition
to
that,
for
example,
there's
a
bunch
of
talk
about
changing
indexes
and
stuff,
like
that.
That's
kind
of
a
tangential
discussion
to
this,
but
that
is
it's
not
like
those
things-
are
off
the
board
for
helm
three
for
anybody,
who's
wondering.
J
A
B
A
B
So
we've
got
about
10
minutes
meeting,
so
I'm
not
sure
how
it
would
be
best
to
spend
this
time,
maybe
to
just
talk
about
next
steps
with
this
word,
how
to
get
more
information,
or
maybe
talk
about
follow-up
discussions
to
this
rather
than
jump
into
specific
questions.
First,
an
initial
thought
for
a
next
step
would
be
to
maybe
figure
out
how
to
split
this
up
into
smaller
proposals.
B
I
think
that
there's
this
covers
the
whole
gamut
and
even
just
running
through
you
kind
of
identified
some
sections
that
could
be
broken
off,
for
example,
to
push
stuff
that
you
know
with
that.
Josh
have
been
looking
at.
Maybe
we
break
that
out
into
like
a
separate
looking
proposal
and
maybe
trying
to
figure
out
some
way
to
slice
and
dice
this
thing
just
so,
it's
a
little
bit
more
consumable
because
most
people
that
work
on
how
all
they
work
on
a
certain
section
of
it.
B
F
D
Because
this
is
something
that
I
was
really
really
interested
in
for
the
helm,
dev
summit
was
we
really
want
to
put
all
these
proposals
in
the
dock
like
do
we
want
to
make
a
enhancement
proposal
documentation
forcing
what
the
current
system
is?
Why
we're
changing
is
a
year
or
why
are
we
considering
changing
those?
A
G
I
could
just
be
and
break
it
out
into
milestones,
Farina
like
in
github.
If
we
do
that
because
then
we
can
target
like
a
specific
milestone
for
those
features
and
will
sound
like
a
helm,
three
milestone,
but
maybe
it
might
be
a
way
to
do
that,
so
we
could
track
all
the
individual
likes
feature
and
issue
things.
We
open
the
track
to
like
implement
those
things
underneath.
G
B
B
A
Brian
I
would
expect
it
probably
happens
in
the
existing
home
reap,
although
it
we
haven't
discussed
it.
Yet.
We
already
used
branches
for
minor
versions
such
as
2.8
2.7,
and
then
we
release
patch
releases
off
of
those.
It
probably
wouldn't
be
unreasonable
for
us
to
now
have
a
you
know,
release
to
branch,
and
so
we
can
suit
iterating
on
that
to
support
version.
Two
well
master,
for
example,
switch
to
version
3,
something
like
that
wouldn't
be
unheard
of,
and
then
we
keep
everything
in
the
same
place.
G
I'm
also
a
fan
of
splitting
it
up,
Adam
and
I.
Think
it'd
be
good,
because
then
we
can
yeah
splitting
up
the
like
slicing
and
dicing
it
in
some
sort
of
way,
because
then
we
can
kind
of
split
it
out
and
we
can
have
the
core
maintainer
kind
of
take
lead
of
whichever
section
either
interests
them
or
they'd
like
to
work
help
out
within
any
of
the
community
members
who
would
also
like
to
kind
of
head
that
up
and
they
can
kind
of
that
way
like.
G
A
How
about
this
can
we
take
what
we
have
now
move?
It
is
a
document
into
the
community
repo
with
maybe
just
in
a
note
describing
what
this
is
at
the
top
and
what's
gonna
happen
here
and
then
we
could
take
parts
of
it
and
start
moving
them
off
into
issues
and
when
we
do
that
next
to
the
heading,
for
example,
we
could
link
off
to
the
issue.
Then
the
issue
we
could
link
back
here
to
provide
the
full
context.
A
B
That's
what
I
was
thinking
was
having
it
be
something
a
little
bit
more
organic
like
that.
Like
ask
certain
sections
become
more
concrete,
then
then
we
can
break
them
out
and
in
different
sections,
or
we
can,
if
it's
a
smaller
thing,
linked
to
a
specific
issue
that
we
can
track
or
if
it's
a
bigger
section
you
know
actually
have
another
document,
maybe
set
that
can
explore
a
little
bit
more
and
we'd
have
more
discussion
around
it
and
then
from
there
bring
off
to
discussions
or
issues
that
so.
F
A
E
C
K
F
Yeah
I
mean
I,
guess
the
way
I'm
sort
of
mentally
envisioning
it
is.
We
drop
it
in
I.
I
drop
it
in
since
I'm
volunteering
to
do
this
part
as
one
big
hole,
and
then
we
actually
break
it
down
and
tell
basically
the
document
that
I
have
today
is
just
the
table
of
contents
and
an
abstract
that
points
to
all
of
the
specific
ones.
F
K
So
I
actually
wanted
to
give
a
quick
demo.
It's
too
late,
but
chart
Museum
can
do
multi-tenancy
now,
so
you
can
actually
run
one
process
and
have
unlimited
chart
repos
that
you
can
use
with.
So
you
lie
so
pretty
cool
stuff,
yeah
Nix,
it's
basically
the
envision
mint!
That's
Nikhil
had
ads
some,
so
it's
pretty
pretty
fun.
I
K
K
Read-Only,
it's
just
for
the
index
animal
art,
it's
it's!
Not!
It's
not
ready
for
primetime
I
just
wanted
to.
Let
you
guys
know
that
that
is
started,
and
it's
it's
going
pretty
well
and
we're
also
talking
about
adding
JWT
authorization,
stuff
so
very
similar
to
docker
registry,
where
you,
some
off
source,
tells
you
you're
able
to
do
these
things,
and
you
can
do
these
things.
K
B
Yeah
and
then
the
other
thing
for
next
week
we
might
want
to
discuss,
is
how
we
want
to
move
forward
with
any
of
these
discussions
with
the
help
to
be
proposal,
if
we
just
want
to
keep
them
ad
hoc
in
the
issue
or
if
we
want
to
set
aside
a
separate
meeting
for
meeting
time
or
extend
meeting
times
or
say,
like
the
last
15
minutes,
is
any
discussion
on
com3
proposal
stuff
that
we're
working
on?
Maybe
just
think
about
that
this
week.
If
you
have
any
ideas,
let's
let's
talk
about
that
next
week,
I
also.
B
F
F
A
A
B
F
The
other
big
section-
that's
that
remains
largely
undefined-
is
the
one
that
Josh
knows
about
right.
We
want
to
make
sure
we
get
that
push
semantics
nailed
down,
but
that's
kind
of
a
known,
known,
quantity,
or
at
least
we
know
we
know
who
to
point
the
finger
to
so.
Those
are
the
two
that
are
the
least
defined
currently.
J
G
K
A
So
just
so
anybody
doesn't
know
this
with
the
the
push
a
lot
of
it
comes
down
to
not
just
the
push
and
the
fetch,
but
also
the
indexing
and
searching,
and
where
does
that
happen?
Does
it
happen
server
side?
There
were
client
side
and,
of
course,
there's
a
big
push
to
do
server
side,
another
folks
one,
because
if
it's
server
side,
then
you
exclude
things
like
object,
storage
because
they
can't
have
server
side
search
right
then
there's
also.
How
do
you
search
across
multiple
repositories
at
once
right
if
I've
got
private,
stable
and
incubator?
A
How
do
I
search
against
all
of
them
at
the
same
time,
without
accidentally
leaking
information
to
one
I
shouldn't
have
like
if
I
meant
to
find
something
in
my
private
repository
I.
Don't
even
want
that
search
to
go
to
a
public
one
right,
and
so
there's
complexities
here
on
information,
leakage
and
stuff,
and
that's
where
some
of
the
discussion
has
been
what's
the
right
way
to
go,
and
there
is
no
way
to
make
everybody
happy
at
the
moment,
so
we're
trying
to
figure
out
what
the
best
way
is
for
it
anyway.
It.