►
Description
Kubernetes Distributions and 'Kernels' - Tim Hockin & Michael Rubin, Google
Kubernetes has historically released a full fledged distribution - everything you need. As the project gets more modular, that will become more complicated. This talk will explore the problems we face with this, and some ways can solve them, considering other analogous OSS ecosystems.
About Tim Hockin
Tim is a Principal Software Engineer at Google, where he works on the Kubernetes and Google Container Engine (GKE). He is a co-founder of the project, and he is responsible for topics like networking, storage, node, federation, resource isolation, and cluster sharing. Before Kubernetes, he worked on Google's Borg and Omega projects and the Linux Kernel, and before that he enjoyed playing at the boundary between hardware and software in Google's production fleet.
About Michael Rubin
Twenty years in the Systems Software Industry, from developing enterprise file servers and systems. The past ten years he has worked at Google where he founded the Linux Storage group for its data centers and worked on world wide WAN and BGP technologies. Today he is co-leading and managing Kubernetes Infrastructure with a focus on node, networking, storage, sharing, GPUs and multi-cluster efforts. For some reason he is still spending way too much personal time with file servers.
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.
A
A
Michael
and
I
as
we're
getting
ready
for
submitting
proposals
for
kube
Khan
we've
had
this
topic
that
we
wanted
to
think
about
to
bounce
around
and
we
thought
hey
if
we
submit
a
proposal
and
we'll
be
forced
to
think
about
it,
and
but
it
almost
didn't
work
so
so
we
submitted
this
proposal
with
a
very
rough
sketch
and,
and
we've
had
this
idea
that
we've
been
chewing
on
for
nine
nine
months
ish
and
the
question
oops.
The
question
is:
how
do
we
manage
kubernetes?
A
This
project
has
grown
exponentially
and
it's
going
to
continue
to
grow
and
it's
it's
sort
of
an
amazing
thing,
unprecedented
in
many
ways,
the
speed
at
which
this
is
happening.
So
we
look
at
the
way
we
manage
kubernetes.
We
look
at
the
the
things
we
hear
from
our
users
and
we
looked
at
the
things
we
hear
from
our
developers
and
and
we're
asking
questions
of
how
do
we?
How
do
we
were
find
this?
A
A
So
today,
kubernetes
is
a
fairly
large
system
right,
we're
pushing
3
million
lines
of
code,
which
is
makes
it
one
of
the
bigger
go
projects
in
the
world
by
most
metrics.
It
is
either
the
most
active
or
one
of
the
top
couple
most
active
projects
on
github.
We
have.
We
have
thousands
of
developers,
hundreds
of
meetups,
but
it's
not
a
monolithic
system
right
and
on
top
of
all
that,
it's
still
growing.
So,
but
it's
not
a
monolithic
system.
It's
not
like
one
binary
that
you
can
use
and
it
does
everything
it
is
in
fact
microservices.
A
In
some
sense,
it
is
a
bunch
of
cooperating
pieces
that
are
very
loosely
coupled
through
api's
and
they
work
together.
So
this
this
is
a
very
high-level
architecture.
Diagram.
You
see
a
little
bit
of
how
the
components
work
on
the
left.
You've
got
our
master
components
on
the
right.
You've
got
our
No
beside
components,
but
these
pieces
are
all
individual,
binaries
and
they're
all
talking
to
each
other.
A
B
The
result
has
been
that
we
want
kubernetes
to
work
in
many
different
ways
and
have
many
different
functions,
and
so
it
needs
to
be
extensible.
This
is
going
with
the
core
principles
of
kubernetes.
The
approach
that
the
community
has
been
taking
and
the
technology's
been
taking
is
to
put
things
out
of
tree
in
order
to
make
things
scale
and
to
have
velocity.
B
The
idea
is
to
take
the
functionality
and
the
drivers
and
other
pieces
of
kubernetes
and
move
it
out
of
the
central
repo
where
it
can
be
worked
on
by
both
the
specialists
and
have
its
own
release
train
and
have
its
own
constraints.
You
know
I'm
more
aware
of
this
in
regards
to
container
runtime,
abstractions
and
storage
abstractions.
You
know
things
like
CSI
and
CNI,
but
it's
been
happening
across
the
entire
systems
of
cloud
provider,
environments,
operators
and
add-ons,
not
just
the
environment,
to
the
drivers.
B
B
Then
you
gonna
have
to
download
those
components,
and
then
you
have
to
keep
clicking.
You
can
see
the
the
pain
that
the
presentations
given
us
just
to
this
prospect
and
then
deal
with
the
version
skew.
You
have
all
these
components
and
how
do
you
make
sure
they're
at
the
right
version
and
keep
clicking
and
then
you're
in
test
hell
or
presentation
hell
and
getting
them
all
to
work
together
and
getting
to
find
them
all
together?
Put
them
all
in
the
same
repo?
B
You
know
your
own
environment
and
then
testing
them
to
make
sure
they
work
before
these
and
what
the
customer
the
result
is:
it's
unusable
to
most
users
and
presenters
and
the
the
barrier
user.
You
know
the
end,
all
user,
who
should
just
be
able
to
grab
a
version
of
kubernetes
and
get
going.
It's
gonna
become
untenable.
It's
not
gonna
work
and
we're
pushing
out
the
very
people
who
you
know.
Don't
have
infrastructure
teams
and
large
amount
of
resources
to
make
kubernetes
viable.
A
So
as
we
as
we
stare
at
this
problem
and
I,
think
it's
a
real
problem,
you
know
the
idea
that
we're
going
from
this
thing
that
works
to
this
thing.
That
is
a
piece
of
a
thing
that
works.
A
mental
model
started
to
emerge
and
I
thought
it
was
interesting
to
do
some
comparative
analysis
to
another
software
system
that
you
guys
might
have
heard
about
Linux.
A
So
taking
a
little
deeper
look
at
the
components.
The
kernel
is
one
big
C
program
right.
Anybody
ever
contributed
to
the
kernel,
it's
kind
of
fun,
it's
a
little
daunting,
but
it
really
is
just
one
big
C
program.
It
lives
in
its
own
git
repository
right.
It
has
its
own
world
of
get
tooling
and
and
workflows
and
people,
but
none
of
the
tools.
None
of
the
add-ons
live
in
that
git
repo
right.
It
is
its
own
thing.
It
releases
fairly
frequently
for
a
being
such
a
big
piece
of
software.
A
It's
pretty
amazing
I
took
a
look
at
the
release:
stats
for
the
four
point,
ex
releases
it
and
it's
about
every
65
to
70
days.
It
cuts
a
kernel
release
and
it
only
versions,
x,
dot,
y,
major
minor
right,
there's
a
4.2
and
there's
a
4.3
and
there's
a
4.4
and
there's
a
bug
in
4.4
it'll
be
fixed
in
4.5.
A
B
So
everything
else
that
you
require
and
that
you
look
to
to
make
the
kernel
useful,
is
developed
separately,
it's
outside
of
that
development,
environment
and
out
of
that
cadence.
The
do-it-yourself
kernel
system
is
really
not
again
tenable
much
the
same
way
as
we
referred
to
the
kubernetes
trends
that
were
going
towards
around
1992.
The
concept
of
a
linux,
distro
emerged
and
a
lot
of
people
got
together
and
put
in
a
ton
of
effort
to
amass
the
tooling
and
the
other
services
outside
of
the
kernel
itself.
In
order
to
make
this
technology
viable.
B
Today,
everyone
uses
a
distro.
In
fact,
looking
online,
it
looks
like
even
Linus
leaves
the
distro
distro
sort
of
different
needs.
You
can
take
the
same
Linux
kernel
and
configure
it
differently
with
the
distro
and
have
it
focused
on
an
embedded
processor,
maybe
sitting
inside
a
phone
or
controlling
a
rollercoaster,
or
you
can
have
it
control
your
desktop,
or
you
can
even
have
two
different
distros
that
both
serve
the
same
function
of
controlling
your
desktop
and
managing
those
resources
in
very
different
ways,
with
different
opinions,
one
can
be
fully
featured.
B
One
can
be
very
lean
and
very
hands-on.
Distros
most
people
using
distros
care
more
about
the
distro
version
than
the
criminal
version.
Distros
release
very
slowly.
You
know
quarters
two
years
in
order
to
get
it
right,
depending
on
the
stability
of
the
distro
and,
like
I,
said
earlier,
the
distros
emphasize
the
difference
in
the
use
cases
of
the
kernel.
B
What
exactly
are
the
specifics
inside
the
distro?
What
are
the
value
ads
that
are
being
provided?
You
know
taking
a
look
at
it,
you
know
from
quick,
Wikipedia
searches
and
some
long
late-night
conversations
between
me
and
Tim.
We
kind
of
put
in
these
four
categories.
There's
platform
support.
You
know
in
the
kernel.
What
are
the
drivers?
What
is
the
hardware
environment
that
the
kernel
should
be
configured
with
in
order
to
operate
successfully
and
easily
the
packaging
and
component
lifecycle
all
of
the
applications
and
the
libraries
associated
that
sit
on
top
of
the
kernel?
B
How
do
you
install
discover
and
manage
them?
Support
security
and
testing
distros.
Do
a
really
good
job
of
making
sure
that
if
there's
a
black
swan
or
a
bunch
of
CVEs
that
are
relevant
to
them,
that
they're
patched
quickly
and
also
that
the
whole
system
itself
is
combined
and
works
stabili
for
the
user
and
the
installation?
You
know
installing
Linux
used
to
take
tons
of
floppy
disks
and
a
lot
of
time
and
a
lot
of
expertise
today,
most
distros
make
this
a
very,
very
simple
process.
B
A
So,
in
the
in
the
vein
of
the
same
comparative
analysis,
what
does
kubernetes
do
right,
distros,
release
every
six
to
twelve
months,
kernels
release
every
six
to
twelve
weeks.
Where
does
Cabrini's
fit?
It
fits
closer
to
the
kernel
side.
We
release
every
quarter
and
we've
been
pretty
successful
with
that,
so
it's
a
little
slower
than
the
average
kernel
and
it's
a
lot
faster
than
the
average
distribution
kubernetes
today
includes
most
of
what
you
need
to
run
on
the
major
clouds
right,
Google,
the
Amazon
that
list
of
clouds
in
the
world
is
changing.
A
The
list
of
clouds
and
communities
is
not
changing
nearly
as
fast
in
the
future.
I'm,
not
sure
that
it
will
be
true
that
you'll
be
able
to
download
kubernetes
and
have
it
run
on
most
cloud
providers.
Likewise,
kubernetes
Today
supports
a
bunch
of
drivers
because
everything's
in
tree
as
we
have
more
vendors
as
the
ecosystem
grows,
I'm,
not
sure
that
in
the
future
that
that
will
be
true,
I
think
that
you
will
have
to
get
vendor
drivers
for
different
environments.
A
So
kubernetes
also
I
mean
it
ships
with
some
third-party
add-ons
right
it,
ships
with
DNS
it
ships
with
you,
I
ship,
swith
logging
and
monitoring
out
the
box,
but
it
doesn't
ship
a
whole
lot
of
those
there's
a
whole
lot
of
ecosystem.
That
kubernetes
doesn't
bundle
right
and
there's
some
really
cool
projects
out
there
that
probably
a
lot
of
people
want,
but
we
don't
put
into
the
kubernetes
release.
You
know
the
thing
we
cut
every
12
weeks
and
one
thing
we
don't
do
at
all
is
we
don't
carry
patches
right?
A
We
don't
have
an
upstream
project
that
we
apply
security,
fixes
to
and
then
ship
that
right,
so
it's
different
than
a
distro.
In
that
way,
kubernetes
does
release
medium-term
support,
XYZ
patches
right.
We
have
several
live
branches
that
we
keep
going
and
we've
released
patches
for
them
over
the
course
of
several
quarters.
So,
in
the
sense
it
is
more
like
a
distribution
and
kubernetes
from
a
management
perspective.
We
live
in
a
small
number
of
git
repositories,
but
not
one
and
in
fact
the
Trek.
A
B
B
But
it's
it's
still
a
little
bit
best
effort
and
you
know
in
testing
again
heroic
efforts
are
being
put
there
too,
but
it
is
hard
given
all
the
configurations,
to
really
make
sure
that
we
know
how
hard
in
the
system
is
when
it
release
comes
out,
simple
installation.
A
lot
of
great
works
been
going
on
over
the
past
year.
A
lot
of
things
that
have
been
checked
into
the
tree
I
want
to
give
it
just
a
shadow
two
cops
because
Justin's
here
and
he's
in
the
front
row,
and
we
love
him
but
other
than
that.
B
How
we
love
embarrassing
him
good
at
both.
But
it's
still,
we
don't
have
a
standard
solution
and
it's
often
one
of
the
first
questions
that
new
new
users
have
with
how
do
I
install
this
system
on
to
let's
say
my
laptop,
and
you
know
how
do
I
get
things
up
and
running
so
I
can
really
learn
to
explore
kubernetes
over
all
other
distros
there's
like
30
other
distros.
Today,
at
least,
and
more
and
more
growing,
you
come
to
cube
con.
B
You
can
see
new
names,
I
didn't
even
know
about
and
they're
coming
in
here
to
add
this
value
and
fill
in
this
gap.
Many
of
them
have
made
their
own
decisions
of
either
productizing
platform
support.
That's
inside
the
upstream
distro
or
adding
their
own
packaging,
and
component
lifecycle
still
seems
to
be
a
challenging
area
and
I
think
this
is
an
area
where
upstream
needs
to
possibly
has
an
opportunity
to
lead,
and
that
would
help
these
other
derivative
distros
figure
out.
B
What
is
a
good
way
for
you,
know,
developers
to
create
and
make
their
add-ons
discoverable
and
be
manageable
and
have
users
be
able
to
update
and
download
them
and
install
them.
Support
security
and
testing
is
something
that
I
think
District
just
has
to
do.
If
you
know
that
you're
creating
a
distro
and
that
it's
not
safe
and
that
it's
not
available
well,
it's
not
going
to
be
successful.
So
there's
a
very
strong
incentive
to
make
that
work,
and
they
generally
do
and
then
simple
installation.
It
falls
in
the
same
category.
A
So,
with
the
with
all
these
distributions
out
there,
we
have
some
real
risks
right.
We
have
the
risk
of
fragmentation
of
terrible
user
experience
of
non
portability.
Communities
is
at
it's
very
core
about
portability
right.
We
really
want
people
to
depend
on
that,
the
portability
of
their
applications,
if
you're
bundling
them
as
part
of
kubernetes.
So
we
have
a
conformance
program
through
kubernetes
that
launched
a
few
weeks
ago.
A
It
is
called
the
certified
communities
program
and
there's
some
people
from
from
Google
and
from
many
other
places
that
are
working
to
robusta,
fie,
that
to
make
it
a
real
thing:
I've
got
stickers.
Apparently,
we've
got
stickers
now
yay
stickers-
and
this
refers
to
the
API
though
like
this
is
all
about
the
kubernetes
api.
If
you
build
your
applications
to
the
conformant
api
set,
then
you
should
know
that
you
can
take
your
your
communities
application
and
you
can
pick
it
up.
A
Take
it
off
of
your
on-premise
data
center
and
drop
it
onto
google
cloud
or
onto
amazon
or
on
to
any
other
conformant
implementation,
and
all
of
these
distributions,
docker
and
Amazon
and
Oracle
and
Google
and
Microsoft
have
all
committed
to
staying
in
the
conformance
based
so
Michael
and
I.
We
said
we
talked
about
this.
We
argued
about
whether
distros
were
a
good
thing
or
a
bad
thing,
or
that
we
could
stop
them
or
whether
we
could
have
prevented
them
and
I
came
to
the
conclusion.
Distros
were
inevitable.
They
were
always
inevitable.
A
A
A
This
is
different,
so
option
the
first.
We
could
just
ignore
it
right.
This
is
sort
of
what
we've
been
doing
to
date.
Right,
there's,
no
such
thing.
This
is
not
gonna
play
out
real
well
for
us,
other
people
are
going
to
continue
to
make
distributions.
We
will
not
have
any
coordination
across
the
distributions
we
will
have
as
a
community.
We
will
have
no
say
in
what
happens
with
these
distributions.
They
are
going
to
invent
tools.
A
We
will
have
the
great
app
to
versus
rpm
or
all
over
again
right,
I'm,
not
sure
that
that's
a
good
thing,
then
that
result
of
this
is
going
to
be
fragmentation.
It's
going
to
be
politicization
people
competing
on
where
they're
different
right,
we've
seen
this
in
other
communities,
I'm,
not
sure
this
is
what
we
want
for
communities,
but
it's
a
valid
option.
B
A
At
least
600
right
I'm,
not
sure
that
we
want
to
do
that
with
communities.
The
second
option
is,
we
could
go
all
in
on
this
right.
We
could
make
the
the
one
true
distro
I,
totally
had
an
awesome
joke
here
and
Jesse
Frisell
scooped
me
on
Twitter,
so
I'm
not
gonna
do
it,
but
this
is
gonna,
be
a
big
effort.
We're
gonna
go
down
this
road.
We're
gonna
need
a
team
of
people
to
focus
on
this
to
organdy
marketing.
We're
gonna
need
advertising.
We're
gonna
need
UI
people
and
UX
research.
A
It's
gonna
be
a
huge
effort.
It's
gonna
be
a
major
distraction
from
the
kubernetes
project
or
its
it's
a
different
skill
set.
It's
a
very
different
focus.
You
don't
want
me
designing
your
UI
I
promise
and
you
know
what,
at
the
end
of
the
day,
everybody
else
is
gonna
do
their
own
thing
anyway,
because
people
have
opinions
and
them
for
every
opinion.
We
take
there's
an
equal
and
opposite
opinion
right.
A
B
B
What,
if
we
formalize
what
we
already
do,
and
what,
if
we
focus
on
upstream,
creating
a
correct
and
stable
and
controllable
distro
based
on
what
we've
got
in
the
kubernetes
functionality?
You
know
the
goal
is
not
to
cannibalize
or
stop
any
of
the
other
efforts
for
the
other
distros
and
we
need
them.
You
know
the
community
needs
them
and
the
technology
needs
them
to
continue
doing
the
great
work
that
they're
doing.
But
what,
if
this
is
an
opportunity
for
the
open
source
community
to
lead
and
provide
guidance
and
some
standardization
I'm
betting?
B
A
lot
of
these
derive
distros
would
actually
appreciate
not
having
sixteen
choices
and
maybe
limiting
it
down
to
like
one
or
two.
The
results
could
be
that
it
would
focus
us
to
not
just
sort
of
keep
these
questions
in
the
closet,
but
clean
up
our
thinking
and
put
it
in
the
front
and
center
help
us
to
find
tools
and
standards.
I
actually
I
know
installation
is
hard,
but
I
also
know
that
this
community
can
tackle
it
fairly
easily.
B
Once
we
set
our
mind
to
it
and
I
think
that
if
we
were
able
to
centralize
our
efforts,
it
would
be
a
thing
of
the
past.
We
can
get
over
doing
that
so
that
you
know
the
upstream
distro
or
you
know
an
upstream
effort
could
make
it
very
easy
to
install
kubernetes,
and
the
neat
thing
is
that
the
drive
distros
would
have
a
benefit
from
staying
close
and
decrease
fragmentation
in
areas
that
are
besides
the
API.
A
So
we
have
some
concrete
ideas:
we're
gonna
throw
these
ideas
out.
These
are
not
proposals.
These
are
not
direction.
They
barely
raise
to
the
level
of
idea,
but
I
thought
we
would
be
remiss
to
do
this
talk
and
not
have
some
concrete
calls
to
action
here
so
step
one.
Let's
pick
an
installer,
let's
put
all
of
our
wood
behind
one
arrow
and
actually
try
to
make
one
installer
that
works
really
well
right.
We've
got
about
two
dozen
installers
across
the
community.
Now
and
I.
A
Don't
the
belief
that
we'll
get
to
one
that
everybody
uses,
but
we
can
make
one
that
we
believe
works
really
well.
In
almost
every
case,
people
will
still
choose
otherwise,
but
we
can
have
the
one
that
works
well.
Alternatively,
maybe
we
don't
need
one
installer,
but
maybe
we
need
one
set
of
infrastructure
that
the
installers
all
use
so
that
we
can
have
the
same
net
result
depending
on
which
installer
you
choose
to
use.
B
B
What
in
the
world,
if
we
could
formalize
an
add-on
system
to
make
them
discoverable
either
to
a
central
repository
or
maybe
through
some
system
that
at
least
allows
us
to
enumerate
and
figure
out,
what's
out
there
and
make
it
clear
the
ownership
of
each
one
of
these
add-ons,
and
you
know
even
knowing,
like
the
last
time
this
one's
been
worked
on.
Is
this
add-on,
that's
fantastic
stale,
or
is
it
up
to
date
and
ready
to
go
based
on
the
latest
version
of
kubernetes?
B
You
know
these
are
basic
questions
that
I
think
are
hard
to
sometimes
understand
the
day
figuring
out.
The
management
of
the
updating
and
deleting
them
on
your
cluster
I
showed
this
slide
to
some
people
today,
and
they
said
it's
really
important
to
be
able
to
say,
upgrading
or
add-ons
should
probably
be
as
reliable
and
not
make.
You
worry
do
the
same
way
that
you
want
upgrading
your
kubernetes
cluster
itself.
B
If
we
had
cute
cuddly
apt-get
update
or
something
along
that
level
of
simplicity,
we
could
start
by
just
looking
at
cluster
add-ons
and
trying
to
fit
them
how
to
track
them.
Upstream
tim
loves
this
picture
by
the
way
so
I'm,
just
letting
you
know
that
if
you
want
to
make
him
happy
at
this
talk
after
the
talk
just
say,
you
love
this
picture
and
you
really
appreciate
it
and
it's
gonna
warm
his
heart,
Woodrow.
A
A
If
we,
if
we
manage
the
colonel
as
a
colonel,
we
can
get
velocity
for
our
kernel
developers
who
are
able
to
apologize
to
all
real
kernel
developers
in
the
audience
for
our
kernel
developers.
We
can
get
them
to
move
faster,
to
focus
on
progress,
to
focus
on
the
technology
that
we
need
to
drive
the
system
right.
We
could
release
it
faster.
What
if
we
could
cut
a
Colonel
Cooper
days,
kernel
release
every
six
weeks
just
but
as
taken
in
the
ground
six
weeks
sounds
like
a
pretty
good
number.
A
We
could
even
manage
it
tick-tock
style
right.
We
do
six
weeks
of
adding
features,
cutting
a
release
six
weeks
of
stabilizing
it.
We
we
sort
of
already
do
this
right.
We
have
our
code
slush
and
stabilization
freeze
which
we're
in
right.
Now.
It's
sort
of
break
it
for
six
weeks
fix
it
for
six
weeks,
we
could
formalize
this.
We
can
manage
the
release
process,
I,
think
it
would
change
the
way
we
think
about
the
tools,
the
way
we
think
about
the
process,
the
code
reviewing
the
way
we
manage
feature
development.
B
If,
let's
say
we
find
a
security
vulnerability
in
busybox
I
think
that's,
it's
not
really,
probably
the
right
thing
to
do
in
the
kernel,
but
in
a
distro.
That
makes
a
lot
of
sense.
You
know
that
we
patched
these
things
together
and
we
say,
like
we
have
a
problem
here
and
it's
also,
you
know
the
constraints
are
different
and
the
focus
is
different.
So
it's
a
it's
a
different
product
so
to
speak,
and
it's
a
different
result
that
we
can
achieve
out
of
it
and
make
things
a
bit
more
nimble.
A
So,
if
we're
gonna
do
this
right,
if
we're
gonna,
take
control,
we're
gonna
start
to
think
of
ourselves
as
a
distribution,
we
manage
it
like
a
distribution.
There's
there's
a
few
other
I
think
tactical
changes
that
we
should
undertake
as
a
project.
Right
aside
from
the
fact
that
we
should
only
ship
code
that
we
that
we
own
that
we
can
reproduce
right,
we
need
to
make
it
really
clear
when
versions
change.
A
Today
we
have
kubernetes
X
dot
y
dot
Z,
and
if
we
need
to
change
the
packaging,
not
not
the
binary
but
the
packaging
of
some
of
our
components,
we
have
no
real
option
except
to
roll
to
X,
Y,
Z,
plus
one
right.
That's
not
great.
Every
distro
out
there,
every
Linux
distro
has
a
concept
of
distinguishing
the
version
of
the
thing
versus
the
version
of
the
packaging
of
the
thing
right.
We
didn't
really
do
that,
so
we
should
fix
this
I
think
this
is
a
big
deal
and
it's
actually
significantly
harder
than
it
sounds
right.
B
A
So,
along
with
that
I'm
proposing
that
we
start
to
slow
the
project
down
right,
I've
been
quoted
several
times
this
week
is
talking
about
boring
infrastructure.
People
keep
hearing
us
talk
about
how
camera
is
getting
boring,
right,
quick
show
of
hands
in
the
room.
How
many
people
are
frustrated
at
the
pace
of
Cabrini's,
in
that
it's
just
too
damn
fast,
yeah,
Wow
I'm
with
you
I
agree:
we've
been
cutting
release
every
quarter
for
a
couple
of
years.
A
Now
nobody
wants
to
be
six
releases
behind,
but
I
recognize
the
reality
that
a
lot
of
shops
can't
afford
to
update
their
clusters
every
12
weeks
right.
The
natural
result
is
that
you
fall
behind
worse
weap
in
our
deprecation
policies
on
releases,
which
means,
if
you're
more
than
a
couple
releases
behind.
I
can't
even
guarantee
that
you
have
a
safe
upgrade
from
1.5
to
1.9
unless
you
touch
1.6
1.7
1.8
along
the
way
right
so
I've
turned
your
one-week
upgrade
into
a
one-month,
upgrade
right.
That
I,
don't
think.
A
B
It
would
be
neat
to
if
you
offered
the
option.
You
know
there
are
machines
in
my
house
where
are
very
LTS
based
and
you
know,
they've
got
like
the
photos
that
I
never
ever
want
to
get
damaged
and
then
there's
other
things
where
I
need
to
be
on
the
latest
and
I'm
playing
games
and
I
want
to
understand
exactly.
B
A
And
I
think
the
cool
the
cool
part
here
is:
if
we
decouple
the
kernel
development
from
the
distro
development,
we
have
a
distro.
We
have
a
skeleton
that
other
people
can
derive
distros
from.
They
can
pick
up
the
intermediate
kernel
releases
if
they
need
to,
we
can
build
a
community
around.
You
know:
X
Y,
Z
kernel
releases
that
integrate
with
distro
releases,
but
we
don't
have
to
right
we're
not
forcing
people's
hands.
We
don't
need
to
take
all
of
the
the
things
to
update
some
of
the
things.
B
This
is
gonna,
create
a
nice.
This
is
a
need
for
an
illicit
new
community
and
a
new
set
of
roles.
Managing
a
distro
is
generally
a
different
group
of
satisfaction
loops
for
the
people
who
do
it,
then
at
least
in
Linux.
That
I've
noticed
is
the
people
who
manage
distros
often
are
satisfied
excited
by
and
have
skill
sets
that
are
different
than
maybe
the
people
who
are
implementing,
like
you
know,
RCU
or
huge
tables,
and
you
know
pieces
like
that.
B
Like
Tim
said
earlier,
you
know
I'm
not
really
sure
if
we
want
Tim
to
manage
your
UI
system
for
monitoring,
but
you
know
he's
exactly
the
person
that
you
want
to
have
managing
you
know
your
deep
network
innards,
finding
ways
for
these
different
groups
to
work
together
deliberately
and
creating
a
whole
new
group
of
people
who
can
contribute
in
focus
in
these
areas.
It's
it's
inevitable.
B
B
So
you
know
this
talk
is
both
a
delineation
and
a
description
and
detail
of
the
situation
that
we've
got
kind
of
a
look
further
down
the
road
and
it's
it's
a
call
to
arms,
to
some
degree
and
saying
that
you
know
there's
opportunity
here
and
in
need
here
and
I
think
it
would
be
much
appreciated
by
everybody
around.
If
these
are
things
that
are
interesting
to
you
and
I,
do
note:
I
talk
to
people
all
the
time
would
love
to
do
these
sorts
of
things
and
don't
yet
feel
empowered
to
get
involved.
B
A
With
that
we're
done,
our
terrible
ideas
are
out
there.
Now,
please
get
out
your
biggest
guns
and
shoot
them
down.
I
would
love
to
to
make
this
just
the
start
of
a
conversation,
I
think
as
a
community
leader,
it's
my
job
to
sort
of
throw
these
things
out
and
see
what
sticks.
I
would
love
to
talk
to
anybody
who
wants
to
talk
about
it.
We've
got
some
time
for
questions
now,
but
afterwards
we'll
be
around
so
I
would
love
to
just
get
this
conversation
going
woo.
Somebody
raised
the
point
today
we're
on
an
exponential
growth.
A
We
will
never
have
less
users
and
we
do
today
and
we
will
never
have
more
freedom
than
we
do
today.
So
if
we're
gonna
make
big
changes
to
the
community
and
the
way
things
operate,
now
is
the
time
to
do
it.
Questions
I
think,
there's
mics
down
in
the
middle.
So
if
people
want
to
queue
up
at
those
mics
or
you
can
just
yell.
A
The
questions
this
sounds
like
something
for
the
steering
committee
to
head
up.
Have
they
been
involved?
The
question
has
definitely
come
up
among
the
steering
committee
and
interestingly
raised
by
some
community
folks,
as
we
were
working
on
these
these
topics,
it's
come
up
no
less
than
a
dozen
times
this
week.
A
Already
in
various
conversations,
we
had
the
the
communities
dev
summit
on
Tuesday
the
day
before
yesterday,
it
literally
came
up
in
every
session
that
I
was
at
literally
I,
put
out
a
plug
for
this
talk
in
every
single
session,
because
it
kept
coming
up
so
I
definitely
think
it's
on
a
lot
of
people's
minds.
It
is
a
big
topic.
The
steering
committee,
the
first
thing
they're
gonna,
do
is
delegate
and
I.
B
Know
as
someone
who's
been
watching,
the
steering
committee
for
a
while
I
think
they're
going
to
be
the
first
group
of
people
to
say
you
know,
don't
look
to
them
for
all
of
the
answers,
and
this
this
conversation
has
been
coming
up
among
customers
among
other
distro
folks
that
you
know
we
interact
with
among
many
of
the
SIG's.
You
know
how
are
we
going
to
you
know
we
can
all
see
the
progression
and
feel
that
there's
there's
got
to
be
a
better
path.
Question
down
here,
yeah.
C
I
heard
you
talking
earlier
about,
it
seemed
like
you
were:
building
a
model
of
the
cloud
integrations
as
sort
of
the
hardware
drivers
that
would
drive
the
kernel,
but
then
it
sounded
like
you
were
talking
about,
maybe
pushing
them
out
and
letting
them
be
something
that
distros
do,
whereas
in
Linux
kernel
development
they
actually
make
a
big
effort
to
pull
those
in
to
the
maintain
kernel.
Is
that
something
that
you
have
a
strong
opinion
about
one
way
or
the
other?
Or
is
that
maybe
like
a
to
be
answered
later?
I.
A
Think
that
is
to
be
answered.
I
we
had
some
of
that
material
in
the
slide
deck
originally
and
we
cut
it
out
because
I
didn't
want
to
dig
too
deep
on
that
topic.
It
definitely
warrants
discussion.
We're
getting
the
stop
signal
too.
So
I'm
gonna
have
to
take
other
questions.
We'll
take
them
out
in
the
hall.
Afterwards
went
limb.
B
Sent
and
someone
had
as
we,
we
ended
up
talking
a
lot
about
that,
and
one
really
important
thing
to
remember
is
even
though
we
made
a
comparison
to
the
Linux
kernel.
Kubernetes
is
fundamentally
it's
not
Linux,
especially
when
you
get
more
detailed.
It's
not
like
one
large
image
with
you
know,
kernel
modules
and
some
very,
very
strict
ap
is
at
its
core.
It's
a
bunch
of
cooperative
containers
and
pods
working
together,
and
it
changes
the
flavor
and
the
tenor
of
a
lot
of
these
questions
and
what
the
answers
will
be.
Thank.