►
From YouTube: Kubernetes Community Meeting 20181129
Description
We have PUBLIC and RECORDED weekly meeting every Thursday at 6pm UTC.
See https://github.com/kubernetes/community/blob/master/events/community-meeting.md for more information!
A
Hello:
everyone
welcome
to
the
kubernetes
community
meeting
for
November
29th
2018,
as
we
as
this
meeting
is
recorded
and
broadcast
on
YouTube,
so
say
nothing.
You
don't
want
to
share
with
the
entire
Internet
the
we
have
a
number
of
topics
for
the
meeting
today
I,
although
I
expect
it
to
be
overall
a
short
meeting,
because
it
is
the
week
before
GUP
con
the
week
before
release
and
on
top
of
which
a
bunch
of
people
are
at
AWS
reinvent.
So
that
said,
I.
The
first
thing
here
is:
can
someone
volunteer
to
take
notes?
A
A
The
self
I
first
ordered
here
is.
We
have
our
demo
of
the
week
the
docs
modeling
working
group,
Andrew
Chen
and
Dominick
tour.
Now,
if
I'm
pronouncing
that
correctly
dominic
excuse
me
if
I'm
not
are
going
to
be
presenting
on
a
demo,
I
guess
of
what
they've
come
up
with
for
modeling
our
Docs.
So
you
want
to
go
ahead.
Sure.
B
B
All
right,
okay,
so
all
right,
so
Dominic
works
at
sa
P
and
he's
on
loan
to
us
from
sapa
for
about
six
months
to
work
on
modeling,
and
this
is
something
that
we're
working
on
to
improve
like
people's
mental
models
of
how
communities
works,
cuz,
I'm
sure,
all
of
you
remember
when
you
started
learning
kubernetes
like
you
know
what
was
your
experience?
Well,
it's
a
beast.
B
Everyone
says
that,
and
you
know
it
has
this
high
perceived
complexity,
but
when
you
actually
take
a
look
at
like
the
patterns
that
it
uses
the
design
patterns,
there's
actually
a
limited
number
and
and
it's
used
to
build
up
its.
You
know,
functional
complexity
and
it's
actually
quite
elegant
but
like
in
learning
it.
It's
quite
difficult.
You
know.
So
why
is
there
this
disconnect
right?
So
then
this
points
to
actually
a
communications
issue
and
then
Dominic's
going
to
talk
about
modeling
and
how
we
might
use
it
Dominic,
either
and
I
think
he's
on
mute.
B
C
C
Thank
you.
In
the
case
of
documentation,
we
have
one
individual
that
studies
the
system
and
then
subsequently
communicates
his
or
her
mental,
and
during
this
communication
we
face
encoding
loss
of
information.
We
may
not
put
our
mental
model
in
the
correct
words
or
diagrams
and
we
face
decoding
loss
at
the
receiver,
where
the
receiver
may
misunderstand
what
we
are
trying
to
convey,
and
this
leads
to
different
mental
models
at
best
to
incomplete
mental
models
at
worst
correct
mental
models.
And
who
can
you
take
the
next.
C
B
Yeah
so
looking
at
you
know,
the
whole
dock
set
I
realized
that
the
docks
are
very
tasks
focused
they're,
not
really
concept
focus,
so
we
introduced,
you
know,
concepts
on
a
need-to-know
basis,
but
because
we
kind
of
don't
weave
them
all
together
into
a
coherent
picture,
it's
hard
for
people
to
reason
about
what
kubernetes
behavior
is,
and
one
example
of
this
is
like,
if
you
just
take
a
look
at
this
replica
set
right.
So
so,
if
you
take
a
look
at
this
yamo
like
you
know,
what
do
you
think
it's?
It
would
produce
right?
B
So
you
probably
most
people
think
you
know.
We
would
say
this
replica
set
specifies
a
desired
state
of
desired
state
of
three
pods
each
pod,
consisting
of
one
busybox
Newton
right.
That's
what
we
normally
think,
but
if
you
actually
look
at
what
communities
does
it
only
pays
attention
to
the
label
like
at
busybox?
It
just
wants
three
pods
with
these
labels
on
so
you
know
in
most
situations,
this
just
works
fine
with
our
mental
model.
Right
we
like
in
a
zero
state.
If
there's
no
pods
already,
you
know
we
deploy
that
replica
set.
B
But
if
they're,
you
know
if
they're
ready
pause
but
they're
running
different
containers,
but
they
have
the
same
app
label
still,
then.
If
then,
the
replica
set
won't
do
anything
right,
and
so
this
is
where
you
know
our
mental
models
made
collide
with
like
how
it
actually
works.
So
we
need
to
do
a
better
job
in
documentation
to
help
people
craft
their
mental
mas.
So
they
understand
the
behavior
of
kubernetes
right.
So
the
docs
should
help
users
develop
mental
models
so
that
they
may
reason
about
what
kubernetes
actually
does.
So.
C
The
fundamental
modeling
concepts
have
been
developed
in
the
context
of
si
P
many
many
years
ago,
and
the
fundamental
modeling
concepts
is
an
approach
to
system
modeling
that
contains
concise
definition
and
formal
and
conceptual
models
of
a
systems,
structure
and
behavior
and
an
review.
Oh
thank
you,
and
so
just
this
is
the
demo
part.
Of
course,
these
are
just
tip
it's
in
the
limited
amount
of
time
in
the
last
three
month
we
applied
this
approach
to
various
aspects
of
kubernetes.
C
On
this
slide,
for
example,
you'll
see
a
definition
of
what
a
steady-state
actually
is
and
it
depicts
kubernetes
overall
behavior
on
the
highest,
that
is
its
convergence
towards
a
steady
state.
In
this
case,
you
see
a
graphical
model
that
companies
form
a
model
in
the
alloy
specification
language
and
if
we
could
go
to
the
next
slide.
C
Thank
you.
This
slide
depicts
kubernetes
high-level
architecture.
It
shows
core
components
and
their
interactions
already
on
this
slide,
even
without
accompanying
text,
you
can
deduce
or
include
that
individual
components
do
not
communicate
directly
with
each
other,
but
only
indirectly
via
the
API
server.
You
can
already
come
to
the
conclusion
that
components
do
not
share
state
by
communicating,
but
they
communicate
by
sharing
state,
which
is
a
central
aspect
of
kubernetes
design,
and
the
next
slide
please
thank
you.
This
slide
shows
a
deep
dive
into
kubernetes
high-availability
setup.
C
It
depicts
a
multi
master
setup
and
also
does
highlight
kubernetes
implementation
of
leader
election,
as
I
said
in.
For
the
sake
of
time,
these
are
just
Tippit's.
If
you're
interested
in
this
approach
to
modeling
and
to
the
models
that
we
came
up
with
so
far,
you
may
find
a
list
of
references
later
in
this
presentation
that
Andrews
come
share.
B
You
know
to
explain
what
it
does
a
situation,
but
we
would
rather
people
like
understand
how
things
work
without
having
to
actually
look
at
the
source
code,
and
so
what
we've
been
working
on
for
the
past
couple
months.
So
our
process
is
like
coming
up
with
these
models
right.
So
first,
we
kind
of
test
them
out
and
we
do
like
a
little
presentation
at
the
weekly
sig
Docs
meeting
right.
B
We
call
like
fun
with
modeling
kind
of
after
the
Sheldon
Cooper
on
you
know
on
Big
Bang
Theory,
and
then
then
you
know
we
well
so
the
first.
We
do
that,
but
also
we
we
talked
to
engineers,
we
interview
them
and
we,
like
you,
know,
ask
some
in-depth
questions
and
then
we
try
to
validate
these
models
and
like
these,
two
steps
are
not
necessarily
they
can
be
in
either
order
right,
so
we'll
bounce
back
and
forth
until
as
we
kind
of
iterate
on
the
different
models.
B
So
we've
already
interviewed
different
engineers
that
I've
been
working
on.
You
know
master
components
or
node
or
API
machinery
to
really
like
make
sure
that
the
models
are
correct
and
that
we
are
what
we're
saying
is
is
correct
and
then
we've
been
creating
some
posts
on
medium,
and
this
is
to
help
us
refine
like
how
we
introduce
these
topics
and
explain
how
they
work
and
also
they
get
feedback.
B
That
way
like
you
know,
it
helps
us
to
kind
of
mature
the
models
and
make
sure
that
what
we're
saying
is
just
correct
and
in
a
way
that
people
can
digest,
and
once
we're
done
with
that,
the
plan
is
to
then
fold
that
back
in
to
Grenada
I/o,
so
that
so
we're
kind
of
working
our
way
through
different
topics.
Right
now,
but
tentatively
in
q1,
we're
gonna
start
like
opening
up
PRS
and
adding
a
lot
of
this
content
back
into
community
style.
So
it
won't
necessarily
be
in
the
same
format
as
like.
B
A
Okay,
thank
you
very
much
we're
out
of
time
for
questions
during
the
meeting.
So
if
you
do
have
questions
for
Andrew,
Dominik
follow
up
with
them
on
slack
or
in
cig
docks
or
in
the
usual
places,
if
you
guys
could
add
links
to
the
community
meeting
notes
to
those
slides
and
to
whatever
repo
you
have:
okay,
okay,
I.
Next
up.
Let's
talk
about
releases,
starting
with
the
current
release,
Aish.
A
D
A
Okay,
thank
you
very
much,
and
and
I
am
looking
forward
to
being
off
the
release
team
again
to
the
cell
I
for
patch
releases.
We
had
patch
release
updates
on
I
all
branches,
all
actively
maintained
branches.
Earlier
this
week,
I
don't
even
need
the
patch
maintainer
here
want
to
say
anything
to
that.
A
A
Okay,
we'll
go
ahead
anyway,
a
bunch
of
patch
updates,
I
think
mostly
this
Monday
for
112-111
and
110.
Okay.
As
a
reminder,
anybody
who's
still
in
1-9
really
needs
to
upgrade
or
you
need
commercial
support,
so
they
back
port
those
things
for
you.
So
those
are
where
we
are
with
the
release.
So,
let's
go
ahead
and
move
on
to
cig
updates
and
that's
going
to
start
with
sega
architecture
and
one
of
our
new
cig
architecture
leads
Matt
Farina
man.
E
Right,
so
this
is
based
on
the
template
with
some
tweaks.
So
for
those
of
you
who
don't
know,
sick
architecture
is
concerned
with
things
like
maintaining
your
architectural
consistency
over
time,
there's
policy
and
government
stuff
like
the
API
governance,
all
API
changes
go
through
a
very
thorough
process.
The
deprecation
policy
code
organization
there's
the
cap
process,
even
though
many
saves
won't
handle
caps
themselves.
We
do
own
the
process
and
just
general
issues
around
cooling,
ID
scope,
that's
kind
of
what
take
architecture
in
general
is
concerned
with,
since
the
last
update.
E
E
Now,
we've
done
a
lot
of
talking
around
the
process
and
there's
some
tools
and
issues
that
are
being
worked
in
the
background
to
improve
that
and
we're
working
on
things
like
code
organization,
how
to
handle
staging
how
to
handle
importing
kubernetes
/
kubernetes,
because
there
are
a
lot
of
people
who
are
importing
that
and
between
things
like
minor
versions.
We
are
breaking
EP
eyes
and
go
modules
are
coming
and
how
are
we
going
to
handle
all
of
that?
So
that's
one
of
the
ongoing
things.
E
E
Well
good
example
of
that
is:
some
clusters
will
have
windows,
other
others
won't,
and
how
do
you
handle
conformance
for
those
different
kinds
of
situations
and
profile
has
been
one
of
the
things
that
are
being
discussed
as
a
way
to
do
that,
and
last
week
I
became
a
co-chair
to
try
and
relieve
some
of
the
pressure
on
Bryan
and
chase
in
the
process.
We
do
have
a
few
sub
projects
and
so
I'll
go
through
those
real
quick.
We
have
the
API
reviews
and
here's
the
status
on
it.
E
We
have
a
process
and
I
won't
open
it
up
for
the
API
reviews
and
we
do
have
a
status
board
if
you
are
bored.
If
you
go
to
the
kubernetes
sakes
org,
there
is
a
repo
called
architecture
tracking
and
it's
got
a
bunch
of
different
projects
and
in
there
there
is
one
for
the
API
refute
and
you
can
see
what's
completed,
what's
currently
underway
and
assigned
and
then
what's
in
the
backlog,
that's
coming
that
we
know
that
it
needs
to
be
dealt
with,
and
so
right
now,
just
as
always,
there's
ongoing
API
reviews.
E
It's
been
a
few
days
since
the
board's
been
updated,
so
there
might
be
some
changes,
but
there's
constant
reviews
happening
by
a
group
of
people
who
are
responsible
for
that.
Then
there's
the
Cape's.
The
big
thing
to
know
about
keps
is
they're
gonna,
be
moving
over
to
the
enhancements
repo
from
the
community
repo
it's
tomorrow
or
tomorrow's
the
last
day,
but
it's
coming
up
very
very
soon.
So
if
you've
got
a
cap
or
a
change
to
account,
see
about
getting
it
merged
as
soon
as
possible.
E
We
do
have
a
dashboard
for
tracking
this
as
well.
That
looks
at
things
that
are
in
the
backlog,
sig
review
things
that
need
architecture
and
api
reviews,
because
there's
lots
of
things
that
need
to
come
to
stick
architecture
or
to
work
out
some
details
for
me:
Nate
got
a
review
and
then
things
that
are
being
implemented
in
process,
and
so
we
do
have
a
board
that
tracks
that
as
well.
This
is
a
short-term
thing
if
you
actually
want
to
help
with
these
kinds
of
toolings.
E
Let
me
know-
and
you
can
put
you
in
the
right
direction,
but
for
now
we're
tracking
it
here
we're
looking
to
get
a
little
bit
better
process
and
tooling
around
this
as
well.
So
it's
not
as
manual
finish
on
the
board
and
then
our
third
sub
project
would
be
the
conformance
testing
and
you
can
see
we've
got
things
and
changes
to
that
that
are
in
flight,
it's
being
minimally
work.
E
So
if
you
are
interested
in
contributing
there's
several
ways,
you
can
do
one
review
caps
related
to
the
stage
that
you're
in
if
you're
gonna
say.
Actually,
if
you
go
back
to
the
cap
board,
you
will
find
that
there
aren't
just
catch
that
you
own,
but
there
are
ones
that
are
related
to,
and
so,
if
you
come
to
this
dashboard
and
say
here
and
say,
storage
and
you
clicked
on
sink
storage,
you
can
see
all
of
the
ones
that
are
related,
because
somebody
in
another
say
and
said
hey.
E
This
relates
to
state
storage,
for
this
relates
to
state
networking.
I'm
gonna,
put
them
on
a
relates,
take
a
look
at
them
and
give
them
feedback,
especially
if
you're,
a
technical
leader,
a
chair,
make
sure
that
these
things
get
reviewed
because
you
might
be
surprised
for
other
states
think
relate
to
you
that
they're
working
in
caps
on
so
the
first
thing
I
would
suggest
is
if
you
want
to
contribute
review,
the
caps
related
to
your
sales
at
the
kubernetes
contributors
of
it.
There
is
AB
off
on
test.
It's
right
after
lunch,
I
think,
wonderful
timing.
E
A
Okay,
well,
if
we
don't
have
any
questions,
you
know
where
to
find
cigar
architecture
on
their
mailing
list,
on
slack
and
apparently
on
the
various
Kanban
boards
stretched
across
github.
So
next
up
for
cigs,
six
scalability
had
to
postpone
because
of
lead
availability,
poorly
availability.
This
week,
Tim
pepper,
who
is
one
of
our
leads
for
cig
release-
pointed
out
that
well,
there
is
a
release
update
every
week.
We
don't
generally
talk
about
cig
release
once
so.
He
is
here
to
remedy
that.
F
We
we
have
people
from
release
here
every
week,
talking
about
the
current
release
and
once
a
quarter.
We
do
a
retrospective,
but
sig
release
has
actually
not
told
you
what
we
do
on
and
what
we're
doing,
what
we're
changing
on
an
ongoing
basis.
So
I
am
Tim,
pepper,
I
work
for
him,
where
I
am
one
of
the
new
chairs
in
cig
release
and
just
wanted
to
give
a
little
bit
of
a
rundown
on
what
we
are,
what
we're
doing
to
start
getting
more
transparency
on
that
more
information.
F
So
what
we
do
this
is
coming
straight
from
our
charter.
The
link
is
there,
but
we
are
about
putting
out
the
kubernetes
releases
on
a
reliable
schedule.
We
are
also
very
much
about
mentoring
and
growing.
It's
it's
a
challenge
to
put
out
the
release
and
it's
a
very
easy
place
to
have
burnout
and
there's
a
huge
spread
of
engagement
to
make
sure
that
the
releases
get
out
and
to
manage
some
of
that
that
complexity
around
burnout.
F
So
we
we've
put
a
lot
of
effort
into
having
a
formal
process
of
shadowing
and
bringing
people
into
that
and
training
and
rolling
things
over,
and
the
goal
is
that
we
have
something
that's
supportable
over
time,
that
it's
not
just
for
three
months,
wouldn't
say
we're
perfect
on
that.
We
have
a
lot
of
work
to
do
to
continue
improving
it.
F
Additionally,
we
we
touch
on
tooling
some
of
this
overlaps
with
other
SIG's
in
terms
of
just
basic
testing,
but
also
sig
testing
and
test
infrastructure
for
the
overall
project.
But
where
that
comes
into
the
release
process,
we
have
involvement
and
some
cone
ownership
as
well,
and
then
a
goal
of
automating
things
and
I
highlighted
some
words
on
the
slide,
and
you
know
highlight
the
D
and
automated,
because
I
think
a
lot
of
us
believe
there's
not
as
much
as
we
want
automated.
F
So
we
have
a
lot
of
work
to
do
around
automate
it
still,
but
that
is
a
clear
goal
of
the
sig
and
then
we
partner
very
much
with
the
other
sig
sig
release.
Sometimes
we
say
that
we
don't
do
real
work.
Click
release
engineering
is
real
and
hard
work.
Integration
is
hard,
but
all
of
the
other
SIG's
that
are
doing
feature
development.
F
But
in
the
release
process
on
this
quarterly
sort
of
three-month
cycle,
we
currently
have
four
releases
a
year.
We
have
initial
period
where
we
work
with
the
SIG's
to
narrow
that
discussion
down
into
sort
of
more
committed
work
and
tracked
work,
and
at
that
point
sort
of
four
weeks
in
we
have
an
enhancements
freeze.
So
that
is
the
work
that
we
are
tracking
as
a
release
team,
so
that
we
can
do
specific
risk
management
and
tracking
on
what
is
going
into
the
release.
F
But
then
it's
open
source
masters
open
code
just
flying
in
for
quite
a
few
weeks.
Eventually,
we
hit
a
period,
we
call
code
slush
where
we're
trying
to
kind
of
bring
down
that
velocity
a
bit
and
then
code
freeze
or
we're
very
specifically
freezing
the
master
branch.
This
is
also
the
time
where
a
release
branch
gets
created.
So
you
start
to
have
a
fork
for
the
release
versus
master
and
code
gets
either
fast
forwarded
from
master
off
to
that
release,
branch
or
cherry-picked.
F
As
we
go
through
this
phase,
this
phase
is
shrinking.
The
freeze
we're
trying
to
make
this
lighter
more
efficient
for
people,
but
at
that
point
during
code
freeze,
it's
all
about
critical
bug,
fixing
and
solidifying
the
CI
test
signal,
which
ideally
has
been
green
all
along,
but
really
we
have
regressions
that
we
have
to
manage
and
work
on
fixing
basically
right
around
now.
This
was
last
night
on
code,
freeze,
ins
for
the
current
release
and
master
branch
reopens
and
effectively
master,
as
of
today
is
114
content.
F
F
So
that's
just
sort
of
like
the
the
quick
overview
release
process
stuff
for
folks
who
maybe
aren't
as
familiar
with
it
so
back
to
sort
of
normal
sig
update
stuff.
What
we
did
last
cycle,
we
have
merged
a
charter
and
we've
had
some
turnover
in
our
chairs.
Jace
has
graduated
on
to
emeritus
status
and
huge
thank
yous
from
everybody
on
cig
release,
past
current
release
teams
to
everything
he
does
on
an
ongoing
basis.
Thank
you.
Thank
you.
Thank
you
and
then
Steven
Augustus,
a
Red
Hat
and
myself
from
VMware,
have
joined
as
chairs.
F
In
addition
to
Caleb
miles,
who
is
continuing,
I
think
at
this
point,
I
mean
already
touched
on
it
briefly,
but
the
naming
features
moving
to
enhancements
that
was
communicated
pretty
broadly
on
K
dev
and
I'll
talk
a
little
bit
more
about
it
in
the
next
slides,
but
last
cycle
so
112
release.
It
went
out
more
or
less
on
time.
We
were
usually
within
a
few
days
on
the
releases
another
highlight
there
is
we
had
our
first
and
on
Google
branch
manager.
F
We're
working
on,
like
I,
said
earlier
kind
of
spreading
the
team
ensuring
that
there's
more
sustainability.
Some
of
this
making
the
sausage
type
of
stuff
on
the
release
had
started
out
very
much
Google
centric
in
terms
of
how
the
automation
and
controls
around
security
and
things
like
that
happen.
So
we
continue
to
peel
away
the
last
vestiges
of
kubernetes
by
Google
versus
the
open
project
that
we
are
and
we're
basically
almost
down
to
zero
on
that.
So
that's
awesome.
Progress.
F
We've
done
a
bunch
around
documenting,
so
the
role
handbooks
that
I
refer
to
on
the
prior
slide
as
well,
that
there
are
lots
of
info
on
how
we
operationally
do
releases
we've
continued
shortening
the
code
freeze
period
and
in
last
cycle.
Also,
the
move
to
tide
was
something
that
very
well
discussed
here
in
the
community
of
meetings
as
well,
so
things
that
are
coming
up
more
around
features
and
enhancements
caps
are
moving
out
of
cake
community
there's
a
kata
of
post
link.
There
I
think
Caleb
sent
that
yesterday,
but
there's
discussion
there.
F
I
would
encourage
folks
to
look
at
our
113
release.
I
should
just
given
the
update.
We
are
on
track
for
December
3,
something
to
call
out
here.
This
is
the
shortest
release
cycle
ever,
which
is
testament
to
Isis
leadership,
I
think,
but
also
all
the
other
sig
leads
for
focusing
on
constraining
the
content
focusing
on
stability
and
to
do
it
short,
but
also
have
it
on
time
is
awesome.
Teamwork
on
everybody
in
terms
of
our
dashboards
in
test
grid,
we've
moved
things
that
were
flaky
or
unmaintained
under
maintained
from
blocking
to
informing
and
past
releases.
F
The
release
team
has
really
had
to
kind
of
visually
sort
and
say,
like
you
know,
that
thing
is
always
a
problem.
We're
just
gonna
kind
of
ignore
it
for
right
now,
but
we're
starting
to
formalize
and
clean
that
up
and
ideally
then,
some
of
those
things
if
they're
important,
we'll
get
them
fixed
up,
get
them
maintained
and
bring
back
in,
but
we're
doing
just
some
coordinating
so
that
we
have
a
more
reliable
signal.
F
F
There's
an
issue
link
there
and
then
also
building
build
tools
around
that
and
some
other
things
need
some
cleaning
up.
We've
got
some
duplication
there.
This
enhancement
versus
features
stuff
that
we
talked
about
or
I've
talked
about
briefly
before
continue
refining
the
process,
their
code
freeze,
in
addition
to
shortening
it,
making
sure
that
it
actually
works
right
for
people.
F
People
understand
it
and
the
process
is
smooth
and
efficient
without
a
new
risk
to
release
stability,
and
then
that
ties
into
tied
and
automation
and
labels
and
how
we
make
the
the
merge
process,
efficient
and
and
transparent
and
understood,
and
then
continuing
on
that
shift
to
stable
branch
management
becoming
more
of
a
team.
Another
big
topic
area
is
discussion
around
release,
cadence
and
possibly
changing
that
faster,
slower,
devil,
stable
and
I've
got
some
more
slides
to
talk
about
that.
F
But
that'll
be
just
a
little
bit
later
here,
so
one
other
area
may
be
less
specific
to
the
cycle.
So
much
as
cig
release
during
the
coming
period.
We
want
to
do
a
more
formal
ization
of
our
sub
projects.
We've
been
very
much
focused
and
an
overly
busy
just
on
getting
releases
out
but
release
team
is,
is
arguably
a
sub
project
of
sig
release
and
not
the
only
one.
It
happens
to
almost
be
the
only
one.
That's
had
consistent
staffing,
though
so
part
of
changing
that
is
defining.
F
What
are
the
other
things
we
want
to
do?
Documenting
them
start
trying
to
start
getting
more
volunteers
involved
and
make
some
progress
operationally
on
some
other
things.
So
areas
we've
been
talking
about,
are
sort
of
broadly
release,
engineering
and
infrastructure,
automation,
improvements,
a
sub
portion
of
that
is
license
compliance
validation.
There's
been
some
looking
going
on
over
the
last
months
on
that
trying
to
try
and
formalize,
and
maybe
finish
off
some
things
there,
but
get
something
more
ongoing
and
staffed
as
well
and
then
again.
Another
sub
part
of
release
engineering
is
release
security.
F
All
of
that
comes
together
and
it's
a
big
space
where
we
could
use,
subject
matter,
experts
getting
involved
and
working
on,
improving
our
processes
and
then
finally,
we
have
just
recently
sponsored
a
working
group
that
we're
calling
working
group
LTS
more
on
that
in
the
coming
slides.
So
how
all
of
this
affects
you,
obviously
with
anything
kept
related
watch
for
caps
in
the
usual
places.
F
F
Better,
if
you're
involved
earlier
as
things
are
drafted
versus
at
the
point
that
it
turns
into
a
kept
in
your
a
stakeholder
and
you
review
at
that
point
in
it-
didn't
have
your
early
input
that
you
you
end
up
with
with
less
optimal
thing
as
being
proposed.
That
working
group
will,
though,
so
very
proactively,
be
asking
certain
sig
leads,
who
are
clearly
blocking
stakeholders
to
get
involved
earlier,
but
the
more
broadly
the
community
is
thinking
about
this
better
and
but
to
be
more
specific.
What
is
this
working
group
LTS
ting?
So
it's
an
early
formation.
F
There
is
a
bunch
of
discussion,
a
very
long
thread
and
lots
of
opinions
on
ke
dev.
There
are
some
links
here
for
folks
who
would
like
to
read
more
about
it,
but
we've
got
a
PR
out
to
be
added
to
the
the
sig
list
at
the
bottom
there's
a
set
of
working
groups,
one
of
the
things
that
we're
doing
there
is
to
have
a
proposed
charter
of
what
the
working
group
is
which
isn't
technically
required
in
the
governance
model.
F
There's
also
a
PR
underway
right
now
that
Jordan
liggett's
doing
just
to
better
clarify
what
is
our
support
stance
like
I
briefly
described
like
three
months
patches,
but
what
does
that
really
actually
mean?
And
what
are
the
version
skews?
How
do
we
manage
actual
update
path
for
our
end
users?
So
getting
that
better
to
find
today
is
a
really
big
deal
and
that's
a
very
active
PR
in
terms
of
discussion.
There's
a
link
to
more
information
about
where
to
find
the
working
group.
We've
got
regular
meetings.
F
Google
Groups
lack
all
the
all
the
regular
things
and
then
there's
also
a
presentation
there,
just
sort
of
just
trying
to
give
a
sense
of
initially
what
we
think
this
working
group
is
doing.
A
lot
of
that
echoed
also
in
the
Charter
document.
So
how
you
can
contribute
sig
release
definitely
always
needs
release.
Team
volunteers,
there's
a
link
there
to
a
presentation.
I
did
at
cube
Connie
you
just
talking
about
how
to
get
involved
in
the
release
team
and
how
there's
a
lot
of
opportunity-
and
this
is
also
not
just
about
coding.
F
F
We
have
our
regular
sig
release
meetings,
we're
trying
to
be
more
regular
about
that.
Every
two
weeks
and
one
of
the
focus
areas
over
the
coming
period
will
be
better,
defining
and
staffing
our
sub
projects
and
then
kept
drafting
related
to
all
of
that
where
to
find
us
there's
links
to
our
current
chairs,
our
home
page,
our
slack
Channel
and
our
Google
Groups
and
now
there's
a
short
overview
of
all
of
what
we
are
doing
right
now.
A
G
A
So
I
and
then
there
is
not
a
cap
of
the
week
or
a
contributor
tip
of
the
week
this
week.
As
a
reminder,
those
are
not
the
exclusive
property
of
Aaron
or
of
cig
p.m.
if
you
are
working
on
a
cap,
and
you
want
to
share
it
with
the
community
and
make
sure
that
people
know
about
it.
Please
contact
us
or
drop
a
note
in
the
community
meeting
topic
stock
that
you
would
like
to
put
your
cap
on
the
schedule
and
we
will
do
the
rest.
A
A
G
So
we're
sold
out
slash
waste
listed
for
the
contributor
summit.
That's
the
Monday
before
cube
con.
If
you're
a
sig
chair
tech,
lead
or
sub
project
owner
literally
last
call
we're
closing
it
off,
and
we
are
up
against
the
fire
code
as
far
as
packing
as
many
people
as
we
can.
So
it's
gonna
be
a
good
event.
Thanks
for
those
of
you
that
have
been
helping
out
being
responsive,
we've
gone
ahead
and
added
the
schedule
for
that
to
the
existing
kubernetes
community
calendar
and
there's
a
link
there.
G
The
pit
bid,
dots,
Lee,
slash,
kubernetes
summit
and
I
went
ahead
and
put
that
link
in
the
hash
contributor
summit.
On
slack.
Do
remember:
please,
subscribe
to
the
calendar,
don't
just
copy
it
over
just
in
case
there
are
changes
and
will
I'm
working
on
a
PR.
That
will
add
some
wordage
on
how
you
can
do
that
and
there's
a
link
there
for
event
information.
G
If
you
want
to
look
at
schedule
and
all
the
other
event
details
real
quick,
any
meeting
scheduled
for
the
rest
of
the
year
release
retro
sounds
like
it's
gonna
be
good
to
go
for
next
Thursday
week.
After
is
going
to
be
Q
cons,
so
no
meeting
and
then
no
Q
cons
the
rest
of
December
and,
as
we
said,
January
third,
it
will
be
sig,
apps,
UI,
cig,
VMware
and
meet
our
contributors
will
be
next
week
on
5
December
and
I
put
the
link
there
for
those
of
you,
so
that
is
definitely
on
for
December.
G
However,
kubernetes
office
hours
will
not
be
going.
This
December
because
will
be
a
cube
con.
Any
questions
on
any
of
that,
oh
and
sorry,
Paris,
is
reminding
me.
Yes,
the
the
contributor
summit
is
going
on
Sunday
and
Monday
the
Sunday
night.
There
is
a
social
event.
If
you
click
through
at
the
garage,
you
can
click
through
there.
You
should
have
RSVP'd
by
now,
but
if
you
haven't
please,
let
us
know:
okay,.
A
That
is
everything
except
for
the
shout
out.
So
let
me
go
through
the
shout
outs.
We
have
some
shout
outs
on
Twitter
for
the
113
release
team
lead
by
sundar.
You
can
follow
the
link
there.
Another
shout
out
eye
to
eye
for
keeping
us
in
line
the
whole
cycle.
As
an
awesome
team
release
lead
a
shout
out
to
MRI
for
adding
a
search
bar
to
test
grid,
so
you
don't
have
to
dig
to
find
the
right
dashboard,
which
is
pretty
cool
if
you
haven't
found
it
yet.
So
that
is
your
release.
A
for
fast
and
insightful
help
with
Signet
work
flakes
a
huge
shoutout
from
ice
to
all
of
the
113
release,
leads
and
shadows
I
for
efforts
at
every
stage
do
with
the
cycle
enabling
us
to
stabilize
and
hopefully
release
on
time.
We
were
scheduled
to
release
sometime
we're
actually
kind
of
running
out
of
time
to
change
that
schedule
so
to
release
some
time
and
she
lists
all
of
the
section
leads
there.
A
I'm,
not
gonna,
read
them
out,
plus
a
special
shout-out
to
a
bunch
of
people
who
are
not
technically
in
the
release
team,
but
who
have
really
been
doing
as
much
work
as
anybody
whose
name
is
on
that
release.
Team
roster,
as
many
of
them
often
do
including
dims
liggett,
Justin,
I,
Kristoff,
Ben
and
Steven
Augustus,
and
then
finally,
a
shout
out
to
mr.
Bobby
tables
for
significantly
reducing
Gwyn's
administrative
overhead
for
the
new
contributor
workshop.
A
So
thank
you,
everyone,
everyone
who
contributes
to
make
this
a
great
project
and
if
you
know
somebody
who
has
done
something
special
to
make
kubernetes
great,
then
please
post
it
in
the
shoutouts
Channel
in
slack,
so
that
we
can
read
them
off
for
the
community
meeting,
and
so
they
can
know
that
they
are
appreciated.
And
with
that
we
are
going
to
finish
up.
This
meeting
see
many
many
of
you
I
at.