►
From YouTube: Kubernetes Community Meeting 20191107
Description
The Kubernetes community meeting is intended to provide a holistic overview of community activities, critical release information, and governance updates. It also provides a forum for discussion of project-level concerns that might need a wider audience than a single special interest group (SIG).
See this page for more information! https://github.com/kubernetes/community/blob/master/events/community-meeting.md
Like what you see here? Continue the conversation on https://discuss.kubernetes.io
A
I'm
at
ten
hello,
hello,
hello,
everybody
thank
you
for
being
here.
I
am
marki
Jackson
for
all
those
that
don't
know
me.
I
work
at
Cystic,
I
am
part
of
the
sake
contributor
experience
as
well
as
cig
release.
I
am
also
one
of
the
shadows
for
the
117
release.
I.
Thank
you
all
for
being
here
today.
Hope
everybody
is
doing.
Well,
let's
go
ahead
and
get
started.
Can
I
get
a
note-taker.
Think
I've
already
got
my
note
taker
George!
That's
you
right!
Thank
you.
Thank
you.
Thank
you.
A
B
B
A
C
C
C
We've
tried
to
keep
an
open
mind
and
the
working
group
around
how
we
approach
the
topic
of
support
so
as
to
not
sort
of
pigeonhole
ourselves
into
saying.
Kubernetes
is
going
to
do
LTS
as
everybody
knows
it,
but
rather
look
at
what
our
user
base
wants
in
terms
of
support
and
try
to
analyze
that
and
see
if
there
are
gaps
in
what
we're
doing
today
and
provide
a
variety
of
potential
solutions
and
then
hopefully
work
towards
consensus
on
some
specific
changes.
C
C
So,
there's
a
link
there
in
the
notes
to
some
of
the
discussions
that
have
been
leading
up
to
the
github
PR
emerging
and
then
also
we
established
our
Charter
and
sort
of
like
I
was
talking
about
a
moment
ago.
We
were
trying
to
come
at
this
open
as
a
working
group
to
discuss
the
problem.
Space
and
potential
solutions.
Open
minded,
open,
open
possibilities,
as
opposed
to
saying,
like
let's
go,
implement
LTS
as
everybody
knows
it,
because
that's
actually
not
a
actual
specific
thing.
C
One
of
the
things
we
started
out
with
initially
was
doing
a
survey
so
end
of
last
year,
beginning
of
this
year,
we
had
334
people
respond
to
our
survey
and
we're
trying
to
get
at
a
spectrum
of
cluster
operators.
Clusters
users,
kubernetes
contributors,
as
well
as
the
vendor
distributors,
hosted
offering
providers
and
and
see
what
they
think
about
the
state
of
support
how
they
use
consume
artifacts
into
clusters,
how
they
upgrade
clusters.
C
How
often
one
of
the
major
findings
that
we
had
there
was
a
large
portion
of
the
respondents
were
running
releases
at
or
near
end
of
support,
and
that
was
something
we
sort
of
speculated
was
possibly
the
case,
because
we
were
hearing
these
sort
of
rumbles
of
people
wanting
longer
support.
If
people
are
asking
for
a
longer
support
lifetime,
that
probably
implies
they're
having
some
type
of
issue
getting
off
of
an
older
release
to
the
newer
one
before
they.
What
they've
deployed
falls
out
of
support.
So
we
collected
a
variety
of
data
on
that
there
were.
C
There
was
actually
kind
of
bimodal.
There
are
a
lot
of
people
who
are
successfully
moving
forward
fairly
rapidly,
which
is
good
to
see.
We
want
to
see
agile
sort
of
cloud
native
forward
motion,
the
other
things
that
we've
done
in
this
area,
around
kind
of
getting
going
and
getting
discussion
going.
Is
it
each
of
the
past
two
cube
cons?
C
We've
had
a
buff
there's
a
link
in
the
notes
to
the
YouTube
recordings
of
that
we'll
be
having
a
session
at
the
contributor
summit
in
a
week
and
a
half
also
to
go
into
some
more
detail
on
things
and
for
people
who
maybe
aren't
as
familiar
with
working
groups
versus
SIG's
SIG's
own
code.
There
they're
listed
in
owners
files
as
reviewers
and
approvers
of
code.
They
have
some
code
they're
responsible
for
working
groups
less.
So
it's
about
understanding
a
problem,
space
and
working
towards
potential
solutions
that
then
get
implemented.
C
Maybe
so
we've
done
a
lot
of
discussion,
then
the
things
that
we've
been
talking
about
a
lot
of
these
I
think
I've
alluded
to
already,
but
the
release
cadence
Haughton
the
project
is
making
releases.
There's
people
who
want
it
faster,
there's
people
who
want
it
slower
and
then
per
release.
What
is
the
support
lifetime?
There's
a
desire
to
have
it
longer,
but
doing
it
longer
it
comes
with
cost.
We
also
have
to
think
about
upgrade
scenarios
across
that.
How
are
people
upgrading
their
cluster
is
moving
to
newer
releases?
What
problems
are
they
having
today?
C
What
help
would
they
like
to
see
from
the
community
and
then
within
that
version,
skew
and
application
policies
if
you're
moving
between
things?
How
hard
is
it
to
keep
your
componentry
of
your
cluster
coherent,
and
do
you
have
things
that
you
depend
on
that
just
sort
of
disappear?
Underneath
you,
a
portion
of
that
too
is
API
stability.
There's
configuration
there's
API,
we
have
REST
API
x',
there's,
there's
a
number
of
different
components
of
what
is
API
stability.
That
then
also
ties
into
conformance
and
testing.
C
Potentially
we've
had
a
number
of
potential
proposals
that
are
relatively
complex
and
span
changing
the
way
upgrade
might
happen
or
the
way
the
release,
cadence
happens
or
the
support
lifetime
or
all
of
them
together,
but
it's
very
complicated
to
try
to
reason
what
that
might
look
like
and
how
something
that's
truly
implementable
today
or
incrementally
implementable.
So
this
this
draft
cap
that
we
have
going
on
is
fairly
simple.
It's
proposing
that
we
add
one
more
quarters
worth
of
calendar
time
of
support.
Today,
a
given
kubernetes
release
is
supported
for
nine
months
ish.
C
The
proposal
is
to
support
it
for
twelve
months
and
there's
there's
a
little
bit
of
fuzz
in
there
and
some
things
that
are
still
under
discussion.
This
is
a
draft
discussion,
as
I
mentioned,
we'll
have
another
session
at
cube
Con.
This
is
a
contribs
Emmett
on
Monday
I,
believe
it's
in
like
the
11
o'clock
hour
Monday
morning,
and
then
working
groups
are
supposed
to
be
time
limited.
So
one
of
the
things
that
we
need
to
decide
is
whether
we
we
want
to
should
continue
into
2020
what
things
we
would
pursue.
C
If
and
when
we
were
to
carry
on
forward
and
do
we
do
another
survey,
because
the
data
findings
that
we
had
are
specific
to
sort
of
1.13
releases
in
earlier,
and
we
measured
a
lot
of
people
on
1.9
releases
and
earlier
obviously,
now
that
we're
up
around
117
that
data
is
quite
old,
we're
moving
forward
fast.
It
would
be
interesting
to
see
how
people
have
changed
since
then,
so
how
these
plans
affect
you.
Hopefully,
the
main
thing
that
people
see
coming
out
of
this
iteratively
is
higher
levels
of
stability,
compatibility,
quality.
C
The
even
though
we're
here
OOP
doesn't
own
code
and
isn't
necessarily
driving
specific
changes
in
code.
Some
of
the
discussion
here
has
turned
in
two
specific
issues
and
pr's
around
better
documenting
our
current
version,
skew
and
deprecation
policies,
how
we
move
features
through
alpha
beta,
stable
and
how
we
do
our
patch
releases
today
and
and
then
ideas
around
how
any
of
these
might
change
going
forward
in
response
to
to
user
demand.
Also
improving
API
stability
I
mentioned
configuration
on
REST
API.
C
Conformance
testing
by
default
requires
that
you
enable
beta
ap
is
the
kubernetes
project,
is
relatively
new
still
and
relatively
amateur
in
some
ways,
and
we
need
to
push
more
of
it
forward
towards
stable
and
not
have
people,
depending
on
beta,
much
less
alpha
api's
for
the
the
standard
running
of
a
conforming
kubernetes
cluster
things
we
need
from
you.
Speaking
of
that
survey,
we're
continuing
to
look
for
more
input
from
cluster
end
users
and
operators
on
how
would
they
actually
do
things?
What
support
needs?
C
I
think
I've
mentioned
both
of
these
two,
the
one
that's
currently
in
an
implementable
state
that
Jordan
liggett's
put
forward
around
making
sure
that
we
can
run
conformance
without
beta
features,
and
then
this
draft
kept
from
the
working
group.
That's
under
discussion
around
moving
from
nine
months
to
one
year
of
support
how
you
can
contribute,
since
this
is
largely
about
discussion,
show
up
to
our
meeting
discuss.
C
We
would
love
that
show
up
to
contribs
Emmett
and
get
engaged
in
the
discussion,
and
if
we
do
a
survey
in
2020
keep
an
eye
out
for
that
and
respond
to
it.
We
would
love
that
and
then
our
standard,
where
do
you
find
us,
like
all
of
the
SIG's,
the
SIG's
and
working
groups,
are
all
listed
in
the
cig
list
out
on
the
kubernetes
community,
whoa
we're
there
as
well
we've
got
to
read
me:
we've
got
our
charter.
We've
got
a
slack
channel,
a
Google
Group.
We
do
have
the
standard.
A
D
So
hi
everyone,
I'm,
bards,
Nicola
and
I-
will
try
to
update
you
about
the
case
in
front
working
group
and
I
think
that
the
most
important
things
are
weat
and
onboarding
session
for
the
new
contributors.
Actually,
the
IT
people
came-
and
this
was
a
result
for
like
a
multiple
people
asking
for
help
on
Twitter
and
other
places,
and
actually
we
didn't
expect
that
many
people
being
interested
in
help.
D
So
that's
I,
think
kind
of
important
thing
and
we
also
started
like
a
process
of
divining
efforts
of
our
working
group
into
subgroups,
which
will
be
responsible
for
the
smaller
chunks
of
the
work
and
the
every
subgroup
will
have
one
mentor
who
is
like
currently
more
experienced
and
multiple
mentees
from
the
people
who
want
to
help,
especially
the
newcomers
and
new
contributors
and
the
deadline.
To
finish
this
work
is
set
for
the
next
week.
D
So
I
hope
that
after
next
week
we
every
subgroup
will
start
working
on
their
tasks
and
I
was
nominated
as
a
culture
of
case
in
frog,
working
group,
I,
don't
know
if
it's
important
enough,
but
it's
here
and
I
think
the
very
one
of
the
biggest
things
we
managed
to
do.
Is
we
created
and
tested
solution
to
give.
D
Users
via
Google
Groups
permissions
to
do
to
create
like
to
manage
and
create
the
namespaces
inside
a
new
infrastructure.
What
does
it
mean?
Is
that
every
project
which
will
have
its
own
namespace
in
our
new
infrastructure
can
be
accessed
and
managed
currently
with
the
by
the
people
who
are
members
of
the
working
groups
which
are
managed
with
our
groups
Yama
file.
So
it
means
that
we
are,
we
can
give
people
permissions
and
we
can
give
people
access
to
their
new
cluster.
D
So
we
are
very,
very
close
to
like
starting
moving
the
projects
itself
to
the
new
cluster
and
the
last
thing
is
ready
to
the
container
in
each
promoter
which
actually
move
to
the
use,
so
called
fin
manifests,
and
this
is
kind
of
security
hardening
and
the
credentials
are
locked
down
under
the
stricter
owners
file.
And
that's
that's
what
we
did
with
the
last
cycle
and
what
is
what
are
our
plans
for?
The
upcoming
cycle
is
to
actually
document
a
little
bit
better,
our
current
state
of
the
world,
of
our
efforts,
so
every
subgroup.
D
The
first
task
would
be
to
create
the
single
document
with
the
state
of
the
world
of
that
particular
efforts
and
in
3
or
4
weeks.
We
want
to
have
one
like
a
design
document
with
what
we
did.
What
we
in
still
need
to
do
and
what
is
the
current
state
of
the
world
and
I
think
that
it
will
help,
and
not
only
us
but
everybody,
to
see
how
further
we
are
in
this
whole
process
of
moving
the
infrastructure
to
the
community
and
one
and
we
are
still
working
and
we
will
be
working.
D
I
hope
that
the
next
cycle
will
finish
the
like
a
solution
for
backups
and
auditioning
for
container
a
niche
promoter,
and
this
will
be
actually
is
actually
the
last
bit
of
things
which
we
need
to
do
to
make
it
fully
working
and
I
hope
that
we
will
start
moving
the
smaller
projects
to
the
new
infrastructure
and
actually
how
these
plants
affect
you.
It's
because
we
are
starting
very
soon
to
move
the
projects.
D
The
new
infrastructure-
probably
we
will
really
need
some
help
or
guidance
the
projects
with
from
the
six
who
owns
the
projects
itself,
but
this
is
not
yet
the
time
to
do
so,
but
I
think
that
in
the
next
month
we
will
start
this
process.
So
that's
the
only
thing
which
can
affect
others
I
think
at
this
point
and
how
you
can
contribute
there.
I
put
some
interesting
links
from
the
onboarding
sessions,
with
the
recording,
with
insight
denotes
from
the
recording
I
put
a
lot
of
intro
I
think
interesting
links
for
newcomers.
D
There
is
multiple,
I,
think,
20
or
so
links
which
can
be
useful
for
new
contributors,
not
only
to
our
working
group
but
new
contributors
itself
and
playlists
for
our
recording,
currently
open
issues
and
the
state
of
the
world
or
the
container
in
each
promoter.
This
point
and
where
you
can
find
us
on
a
slack
channel,
our
google
group
and
feel
free
to
find
us
there
to
talk
to
us.
That's
Maya
died.
A
Thank
you
very
much,
but
I
really
appreciate
that
very
informative.
Okay,
let's
go
ahead
and
go
right
into
announcements.
So
for
all
that
don't
know
this
will
be
the
last
community
meeting
until
December
5th
that
that
means
no
meetings
because
cube
con
and
Thanksgiving,
which
also
happy
cube.
Con
and
Happy
Thanksgiving
I
look
forward
to
seeing
everybody
that
can
make
it
there
don't
forget
to
register
for
the
contributor
summit
and
we
will
go
into
shoutouts
mm-hmm
Chris
Chris
short
gave
a
shout
out
to
George
and
Jeffy
for
getting
him
all
set
up
for
streaming.
A
Community
meetings
so
helpful
in
kind.
Even
when
I
forgot
things
and
Chris
doesn't
forget
anything.
Chris
blocker
gave
a
shout
out
to
Leggett
and
bend
the
elder
for
getting
us
upgraded
to
go
113.
That
was
a
huge
effort.
Harris
also
gave
a
shout
out
to
everyone
on
the
cube
con
planning
stretch,
especially
the
wonderful
contributor
summit
events
team
whoo.