►
From YouTube: Kubernetes Contributor Summit 2018: Long Term Support
Description
This session will feature a couple brief slides with words around what is kubernetes and what is support and what is "long term support" (LTS) and why we're forming a WG LTS. Then it will open to discussion BoF style around the WG's charter, in-scope & out-of-scope topics, timeline, and deliverables. Bring your strong opinions and an open mind around the current Kubernetes project's support stance and what improvements might be possible.
Presenter: Tim Pepper, VMware
A
A
It
so
Jordans
been
working
on
that
and
then
the
L
obviously
stands
for
long,
but
the
the
idea
that
there's
gonna
be
something
for
a
length
and
type
of
support
and
people
have
their
preconceptions
of
what
that
may
be.
It
could
be
something
like
certain
types
of
bug
fixes
for
a
couple
of
years
or
some
some
of
one
type
for
a
shorter
period
and
then
some
other
tail,
but
there's
there's
different
schemes.
The
key
is
that
you
define
one
and
you
make
sure
that
you
match
it
to
what
your
your
user
base
wants.
A
What
your
developer
community
is
capable
of,
and
then
L
long
typically
one
year
or
more,
is
what
people
are
used
to
I
think
in
industry,
different,
obviously
than
what
we're
doing
here
and
within
that
juxtaposition,
you
start
to
get
into
the
controversy
so
benefits
users.
Vendors
developers
could
have
some
benefits
from
having
a
better
defined
support
stance.
I
think
that
much
is
at
least
clear
and
not
so
contentious,
but
these
also
come
at
a
cost.
So
human
staffing
is
a
current
issue
test,
matrix
or
even
just
testability.
A
Today,
in
the
first
place,
much
less,
we
don't
want
to
grow
dramatically
our
test
matrix.
If
it's
already
unstable
right
look,
we
have.
We
have
issues
that
we
need
to
deal
with
the
head
of
this
so
like
this
in
some
ways
feels
like
a
distraction,
but
at
the
same
time
users
are
asking
for
something
different
than
what
we
have
today.
A
So
if
we
don't
start
planning
and
thinking
about
it
now
and
a
few
more
months
once
Aaron's
fixed
all
the
test
flakes,
then
then
we
won't
be
ready
to
solve
this
problem
next
right,
so
so
I
guess
I'm
kind
of
here
is
tribute
to
start
driving
these
conversations
a
little
more
formally
in
the
community
and
I
work
at
VMware.
We
have
an
interest
in
this.
We
have
users
who
want
support.
A
Obviously
our
customer
base
is
used
to
that
much
more
traditional
type
of
long-term
support,
but
then
we
have
to
help
figure
out
how
we
balance
that
versus
what
they
want
and
what
the
community
is
doing
and
then
contribute
to
it.
So
I'm,
not
just
here
to
get
flamed
and
raw
vegetables
turn
at
me.
I
actually
have
a
desire
to
see
something
constructive
here
and
I.
Have
my
personal
biases
as
well
so
I'm
gonna
try
to
be
a
moderator
in
discussion
today,
but
I
will
also
probably
express
opinions,
not
necessarily
VMware's
opinions.
A
Personal
engineer
ones
is
I
hope.
All
of
you
do
that
we
do
this
with
an
open
mind
for
how
we
manage
these
complexities.
So
the
first
thing,
then,
to
mention
or
the
last
thing
that
I'll
mention
is:
where
are
we
so
we've
we've
had
some
initial
discussions
about
this
we've
gotten
agreement
that,
yes,
a
working
group,
makes
sense
to
do
for
this.
We've
put
up
a
PR
there's
what
for
the
the
chairs
or
leads
whatever
you
call
them
now
for
working
group
organizers.
A
What
we,
what
we
think
of
is
roughly
a
reasonable
mission
for
this
group
is
out
there,
it's
more
or
less
ready.
We
think
for
steering
to
review
and
sign
off
on
so
I'd
encourage
you
all
to
take
a
look
at
that
comment,
if
you
think
otherwise,
let's
fix
it,
let's
iterate
otherwise,
lgt
I'm
also
would
be
awesome
just
to
make
it
clear
that
people
are
thinking
about
that
and
then
what
kind
of
going
back
to
my
comment
about
keeping
an
open
mind
and
trying
to
understand
what
we
might
do
differently.
A
We
need
to
figure
out
the
path,
so
that
is
out
there.
We'd
love
more
involvement,
shaping
that
we'd
like
to
kind
of
get
it
nailed
down
a
little
more
in
the
coming
weeks
and
start
getting
it
out
there
for
specific
feedback
and
then
finally,
so
closer
life
cycle
also
has
a
survey
out.
Similarly-
and
it
has
some
questions
that
touch
on
this
area
as
well,
I
think,
like
Tim
mentioned
earlier
in
the
contribs
of
the
between
cig
release,
cig
testing
cluster
lifecycle,
the
operational
reality
of
this
day-to-day
is
them
is
cluster
life
cycle.
A
So,
even
if
we
didn't
have
this
working
group,
they
would
be
struggling
through
some
of
these
things
on
their
own
and
I.
Think
if
we
can
bring
in
other
SIG's
and
more
perspectives.
Hopefully
we
can
can
do
something
better
as
a
community,
so
I'd
encourage
you
guys
to
get
involved
in
providing
input
to
the
existing
surveys.
Helping
draft
the
other
survey,
the
Charter
and
then
I
wanted
to
kind
of
open
things
up
to
conversations
about
where
people
think
we
should
head,
because
the
Charter
isn't
quite
merged
yet
right.
B
Think,
like
Jordan,
for
example,
gave
a
great
thesis
for
why
this
we
do
not
want
to
slow
down
that
particular
velocity
because
to
roll
out
API
changes
in
way
that
are
non
disruptive
to
end-users
and
allow
both
forwards
and
backwards
migration.
You
actually
have
to
do
this
across
three
different
releases
or
three
different
versions,
and
if
we're
at.
B
A
minimum,
and
if
we
reduce
that
cadence
that's
going
to
make
it
extraordinarily
painful
to
roll
out
new
features
that
rely
on
new
API
fields
there.
You
could
potentially
argue
that
maybe
we
should
drop
the
one
from
kubernetes,
1.14,
zero
and
just
say
the
fourth.
What
we
now
call
the
minor
version
is
actually
the
major
version
and
that's
the
thing
that
we
are
committed
to
supporting
a
little
more
long
term,
because
today
we
talk
about
patch
releases
like
1.13
dot.
B
One
will
be
the
actual
release
of
one
thirteen
that
everybody
will
use,
because
that's
the
patch
release
that
fixes
all
the
bugs.
But
historically
those
haven't
been
patch
releases.
Regressions
have
snuck
in
and
things
that
are
more
than
just
bug
fixes
have
also
snuck
in.
Maybe
we
should
call
those
what
those
are
which
are
minor
releases
anyway.
I
just
want
to
throw
that
as
I.
Think.
That's
the
other.
The
complete
other
end
of
the
spectrum
from
LTS
is
there
should
be
no
such
thing
as
LTS.
A
C
Think
one
of
the
things
that
I
didn't
write
up
in
my
proposal
and
I
promised
to
you
and
other
group
that,
like
other
systems,
have
had
this
problem
before
this
is
not
a
unique
set
of
problems.
They
have
solved
it
in
in
by
having
like
two
streams
by
having
a
development,
stable
series
right
and
because
the
unique
requirements
have
a
lot
of
people
that
are
in
the
wild.
C
They
only
have
a
certain
limited
outage
window
to
protect
them
to
do
upgrades
and
like
history
on
open
shift
and
history
at
hefty
o
has,
you
know,
had
made
me
very
empathetic
to
their
situation.
You
know
these
are.
These
are
readers
who,
once
they
get
it
qualified
they're
too
busy
trying
to
like
just
make
sure
that
the
world
doesn't
light
on
fire
right
and
they
only
have
an
outage
window
of
maybe
like
a
day
a
quarter
at
best
right
to
actually
get
an
upgrade
in.
D
Except
I
think
I
should
add
just
on
that
that
kubernetes
is
a
bit
different.
This
is
not
a
kernel
that
you
have
to
reboot
with
an
outage
window.
In
order
to
upgrade
this
is
we've
built
a
thing.
That's
meant
to
be
high
availability
you're
meant
to
be
able
to
do
upgrades
without
downtime,
with
zero
downtime
much
a
small
downtime,
which
is
a
little
special
in
the
in
the
scheme
of
computer
science
history.
A
D
E
E
E
Several
minor
upgrades
at
the
end
of
it
and
catching
up
through
the
same
path
that
the
other
channel
went,
or
we
build
the
real
migration
tools
to
spin
up
a
new
cluster
and
migrate
existing
workloads
from
the
end
of
that
LT
to
the
next
one
of
those
I
think
those
are
possibilities.
There
are
likely
lots
more,
but
that's
the
thing
that
I
immediately
jump
to
when
we
talk
about
LTS
is
what
happens
at
the
end
I
think
more
fundamentally,
before
I
go
up
that
mic.
E
I
think
it's
disingenuous
of
us
as
a
community
to
suggest
to
enterprises
that
they
can
containerize
all
of
their
running
legacy
workloads
and
get
it
just
right
and
then
not
touch
it
anymore
and
I
think.
The
really
hard
problem
is
that
this
is
fundamentally
different
way
to
run
software,
and
even
those
of
us
in
this
room
who
own
all
of
the
pieces
are
not
in
control
of
all
of
the
pieces.
These
systems
continuously
evolve
continuously
change
the
infrastructure
that
we
run
on
and
assume
within
Google.
We
do
live
migrations
of
vm's.
E
E
Can
we
pull
the
ultimate
COO
and
say
one
dot?
X
is
the
stable
LTS
and
each
one
of
those
miner
is
a
what
do
they
call
it?
A
patch
patch
release?
No,
but
it's
a
security
patch.
That
said,
what
did
what
is
Windows
call
it?
They
have
a
service
pack.
There
you
go
it's
a
service
pack
and
then
the
auditors-
and
this
is
a
really
critical
one
to
work
out-
is
that
these
enterprises
have
have
to
go
through
compliance
auditing
and
we
can't
blow
that
for
them.
So
those
are
some
thoughts.
G
F
A
solution
that
gets
compromised,
user
users
usually
can't
upgrade
for
reasons,
and
usually
users
wants
to
have
clusters
that
gets
patched.
So
maybe
we
can
have
an
LTS
that
actually
says
like
okay,
this
version
will
get
all
the
cherry
picks
and
all
the
patches
in
it,
but
just
the
patches,
nothing
more.
This
might
be
an
idea
of
an
LTS
just
a
version
of
kubernetes
that
gets
patched
against
vulnerabilities
on
bugs
that's.
A
This
is
critical
urgent
who
are?
We
is
non
subject
matter,
experts
to
say
no,
unless
it's
very
obvious,
but
the
is
a
huge
gray
area
where
I
mean
even
just
this
week
as
we're
planning
one,
not
13:1
a
lot
of
the
stuff
going
by
we're
like
we'd,
rather
not
take
that.
But
it's
in
the
cluster
subdirectory
and
it's
clearly
needed
for
them
and
it's
a
mess.
D
D
H
Just
just
for
a
data
point
you
know:
I
have
a
cube
or
a
nice
cluster.
That's
112!
Api
server
and
I've
got
110
nodes
that
I
haven't
been
able
to
upgrade
yet
because
I
have
to
roll
all
the
workload
forward
to
another
node
first,
because
it
won't
do
an
in-place
upgrade.
But
I've
got
Singleton's
that
if
I
actually
roll
them,
then
I'll
take
a
downtime
and
the
particular
service
isn't
really
it.
H
I
J
C
C
E
But
I
think
the
the
essence
of
what
Phil's
getting
at
is
then
you're,
essentially
having
a
requirement
on
all
participants
in
the
kubernetes
ecosystem
to
also
support
this
LTS
version
and
a
head
or
de
velde
bert
well,
I
mean
somehow
right
if
you're
clinging
to
an
enterprise,
that
this
is
the
stable
version
of
kubernetes.
And
it's
somehow
is.
A
Have
something
that's
cohesive,
whether
that
truly
requires
Curran?
It
is
a
net
CD
and
every
every
everything
to
all
declare
that
today's
release
is
LTS
across
all
of
these,
so
that
we
all
have
LTS
is
I,
mean
I,
don't
think
that's
not
the
case
with
Linux
distros
today,
like
that,
doesn't
happen,
but
the
advantage
that
they
have
I
feel
like
even
going
pretty
far
back
in
the
history
of
Linux
is
that
things
were
already
more
stable
across
these
components
we
have.
A
So
it's
easy
to
see
it
becoming
a
distribution
model
about
how
like
I,
I,
wouldn't
those
distributors
on
a
lot
of
days,
because
it's
integration
as
hard
and
all
of
these
things
are
moving
it
really
varying
states
and
you're,
not
just
gonna,
be
able
to
declare
all
of
cloud
native
is
LTS
for
today
and
we're
gonna
integrate
that
all
of
us
will
integrate
that
one
somehow
so
kubernetes.
If
it
does,
something
would
be
probably
largely
doing
it
on
its
own
I.
Think
yeah.
J
C
I
think
this,
what
we
need
this
group
needs
to
decide
right.
So
then,
one
of
the
things
I
wanted
to
mention
too,
is
that
I
think
you
can
still
move
fast
and
move
slow
right.
The
this
is
not
a
unique
model,
but
if
you
have
a
develop
stream
that
released
every
single
month,
it
actually
got
beta
testers.
This
is
the
way
other
configuration
or
cluster
management
systems
actually
work.
C
The
heav'n
Tavella
type
people
who
want
to
bleed
on
the
edge
install
it
as
developers
in
the
wild
right,
because
no
one
I
mean
no
one
installs
a
beta
release
of
kubernetes
like
absolutely
no
one.
But
if
you
had
to
develop
stream
that
was
being
published,
they
would
actually
try
and
test
it
out.
Then
you
have
a
stable
series.
Every
time
window
of
X
devel
becomes
stable
through
some
hardening
path
right
and
then,
which
you
could
define
all
right.
B
I,
first
off
two
walls
waiting
for
Mike
behind
you,
but
before
that
like,
why
isn't
anybody
using
a
release
of
kubernetes
that
has
cut
every
two
weeks
because
we
actually
do
publish
builds
of
kubernetes
every
two
weeks?
First
they're
tagged
as
alpha
and
then
they're
tagged
as
beta
right,
everyone's
raising
their
hint
I
suspect.
I,
wonder
if
part
of
it
is
that
we
don't
build
depths
or
rpms
wait,
that'd
be
part
of
it,
yeah
right
so
so
so,
hang
on
so
part
of
that
I
think
is
there's
a
there's.
B
I
have
heard
some
people
within
the
project
say
that
that
is
a
boundary
that
maybe
the
kubernetes
project
should
not
cross
is
that
we
should
provide
the
binaries,
but,
for
example,
Debian
is
responsible
for
packaging
all
of
their
own
Deb's
that
work
with
them
right.
Why
wouldn't
we
look
to
Debian
to
actually
do
downstream
builds
because
it
seems
like
what
they
wanted?
Was
they
didn't
our
experience?
In
the
last
time
we
had
a
Debian
maintainer.
You
want
to
talk
to
Christoph
Blocher
about
this.
B
G
J
B
Kind
of
have
to
take
responsibility
for
the
sanctity
of
all
of
our
own
dependencies
right.
We
were
just
talking
about
security
threats
from
vendor
today,
like
we
have
to
take
ownership
of
that,
we
can't
rely
on
downstream
distributors
to
take
ownership
of
that
so
like.
How
do
we
bridge
that
particular
gap?
To
me,
it
seems,
like
we
say,
look
we'll
provide
you
a
binary
and
then
it's
up
to
you
to
provide
the
packing
of
a
Deb
or.
C
I
think
this
is
just
a
release,
tooling
problem,
it's
not
hard
and
it's
solved
for
almost
every
single
distribution
provider
that
exists
if
they
just
have
streams
right
and
if
your
binary
FX
includes
the
ability
to
install
those
artifacts
whatever
they
may
be
like.
If
there
are
PMS
or
Deb's,
or
you
know
some
Byzantine
MSI
installer.
If
you're
really
cared
to
do
that,
then
then
you
could
do
that,
but
you
just
need
a
regular
stream
and
a
cadence.
M
K
So
I
when
I
mean
ma'am
double
I
work
at
VMI,
I'm,
an
engineer
at
VMware
and
I
was
a
co-chair
for
this
working
group.
I
wanted
to
mention
one
thing
that
Tim
had
brought
in
the
distributors,
so
is
anybody
here,
packaging,
an
application
and
releasing
it
as
a
software
on
kubernetes,
because
for
them
I've
heard
some
people
who
do
that
and
for
them
this
release?
Cadence
was
I,
mean
hard
issues
that
the
that
they
had.
So
they
could
explain.
K
K
D
D
D
The
main
issue
we
have
is
yeah
I
mean
very
much
that
the
main
issue
we
have
is
things
like
client
go
like
you
can
use
a
client
go
from
four
versions
ago
and
it'll
work
against
those
API
groups
from
four
versions
ago,
except
for
authentication
plugins.
Every
time
you
turn
around
is
yet
another
authentication
plug-in
burnt
into
client
go
and
then
along
comes
you
KS
and
suddenly
you
have
to
upgrade.
All
of
your
client
goes
just
to
embed
the
eks
authentication
plugin.
K
D
We
just
say
it's
got
to
be:
we
say
which
versions
of
Cuba
Natives
we
let
it
run
on.
We
test
it
against
and
then
I'm
trying
to
think
how
that
restructured,
and
then
we
because
we
don't
provide
support
for
the
kubernetes
underneath
right.
So
if
they
want
to
support
a
kubernetes
or
whatever,
then
they've
got
to
stay
within
the
support
window
for
companies
themselves.
That's
that's
their
problem,
not
ours.
N
N
Yes,
so
like
actually
getting
the
api's
to
that
state
is
not
just
like
well
we'll
rename
them
and
call
them.
V1
like
some
of
them
are
maybe
close
to
that.
Some
of
them
still
have
like
scale,
testing
and
and
other
issues
like
that
to
work
through.
But
then
you
said,
the
state
believe
you
guys
don't
break,
and
everybody
laughed
and,
in
addition
to
getting
ap,
has
two
stable.
H
If
a
lot
of
applications
need
unstable
api's
in
order
to
actually
deploy
properly,
if
we
go
and
make
an
LTS
before
those
things
are
stabilized,
then
it
will
be
harder
for
applications
developers
to
generally
target
the
kubernetes
community,
because
they'll
there
won't
have
the
functionality
stabilized
yet.
So
there
is
a
slight
risk
of
LTS
in
too
soon.
O
So
hi
everyone
I'm
Nick
young
I'm
from
adolescent
on
there,
so,
okay,
yet
so
I'm
also
doing
the
there
are
the
mic
and
the
mic
stuff
I'm.
Just
in
the
interest
of
time
does
it
do
other
people?
Is
everyone
commenting
on
this
or
do
other
people
have
other
things
to
raise?
Justin
you
got
anything
yeah,
okay,
cool.
So
who
else
wants
to
comment
on
this?
I
just
want
to
get
an
idea
of
how
much
longer
we
have
cuz
yeah.
We
need
to
keep
moving
Bob.
O
H
P
I
The
discussion
has
clearly
taken
a
veer
towards
early,
really
early
and
better
release,
as
opposed
to
LTS
and
I.
Understand
that
there's
some
linkage
between
the
two
but
can
can
someone
take
a
crack
at
explaining?
What's
the
difference
between
LTS
and
expanding
our
current
version,
support
from
three
to
four
to
five
releases
I
mean
this
seems
like
a
fairly
simple
thing
to
me.
So.
I
N
I
E
If
we
extend
to
five
releases
right
instead
of
three,
then
it's
possible
to
stay
on
a
routes
supported
release
for
the
duration
of
whatever
that
calendar
time
is
right,
but
then
the
question
becomes.
If
we
agree
that
you
can't
skip
versions
which
I
challenge,
anyone
to
prove
that
it's
possible
to
skip
versions
and
be
safe,
so
I
agree
assume
that
we
cannot
skip
versions,
then
at
least
and
be
smart
enterprise.
E
Customers
have
a
turbulence
threshold
or
appetite
that
would
lead
me
to
believe
that
they
will
upgrade
only
one
version,
and
then
they
have
the
exact
same
cadence
of
upgrades
just
far
behind.
So
maybe
I've
I've
thought
this
through
as
much
as
I
can.
Maybe
we
can
bundle
it
together,
so
it
appears
to
be
one
upgrade
across
multiple
versions
and
we
just
packaged
up
real
nice.
E
So
it
feels
like
one
upgrade,
but
it's
really
lots
I
worried
across
tens
of
thousands
of
clusters
that
that
goes
awry
in
interesting
ways
across
those
number
of
clusters,
but
that's
one
way
or
we
have
actual
migration
tooling.
That
means
you
spin
up
a
new
cluster
at
the
most
recent
stable
version
and
you
migrate.
Workloads
across
them
that
I
also
have
a
really
hard
time,
believing
that
will
work
at
scale.
Sorry.
I
I'll
go
ahead
if
it
were
if
it
were
my
system,
so
if
I
would
say
couple
of
principles
here,
one
principle
I
think
and
if
maybe
we
should
set
some
of
these
principles
as
a
way
to
try
to
clarify
things
that
kind
of
upgrade
I
think
should
only.
We
should
only
try
to
support
it
in
the
context
of
automated
pipelines.
Doing
this
kind
of
testing,
in
which
case
the
skip
upgrade
path,
is
not
well.
First
of
all
it
really.
I
It
doesn't
have
to
take
that
long
to
do
two
versions,
but
what
it
does
is
it
reduces
the
test
matrix
that
everybody
has
to
do.
In
any
case,
you
could
always
upgrade
upgrade
and
then
run
your
application
testing.
On
top,
so
I
don't
actually
think
the
skip
level
thing
is
as
big
a
barrier
to
these
enterprises
like
when
they
want
to
take
their
painful
like
window
to
do
the
upgrade
yeah.
I
N
Sorry,
the
question
about
certification,
if,
as
part
of
upgrading
from
one
dot
X
to
1
dot,
X
+5
means
that
you
run
four
versions
in
between.
It
would
be
good
to
get
feedback
from
companies
and
customers
and
environments
that
do
need
to
only
run
certified
versions.
Does
that
mean
they
have
to
get
five
individual
versions
certified?
Because
at
any
given
point
in
time
they
are
running
every
single
one
of
those
intermediate
versions?
That's
a
question
about
the
Skip
level.
Things.
I
I
Of
qualifying
a
release
through
your
CI
NCT
process
that
you
would
do
a
double
upgrade
before
you
did
the
deployment
so
for
the
the
use
case
that
I'm,
you
know,
sort
of
advocating
here,
at
least
as
a
thought
experiment.
You
wouldn't
put
the
enterprise
in
that
in
that
multi
version
certification
case,
because
that's
gonna
be
the
production
case.
The
production
use
case,
not
the
upgrade
in
staging
use
case.
O
N
Q
I,
do
have
one
point
on
this
and
that's
so
I
work
with
a
lot
of
regulated
industries
by
the
way
hi
I'm
Noah
I'm,
with
info
center
working
with
defense
working
with
casinos
working
with
a
handful
of
very
tightly
regulated
industries.
They
may
not
be
able
to
do
the
individual
versions
that
are
in
between,
because
if
they
have
to
use
a
particular
version,
it
has
to
go
through
regulatory
approval
and
then
they
have
to
sit
there
and
wait
for
six
to
nine
months
to
be
able
to
get
that
version
to
go
through
that
upgrade
step.
D
Any
other
upgrader
has
some
indeterminate
state
in
between
going
from
windows
version
six
to
seven,
even
though
they
were
both
certified
halfway
through
the
upgrade.
When
you
only
had
some
of
the
bits
on
the
disk
and
the
other
bits
were
still
being
loaded
off
the
city
wrong.
You
didn't
certified
that
situation
right,
so
you
could
bunk
on
that.
I
am,
but
you
could
bundle
it
up
in
a
nice
upgrade
tool
so
that
they
never
thought
about
the
intermediate
states.
Yes,.
D
L
C
Think
the
answer
is
all
of
them.
That's
the
problem
right.
It
is
literally
in
every
single
industry,
so
saying
trying
to
take
preferential
treatment
versus
a
versus
B
is
SuperDuper
hard,
and
that's
part
of
the
reason
why
we
have
the
Tim
started
to
survey
is
because
trying
to
gather
the
signal
through
the
noise,
but
I
guarantee
you
from
what
I've
experienced
firsthand
across
a
number
of
different
companies.
I
work
for
is
that
it's
every
industry
and
the
requirements
are
wildly
different.
F
Our
releases
is
basically
at
the
end,
so
we
get
some
tests
that
are
broken.
Things
like
that,
so
I
think
that
if
we
stabilize
our
our
CI
process
our
tests,
our
code
and
if
we
release
often
then
yes,
users
might
want
to
try
these
binaries
because
last
time
I
wanted
to
try
these.
These
are
these
pre
releases
or
release
candidates
on
some
development
environments.
It
totally
like
you,
it
didn't.
B
B
O
O
M
M
I,
wonder
whether
we
shouldn't,
rather
than
trying
to
solve
the
perfect
problem,
let's
at
least
try
and
be
as
good
as
what
are
considered
to
be
reasonably
decent,
upgrade
paths
that
exists
out
there
at
the
moment
there
are
you
know:
Microsoft
has
been
doing
this
stuff
across
desktops
for
many
many
years,
Amazon's
got
internal
stuff,
I'm
sure
there
are
problems
with
many
of
these
things,
but
you
know
maybe
a
first
step
is
to
be
no
worse
than
those
Oracle's
been
upgrading
databases,
IBM's
been
upgrading
mainframes,
and
these
are.
This
is
a
well-trodden
path.
O
R
It
was
actually
something
that
Django
said
a
while
ago
about
the
idea
that
we
could
sort
of
persuade
customers
that
the
new
version
was
not
different
and
it
brought
into
my
mind
the
idea
that
you
know
we've
talked
about
about
our
API
versioning,
but
this
means
that
we
essentially
have
to
keep
our
feature
set
more
or
less
the
same.
We
can't
upgrade
core
DNS.
R
We
can't
upgrade
to
IPS,
we
can't
upgrade
docker
and
whether
we
call
it
the
LTS,
where
we
add
security
releases
to
an
older
version,
is
a
way
of
implementing
that,
as
would
be
a
long-term
stream.
Where
we
say
we
will
support
this
feature
set
and
will
not
deprecated
it
for
a
longer
period
than
our
current
application
period,
whether
it's
two
years
or
something
like
that
and
I,
don't
know
whether
that
would
help
the
problem
and
I.
O
I'm
gonna
be
using
my
mic
privileges
now
to
talk
so
the
my
feeling,
my
feeling
there's
later
yeah.
That's
what
Jordan
was
saying
before,
like
that
you
move
the
api's
to
stable
and
once
they're
stable.
Then
you
have
that
that's
the
gap
that
is
literally
the
guarantee
of
a
stable
API
of
a
ga
API
is
that
it
doesn't
change
anymore.
So.
A
There's
been
a
lot
of
discussion
on
what
should
be
conformance,
testing
I
feel
like
those
kind
of
dovetail
a
bit.
How
are
people
getting
more
comfortable
I
know,
there's
been
a
lot
of
conversation
about
conformance
again,
it's
one
of
those
places
where
you
need
hands
on
deck,
but
and
going
up
back,
maybe
to
the
earlier
comment
like
I
I,
really
doubt
anybody
is
saying
that
we're
ready
to
make
an
LCS
now,
like
too
soon
I,
don't
think,
is
actually
a
problem.
A
I
think
we're
all
pretty
much
agreeing
that
now
is
clearly
too
soon,
but
sometime
in
the
future,
maybe
we're
in
to
a
better
place.
But
that's
what
that's
why
we
started
talking
about
it
now,
I
think,
but
do
people
feel
like
we
could
achieve
that
in
6,
9
18
months
like
where
would
where
would
people
throw
a
number
out
on
how
much
work
our
current
community,
with
its
pace
of
things,
would
take
I.
S
Think
the
answer
to
that
is,
we
need
a
checklist
on
what
are
the
things
that
we
need
to
do
to
get
ready
for
an
LDS
and
when
we
check
them
off,
then
we
are
ready.
That's
the
time
when
we
would
do
the
first
one
and
what
Jordan
said
was
like
item
number
one
on
the
checklist.
So
but
there
are
some
other
things
that
we
need
to
do
as
well,
including
making
sure
that
you
know
the
release
process.
Artifacts,
signing
things
like
that
have
to
be
lined
up
as
well.
So
once
that
is
done,
I
mean.
S
If
you
want
me
to
name
a
time.
It
would
take
at
least
six
months
to
nine
months
if
a
lot
of
people
in
this
room
are
willing
to
help.
That's
part
of
the
usual
problem
that
we
have,
where
you
know,
people
who
want
a
lot
of
stuff,
but
then
we
need
to
coordinate
the
work
and
we
need
to
make
sure
that
everybody
can
show
up
and
we
have
a
role
for
them
and
we
we
know
what
we
need
from
them.
I.
I
Let
me
let
me
try
to
take
a
little
bit
different
perspective
on
this,
so
I
think
the
status
quo
is
really
horrible
and
miserable
companies
move
too
slow.
One
of
the
reasons
why
kubernetes-
and
in
fact
the
containerization
in
general,
has
been
adopted
as
vigorously
as
it
has
been
as
companies,
including
all
these
companies
a
lot
of
older
school
IT
companies
that
are
that
I'll
say
they
think
they
want
LTS.
I
I
Their
practices
understand
what
it
means
to
live
in
this
kind
of
cloud
native
immutable
pipeline
driven
way
and
as
a
community
I
really
feel
like
if
we
can't
help
our
user
community
adopt
that
way
of
working
as
opposed
to
falling
into
the
habits
that
got
them
into
the
trouble
that
they
were
in.
To
begin
with,
we'll
eventually,
like
you,
know,
we'll
eventually
sort
of
collapse
back
into
something.
That's
waiting
for
the
next
system
to
come
along
I
know.
That's
that's
super
philosophical,
but
something
I
know
that
we're
very
passionate
about
thanks.
N
Tim
is
like
itching
for
the
mic:
it's
like
a
reflex
I'll,
give
it
to
you
in
just
a
second
ight
I
agree
with
that
I
the
the
questions
that
Justin
raised
about,
like
what
versions
of
docker
what
versions
of
ICD
we've
switched
to
core
DNS.
All
of
those
are
like
those
speak
to
us
and
we
speak
to
them
through
api's
I.
Think
it's
all
about
what
API
is.
Do
we
test
the
conformance
tests
that
we
have
so
I
talked
about?
Rest
API
is
like
the
the
things
that
people
are.
Writing
manifests
for.
N
That
is
one
dimension.
We
have
three
dimensions
of
API,
so
we
have
the
REST
API.
Is
we
have
the
config
api's
which
we're
trying
to
get
flags
into,
and
then
we
have.
The
back-end
API
is
like
CNIC,
RI
CSI,
so
many
seasoned
eyes,
and
if
we
think
in
terms
of
API
is
how
users
speak
to
the
API
server,
how
you
configure
those
components
and
how
they
shell
out
to
show.
N
How
they
call
out
to
the
backends
those
things
we
can
actually
test
those
things
we
can
actually
get
to
stable
and
keep
stable
and
I.
Think
that
is
I
said
stabilize
our
priority.
One
in
my
mind,
that's
all
three
of
those
areas.
The
rest
api
is
are
the
most
invisible,
but
the
other
two,
I
think,
would
put
us
in
a
much
better
place
going
forward.
So
we
can
promise
if
your
container
runtime
supports
this
version
of
the
CRI.
We
test
that
and
we
work
with
them
all
right.
G
N
C
While
you're
passing
the
mic
so
called,
this
is
a
cultural
problem,
not
a
technological
or
strategy
problem.
So
the
the
problem
is
culture
like
Sarah,
famously
quoted
like
in
coop
con,
then
Austin
is
culture
eats
strategy
for
breakfast
right,
so
the
problem
is
changing.
Culture
is
SuperDuper
hard
and
I.
Don't
exactly
know
how
you
do
that
I?
Don't
think
anyone
does,
but
in
order
for
us
to
do
that,
we
need
to
live
the
mantra
that
we
are
trying
to
espouse
and
making
tests
actually
be
passing
in
green.
C
P
D
O
So
sorry,
just
to
jump
in
there
for
a
second
I'm
part
of
the
reason
that
you
know
that
the
other
guys
asked
me
to
be
one
of
the
coaches.
Is
that
that's
me,
like
I,
am
an
operator
I,
don't
write
a
lot
of
code
I'll
make
you
project.
I
am
here
to
represent
all
of
those
people,
but
that
isn't
that
is
literally
my
job
as
in
this
in
this
working
group,
is
to
be
the
guy
who's
like.
But
what
about
the
end?
Users.
E
I
just
wanted
to
suggest
that
it's
interesting
that
cube
con
happens
in
or
Cuba
in
North
America
as
a
December
event.
It's
interesting
because
retail
customers
are
typically
in
their
freeze
period
and
we
ourselves,
as
providers,
are
often
in
our
own
freeze
periods
and
the
trend
that
I
see
and
see
continuing
is
that
large
enterprises
tend
to
hold
off
on
a
lot
of
upgrades
towards
the
end
of
the
year
and
what
we
and
JE
are
in
a
position
where
we
will
do
multiple
sort
of
faster
upgrades
through
the
beginning
part
of
the
year.
E
And
so
maybe
we
can
use
this
as
a
learning
experience
to
inform
the
multiple,
faster
upgrades
over
a
short
period
of
time
and
trend
in
that
direction.
Such
that
at
least
the
support
window
stretches
so
that
what
is
in
production
for
many
enterprise
customers
is
still
security
scanned
and
patched,
and
we
go
back
a
little
bit.
I,
don't
know
if
that's
a
dangerous
precedent
to
set,
but
it
may
be
a
way
to
gain
some
incremental
knowledge.
K
So
I
think
I
hear
different.
You
know
whenever
you
start
a
topic,
I
mean
there
sometimes
are
get
into
solution.
Someone
describes
a
problem,
so
I
think
a
survey
that
we
have
is
trying
to
cover
questions
that
will
get
us
the
list
of
problems
that
we
want
to
solve.
Tim's
question:
Tim
pepper.
There
are
too
many
teams
in
the
room
said
Tim
Peppers
question
was
how
much
time
you
know
can
we
solve
this
problem?
K
I
mean
the
first
thing
is
we
need
to
start
defining
the
problems
and
a
list
we
want
to
solve
and
then
build
the
checklist
as
Tim's
mentioned,
to
say
that
okay,
these
are
the
things
that
we
need
to
solve
those
problems
and
if
you
start
looking
at
okay,
first
problem
solved
with
these
three
things:
testing
these
three
things
in
a
checklist,
salt,
so
I
think
a
systematic
approach.
There
would
help
and
the
survey
it's
trying
to
collect
that
information
and
that
link
that
you're
sees
of
a
doc.
K
A
Pull
that
back
up,
so
the
reason
I
asked
the
time
was
because
I
wanted
people
to
leave
here,
not
just
having
had
this
awesome
wide
open
conversation,
but
to
think
about
we're
talking
about
something
for
a
better
future
right.
But
when
could
that
be,
and
we
could
we
can
be
here
again
next
year,
talking
about
we're
having
this
same
conversation
but
I
feel
like
without
something
for
a
concrete
goal.
So
getting
the
survey
out
starting
to
develop
the
criteria.
A
Thinking
about
doing
that
sort
of
this
quarter
next
quarter
having
the
next
level,
then
more
robust
conversation
about
it,
a
coupon
in
the
spring
trying
to
drive
towards
concrete
actions
to
achieve
things
on
a
timeline
without
saying
like
hey,
we
would
like
to
be
in
a
better
place,
whatever
it
turns
out
to
be.
Maybe
multiple
prongs
to
it
as
well.
But
could
we
end
next
year
at
cube,
Kahn
saying
we've
actually
moved
the
needle
on
this
stuff
yeah?
A
H
So
for
my
some
of
my
own
applications,
I've
got
two
holes
in
the
kubernetes
api
that
I'm
working
on
trying
to
finally
get
solved
in
114,
which
means
they'll
be
elfin,
114
and
they'll
be
beta
in
115,
which
means
it
needs
to
be
LTS
at
least
16
right,
there's
a
long
tail
on
getting
stuff
through
the
API
process.
So
a
year.
B
O
Think
to
have
that
is
super
important
to
emphasize
that
this
is
not
a
working
group
to
make
an
LTS.
This
is
a
working
group
to
be
like.
Do
we
even
want
an
LTS
and
what
the
hell
is
an
LTS
and
a
whole
bunch
of
other
questions?
It's
just
much
shorter
to
write,
wgr
TS,
then
a
20
letter
acronym
right,
like
yeah,
so.
B
This
is
somewhat
reminiscent
of
when
we
all
got
in
a
room
about
a
year
and
a
half
to
two
years
ago
and
said
you
know
what
this
is
the
year
of
making
kubernetes
stay
mission
accomplished
right.
So
that
said,
I
feel,
like
we
have
said
some
very
discreet,
accomplishable
things
in
this
room
to
me.
Jordan
stake
in
the
ground
of
we
need
to
move
for
the
api's
that
people
are
actually
using
to
make
their
real
applications
to
stable
is
the
goal
is
a
great
goalpost.
B
I
feel
like
a
year
is
roughly
speaking,
going
to
get
us
some
appreciable
level
of
functionality.
I,
don't
know
if
it's
going
to
be
a
hundred
percent,
but
it's
going
to
be
very
close.
I
also
personally
want
to
put
a
stake
in
the
ground
for
like
what
can
we
accomplish
in
the
next
quarter
in
terms
of
making
it
easier
to
exercise
releases,
or
how
can
we
consider
making
upgrades
easier
part
of
that
might
be,
for
example,
using
the
kept
process
that
was
described
earlier
and
will
be
talked
about
in
the
conference.
B
We're
like
for
everything
that's
going
to
land
in
kubernetes
can
I
make
sure.
There's
actually
a
written
documented
plan
that
talks
about
what
the
upgrade
path
is
and
what
the
downgrade
path
is
and
that
the
end
user
has
actually
been
kept
in
mind,
because
I
don't
see
that
when
I
don't
see
that
a
company
releases
until
like
the
very
end
and
I
want
a
lot
of
thought
to
be
put
into
that
at
the
very
front,
so
that
the
release
team
isn't
scrambling
to
try
and
figure.
All
of
this
out.
B
The
people
who
have
the
technical
knowledge
on
these
features
have
considered
it
up
front
and
so
I
think
all
of
the
oh
and
finally,
could
we
please
actually
maybe
cut
one
release
of
kubernetes
where
all
of
the
tests
have
passed?
That
would
be
great,
I
mean
yeah,
so
so
I
just
I
call
all
this
out.
I
saw
him
writing
them
down,
like
I
think
we
should
aspire
to
at
least
that
all
of
those
things
are
accomplishable
by
the
people
in.
O
This
room-
yes,
we're
currently
five
minutes
over
time,
so
we
are
cutting
into
your
break
time.
So
I
really
appreciate
all
the
feedback,
but
the
survey
is
the
place
for
the
feedback.
Please
please
help
us
with
that
help
us
with
the
questions.
Once
the
questions
are
done
answer.
The
survey
like
all
of
this
stuff
has
been
awesome,
but
if
it's
not
going
to
be
ended
up
running
down,
then
we
won't
remember.