►
From YouTube: Helm Developer Call 20180322
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
All
right
welcome
to
the
helm.
Public
dev
stand
up
today
is
Thursday
March
22nd
and
if
you're
not
familiar
with
the
format
of
this
meeting,
the
core
maintainer
go
around
the
room
from
both
the
charts
and
Cora
and
helm
repository
side
and
bring
us
up
to
date
on
what
they've
been
working
on
when
they
plan
on
working
on,
and
then
at
the
end
of
that,
we
have
an
open
time
to
discuss
the
things
we
need
to
discuss.
Do
we
have
any
topics
that
we
know
for
sure
we're
talking
about
today.
C
E
Sounds
good
so
last
week
a
little
bit
of
time
and
also
spent
a
little
bit
of
time,
moving
Kurt
Museum
to
depth
so
this
week,
I
want
to
spend
a
little
bit
more
time
on
the
authentication
pieces.
I
haven't
had
a
chance
to
do
that,
for
especially
some
of
the
odd
stuff
to
to
iron
that
out
and
what
that
would
look
like
for
for
chart
Museum.
So
we'll
work
a
bit
more
with
Josh
this
week,
so
I
will
pass
it
on
to
Adam.
D
E
D
B
B
That's
good
to
know
so.
Last
week
and
the
week
before,
I
was
kind
of
trying
to
push
through
the
Jade
frog,
remote
authentication
support
for
all
safaris
PR
got
that
one
through
and
then
a
code
reviewed,
Adams,
1.10
PR,
but
I
haven't
done
a
manual
test
so
either
today
or
tomorrow,
I'd
like
to
do
a
manual
test
just
make
sure
that
everything
runs
this
nicely
and
smoothly.
B
G
All
right,
mute
bug,
problems,
okay,
so
I
would
this
week
was
a
bit
busy
for
me,
so
I
didn't
get
around
to
too
much
I
tied
up
some
PRS
I
mean
you
should
double-check.
My
notifications,
I
think
there
was
another
one
or
two
I
had
to
follow
up
on
I'm
planning
on
jumping
on
some
more
PRS
this
week,
so
I'm
not
going
to
volunteer
for
the
Sherpa,
but
I
am
going
to
be
volunteering
myself
to
try
to
take
on
stuff
in
the
PR
queue.
G
So
if
there's
just
for
everyone
else,
core
maintainer
to
keep
keep
an
eye
out
for
mediums
and
larges
and
extra
larges,
because
I'll
probably
review
it.
But
then
I
need
a
second
review
to
finish
that
off
so,
and
also
just
a
reminder
for
those
who
are
new
and
all
sunny
and
newer
and
poor,
maintain
errs
the
way
that
works
is
that
if
it's
a
it's
a
medium,
it's
up
to
the
person
who
first
grabs
it
to
decides
whether
or
not
they
need
the
second
reviewer.
G
But
after
that
we
always
have
a
second
review
at
least
and
the
person
who
initially
did
the
review
merges
the
code.
Unless
it's
a
like,
let's
say,
Fisher
had
opened
a
PR
and
then
I
reviewing
that
someone
else
does
Fisher
artistic
because
he's
a
he's
a
maintainer,
but
that's
how
that
works
so
well.
I
always
mean
that
second
one
know
me
always
pass
it
back
to
the
person
who
first
did
the
review
to
do
the
final
merge
and
make
sure
it's
all
there.
G
G
This
comes
with
no
promises
or
warranties
implied,
but
I
will
I'm
going
to
talk
to
Michelle
about
getting
in
touch
with
the
CNCs
people
about
starting
to
hopefully
look
at
having
a
helm
summit
in
the
EU,
so
don't
get
too
excited
nobody
blow
up
and
announce
this
on
Twitter,
but
I'm
gonna
start
trying
to
look
on
it.
I'll!
Look
into
that
and
see
what
we
can
do
to
set
that
up
anyway,
who
hasn't
gone.
I
lost
track
of
everyone.
I'm
sorry
do.
H
Yeah
just
some
issue
triaging
for
me:
I've
been
pretty
busy
I
thought
about
bringing
up
into
in
tests,
and
maybe
we
could,
you
know,
expand
what
we
currently
have,
because
it
seems
like
there's
some
regressions
keep
popping
up.
Maybe
we
could
talk
about
that
at
some
point.
Yeah
just
issue
triage
for
me:
do
it
some
other
stuff,
but.
A
This
week,
again
has
been
completely
focused
on
how
three
stuff
for
me
after
feedback
from
last
week
and
a
batch
of
feedback
that
came
over
the
weekend.
Well,
so
they're
about
12,
PRS,
I've
done
I
broke
the
document
out
and
everything,
but
the
big
ones
are
over.
The
feedback.
I
got
about
the
application
our
chart
will
rewrite
and
the
application
see
Rd
stuff.
After
several
conversations,
I
decided
to
back
out
our
change
in
format
to
chart
amell's.
So
it's
back
to
the
same
format.
A
It
is
now
which
should
greatly
reduce
the
amount
of
stress
that
both
the
developers
and
chart
authors
have,
but
what
we're
gonna
do
is,
instead
of
changing
that
format
into
a
format
that
looks
like
it's
competing
with
the
applications
here.
D
format
we're
just
going
to
let
the
application
see.
Rd
format
run
its
course
and
hopefully
be
able
to
support
them
depending
on
their
final
format,
whenever
they're
done
so
that
means
the
chart
will
be
even
closer
to
the
same,
which
means
less
backward
compatibility,
logic
and
less
learning
curve
for
home
3
users.
A
The
other
big
thing
that
I've
been
doing
this
week
and
Adam
has
been
helping
me
out.
Actually
Adams
done
a
lot
of
independent
work,
as
you
wouldn't
call
it.
Helping
me
out
because
he's
doing
better
than
I
am
is
we've
been
vetting
the
ideas
around
the
Lua
extension
model,
and
so
we've
independently
we've
tested
different
ways
of
generating
API
bindings
I
think
Adams
got
one.
That's
gonna
be
a
winner.
A
So
the
short
version
is
we
have
vetted
the
loading
process,
the
runtimes
start
up
and
the
idea
that
we
can
build
kubernetes
objects
in
Lua,
so
I
think
we've
cleared
most
of
the
obstacles.
Are
there
any
left
big
ones,
Adam
that
we
have
yeah,
Mel
I,
think
we
don't
have
a
Yambol
decoder
yet,
but
I
think
we
have
a
workable
solution.
Oh
my
so
so
I
think
we've
cleared
the
way
to
basically
say:
Lua
could
be
our
language
without
any
major
pitfalls
or
oddities
or
inconsistencies
that
we've
found
so
far.
A
A
So,
instead
of
having
to
see
our
DS
appellee
a
release
and
release
version,
we
are
now
at
one
CRT
release
and
we're
back
to
secrets
so
that
we
can
manage
release
versions
in
a
way:
that's
hopefully
more
attuned
to
security,
best
practices
and
kubernetes.
So
that's
kind
of
where
we
are
on
that
kind
of
stuff
and
I'll
just
keep
working
on
that
this
week.
Is
there
anybody
who
hasn't
gone
yet
I.
I
All
right
this
week
has
been
a
little
bit
of
the
home
3
stuff
when
Butcher
needed.
Something
reviewed
he's
been
throwing
it
at
me.
Then.
In
addition
to
that,
it's
been
some
charts
work.
One
of
the
things
that
we
landed
over
there
is
now
a
chart
can
have
a
CI
subdirectory
and
in
there
you
can
have
one
or
more
values
files
that
are
specific
configuration
so
where
a
chart
may
have
general
stuff
like
you
don't
want
to
pass
keys
in.
I
You
might
want
to
do
something
like
that
for
specific
circumstances,
for
our
upstream
testing,
and
so
now
you
we've
got
that
working
upstream
I
think
it
was
merged.
Today,
we're
also
adding
some
more
stuff
that
people
have
done
with
better
linting
and
vetting
and
validation
of
files.
So
we
can
more
easily
identify
where
there's
a
problem
without
having
to
think
for
ourselves,
automation
and
that's
been
mostly
it
anybody
else.
D
A
C
So
yeah
so
I
have
a
demo
and
basically
Sharpe
museums
of
providing
multiple
repos,
so
multi-tenancy,
like
Nick,
proposed
at
the
summit,
but
also
the
the
repo
stuff
I,
just
kind
of
threw
some
stuff
together
like
there's
30
minutes
ago.
So
one
of
the
biggest
things
here
that
I
wanted
to
bring
up
in
the
call
was
authentication
against
a
repo.
C
So
if
you
want
to
do
home
push,
what
are
the
methods
for
authenticating
and
I
was
thinking
about
doing,
proposing
the
helm
login,
but
that
kind
of
requires
that
you
have
some
sort
of
token
provider
on
the
repo
itself.
So
what
I'm,
suggesting
in
in
the
PR
which
I
threw
in
the
helm
dev
channel,
is
if
we
had
some
sort
of
similar
to
cube
config
like
a
helm,
config
file
and
what
are
the
impacts
of
that?
And
are
there
any
other
type
of
things
we
would
want
to
put
there
besides,
just
repo
off?
B
Have
we
looked
at
alternative
authentication
methods
like
different
CLI,
you
X's
so
I
know,
for
example,
like
Python
I
was
like
when
you
are
pushing
to
the
piper.
They
call
it
pi,
PI
or
PI
pi,
which
is
the
python
package
index
right.
Have
we
looked
at
how
they
do
a
login
mechanism
like
on
the
push
they
say?
If
it's
an
often
indicated
back
in,
then
you
have
to
add
your
credentials
here
and
then
you
do
another
push
or
I
mean.
C
F
G
C
B
C
And
then
I
also
had
a
thing
for
like
a
set
context,
so
you
could
I
mean
similar
to
keep
config
right
where
you
are
offing
against
a
different
repo.
Yet
multiple,
the
one
thing
that
this
the
one
thing
that
this
also
introduces
that
I
think
Matt
Farina
may
take
issue,
is
it's
of
removing
the
entire
concept
of
a
local
index
and
therefore,
when
you're
doing
like
a
helm,
search
you're,
you
have
to
point
at
a
single
repo.
You
can't
just
search
across
multiple
repos
and
Matt
Fischer.
I
Yeah,
so
for
folks
who
don't
know
my
thing
with
this
and
and
I
really
haven't
brought
up
my
stance
on
it,
I've
been
more
or
less
trying
to
bring
up
all
the
stances
is
there's
kind
of
do
you
do
search
locally,
or
do
you
do
search
within
service
providers
right?
If
you
have
a
bunch
of
services
like
chart,
museum-
and
you
say,
okay,
I'm
gonna
query
over
there
for
search,
then
they
know
all
of
the
things
you
search
for
right.
I
You
now
are
telling
them
when
and
how
you're
searching
for
things
in
a
public
service
versus
something
like
apps,
where
it
pulls
the
indexes.
You
can
search
all
you
want,
and
so
they
don't
know,
and
so
it's
a
difference
between
privacy,
there's
also
issues
of
searching
across
everything.
If
I
search
an
app,
it
doesn't
matter
which
repository
I'm
in
I.
Just
you
know,
I
can
just
search
for
it.
I
And
so
we
probably
need
to
talk
through
and
figure
out
which
rates
are
important
stands
on
this
as
home.
What
is
the
community
where
the
requirements
to
know
what
direction
we
go
in,
because
a
bunch
of
providers
getting
together
to
figure
out
what
people
need
may
not
address
things
like
enterprise,
security
and
stuff,
like
that
yeah
or
my
curiosity
is
I.
C
I,
don't
I
honestly
I
mean
in
my
own
workflow
I,
don't
see
a
whole
lot
of
com
search
in
general,
because
I'm
I'm,
typically
knowing
the
name
of
the
repo
and
the
chart
that
I
want
to
install
I,
may
not
know
the
version
so
I'm
doing
home
and
saw
repo
name
chart
so
I'm
interested
to
know
like
how
people
are
using
home
search
because
I,
don't
I,
don't
really
see
its
place
in
a
CI
workflow.
It's
just
it's
a
nice
thing
to
have
on
your
laptop
but
yeah.
B
And
so
so
the
problem
that
I
think
Farina
you're
bringing
up
is
the
ambiguity
of
when
you
do
a
search,
is
it
being
sent
to
the
right
index
server
or
is
it
being
sent
to
all?
And
so
there's
the
concern
about
leaking
those
leaking.
Your
intent
of
searching
to
basically
every
single
company
that
you've
currently
added
or
repository
that.
D
B
I
And
some
of
this
has
to
do
with
how
we
approach
things,
because
in
the
case
of
pipe
I,
and
if
you
look
at
composer
and
NPM
and
even
docker
a
lot
of
times,
you
have
one
major
hub
right
and
that's
where
everybody
puts
their
stuff
and
it's
hosted
now
in
the
case
of
things
like
apt
and
helm,
we
don't
lots
of
people
can
have
lots
of
indexes
and
there
is
no
one
central
one,
and
so
how
do
we
do?
We
want
to
go
towards
the
central
one?
What
does
that
mean
right?
C
One
of
one
of
the
things
I
want
to
bring
up
here
is
the
in
my
PR
I
put
that
the
that
helm,
that
the
v1
index
animal
and
all
that
should
still
be
supported.
So
basically,
if
you,
if
you,
if
you
have
an
old
repo
that
you're
using
with
this
home
search
and
stuff,
it
should
still
work.
I,
don't
know
if
you
guys
agree
with
that,
but
I
think
v2
could
become
the
default.
But
if
people
have
requirements
on
these
on
these
specific
features
and
could
use.
B
It
for
some
time,
yeah
I,
think
one
of
the
things
I
was
really
interested
in
was
making
sure
that,
during
this
transition
between
home
2
and
helm,
3
that
we
could
at
least
install
helm,
2,
charts
and
I.
Think
one
of
the
things
that
still
needs
to
be
addressed
is
search.
Ability,
I,
think
that
would
sound
pretty
reasonable
to
be
able
to
both
handle
the
old
v1
search
methodology.
B
I
There's
there's
also
the
issue
that's
at
hand
here
is
we're
doing
a
lot
of
we
think,
rather
than
going
to
folks
and
finding
out
what
they
need,
and
it's
very
easy
for
service
providers
say:
I
want
to
offer
a
service
in
this
way,
but
does
it
actually
hit
home
with
the
need?
Does
it
meet
the
security
requirements
and
where
a
bunch
of
our
users
want
to
go
and
I
would
like
to
get
more
information
on
that
I'm
actually
willing
to
throw
a
survey
together?
I
C
I
I
It
actually
creates
things
where
you
can
have
a
more
efficient
memory
footprint
around
it,
and
so
the
solutions
don't
always
have
to
be
obvious
to
this,
but
I
want
to
make
sure
at
the
end
of
the
day,
there's
things
like
security
requirements
that
enterprises
have
and
I
know
lots
of
startups.
Don't
have
those
kinds
of
things
thrown
in
their
face
they're
trying
to
quickly
get
things
out
and
I
want
to
make
sure,
because
a
lot
of
enterprises
use
this
stuff
that
it
meets
their
needs
and
a
lot
of
them.
I
I
F
That's
me
I'm
new
to
this
Paul's,
my
first
time
on
I
assume
you
guys
can
hear
me
right
now,
since
nobody
else
is
talking
so
awesome,
I
can't
I
showed
up
just
to
listen
and
learn
on
the
Red,
Hat
and
I
work
on
our
tooling
behind
the
the
Service
Catalog
and
the
broker
automation
behind
that
and
work
at
helm
and
started
using
home.
But
what
you're
talking
about
now
is
right
up
my
alley.
My
last
five
years,
I
spent
working
on
repository
management
and
they
say
the
Swiss
Army
knife
of
puppet
models.
F
Python
packages,
docker
images,
Debian
packages,
rpms
all
that
stuff.
How
do
you
engineer
up
and
manage
all
that
stuff?
So
I
know
a
lot
about
that
topic
and
the
one
thing
I
did
want
to
at
least
just
put
on
the
table,
for
you
guys
right
now
to
think
about
is
there's
a
tremendous
amount
of
value
to
be
had
if
you
can
avoid
requiring
a
service
or
in
a
live
API
to
serve
your
content.
F
If
you
can
throw
files
on
a
static
web
server
like
s3
bucket
or
just
patchy,
or
whatever
huge
value
in
that,
both
in
a
reducing
friction
or
just
being
able
to
stand
up
my
own
repository
so
we've
seen
a
community
is
like
python
and
puppet
there's
huge
demand
for
I
want
to
have
my
own
internal
public
boards.
Out
of
my
own
internal
pipe
I-
and
you
know
this
years
went
by
and
people
took
Swagger's
at
it,
but
you
know
it's
for
all
kinds
of
reasons.
It
was
not
not
easy.
There
are
decent
solutions.
F
Not
for
that.
The
other
is
that
speaking
of
the
enterprise,
these
cases,
in
particular
those
those
users,
want
content
on
site.
So,
even
if
they're
using
public
up
to
turn
stuff,
they
want
their
own
copy
inside
their
own
balls
that
they
can
guarantee
is
going
to
be
available.
They
can
audit
it,
they
can
sign
it
track
it
and
so
on
and
even
curate
it
into
their
own
collections
and
their
own
repositories.
A
A
A
F
A
A
D
A
C
Way,
all
right
so
I'm
gonna
make
it
real,
quick
I
have
this
directory
called
charts
so
in
a
typical
chart
repo
today,
you
store
all
your
files
right
next
to
each
other
with
this.
What
this
new
layout
is,
is
your
ability
to
nest
charts
for
the
so
that
we
can
enable
authorization
on
specific
organizations
or
specific
repositories
in
an
organization.
So
this
is
an
example
with
nine
different,
unique
repositories.
C
Nested
two
levels,
deep
under
an
organization
and
chart
museum
server,
has
added
the
depth
flag.
This
multi-tenant
flag
is
going
to
go
away,
but
this
depth
flag,
if
not
provided
to
our
museum,
will
work
as
it
is
today
and
provide
a
single
index
animal.
If
you
provide
a
number
here,
it'll
nest
it
that
many
times
so
you
could
actually
just
do
charts
for
equal
one,
two
three
under
here.
If
you
want
so,
if
I
run
this
I.
C
C
A
C
C
A
E
C
Yeah
and
then
the
nesting
will
allow
us
to
basically
come
up
with
some
set
of
scopes,
similar
docker
registry,
so
the
next.
The
next
step.
Is
you
pass
a
JWT
token
that
says
you
have
access
to
these
repos
and
you
can
pool
from
them.
You
could
push
from
them
and
hopefully
that
will
make
gets
way
into
what
we're
talking
about
for
home
three
as
well
excellent.