►
From YouTube: CNCF TOC Meeting - 2018-05-15
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
B
A
A
A
A
H
G
A
A
A
G
Please
yeah
I
mean
you
know
as
you're
aware
this
is
our
largest
cube
con.
Yet
there
was
a
stupid
amount
of
announcements
at
the
conference.
You
know
from
a
TOC
perspective,
Quinton
has
kind
of
rebooted
the
storage
working
group
and
is
now
the
lead
and
sponsor
of
that
we'll
hear
from
him.
The
next
TOC
called
kind
of
how
that's
going
they've
started
work
on
a
white
paper,
which
is
which
is
great
news
and
there's
a
variety
of
product
related
launches.
G
The
claw
defense
team
should
point
wanna
know:
there's
a
variety
of
operators
launched
from
all
over,
so
it
was
too
much
to
list
I
just
basically
tried
to
prune
what
was
best
from
you
know
the
the
mail
threat
on
the
TOC
list
that
I
linked
off
there.
More
importantly
on
slide
7,
you
know
we're
just
looking
for
feedback
from
the
community.
We
have
two
big
events
coming
up
in
the
air
we
got
Shanghai
and
then
Seattle.
G
So
anyway,
we
kind
of
make
these
events
better
for
you
and
the
community,
please
let
us
know
and
I'd
love
to
kind
of
take
some
time.
Maybe
a
few
minutes
on
this
call
to
hear
from
folks
if
they
have
ideas
on
how
to
and
prove
things
we've
been
writing
stuff
down
over
the
last
week
from
from
people
who
have
reached
out
to
me
so
consider
this
time
to
make
some
suggestions
for
an
X
conference.
A
You've
got
anything
urgent
to
say:
I
also
want
to
just
pick
out
from
the
highlights
on
slide,
6
the
launch
of
several
implementations
of
a
cloud
events,
implementation
by
I
believe
as
your
own
IBM,
which
is
unexpected
dividend
from
the
service
working
groups.
Efforts
to
do
some
work
there
early
in
the
process,
so
well
done
guys.
Thank
you
very
much.
G
A
A
Can
lead
to
sort
of
the
loss
of
the
original
sort
of
develop
a
community
vibe?
It
would
be
great
for
people
to
suggest
ways
that
the
conference
or
other
conferences
could
continue
to
sustain
a
developer,
to
develop
an
interaction
as
opposed
to
a
user
to
user
or
developer
to
user
interaction.
I
think
that
this
is
important.
Otherwise
it
will
turn
into
a
different
kind
of
conference
altogether,
which
would
be
a
shame.
A
A
D
I
Do
want
to
avoid
that
it
just
be,
but
benders
talking
to
each
other's
reputation
from
some
other
conferences
or
just
business.
Pitches
I
think
the
biggest
strengths
that
we
have
going
for
us
is
the
co-chairs
that
they
come
from
the
community
and
that
they
pick
a
program
committee
from
the
community
to
that's
an
independent
rating
of
these
talks,
and
so
it's
not
Chris
or
myself
or
the
board
or
anyone
else.
I
That's
actually
selecting
the
talks,
it's
a
relatively
neutral
process
or
as
much
as
these
things
can
be,
and
so
I
do
just
want
to
mention
that
the
CFP
for
both
Shanghai
and
Seattle
and
they'll
be
integrated
together,
so
that
you
can
pick
one
or
the
other
or
both
is
going
to
open
on
May
21st.
So
we
would
love
to
have
people
begin
thinking
about
the
topics
they
want
to
be
talking
about
at
the
this
winter.
A
Okay,
thank
you
so
slide.
Eight.
This
is
about
working
groups
in
general,
which
covers
a
number
of
different
issues.
Just
to
be
clear,
a
lot
of
people
have
said,
and
I
myself
feel
strongly
that
the
working
groups
were
created.
You
know
to
fill
a
need,
but
now
that
we've
got
a
couple
of
them
underway,
we're
starting
to
have
requests
for
greater
clarity
around
their
shape
and
I.
Think
it's
very
important
that
each
working
group
has
a
clear
mission
and
exit
criteria.
A
The
the
working
group
process
that
Chris
is
chairing
here
is
supposed
to
formalize
that
so
the
output
of
this
will
be
a
written
document
with
guidelines
for
creating
a
working
group,
shutting
one
down
and
making
sure
that
people
work
on
it.
Having
a
clear
mission
and
we've
already
had
people
contribute,
Chris
is.
G
There
anything
else
we
need
to
say
about
this
bug
sure
just
just
final
call
any
feedback
on
this
Matt
Farina
and
other
community
members
have
given
feedback,
so
I'm
gonna
crystallize
that
into
an
updated
draft
soon
so
check
the
pull
request.
But
please
get
the
feedback,
and,
by
the
end
of
this
week,
I'd
like
to
finalize
this
soonish,
because
we
have
a
couple
working
groups
that
want
to
be
proposed
and
it
would
be
great
to
kind
of
have
them
go
through
this
new
new
process.
C
J
A
G
A
You
so
slide
9
project
proposals.
We
are
building
out.
Quite
the
you
know,
logjam
here
now
around
new
projects
coming
up
I'm
happy
to
see
that
a
lot
of
these
are
sandbox
projects.
I'm,
just
good,
we'll
probably
spend
less
time
on
those
and
really
drill
into
the
incubation
ones.
I'm
trying
to
have
a
high
standard
for
incubation.
Remember
that
if
you
get
into
the
sandbox
you
don't
get
all
the
press
and
marketing
it's
just
basically
an
experimental.
G
The
Alexis,
the
final
thing
for
telepresence,
since
we
discussed
it
last
weeks,
is
I.
Believe
you
and
Camille
have
volunteered
to
be
the
TOC
sponsors
on.
Was
there
anyone
else
before
we
kind
of
finalize
this,
because
it's
an
action
item
from
last
in
the
last
TSE
meeting,
they've
submitted
their
proposal
officially
to
that
I
linked
I.
D
It's
a
yeah.
This
is
Doug.
This
is
a
status.
This
is
a
status
update
and
as
well
as
a
sandbox
proposal
for
cloud
events,
if
that's
okay,
okay,
all
right,
thank
you
so
jumping
to
slide
11
just
to
refresh
everybody's
memory
and
how
we
got
to
where
we
are
back.
In
March
of
last
year,
Ryan
Scott
Brown
kicked
off
an
email
discussion
about
what
should
the
server
lists
or
what?
What
should
C
and
C
F
do
relative
to
service.
D
If
anything,
at
all,
as
a
result
of
discussion,
the
TOC
agreed
to
form
a
service
working
group
to
do
some
investigation
figure
out.
What,
if
anything,
should
the
C&C
have
do
with
server
list?
What
exactly
is
service?
What's
its
relationships,
the
other,
as
is
out
there
stuff
like
that
in
November
last
year
we
presented
our
outputs,
which
is
a
white
paper
defining
everything
I'd
mentioned
there.
D
You
know
what
is
service,
what
is
use
cases
come
in
architecture
stuff
like
that
and
included
the
landscape
of
the
community
out
there,
so
projects,
tools
and
services
and
we
keep
a
spreadsheet
up-to-date
as
best
we
can
what's
out
there
for
people
to
use
without
saying
which
are
good
or
bad.
It's
just
sort
of
a
statement,
the
fact
that
what's
out
there
and
then
most
importantly,
we
had
a
set
of
recommendations.
What
should
the
CNC
have
do
going
forward?
Things
like
education?
D
Now
we
have
weekly
phone
calls
or
we
get
around
30
people
joining
each
call
for
a
week.
I
think
that's
pretty
high!
That's
a
good
indication
of
the
popularity
we
have
37
different
companies
who
have
been
involved
at
one
point
or
another,
with
I
would
consider
15
regulars
and
by
regulars
what
I
mean
by
that
is.
If
you
attended
the
last
three
of
the
four
last
farm.
D
Sorry,
if
you
attended
three
of
the
last
four
phone
calls,
then
you
have
voting
rights
and
that's
what
I
consider
a
regular
person
or
a
regular
company
on
the
call
and
so
I
think
15
regular
companies
attending
a
phone
call
every
week
is
is
pretty
good.
As
Chris
mentioned,
we
released
0.1
of
the
spec
back
in
April,
so
about
a
month
ago,
and
just
for
clarity,
unlike
other
quoted,
venting
specs
that
may
have
been
produced
in
the
past,
we
aren't
necessarily
trying
to
define
what
all
events
look
like.
D
That's
been
done
before
we're
not
trying
to
do
that.
Well,
we're
trying
to
do
is
just
to
find
the
common
metadata
or
envelope
that
goes
around
your
data.
So
if
you
actually
look
at
that
little
snippet
of
JSON
in
there,
you
can
actually
see
what
we
did
is
in
the
same
way
HTTP
just
to
find
some
common,
headers
or
piece
of
metadata
that
people
can
count
on
being
there
without
having
ously
understand
the
payload
itself.
That's
what
we
did
here
right.
D
We
defined
some
common
attributes
to
help
the
infrastructure
routes
the
message
more
than
anything
else,
but
then
the
data
itself,
the
last
property
in
there,
is
where
the
event
data
itself
goes,
and
we
don't
even
touch
that
it's
just
a
blob,
basically,
and
so
we're
staying
out
of
that
business.
We're
here
just
to
help
the
infrastructure
get
its
job
done
for
the
most
part.
D
D
It's
all
my
pipeline
well
enough
to
be
connect
to
start
thinking
about
what
comes
next,
and
so
we
are
looking
at
what
next
project
we
want
to
work
on
in
this
quote
harmonization
area,
and
so
we're
having
some
discussions
this
week
about
different
things
were
considering
things
like
function
signatures.
Can
we
get
some
harmonization
around
orchestration
of
functions
and
stuff
like
that?
I
haven't
decided
yet
it's
still
up
in
the
air,
but
that's
we're
gonna
be
looking
at
next.
D
I
think
we
made
a
lot
of
good
progress
really
really
fast,
like
the
lots
of
credit
to
the
to
the
members
of
the
working
group,
because
we've
had
lots
of
ideas
tossed
around
and
everybody
seems
to
really
be
anxious
to
come
to
come
up
with
the
consensus
as
quickly
as
possible,
and
so
they
work
very,
very
fast
and
I.
Congratulate
them
on
that,
as
was
mentioned,
got
lots
of
good
coverage
at
coop
Connie
you
we
had
Kelsey
mentioning
us
on
the
main
stage,
which
is
great.
We
had
a
service
working
group.
I'm.
D
Sorry
I
serve
this
session
by
Austin,
where
he
actually
showed
a
demo
of
I
believe
it
was
11
different
companies
involved
in
producing
or
consuming
cloud
events
to
show
in
our
building,
and
that
this
thing
is
real.
We
thought
that
was
really
great
and
it
went
over
very,
very
well
I.
Think
we've
had
some
interviews
go
on
a
big
cloud.
Events
at
coop
Connors
as
well
and
in
terms
of
milestones
we
actually
exceeded
our
expectations.
I
think
we're
hoping
to
just
meet
our
0.1
milestones
by
koukaon.
D
D
Obviously,
we
have
a
lot
of
people
who
are
very
opinionated
in
the
group
and
they
have
lots
of
things
that
they
want
to
get
included,
and
so
it's
been
a
challenge
for
some
of
us
to
pull
back
and
say:
okay,
really,
what's
the
minimal
set
that
we
need
just
to
get
our
job
done
without
trying
to
boil
the
ocean?
And
it's
been
a
challenge
for
some
of
us,
but
I
think
we've
come
through
for
the
most
part.
We're
not
done
yet,
though.
D
The
other
challenge
is
more
for
our
users
perspective
in
terms
of
they
need
to
understand
that
we're
not
doing
what
people
do
in
the
past,
which
is
defining
a
common
event
format
for
all
events.
It's
just
the
metadata
to
help
the
infrastructure
get
his
job
done.
So
people
are
still
gonna
be
expected
to
write
the
code
to
process
the
event
itself
and
whatever
data
format
it
comes
in.
D
So
people
need
to
understand
what
our
goal
is
here
and
we're
not
trying
to
boil
the
ocean
all
right,
so
cypher
teams
for
the
next
steps,
obviously
we're
trying
to
get
to
1.0
as
quickly
as
possible,
and
we
want
to
increase
the
number
of
vendors
who
are
using
it
in
production.
I.
Think
right
now
we're
we
only
have
one
who's
officially
announced
official
support,
I
think
that
might
be
deserve.
D
But,
as
you
can
see
from
the
list
here
with
other
people
that
are
have
it
in
their
open
source
project
or
will
soon
and
of
course
the
we
also
want
to
propose
cloud
events
to
be
a
to
be
a
CNC
F
sandbox
project
which
I'll
get
into
next
and
all
that
slide.
So
we
do
actually
have
a
proposal
out
there.
There's
the
link
is
on
the
previous
slide
slide.
14
I'm,
a
lot
of
the
stuff
I
mentioned
there
in
terms
of
status
and
stuff
like
that
ability
in
that
pull
request.
D
But
a
couple
of
things
I
wanted
to
mention
that
I
didn't
talk
about
already.
We
are
working
under
the
Apache
version
to
license
the
governance
model.
We're
following
is
very
much
consensus,
driven
where
we
just
PI
we
just
try
to
get
to,
as
I
said,
to
consensus
as
best
we
can
come
to
agreement,
get
everybody
on
board.
D
But
if
something
happens
and
we
can't
actually
come
to
agreement,
we
do
have
a
process
in
place
for
how
to
resolve
that.
It
basically
comes
down
to
a
vote,
and
that
goes
back
to
that.
Those
voting
rights
I
talked
about
earlier,
where,
if
you
were
from
a
company
and
you've
been
there
for
the
last
three
of
the
three
four
of
the
last
four
phone
calls,
then
you
get
a
vote.
Luckily,
I
think
we've
only
had
one
vote
the
entire
time
and
it
was
something
kind
of
silly
it
was.
D
Is
it
gonna
be
clouded
SDIO
cards,
I,
work
or
comm?
That
was
it
all
technical
decisions
we've
been
able
to
come
to
a
consensus
on
stuff,
so
that's
been
really
really
great.
We
have
another
bloke,
the
voting
rules.
We
have
your
standard
things,
mailing
lists,
like
channels
hasn't
mentioned,
weekly
zoom
calls
issues
and
PRS
are
all
tracked
in
the
github
repo.
D
Why
should
we,
you
know?
Join
the
CN
CF
or
be
a
foreign
project
under
there.
Obviously,
because
we
were
founded
from
the
CN
CF,
all
our
members
already
share
the
goals
of
the
CN
CF,
meaning
cloud
native
promotion,
providing
choice
for
the
consumers,
interoperability
and
portability
of
infrastructure
or
code.
D
Because
we
want
this
thing
to
be
as
successful
as
possible
is
why
they
use
as
possible
and,
most
importantly,
to
make
sure
it
doesn't
become
vendor
specific
in
any
way.
Even
though
good
Lots
participate
from
other
companies,
we
need,
we
need
the
verification
that
people
actually
can
use
this
as
many
spots
as
possible.
D
A
D
D
12,
it
just
shows
the
metadata
and
decides
how
they
are
having
how
that
metadata
looks
on
the
wire.
Oh,
we
do
have
many
implementations
out
there
so
forth,
as
you
mentioned,
openness
couple
is
to
support
this,
as
well
as
all
the
other
projects
that
are
mentioned
on
slide
13.
If
you
look
in
the
speaker's
section,
you
guys
to
see
all
the
various
companies
that
do
support
it.
So
what's
the
situation
with
the.
A
With
with
Amazon
lambda
and
open
files
and
serverless
open
source
project
which
all
very
popular
and
have
different
purposes
and
roles
and
implementations,
I
believe
they
were
involved
in
some
of
the
conversation
around
surveillance
working
group,
you
anticipate
that
they
would
be
interested
in
this.
Where
is
this
something
that
separate
from
them
all
so
pivotal?
Riff
is
another
example:
yeah.
D
So
all
the
companies
that
you
mentioned
there,
with
the
exception
of
Amazon,
who
regularly
join
the
phone
call,
so
that's
me
the
education
of
they
do
see
value
and
interest
in
going
forward
with
this
Amazon
in
the
past
has
joined
our
phone
calls
they've
dropped
off
since
then,
and
we
do
have
some
people
with
action
items
to
go
off
and
figure
out.
Why
is
it
because
they
don't
see
value
in
it
is
because
they're
busy
we
just
don't
know,
and
so
we
do
have
some
some
people
putting
out
some
feelers
to
get
that
information.
D
But
everybody
else
that
you
mentioned
is
definitely
part
of
the
working
group
on
a
regular
basis
and
I
believe
almost
all
those
people
actually
I'm
sorry,
except
for
Oakland
fans,
leave
all
those
other
people
were
involved
in
the
demo
but
they're
putting
them
there.
You
know
they're
coding,
effort
behind
this
as
well.
C
K
C
But
the
answer,
the
question
that
alexis
is
posing
with
respect
to
one
of
the
faz
is
that
the
cloud
event
can
be
passed
straight
on
through
as
event
data
and
then
it's
up
to
the
function
to
be
able
to
deal
with
it
there.
There
are
other
implementations,
such
as
the
event,
Gateway
or
dispatch,
where
I
believe
we're
both
using
cloud
events
as
a
common
substrate
to
be
able
to
use
that
as
a
middleware
routing
function
to
be
able
to
transit
the
event
to
the
actual
consumer,
and
so
there's
there's
different.
A
Mean
yeah
I
just
think
it
is
very
important
that
we,
you
know,
keep
that
insight
that
we
don't
the
kind
of
island
of
open-source
projects
that
people
don't
use
relative
to
a
much
more
popular
mainstream
service
implementation.
That's
the
basis
of
my
concern,
and
we
saw
something
like
this
happen
with
the
API
discussion
or
IDE
OpenStack
a
few
years
ago.
You
may
remember
so
I'm
just
sort
of
keen
to
kind
of
remind
people
about,
but
it
sounds
like
you're
aware
of
the
issue.
Yep,
definitely
yeah.
L
G
G
M
A
M
Go
for
it
so
a
slide
17
as
well
start
off
helm
is
a
project
seeking
incubation
to
become
a
part
of
the
CNC
f.
It
provides
package
management
for
kubernetes
like
most
platforms.
Think
of
app
forgetting
you
don't
download,
Maria
DB
and
then
go
get
your
configuration
files
and
then
tell
them
how
to
start
up
and
go.
They
go
through
all
of
those
things.
Instead,
you
install
a
package.
Typically,
you
can
act
and
then
you
can
depend
on
that
by
other
applications.
You
have
your
dependencies
and
it
can
be
well
maintained
and
versioned
and.
E
M
Tools
can
be
built
on
top
of
it
like
ansible
and
chef,
and
things
like
that.
That
can
leverage
this
and
that's
what
home
brings
kubernetes.
It
brings
package
management
for
our
applications
and
we
can
use
its
dependencies
and
so
forth.
If
you're
going
to
slide,
18
you'll
see
that
the
project
we
have
helm
and
we
have
several
what
we
call
sub
projects
here.
This
term
is
borrowed
from
kubernetes
there's
the
helm
package
manager,
but
we
have
a
little
bit
more
than
that
that
we're
looking
to
bring
in.
M
We
have
what
we
call
the
community
charts,
which
are
our
packages
by
the
community
for
people
to
install.
Then
we
have
a
monocular,
which
is
a
user
interface
which
can
it
has
two
parts.
It
can
be
run
in
cluster
and
it
can
be
run
as
a
directory
to
search
for
things
either
privately
or
is
most
known
for
being
the
original
UI
for
Kumba's
comm.
M
If
you
go
to
slide
19,
we
can
look
at
a
little
bit
of
a
history
here.
So
home
was
started
over
Eid
day
is
an
over
six
months
back.
This
is
back
in
2015
number
six
months.
It's
all
lots
of
rapid
development,
and
then
it
was
invited
to
merge
with
deployment
manager
which
was
part
of
kubernetes
at
the
time
and
it
merged
with
deployment
manager
to
become
kubernetes
helm,
and
that
was
very
early
on
in
January
of
2016
and
then
shortly
thereafter.
That
March
is
when
kubernetes
became
a
ciencia
project.
M
Over
time,
helm
two
was
finally
released,
which
was
the
merger
of
deployment
manager
and
kubernetes
Elm,
plus
a
whole
lot
of
things
that
were
learned
over
time
that
was
released
in
November
2016.
Then
over
2017
we
saw
lots
of
growth
with
minor
releases
patch
releases
and
lots
of
growth
in
usage,
and
things
like
that
that
I'll
talk
about
a
minute
and
in
people
contributing
near
the
end
of
2017.
M
We
started
to
talk
about
how
the
three
a
lot
had
changed
in
kubernetes
there
were
things
such
as
custom
resources
that
worked
there
was
being
was
being
developed.
There
were
changes
in
usage
patterns
and
what
people
wanted.
We've
learned
a
lot
and
helm
uses
semantic
versioning,
and
so
we
couldn't
change
api's
and
break
backwards
compatibility,
which
means
to
add
a
bunch
of
the
features
and
make
changes.
We
wanted
to
do
that.
M
It
would
mean
it's
time
for
round
three
and
so
at
the
end
of
2017
is
when
we
started
talking
about
what
are
we
going
to
do
that
and
then
in
early
2018
in
February?
Just
a
few
months
ago
we
had
our
first
home
summit,
which
was
a
two-day
conference
focused
solely
on
helm,
and
it
was
the
official
kickoff
to
helm
3.
If
you
look
at
slide,
20
we'll
look
at
the
community
charts
a
little
bit,
because
I
think
this
gives
a
little
bit
of
insight
into
usage
back
in
December
of
2015.
M
There
were
just
seven
charts,
but
by
the
time
we
launched
tell
them
it
had
grown
to
27
charts.
Once
we
launched
there
was
a
massive
take
up,
paint,
charts
and
Kuk
on
you
and
2017,
which
was
just
you
know.
Four
months
later
we
had
2.5
x
growth
in
charts
and
then
that
growth,
it
teetered
down
a
little
bit
koukin
us
in
2017.
Well,
we
had
143
QbD
charts
and
just
the
other
hand,
kuqali.
M
You
I
took
the
day
before
that
we
had
203
community
charts
and
it's
continuing
to
grow
and
the
tapering
off
effect
actually
isn't
interest.
Its
scalability
and
one
of
the
problems
we're
working
on
is
how
do
we
scale
sharing
charts?
Because,
right
now
we
have
the
community
repo
with
lots
of
people
wanting
to
contribute,
updates
and
changes
and
fixes,
along
with
new
charts,
and
we
have
to
change
them,
how
we
do
them
in
order
to
scale
that
growth,
that's
one
of
the
things
we're
looking
for
how
long
and
we're
already
getting
into
right.
M
Now,
if
you
go
to
slide
21,
we
can
see
a
little
bit
of
the
community
contributions
right
now
there
are
11
held
maintainers,
that's
for
the
whole
package
manager
code
base
and
they're
from
they
represent
five
companies,
and
we've
had
328
contributors
for
the
community
charts,
their
love
and
maintainer
from
8
companies
with
over
800
contributors
to
the
charts.
In
addition
to
that
chart,
museum
and
binocular,
some
of
the
other
stuff
we've
touched
on
those
have
additional
maintainer
to
maintain
and
manage
those
code
bases.
M
E
M
M
M
E
M
Installations
using
Cobra
in
slack,
we
have
over
4,000
people
their
users
and
close
to
a
thousand
people
and
how
dev
the
users
are.
People
who
use
home
dev
is
where
we're
actually
discussing
how
we're
going
to
develop
them
to
and
come
three
features
and
things
like
that
and
the
community
chart
side
we're
able
to
track
some
of
the
details
and
we
have.
M
We
have
over
12
million,
get
requests
for
individual
charts
per
month
and
that's
from
multiple
tools,
so
folks
who
use
helm
will
download
them
in
order
to
install
them,
but
people
I
can't
chase
on
our
factory
will
download
and
use
them
as
well.
In
fact,
when
we
talked
about
chart
museum
being
a
server-side
thing
a
moment
ago,
current
museum
isn't
the
only
one.
The
way
it
works
is
there's
a
static
implementation
built
at
the
helm
itself
to
create
a
static
repository.
M
Shark
museum
provides
dynamic,
it's
all
specifications,
so
it
looks
like
artifactory
from
jay
frog
or
able
to
do
it
as
well.
So
artifactory
pulling
in
lots
of
these
community
charts
and
having
ways
to
use
them
is
ways
that
actually
supports
them
as
well
and
in
the
charts
where
we
discussed
developing
charts
we
over
a
thousand
people.
M
If
you
go
to
slide
23,
we
have
helm
and
the
kubernetes
app
survey,
so
we
did
an
application.
How
do
people
use
applications
with
kubernetes?
We
did
a
survey,
we've
been
pulling
data
from
that,
and
so
from
here,
I
grabbed
two
things
that
I
thought
would
be
useful.
One
is
that
64%
of
people
who
share
the
tools
they
were
using
we're
using
help
and
it
was
higher
than
any
other
tool
that
we
had
out
there.
M
That
was
not
part
of
core
kubernetes
and
then
more
than
78%
of
the
people
are
using
third-party
software,
which
is
something
that
can
be
distributed
via
helm
and
charts.
This
could
be
proprietary
majority
of
it
70
some
percent,
as
so
choosing
open
source
software
that
can
be
packaged
and
shipped
and
depended
on
using
charts
in
their
applications.
But
there
is
a
lot
more
detail
if
anybody
wants
given
the
survey,
so
why
the
CN
CF
helm,
is
part
of
kubernetes.
M
Today
and
so
why
the
CN
CF,
it's
already
part
of
Cleveland
ad
side
of
the
CF
CN
CF
and
one
of
those
things
is
that
it
has
grown
and
it's
grown
up
and
it's
become
a
rather
large
community,
as
a
sub
community
of
kubernetes
and
as
kubernetes
focuses
on
core
kubernetes
at
home
is
now
at
a
place
where
it
could
use
more
to
help
flourish,
and
so
brian
has
offered
to
be
our
TOC
sponsor
it's
patchy.
It's
already
been
not
your
kubernetes
for
quite
some
time
for
governments
right
now.
M
Right
now,
each
of
the
projects
has
their
own
sets
of
maintained,
errs
well,
there's
home
or
the
community
charged
monocular,
and
when
it
comes
up,
it's
been
coming
up
to
the
next
level
to
equip
in
any
sig
axe.
In
the
absence
of
that
you're,
looking
for
some
guidance,
I
may
be
doing
a
steering
committee
and
figuring
out.
How
do
we
do
that
to
govern
all
of
it
as
a
whole,
but
helm
is
now
grown
to
the
point
where
we
can
have
our
own
conferences.
M
We
successfully
had
one
just
a
few
months
ago
and
we're
looking
for
help
in
organizing
those
things,
because
some
of
the
core
maintainer
should
attacks
with
kind
of
looking
for
for
help
for
people
who
know
how
to
do
is
far
better
than
we
do
help
with
governments
as
we
grow
the
community.
We
need
something
like
the
CNC
have
to
ensure
better
neutrality,
because
we've
got
so
many
people
from
so
many
competing
companies
and
collaborating
companies
that
having
a
neutral
place
for
them
to
come.
M
Collaborate
together
in
a
safe
place
is
one
of
those
things
you
just
know
we
need,
and
then
there
is
working
with
the
current
infrastructure
and
figuring
out
how
to
scale
that
in
a
way
that
benefits
the
whole
community.
Well,
you
know
those
who
have
to
consume
charts
those
who
wanted
to
pen
down
charts
and
those
who
want
to
share
their
applications
via
charts
and
make
them
discoverable,
and
so
this
is
some
of
the
reasons
we're
looking
for
CNC
accom,
and
so
with
that.
Are
there
any
questions.
A
Hey
one
thing:
I've
always
wondered
about
helm
and
came
up
recently
in
the
helm.
Three
conversations
is,
you
know:
what's
the
scope
of
the
project?
What's
the
road
map
I
think
that's
pretty
important,
because
one
of
the
concerns
that
many
people
are
voiced
to
me
in
personal
conversations
is
the
helm,
seems
to
sort
of
grow
and
grow
and
try
and
do
a
lot
of
different
things
at
once,
ranging
from
templating
to
dependency
and
package
management.
I
worry
about.
If
it
tries
to
do
all
of
those
things,
it
will
fail
and
collapse
under
its
own
complexity.
M
That
so
there's
two
things
for
one
Michele
just
dropped
a
link
in
the
chat
here
that
it
talks
about
where
we're
going
with
Humphrey.
That
will
give
you
some
detail
on
what
we're
planning,
technically
speaking,
he'll,
know
and
I'll
see
if
I
can
share.
It
is
how
long
has
focus
on
the
package
management,
fortunately
think
of
it
as
a
king's
you
homebrew
or
apps
for
kubernetes.
As
far
as
trying
to
compete
with
ansible
and
chef
and
going
up
to
those
higher
levels,
that's
not
its
purpose.
M
M
We're
encouraging
others
to
build
projects
that
use
it
that
want
to
be
more
and
use
that
as
component
readers,
that
included
templates.
Oh
no,
oh,
yes,
templates
are
a
part
of
package
management.
If
you
look
at
how
apt
and
does
things
there
is
templating
as
part
of
that,
we
know
some
folks
want
to
do
more
with
templating
and
go
beyond
go
TPL.
We've
been
exploring
other
ways
of
approaching
that
and
right
now
it's
mostly
about
collecting
data.
Are
people
happy
with
it?
If
not,
what
are
the
issues?
What
do
they
want
to
do?
M
One
of
the
things
we
ran
into
in
the
past
was
so
helm.
Has
the
ability
to
use
other
engines
today
that
go
beyond
go
TPL,
but
we've
had
trouble
getting
people
to
uptake
on
that
part
of
it,
and
so
we're
attempting
to
bend
over
backwards
to
make
that
easier
to
use
or
having
a
hard
time
having
people
who
want
to
go
and
do
more
than
that,
and
that's
one
of
the
things
that
we're
struggling
with
so,
for
example,
with
KC
net.
M
There
was
a
proof-of-concept
created
a
while
ago
by
somebody
who's,
not
a
case
of
net
user,
just
to
show
that
it
could
happen,
and
we
had
trouble
getting
anybody
to
take
that
and
turn
it
into
more
than
a
proof-of-concept
was
a
user.
And
so,
while
I
know
people
talk
about
wanting
other
template
engines
and
there's
things
you
can
do
today
or
having
trouble
getting
uptake
on
using
other
templating
things.
And
yet
in
order
to
make
a
package
manager
that'll
work
with
kubernetes.
We
need
a
certain
level
of
that.
Templating
capabilities.
M
M
J
Alexis
is
Brian,
I
think
you
know
what
he'll
buy,
depending
on
how
you
slice
it
does
five
to
ten
provides
five
to
ten
different
pieces
of
functionality,
but
it
I
don't
think
it's
growing
in
terms
of
scope.
It's
always
stayed
really
close
to
that
original
vision
of
being
an
operating
system
package
manager
that
distinguishes
it
from
other
types
of
package
managers
like
language
package
managers,
but
you
know
having
that
basic
functionality
of
searching
and
browsing
packages
managing
dependencies
installing
a
package
lifecycle
hooks
things
like
that
is
very
closely
modeled
on
the
OS
package.
J
Managers
and
I.
Don't
really
see
it
growing
beyond
that.
I
do
suggest
that
you
know
now
is
actually
a
really
good
time
with
the
helm,
3
proposal
there
that
was
posted
in
the
chat
and
development,
starting
for
people
to
get
involved
to
help
shape
that
helm
has
grown,
as
matt
said
quite
substantially
as
it's
been
kind
of
incubated
within
kubernetes
and
effectively.
J
A
It
would
be
nice
to
understand
what
a
scene
is
the
kind
of
major
technical
gotchas
in
the
project,
which
are
other
things
that
the
communities
happen
to
live
where
that
would
like
to
improve
around
atomicity
determinism,
compositionality
I
mean
we
are
very
happy
using
helmet,
we've
works,
but
would
love
to
know
more
about
where
that
what
the
direction
is.
So
that's
all.
It's
really
a
request
and
yeah
I
love
the
idea
of
moving
it
out
of
Cuba
Nettie
is
saying
it's
definitely
grown.
A
M
H
M
Yes
and
I
think
Brian
touched
on.
One
of
the
big
points
here
is
that
well,
there's
maybe
two
points
there
Brian
touched
on
one
of
them,
and
that
is
helm
is
culturally
growing
to
be
differently.
Helm
has
kind
of
grown
up
and
like
a
child,
their
personality
is
a
little
bit
different
from
the
parent
and
so
helm
has
its
own
personality.
M
So
kubernetes
is
mostly
focused
on
the
core
kubernetes
project,
which
is
about
you
know.
Building
container
management
and
helm
is
kind
of
above
that
in
operating
applications
and
starting
them
up
inside
of
kubernetes,
and
so
the
people
who
build
container
management
system
are
different
from
the
people
who
write
and
manage
apps
in
that
system,
and
we
just
see
cultural
differences
between.
In
the
same
way,
we
want
to
use
tooling
to
merge
patches
the
way
we
want
to
use
tags,
the
way,
meetings
and
governance
work.
M
In
many
ways
we
can
have
our
own,
we
had
a
successful
summit.
We've
got
lots
of
contributors,
you
do
nothing
with
kubernetes,
but
they're
all
around
health
and
we'd
like
to
optimize
processes
and
things
to
help
throw
that
community
of
app
developers
and
operators
who
are
using
home
to
enable
them-
and
that's
that's
a
little
bit
different
than
the
other,
and
so
it's
more
about
giving
helm
the
opportunity
to
continue
to
grow
rather
than
being
part
of
kubernetes
and
fitting
within
its
structure.
So
it
can.
H
J
In
some
respects-
and
it
started
out
as
a
fairly
small
percentage
of
kubernetes
users-
we're
using
it
now,
as
Matt
showed
a
fairly
large
percentage
of
kubernetes
users
are
using
it
so
and
its
growth
rate
is
may
be
limited
by
kubernetes,
but
it's
but
the
some
degree
independent
just
to
use
an
example
queue
bliss
is
a
functions
project.
It
only
runs
on
kubernetes,
but
it's
not
part
of
the
kubernetes
project.
So
you
know
our
basic
stances:
not
every
project
that
is
kubernetes
specific,
belongs
under
the
umbrella
of
kubernetes
itself.
J
H
You
can
elaborate
a
little
on
that
Brian,
because
I
mean
I,
guess
the
reason.
A
couple
of
reasons
why
I'm
asking
what
I
just
want
to
get
clarity,
that
helm
has
got
no
aspirations
beyond
kubernetes
right
method?
Is
that
correct,
I
would
say
at
the
time
that
is
correct?
Okay,
so
it
is
effectively.
It
is
an
aspect
or
a
feature
of
kubernetes,
with
the
caveat
that
there
may
be.
There
are
other
ways
of
doing
it,
the
from
as
somewhat
of
an
outsider
to
kubernetes
itself.
H
J
Well,
I
think
it's!
You
know.
The
complexity
has
been
mentioned
and
by
a
number
of
people-
and
there
have
been
a
number
of
recent
threads
about
it.
I
think
it's
legitimate
concern.
Kubernetes
effectively
is
a
portable
cloud
platform
right,
so
as
about
60
API.
Is
that
cover
things
ranging
from
running
containers
to
load,
balancing
to
authorization
policy
and
we're
growing,
more
and
more
kinds
of
policy?
J
In
fact,
as
enterprises
want
more
controls
over
what
things
run,
so
we
are
trying
to
bound
the
scope
of
the
project
and
take
a
hard
look
at
what
needs
to
be
in
the
core.
Effectively,
though
you
know,
we
have
to
draw
the
boundary
somewhere
and
wherever
we
draw
the
boundary,
that's
going
to
create
some
amount
of
diversity
outside
of
that
with
respect
to
configuration
and
deployment,
I
think
that
that's
an
area,
that's
always
been
fair,
fragmented
and
there
are
a
lot
of
different
opinions
about
how
to
do
things.
Some
people
want
to
use
a
path.
J
J
So
I
don't
think,
there's
going
to
be
a
one-size-fits-all
about
this
I
have
a
25
page
document
up
that
I
could
post
a
link
in
there
are
alternatives
to
how
today
and
I
think
there
always
will
be.
You
know.
Hep
tio
has
developed
a
tool
called
case
on
it,
which
is
inspired
by
some
tools
developed
inside
of
Google.
J
So
I
think
this
is
an
area
that's
still
developing
and
people
are
still
experienced.
Pyrrha
Mentink,
you
pack
is
an
example
of
a
project.
That's
just
focused
on
package
management
and
it's
inspired
by
go,
get
based
style,
dependency,
management
tools,
I
think
that's
fairly
promising
of
an
approach,
and
it's
completely
orthogonal
to
templating
or
lifecycle
management,
for
example,
where
there
are
other
interesting
projects
like
operators
that
are
trying
to
address
the
application
lifecycle
management
space.
So
I
think
this
is.
H
Sure
I
mean
it
helps
ask
the
question
that
you
don't
view
in
the
limit.
Helm
is
not
going
to
be
the
only
alternative.
You
think
that
there
are
going
to
be
alternatives
to
helm
and
from
your
perspective,
that's
that's
a
healthy
thing.
Yes,
okay
yeah,
but
it's
the
question
I
mean
does
I.
He
does
leave
me
with
the
complexity.
Concern
because
I
think
that
there's
a
very
real
risk
of
complexity,
death,
just
there's
just
so
much
and
there's
there's
so
many
different
dimensions
of
freedom,
but
that's
I
mean
ultimately
it's
always
gonna
be
a
balance.
A
E
E
What
group
this
year,
we
had
a
couple
of
good
meetings
and
said
to
make
some
progress
and
then
I
think
people
just
got
busy
and
wondering
what
to
make
some
additional
follow-up
meetings,
and
so
I
definitely
need
support.
Does
anyone
on
the
class
say
that
is
part
of
that
working
work?
Group
I
would
definitely
use
your
support
in
getting
some
attendance
and
driving
some
discussions
and
they're.
E
E
G
B
I'm
Aaron
I
had
a
quick
question
about
home.
I
thought
when
we
kind
of
switch
to
the
new
model
we
needed
to
toc
represent
for
is
that
just
for
its.