►
From YouTube: Kubernetes WG LTS 20181113
A
A
Well,
I
guess!
So
that's
why
we're
a
couple
of
minutes
past
the
start
of
the
hour
we
may
as
well
get
going.
This
is
probably
our
initial
set
of
folks
and
we're
liable
to
have
a
fairly
small
number
of
people
just
because
we
haven't
done
a
whole
lot
of
advertising,
we're
just
trying
to
initially
get
off
the
ground
here.
So
we
may
as
well
just
get
started.
A
Initially,
we
were
figuring
that
we'd
do
a
round
of
introduction,
so
I
guess
I
can
start
just
I'm
talking
and
it
says
I'm
the
host,
so
I'm,
Tim
pepper.
It
says
work
group
LTS
on
sick,
but
I'm,
Tim,
pepper,
I,
work
for
a
VMware
and
I
partly
have
an
interest
in
this
topic
because,
as
the
112
release
team
lead
and
working
in
cig
release
on
and
off
this
year,
I've
really
come
to
feel
that
the
project's
got
a
weakness,
I
guess
in
the
release
engineering
side
it
was
a
constant
struggle
on
each
of
the
releases.
A
I've
been
involved
with
to
figure
out
whether
the
artifacts
we
were
building
were
correct
and
good
and
making
sure
that
they
were
consumable
by
cube
adium
and
others
and
upgrade
was
a
constant
problem
during
the
release
and
just
from
that
perspective,
it
had
me
realizing
like
well.
What
do
customers
experience
then
and
trying
to
think
about
what
we
could
do
to
improve
the
situation
and
and
from
that
context,
not
necessarily
LTS
specific
I
know
that
the
LT
s
term
is
controversial
in
many
parts
of
the
project.
A
E
A
A
So
with
my
ĂȘtre
there
Nick
Young
next
on
the
list,
sure.
C
I
am
Nick
Young
I'm
working
at
last
in
kubernetes
team.
My
interest
in
this
area
is,
as
user
we've
been
users
of
this
community's
for
three
years
now,
so
we've
done
quite
a
lot
of
releases
in
that
time.
Personally,
for
us,
actual
process
of
rolling
out
is
relatively
painless,
but
where
I
started
to
get
a
lot
more
adoption
of
service
by
workloads
and
people
are
actually
starting
to
use.
C
The
API
is
a
lot
more
and
so
divergence
key
thing
is
becoming
a
problem
for
people
and
so
yeah
I
guess
I
feel
like
I'm
trying
to
be
here
to
help
with
to
help
with
representing
the
end-user
perspective.
As
someone
who
hasn't
spent
a
lot
of
time
working
on
the
mechanics
of
it,
but
feels
the
pain
of
actually
have
an
upgrade
yeah.
B
401
not
11
I
had
a
lot
of
upgrade
experience,
running
clusters,
writing
extension,
schedulers,
controller,
greater
etcetera,
so
I
learned
a
lot
about
Cuban
natives
and
also
operational
experience,
and
that's
why
I'm
here,
while
I
was
part
of
share
I
mean
I
was
actually
observer
and
they
1.12
release
I,
attended
all
the
meetings
and
then
now
I'm
a
testing
for
a
lead.
I
I
had
various
questions
about
the
release,
cycle,
etc
and
when
I
posted
those
questions,
a
different
forums,
I
got
various
answers
and
I
felt
that
there
was
a
lot
of
opinions.
B
D
Jordan
and
Jordan,
like
it
I've,
been
on
the
kubernetes
project
for
a
while,
originally
working
with
Red,
Hat
and
I'm.
Now
at
Google,
I've
had
a
lot
of
experience
both
supporting
kubernetes
in
on-premise
customer
environments
and
in
hosted
environments
and
I
work.
A
lot
with
the
API.
The
the
REST
API
is,
and
then
also
the
config
and
storage.
Api
is
and
consult
on
a
lot
of
the
designs
around
compatibility
and
making
sure
that
we
as
we
make
progress.
D
Every
release,
leveling
that
up
to
give
the
people
who
are
writing
their
own
release,
scripts,
better
tools
to
understand
what
they
need
to
react
to,
or
ideally
like,
consume,
something
in
an
automated
way.
That
would
let
the
project
make
progress,
but
also
be
nicer
to
our
users.
So
I'm
excited
to
hear
about
Nick,
your
your
your
experiences
and
yeah
I.
Think
the
information-gathering
part
of
this
is
going
to
be
really
useful
and
you.
D
Yeah
so
I
a
tech
lead
for
sig
off,
and
so
that
kind
of
has
interesting
compatibility
implications,
making
sure
that,
as
new
features
get
added,
we
don't
automatically
expand
or
expose
clusters
that
thought
they
were
previously
really
nicely
locked
down.
It's
it's
kind
of
a
the
flipside
of
the
compatibility
progress.
Is
you
you.
D
A
Y'all
are
working
on
sort
of
broadening
that
set
out
now,
but
prior
to
that,
I
wasn't
really
aware
of
how
the
actual
process
worked
for
for
doing
back
ports
to
whichever
support
streams,
exists
and
I
feel
like
as
the
project
is
growing
and
maturing,
and
adoption
and
eyeballs
that,
based
on
other
experience
and
open
source
projects,
it
invariably
leads
to
more
things
being
noticed,
and
that
then
leads
to
more
work
on
backporting
and
I.
Think
it's
one
of
the
important
things
that
we'll
want
to
think
about
as
a
group
and
try
to
address.
A
Is
that
just
the
the
cost
of
support
whatever
it
is
most
basic?
One
of
the
aspects.
The
key
aspects
of
support
is
back
porting
to
some
particular
support
branch,
critical
fixes
such
as
security
fixes
and
as
the
volume
of
those
things
goes
up,
which
I
would
just
again
based
on
kind
of
industry
standard,
would
expect
to
be
something
that
happens.
That
means
the
cost
of
doing
those
back.
F
F
This
is
something
I
want
to
fall.
How
LTS
is
gonna
progress?
How
is
it's
going
to
affect
the
back
outside
of
the
corporate
model
and
I'm?
Probably
gonna,
try
to
help
with
random
bits
here
and
there
and
ID?
Yes,
so
I
also
Tim.
Thank
you
for
staying
up
so
late
to
Madison,
it's
1:00
a.m.
in
the
morning.
For
you
that's.
A
Correct
and
it's
also
quite
late,
I
think
for
quite
early
for
Nick
yeah.
It's
called
possible
for
me
yeah.
So
one
of
the
things
that
we
need
to
discuss
as
a
group
like
I,
double
and
I,
as
we
were
talking
initially,
we
just
sort
of
throughout
this
nine
o'clock
Pacific
time
and
in
the
community
calendar
happen
to
be
one
that
was
free.
But
that
doesn't
mean
it's
a
good
time.
It
could
quite
well
be
free
because
other
people
don't
want
to
go
to
meetings
at
that
time.
A
C
From
my
point
of
view
on
that,
yet
it
certainly
would
be
nice
to
not
need
to
wake
up
at
3:30
in
the
morning
to
join
the
course.
You
know,
but
you
know
I've
kind
of
accepted,
that
a
lot
of
the
time
for
the
stuff
I
do
need
to
it's
doable
but
yeah.
It
certainly
be
nice
to
have
a
rotating
schedule
or
something
like
that,
so
that
we
can
attend
many
meetings.
B
A
A
I
saw
him
earlier.
Well,
let's
say
it's
not
earlier
today,
anymore,
but
yesterday,
and
it
was
actually
the
first
time
we
met
face
to
face
so
he's
our
other
organizer,
which
I
guess
is
the
official
project
term
for
work,
group,
facilitator,
sort
of
people,
and
we
we
wanted
to
pick
an
initial
set
of
people.
A
A
A
Sig's
are
now
with
the
sig
charters
are
fairly
structured
in
terms
of
what's
expected,
but
they're
also
easier
because
SIG's
own
code
working
groups
don't
own
code.
So
you
have
some
sort
of
mandate
to
address
a
problem,
and
that
means
you
don't
have
as
clear
of
a
charter
or
there
isn't
even
a
requirement
on
a
charter
but
Dhaval
and
I's.
We
were
talking
about
this
over
the
last
months.
A
We
wanted
to
make
a
charter
and
put
it
out
there,
even
if
it's
not
strictly
required,
because
we
recognize
that
this
is
a
really
contentious
topic
and
it
could
be
very
easy
to
just
get
stuck
on
some
certain
details.
So
we
wanted
to
kind
of
lay
some
ground
rules
about
what
we
thought
was
in
scope
and
out
of
scope
and
then
also
to
approach
it
from
a
very
open-minded
perspective.
A
Making
sure
that
we
don't
just
say
like
this
is
about
traditional
LTS
multi-year
support
very
long
version
skews
across
those
and
support
upgrading
from
1.12
LTS,
one
dot,
I,
don't
know
20
LTS,
say
hypothetically,
like
that
sort
of
model
from
other
software
projects
that
we're
not
necessarily
sure
that
that
could
work
here
like
today.
I
really
don't
think
it
could
functionally
work
on
this
project,
but
even
if
that's
the
aspiration
or
desire
from
it
an
end
user.
A
So
we've
gotten
a
little
bit
bogged
down
like
me
already
thinking
that
we're
gonna
get
ahead
of
some
of
the
bike,
shedding
concerns
of
these
bike,
shedding
issues
or
cropping
up
in
the
PR.
Just
to
put
the
working
group
in
SIG's
animal
and
add
the
Charter
to
the
repository,
so
I
am
completely
unable
to
pull
up
the
PR.
But
oh
well,
could
you
maybe
post
a
link
to
it.
A
D
So
I
agree
with
your
comment
that,
like
pretty
much,
every
sig
could
be
listed
as
an
interested
sig,
but
the
ones
that
deal
specifically
with
like
the
API
and
the
primary
clients
and
the
cubelet
and
version
skew
like
those
are
the
ones
that
I
think
would
have
the
most
direct
input
to
say
like
here's,
where
we're
at
today
or
XYZ
to
happen.
Here's
what
would
need
to
change,
and
so
we
want
to
make
sure
we
had
representatives
from
those
groups
yeah.
A
I
I
totally
agree.
Those
are
the
the
most
core
ones
from
a
technical
perspective
for
the
control,
plane,
I
so
I
think
there's
a
couple
of
so
to
even
back
up
a
step.
There's
a
couple
layers
here:
the
first
one
was
a
number
of
people
were
saying:
don't
list
much
there,
because
at
this
point
just
for
bootstrapping
anybody
that
we
list
has
to
approve
and
people
were
saying
you'll.
A
Never
you're
gonna
spend
a
couple
months
just
trying
to
wrangle
getting
the
initial
PR
through
I'm,
less
worried
about
that
I'm,
fine
listing
a
bunch
or
more
and
the
only
reason,
I
haven't
gotten
to
Brian's
comments.
Is
that
I've
been
on
dodgy
Wi-Fi
since
Friday,
when
he
posted
them
and
complicated
network
routing,
but
yeah
I
agree
it,
but
then
beyond
just
the
bootstrapping
process,
then
as
we're
doing
discussions,
there's
understanding
from
a
technical
perspective
like
in
an
API
level,
how
we
figure
out
what
is
workable.
So
definitely
the
ones
he
listed
are
totally
optical
there.
A
But
then
the
next
layer
is.
If
we
were
to
operationalize
something
for
a
change,
then
those
were
the
ones
that
I'd
started
for
with
from
based
on
my
discussions
with
Zig
release
and
Tim
Sinclair
and
folks
on
the
cluster
life
cycle
perspective,
because
at
the
core
of
what
we
talked
about
for
a
potential
change,
it
ends
up
hitting
the
users
from
a
cluster
life
cycle
perspective.
So
I
think.
D
Didn't
mean
that
you
should
remove
the
yeah
yeah
you
listed
I
think
that's
a
good
way
to
break
it
down
like
which,
which
SIG's
are
the
most
core
to
the
areas
that
are
that
add
complexity
to
this
type
of
process
and
then,
which
SIG's
are
the
most
involved
in
the
processes
that
would
help
deliver
and
test
and
ensure
that
whatever
solution
we
come
up
with
yeah
operationally
works,
so
maybe
Britt
may
be
summarizing
it.
That
way,
like.
A
Yeah
I
kind
of
split
it
all
into
a
couple
of
groups
like
that
and
then
I
think
the
I'm
still
stuck
on
cloud
provider
is
sort
of
a
canary
one
as
we're
splitting
the
monolith
and
I
think
then
we're
also
gonna
end
up
bumping
into
network
and
storage
and
and
node
already
covered,
but
the
reason
I
look
at
those
three
is
see:
Ric
and
ICSI.
A
Whatever
happens
there
for
interfaces,
API
changes
or
over
time
like
thinking
about
over
the
coming
years
and
providers
being
out
of
tree
and
multi-vendor,
the
whatever
the
support
matrix
is
and
as
we're
freeing
things
to
work
on
there
they're
our
own
Cadence's.
There
still
has
to
be
some
way
where
integration
is
viable
and
I
think
that
at
that
point
we
have
practically
the
whole
sig
list.
D
What
would
have
been
helpful
in
this
release,
like,
as
you
were
transitioning
from
version
X
to
version
y,
like
an
information
gathering
phase
doesn't
yet
and
that
kind
of
feeds
into
what
you
were
trying
to
do
by
a
like,
avoiding
assuming
an
outcome
and
if
we're
just
in
the
information
gathering
phase,
there's
a
set
of
people,
they
need
to
be
involved
there.
And
if
we
come
to
the
conclusion
that
we
actually
don't
want
to
support
greater
versions
skew,
then
maybe
we
don't
need
to
get
some
of
those
other
SIG's
involved
right.
D
That's
true,
yeah,
so,
like
kind
of
phasing
out
like
first
phases,
information
gathering
users
and
these
like
kind
of
core
control,
plane,
SIG's
and
then
the
second
phase
is
evaluating
the
information
that
we
gathered
and
said
all
right.
What
problems
do
we
see?
What
are
various
solutions?
Right:
greater
versions,
Q
long-term
support,
possibly
better
upgrade
tools,
better
artifacts
for
people
who
are
upgrading
better
testing
around
upgrades,
possibly
like
good
like
at
that
point.
We
can
kind
of
have
a
phase
where
we
are
throwing
out
solutions
and
thinking
the
pros
and
cons.
Yeah.
A
Exactly
at
that
point
too
I
think
the
the
stakeholders
that
are
needed
for
any
specific
thing
become
much
more
clear
because
we're
into
the
standard
kept
process
and
we
we
know
how
to
pull
in
the
right
stakeholders.
At
that
point,
but
yeah
this
initial
information
gathering
phase,
we
could
constrain,
maybe
in
two
particular
pockets
that
we
we
do.
Some
pointed
surveying
of
that.
D
Would
be
my
recommendation,
do
you
actually
do
name
specific
people,
you're
gonna,
engage
in
SIG's
and
groups,
and
then
you
have
an
initial
set
of
like
here.
Are
the
tasks
we're
gonna
do
and
then,
when
you
reach
the
end
of
that
list,
then
we
will
decide
where
we
proceed
from
there.
So
it
keeps
it
clear,
but
also
scoped,
yeah.
A
And
one
of
the
things
that
we
had
hoped
was
to
get
more
group
consensus
like
we,
partly
through
that
initial
charter
draft
out
there,
just
to
like
say
like
here's,
some
words,
but
we
really
hope
then
that
as
a
group,
we
could
decide
these
specific
things.
What
do
we
want
to
do
for
a
phasing,
and,
and
how
do
we
want
to
do
the
specifics
of
that?
F
I
wanted
to
make
a
comment
that
this
PR
is
gonna.
Take
a
while
to
get
much
because
of
the
bike
sharing
so
I
was
my
proposal.
Deal
was
to
invent
some
sort
of
a
mechanic
for
key
members
of
the
community
to
vote
I'm
not
talking
about
a
public
voting
system
like
distinguish
tech
leads
and
cig
leads
for
things
like
deciding.
F
A
Think
if
we've
done
a
survey
and
somehow
we've
decided
like
the
way
is
to
set
in
releases,
are
supported
in
every
in
every
m3
release
is
gonna,
be
called
LTS
and
we're
gonna
support
that
for
Y
years.
At
the
point
that
we've,
if
we
were
to
come
to
a
point
where
we
declared
those
three
magic
numbers
and
they're
they're
different
than
what
they
are
today,
I'm
expecting
that
that's
gonna
have
to
be
a
cap
and
that
every
Stig
would
be
a
stakeholder
a
blocking
stakeholder
on
that
I
I.
A
D
Yeah
I
mean
something
like
that:
it
wouldn't
be
lazy.
Consensus
like
that
that
has
that
kind
of
a
change
has
to
be
opted
into.
I
agree
that
getting
the
Charter
merged
becomes
harder,
the
more
it
bites
off,
and
so,
if,
if
we
can
scope
it
down
to
say
we're
investigating
to
try
to
improve
this
area,
this
area
needs
improvement.
We're
not
sure
what
it
like.
What
specifically
it
needs
yet
but
figuring
that
out
is
the
goal
of
this
work
group.
D
Here's
who's
going
to
be
involved
and
here's
the
first
set
of
really
concrete
things
we're
going
to
do,
and
then,
at
the
end
of
that
we
will
evaluate.
Do
we
disband?
Do
we
come
up
with
recommendations?
Do
we
like
what
do
we
do
after?
This
will
be
determined,
I,
think
we'll
be
able
to
get
this
emerged
quicker
than
you
think,
I.
A
C
I
mean
I
think
as
Jordan
says,
I
think
the
key
is
to
be
clear
that
this
is
an
initial
investigation,
not
to
be
vague.
It's
to
be
clear
that
yeah,
it's
like
hey,
we
know
some
things.
Everybody
knows
that
something
needs
to
give
around
this
area,
but
probably
know
what
needs
to
give
and
how
it
could
give
and
what
are
the
options,
and
so
the
first
part
there
like
is
to
say
what
are
the
pain
points?
C
What
what
don't
people
like
like
I
mean
I
think
we
all
have
an
idea
about
what
people
don't
like,
but
chances
are
pretty
good
at
this
point
that
we
all
had
different
ideas
about
what
people
don't
like.
You
know,
because,
because
we've,
even
even
in
this
small
group
or
a
relatively
wide
cross-section
of
you,
know,
participation
levels
and
you
know
knowledge
of
the
code
base
and
knowledge
of
the
release
process
and
all
this
sort
of
stuff,
the
you
know,
I
think
it
really
is
key
to
sort
of
do
it.
A
B
Yeah,
sorry
to
interject
there,
so
I
think
the
important
thing
is
to
classify
is
that
the
group
is
not
gonna
be
vague.
The
Charter
might
be
broad,
so
the
group's
outputs
may
not
be
vague,
but
the
Charter
might
just
cover
broadly
saying
this
are
what
we
are
trying
to
intend
to
do
right.
That's
what
I
just
want
to
be
clear
about
that
I.
D
The
point
of
it
harder
is
to
be
able
to
say
for
a
given
activity.
Is
this
what
this
working
group
should
be
doing
or
not,
and
that
when
all
the
cigs
went
and
did
their
charters
like
it
was?
The
point
was
to
be
able
to
say
you
know
for
a
given
design
or
activity.
Your
artifact
like
what
cigs
are
involved
in
this,
and
you
should
have
a
look
at
their
charters
and
say:
oh
yeah.
A
D
A
I,
probably,
to
some
extent
misusing
the
word
fake,
but
I
was
meaning
it
like
from
there's
I,
guess,
maybe
to
make
an
analogy
with
waterfall
and
agile
like
work.
If
we're
gonna
time
box,
the
working
group
to
sort
of
maximum
a
year
say
like
to
throw
that
into
the
charter.
I
think
is
maybe
I
think
that's
realistic,
just
to
say,
like
we're.
Gonna
put
some
sort
of
maximum
time
box
on
it,
but
in
the
meantime,
during
that
year
did
not
say
like
this
month.
A
We're
doing
X
next
month
were
doing
Y
and
spell
that
out
across
the
course
of
the
year,
but
to
say
over
the
quarter.
We
want
to
focus
on
investigation
and
then
we'll
decide
what
that
leads
to
and
probably
then
we
update
the
Charter
to
describe
where
we're
headed
next
book
that
we
don't
have
the
the
concrete
long-term
vision
of
what
the
workgroup
will
be
doing,
because
we
don't
know
yet
until
we
do
that
investigation
and
make
some
choices.
Yeah.
D
F
A
Not
but
I
think
in
this
case
very
quickly
is
if
we
hadn't,
we
would
have
asked
been
asked
for
good.
If
you
look
at
the
the
way
the
content
is
automatically
populated
in
k,
community
six
tamil
everybody
has
like
a
sentence
or
two
on
what
they're
doing.
If
we
tried
to
describe
in
a
sentence
or
two
to
automatically
flowed
into
the
generated
readme
for
the
working
group
like
I,
don't
think
we
could
capture
concretely
enough
for
people
to
say
yes,
I
understand
what
this
working
group
is
going
to
be.
A
We
needed
something
for
a
long
form
document,
and
then
that
starts
to
look
like
a
charter
in
the
community.
So
it's
not
strictly
required
for
a
working
group,
but
I
think
for
this
one
for
the
level
of
confusion
that
we
could
generate
and
end
up
not
having
concrete,
specific
outputs
and
getting
somewhere
in
the
end,
making
some
positive
change
and
what
the
situation
is.
We
had
to
start
writing
something
now
and.
D
The
clearer
you
are
about
what
the
initial
work
is
going
to
be
I.
Think
the
better
representative
of
a
group
of
people
you
will
get
involved
because,
if
you're
saying
we're
going
to
be
doing
XY
and
Z,
if
you
have
opinions
and
thoughts
come
participate
like
that
is
more
compelling
than
something
that
is
hard
for
people
to
understand
what
you're
doing
and
they're
like
well
I,
don't
really
feel
like
going
to
another
working
group.
If
I
don't
really
understand
what
it's
doing
so,
yeah.
D
F
D
The
most
reasonable
avenues
that
I've
seen
for
more
scope,
things
I've,
seen
people
take
take
a
proposal
or
a
design
or
a
survey
around
to
a
bunch
of
different
things.
So
I
get
six
or
seven
different
sig
meetings,
but
for
something
where
we're
wanting
to
get
users
and
deployers
and
external
companies
involved,
probably
add
the
public
communication
channels
is
the
best
I've
seen
from.
A
A
I
think
that
could
potentially
be
a
path
to
operators
and
users
more
broadly
and
then
the
other
thing
that
I
was
thinking
about
is
we
have
a
list
that
the
CN
CF
curates
it's
up
to
I,
think
about
eighty
distributors,
vendors
and
hosting
providers,
and
they
have
that
list
because
those
entities
have
uploaded
conformance
results.
So
that
gives
us
an
angle
back
to
a
contact
who
uploaded
those
can
we
reach
out
to
because
all
this
is
public
artifacts
right?
A
Can
we
reach
out
to
those
people
and
say,
like
hey,
tell
us
your
story
and
the
the
spreadsheet
that's
maintained
there.
It
shows
I
think
from
1/8
onward,
which
releases
they've
done.
We
can
we
can
kind
of
look
at
some
of
those
and
say
like
hey,
here's,
a
set
of
vendors
who
certified
on
1/8
and
haven't
since
ping
them
with
us
about
a
targeted
thing.
Saying:
hey?
Are
you
still
active?
Are
you
struggling?
A
What
are
your
issues,
the
ones
that
have
that
certified
conformance
on
every
release
being
them
say,
hey,
it
looks
like
you're
able
to
move
quickly.
Can
you
tell
us
about
what
what's
helped
you
on
the
velocity
or,
and
maybe
we
find
that
each
of
them
has
a
team
of
a
hundred
people
behind
the
scenes
or
like
what?
What
are
the
specific
details?
I
think
we
have.
So
let
me
go
there
to
get
us
some
interesting
data.
You.
D
B
Be
effective,
yeah
I
was
gonna,
suggest
that
so
I
was
thinking
of
having
a
survey
that
we
could
wish.
We
had
the
meeting
last
week,
so
we
could
have
done
for
koukin
China,
but
we
have
at
least
cook
on
America's.
I
could
probably
jot
down
a
beginning
set
of
questions
for
the
survey,
and
then
we
can
all
contribute
to
it
to
make
one
seven
and
probably
give
it
to
sick
p.m.
and
CN
CF
to
see
if
they
can
run
it
getting
a
jump.
D
On
a
set
of
questions
now
and
ideally
getting
feedback
from
maybe
some
of
those
early
stakeholders
that
we
identified
saying
here,
here's
the
information
that
we
want
to
know
about
our
users
and
how
they're
doing
and
how
we
can
do
better.
Are
there
specific
questions
that
you'd
want
to
ask
or
a
way
you'd
want
to
rephrase
this,
or
you
know
kind
of
ask
the
question
neutrally
without
pushing
towards
any
particular
solution
like
we
really
want
to
hear
what
what
people's
experiences
are.
D
A
A
F
A
Should
look
more
broadly
to
on
a
little
bit
of
a
survey
of
established,
open
source
projects?
How
do
they
do
their
release
and
lifecycle,
regardless
of
LTC
LTS
do?
Are
they
are
they
making?
Are
there
other
projects
out
there
that
we
could
learn
from
that?
Are
making
more
fastener
releases
and
maybe
only
having
a
single
support
stream
that
you're
there's
current
and
that's
that
there
are
other
models
out
there,
and
just
because
the
LTS
model
is
one
that
is
familiar,
doesn't
mean
that
that
that
is
the
only
way.
C
Yeah
I
think
from
from
my
experience
talking
to
people
who
are
running
clusters.
There
are.
There
is
quite
a
reasonable
population
of
operators
who
are
not
well
plugged
into
the
wider
queue
project,
and
so
it's
only
something
that
I
will
do
is
have
a
think
about.
You
know:
I've
been
decided,
there's
a
couple
even
to
small
smallish
Enterprise,
like
cubed,
for
the
enterprise
forums
in
Australia.
Where
you
know
one
of
the
presentations
there
was
literally
here's
some
highlights
from
all
of
the
cg
activity.
C
That
I
was
like
people
don't
know
this
already,
but
but
a
lot
of
people
don't
like
you
know
it's
hard
to
keep
up
with
everything
is
happening.
It
takes
a
lot
of
effort
and
so
yeah
that
it
might,
it
might
be
a
little
tricky
it
might
take
a
little
while
for
that
to
trickle
out
thanks,
but
yeah
like
a
CNC
F
sponsored
survey
would
probably
be
a
great
way
to
reach
some
of
those
people
as
well.
A
D
I
really
do
want.
You
understand
what
is
problematic
around
upgrades,
but
I.
Think
LTS
releases
are,
in
my
mind
a
last
resort.
That
is
kind
of
an
admission
of
failure
to
provide
software
that
can
be
upgraded
and
if
that's,
where
we
have
to
end
up
I
think
it
will
come
with
compromises
and
implications
that
people
are
not
happy
with
like
you
can
have
an
LTS
release,
but
we
don't
support
upgrading
from
it,
because
we
don't
support
upgrades
across
eight
versions
and
so
I
I
would
avoid
asking
questions
up
front
like
how
long?
A
A
D
We
can
look
at
the
universe
of
things
we
have
control
over
inside
the
kubernetes
project
and
the
universe
of
things
outside
our
control
and
see
what
we
can
do
to
improve
the
things
under
our
control
to
help
people
who
aren't
able
to
upgrade
as
easily
or
as
frequently
as
they
want
to
or
when
they
do
upgrade.
They
encounter
problems
or
they
use
things
that
aren't
stable
and
those
things
change
behavior,
and
so
they
want
to
just
stick
on
whatever
version
they're
on,
even
though
it's
not
a
stable
birth.
D
A
I
think
that
that
stability
issue
I
mean
I,
can
totally
imagine
a
user
that
is
constantly
trying
to
upgrade
and
manages
to
get
to
stable
production
once
or
twice
a
year.
Even
though
they're
they've
got
multiple
staff
constantly
trying
to
roll
forward
because
of
weird
inner
dependencies,
because
we
also
I
think
one
of
the
things
we're
gonna
have
to
talk
about
at
some
point
is
what
is
kubernetes
and
what
is
a
release
because
from
from
the
core
control
plane,
it
means
something
very
different
than
what
an
end-user
actually
deploys
all
across
all
of
our
cluster.
A
The
fully
integrated
set
of
things
that
becomes
a
usable
cluster,
that's
much
more
than
just
the
simple
cake,
a
control
playing
and
thinking
about
version.
Skew
there
and
interdependencies,
and
the
is
we've
been
discussing
this
with
a
number
of
folks
over
the
last
month,
or
so.
It's
become
clear
that
the
discussion
last
year
at
cube
con
around
what
is
kubernetes,
and
could
it
be
something
like
a
kernel
in
a
distribution
that
that's
almost
gotten
lost.
I.
A
Think
in
the
noise
of
just
the
hey,
rah-rah
kubernetes
is
awesome
as
the
Linux
of
the
cloud,
but
when
people
hear
that
they
don't
necessarily
hear
Linux
kernel
versus
Linux
distribution
and
this
concept
of
kernel
versus
distribution,
I
think
we
have
gaps
beyond
just
what's
in
control
of
kaykai.
But
as
we
split
the
monolith,
thinking
about
well
who's,
going
to
make
a
distribution.
A
D
Yeah
and
to
me,
the
talking
about
like
compatibility
and
long-term
support,
I
am
much
more
interested
in
stable
api's,
and
so,
if
you
think
about
when
a
lot
of
people
think
about
api's
in
cooler
Nettie's,
all
they
think
about
are
the
rest.
Api
is,
but
we
actually
have
three
types
of
api's.
We
have
config
file.
D
Api
is
so
config
files
that
feed
into
the
cubelet
and
cube
scheduler
and
cube
proxy
are
versioned
api's,
some
of
the
components
don't
yet
consume
version,
2
configuration
files,
they're
all
fed
via
flags,
thousands
and
thousands
of
flags,
and
so
config
files,
actually
getting
all
the
components
consuming
version
configurations,
less
unique
looks
like
you
died
in
there
and
then
working
to
graduate
those
configuration
files
too
stable.
So
the
all
the
ones
I'm
aware
of
are
still
either
at
alpha
or
beta.
So
that's
one
set
of
api's.
D
So
there's
the
REST
API
guys
and
then
the
last
set
are
the
the
underlying
api's
like
CNI
CRI,
and
those
technically
are
still
I
think
at
alpha
the.
Despite
that
being
the
way
all
clusters
run
and
so
I
think
it
would
be,
especially
when
we
talk
about
kernel
versus
distribution
and
the
core
control
plane
versus
all
the
things
that
distributors
are
going
to
wrap
in
wrap
around
it
and
plug-in
they're
wrapping
things
around
it
and
plugging
things
into
it
via
those
three
types
of
api's
configuration
file.
Api
is
the
rest.
D
Api
is
and
then
the
backend
CNIC
RI,
if
you
guys
and
I,
think
regardless
of
whatever
else
happens
with
LTS
or
not
LTS
getting
those
API
is
the
way
that
you
configure
and
speak
to
and
back
a
kubernetes
server
and
cluster.
Getting
those
api
is
too
stable
is
essential
and
we
have
much
stronger
and
longer
term
guarantees
around
stable.
Api
is
v1.
Api
is,
if
you
look
at
the
cube
deprecation
policy,
it's
like
on
the
order
of
years
for
them
yep,
where.
C
Say
with
respect
to
that,
api's
I
can
definitely
say
as
an
operator
that
you
know,
we've
been
bitten
quite
a
lot
by
the
sort
of
shifting
sands
there,
especially
with
yet
the
complete
file
stuff.
You
know
that
we've
done
our
best
to
move
all
our
cube.
Look
flags
as
the
compute
file
stuff
becomes
available,
but
the
you
know,
but
that
is
hi
process
and
a
lot
of
the
time.
D
C
D
To
take
some
of
the
energy
of
the
people
who
are
working
on
these
improvements,
they
are
improvements
but
also
say
consider
the
user,
like
you've,
just
told
a
user
to
change
a
command
line
of
80
flags
to
a
config
file.
Do
you
think
maybe
you
could
like
include
a
tool
to
let
them
do
that
automatically
like
yeah
I.
A
F
F
A
F
B
The
pattern
we
want
to
see
you
right
up
I
just
want
to
point
out
that
we
have
four
minutes
left
for
this
meeting
and
I'm
really
excited
that.
We
didn't
even
notice
that
we
are
running
out
of
time.
There's
so
much
to
talk
about
I
would
just
say
we
should
get
in
the
last
few
minutes.
Some
action
items
for
ourselves,
I,
like
I,
said
I'll
work
on
the
survey.
I
think
they
have
a
lot
of
good
points
made.
I
have
not
captured
all
of
them
as
Edwards
guy,
but
I
would
say.
B
B
A
That's
a
high
and
a
great
firewall
right
now
could
I
suggest
that
maybe
we
try
and
do
this
not
via
a
Google,
Doc
I,
know
Google
Docs
are
great
for
and
I
love
them
for
early
collaboration
like
this,
but
I
wonder
if
we
could
do
this
is
a
issue
discussion
and
and
then
shift
it
over
to
a
PR
if
we
wanted
to
make
it
durable
somewhere
within
the
codebase.
Otherwise
go
from
the
issue
straight
to
a
survey,
and
we
do
you
folks
think
that
it's
realistic
to
do
it
that
way
versus
a
doc.
A
F
A
It's
not
just
me,
I
mean
I'm,
hoping
to
get
others
involved
in
the
sink
while
I'm.
Here,
that's
like
the
working
group
while
I'm
here,
but
just
thinking
long-term.
Is
it
there's
a
project?
It
is
something
that
we
have
to
think
of.
How
do
we?
How
do
we
be
inclusive
of
folks
who
can't
access
the
Google
Docs?
Well.
C
I
think
I
think
Kim's.
The
broader
question
is
pretty
fair
that
it
is
a
good
idea
to
do
that.
I
mean
I
think
as
a
practical
measure,
Kim,
like
probably
in
the
short
term,
because
we've
got
a
tight
timeline
for
the
right
for
experiencing
yeah
we
went
probably
gonna
have
to
stick
with
a
Google
Doc
this
time,
just
because
it's
gonna
be
so
much
faster
than
trying
to
do
it
via.
C
You
know
comments
on
a
PR
or
doing
it
in
an
issue
or
something
like
that,
because
it's
hard
to
do
yeah
it's
much
harder
to
do
sort
of
back
and
forth
when
you
can't,
when
you
easy
to
do
that,
sort
of
collaboration
in
a
quick
way
on
a
Google,
Doc
and
burn
them.
I
think
this
one
that
the
time
frame
is
critical
yeah.
We
want
to
get
family
not
the
next
week
or
so
so
that
we
can
do
that.
I
would
say
the
other
action
item.
C
I
would
say:
I
mean
I
can
maybe
take
it,
but
you
know
I,
don't
know
my
time.
Zones
of
work
is
codifying
something
a
little
bit
more
about
a
meet-up
at
UConn
us
or
a
session,
or
you
know
something
in
the
current
contributor
summer
or
something
like
that.
I'm,
not
sure
if
we've
got
anything
in
any
of
the
times
there,
but
given
that
we're
only
really
just
formed
like
right,
it
is
unlikely,
I
would
say.
C
A
Ostensibly
it
was
what
can
we
learn
from
the
OpenStack
community
and
it
very
quickly
got
into
a
Support
Lifecycle
the
discussion,
so
it
in
LTS,
specifically
so
on
I
think
it's
totally
viable
there
it
it's
very
often
the
case
to
have
a
circle
of
50
people
just
having
a
hallway
track
conversation
on
something
targeted
like
this
so
worst
case.
We
could
do
that,
but
it
may
be
possible
use
something
officially
scheduled.
A
So
that's
three
specific
action
items
so
I'll
take
the
on
looking
at
a
forum
at
Cuba
and
Ava's
gonna
start
a
Google,
Doc
Draft,
and
then
everyone
any
comments
on
the
issue
that
are
around
the
Charter
and
then,
as
I'm
able
dodging
Network
aside.
I
will
try
and
get
those
amended
on
the
ER
and
iterate
there
all
right.