►
From YouTube: Kubernetes Community Meeting 20170810
Description
We have PUBLIC and RECORDED weekly video meetings every Thursday at 10am US Pacific Time.
This week we have a 1.8 release update, 1.73 is out, and 1.6.8 is out. SIG PM has been working on defining just what we mean by "stability release" vs. "feature release". Then we have updates from SIG Cluster Lifecycle and SIG Big Data.
The Steering committee voting process has also begun! Check out the full notes:
https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY
B
Welcome
everybody:
this
is
your
community
meeting
for
kubernetes
for
August
10th
2017.
This
is
a
publicly
recorded
meeting.
We
keep
an
archive
on
YouTube
and
we
are
live
streaming
live.
So
thank
you
to
the
five
people
who
have
already
shown
up
to
the
livestream.
We
had
a
demo
cancelation
last
minute,
so
unfortunately,
we're
not
gonna
have
that
for
this
week,
so
we're
gonna
go
right
into
release
updates
with
Jace
hello.
C
So
make
it
quick,
1.8
is
rolling
right
along
got
some
great
stuff
happening
there,
we're
still
repeating
the
teachers
folk
and
that
that
work
over
in
conjunction
with
the
SIG's,
as
they
will
continue
to
give
us
some
demos
and
when
I
so
I
couldn't
resist
code.
Winter
is
coming
sorry
September
1st,
so
this
is
really
a
big
step
in
the
release
process.
So
we
want
to
make
sure
that
the
features
are
mostly
feature
complete
at
that
point.
So
please
know
Clayton,
that's
not
close,
so
yeah.
C
C
That
8
is
also
out
and
Thank
You,
Anthony
patch
manager
and
extra
just
a
just.
A
quick
word
of
thanks
the
patch
manager
job
is
a
long
and
sometimes
arduous,
and
occasionally
thankless
job
and
there's
a
lot
of
work,
and
you
basically
run
for
at
least
two
releases
because
of
policy.
So
if
you
see
the
release
managers
around,
please
thank
them
for
their
hard
work,
because
the
patch
patch
releases
a
lot
of
stuff
to
do,
and
it's
fantastic
that
they're
doing
that.
Thank
you.
So
much.
B
Alrighty
and
if
you
had
a
hard
time
hearing
that
because
of
the
volume
level,
basically
draft
release,
notes
will
be
pushed
out
through
the
normal
email
channels,
so
keep
an
eye
out
for
those
moving
on
to
the
project
management
section.
So
we
kind
of
added
this
after
some
feedback
as
to
get
a
little
bit
more
coordination
from
6:00
p.m.
and
the
other
SIG's
Jason
Dory
did
you
want
to
mention
the
agenda
items
here?
Yeah.
F
E
Regarding
then,
your
proposal
that
we
currently
have
again
and
feature
orientation
could
come
in
something
like
that.
So,
as
you
should
remember,
we
had
one
of
six
release
in
the
beginning
of
the
year
that
has
been
has
been
mentioned
as
a
stabilization,
at
least
at
the
correct
one.
At
seven,
it
is
defined
as
the
non
stabilization
released
at
kinetise
leadership
summit
in
San.
Jose
we've
been
discussing
this
pollicis
over
Lisa
humanities.
Where
do
we
have
like
more
like
what
kind
of
her
list
can
we
convene
a
mass?
E
A
stabilization
of
control
is
in
venomous
non
stabilization.
Until
this
week
we
haven't
had
any
defined
policy,
any
different
document,
any
defined
constructure
description.
What
how
should
release
given
itis
in
terms
of
the
stabilization
and
on
stabilization,
so
at
6:00
p.m.
and
the
crudest
to
Jason,
who
has
been
the
primary
person
to
prepare
this
document?
We
have
this
formalist
document.
We
have
formulated
description
and
this
meeting
we're
expecting
to
discuss.
Is
the
cocoa
community
to
oversee
ways
like
some
next
steps,
so
we'd
like
to
receive
like
go
signal
on
this
maiden?
Are.
C
So
people
have
it,
but
essentially
that
this
process
of
feature
focused
and
then
switching
to
more
of
a
stabilisation
focus
and
a
feature
focus
has
been
in
play
more
or
less
since
version
1
data,
so
I,
don't
think
we're
talking
about
anything
new.
What
we're
really
trying
to
drill
down
is
what
does
it
actually
mean
and
how
is
it
enforced,
because
at
the
end
of
the
day,
the
release
consists
of
the
things
that
people
put
in
the
code.
So
if
nobody
decides
to
do
any
work
on
stabilization,
then
ostensibly
it's
not
a
stabilization
release.
C
What
this
document
is
really
trying
to
accomplish
is
what
are
the
basic
characteristic
differences
between
that
and
what
are
the
differences
in
terms
of
the
product
management,
release,
management
and
architecture
groups?
What
are
what
are
they
doing
differently
per
release?
What
are
what
are
the
activities
that
might
be
different,
so
the
document
is
broken
out
into
just
describing
what
those
releases
look
like.
So
it
starts
with
feature
or
name
releases
saying
this
is
sort
of
what
it
is.
It
talks
about
what
the
stability
really
says
and
one
of
the
key
takeaways
of
the
stability
releases.
C
It's
it's
not
about
making
a
stable,
kubernetes
release;
it
is
about
trying
to
mature
features
out
or
determine
if
a
feature
that
we
would
like
to
promote,
maybe
doesn't
have
the
support
in
the
community
or
in
the
SIG's,
or
maybe
it's
just
something
that
we
thought
was
a
good
idea
and
turned
out
not
to
be
and
then
going
through
the
process
of
deprecating
that.
So
it's
really
about
just
being
really
mindful
about
how
we
steward
and
Shepherd
releases
through
the
process
and.
C
Moving
forward,
it
really
talks
about
some
of
the
other
activities
that
happened
during
a
release.
So
ideally,
if
we're
in
a
stabilization
period
that
might
extend
to
other
aspects
of
the
project
as
a
whole,
so
maybe
things
like
breaking
out
code
enter
their
own
repositories
or
refactoring
code.
That
we
all
know
is
maybe
not
ideal
things
like
the
cloud
provider
breakout.
Some
of
that
stuff
would
make
sense
to
do
during
a
stabilization
release
versus
maybe
a
more
feature,
focused
release
and
another
key
differentiator.
Is
it's
not
necessarily
about
features
per
se?
C
The
features
are
good
or
bad.
It's
really
about.
Where
are
we
expending
our
effort?
Because
what
we're
seeing
is
an
increasing
amount
of
burnout
and
a
lot
of
the
core
contributors
who
are
spending
a
tremendous
amount
of
time
not
only
just
working
on
the
project
code,
but
also
a
lot
of
a
minutia
around
testing
and
getting
things
approved,
and
that
burden
is
getting
higher
and
higher
every
release.
C
So
what
we
want
to
try
and
avoid
is
burnout,
and
part
of
that
is
directing
people's
efforts
toward
the
most
important
thing
that
they
can
do
with
their
time,
which,
hopefully
based
on
this
release,
cadence
of
alternating
feature
and
stabilization,
is
focus
on
this
one
one
aspect
of
the
release
as
much
as
possible
and
do
what
you
can
in
the
other
regard
so
definitely
features
would
be
prominent
in
a
stabilization
release
as
well.
But
that's
not
the
focus.
The
focus
is:
how
do
we?
How
do
we
mature
and
graduate
existing
features?
C
So
in
a
nutshell,
that's
it
at
the
bottom
of
the
document.
It
kind
of
talks
about
those
three
sort
of
program
management
states
which
are
cigar,
protects
your
cig
release
into
product
management,
so
I'm
not
sure
if
having
just
thrown
this
at
people
right
now,
if
it's
a
great
time
to
discuss
it
or
if
there
are
questions,
but
let's
go
and
open
the
floor
and
just
see
what
comes
in.
G
Communicating
more
concretely
what
our
goals
are
for
the
project
at
the
Leadership
Summit.
We
talked
about
increasing
the
focus
on
stabilization
in
general
and
just
to
give
a
brief
recap
of
that.
We
are
working
towards
trying
to
reduce
the
surface
area
of
what
has
been
called
the
core
in
the
past
and
we're
trying
to
formalize
the
delayers.
What
has
been
called
the
layers
proposal
in
cig
architecture.
G
Communities
repository
we're
trying
to
push
mature,
won't
widely-used
api's
like
the
workload
API
such
as
deployment
and
even
set
and
staple
set,
and
our
BA
for
authorization
policy,
and
things
like
that
that
sometimes
you
Pires
new
features
in
order
to
do
get
them
to
d1
or
GA
and
ensure
that
we
don't
need
to
break
backward
compatibility
of
the
API
in
the
future.
So
some
of
those
are
adding
features
in
1.8,
but
with
the
goal
of
getting
a
nose
too
stable
by
the
end
of
the
year.
G
So
I
think
we
need
to
look
very
carefully
about
at
the
features
that
are
being
developed,
and
this
is
efforts
underway
and
make
sure
we
have
overall
agreement
that
these
are
the
right
sets
of
things
to
be
focused
on
across
the
project.
I
realize
different
SIG's
have
different
priorities.
Cluster
lifecycle
is
trying
to
do
things
and
what
yeah
I
think
where
the
governance
could
come
in
is
have
a
review
of
whether
you
know
we're
all
rowing
in
the
same
direction
or
not.
G
Code
gets
merged
within
two
kubernetes
to
an
II's.
It's
too
hard
to
rip
things
out.
The
way
we
used
to
do
leading
up
to
one
dot
out
so
expect
those
kinds
of
changes
to
be
coming
1.8,
it's
kind
of
late
to
make
radical
changes.
But
we
are
working
on
building
some
kind
of
mechanism.
We
can
use
to
track
the
metrics
across
the
project,
get
involved
in
contributing
experience
if
you're
an
interest
in
that,
but
we're
exploring
a
couple
of
alternatives.
F
The
project
out
a
bit
more
and
I'm,
not
sure
if
folks
feel,
like
the
theme
of
features
or
work
being
done
overall,
is
actually
headed
in
that
direction
or
or
not,
but
it
seems
like
being
able
to
empower
SIG's
to
make
that
decision
for
go/no-go
is
a
good
first
step,
because
my
concern
is
a
lot
of
the
discussion
around,
but
this
seemed
to
be
like.
Well
sorry,
we
just
can't
solve
this
until
the
steering
committee
comes
around
and
I
guarantee
the
steering
committees
getting
reaction
is
gonna.
F
Be
sorry
we're
not
going
to
decide
this
we're,
not
the
choke
point
for
what
goes
in
and
what
goes
out
of
release.
We
are
going
to
delegate
this
to
the
right
people
to
make
that
decision.
So
we
are
the
right
people
today,
somewhere
the
right
people
are
here
and
I'm
trying
to
figure
out.
If
we
can
make
that
decision
today,
I
totally.
C
Yeah
and
I
think
Brian.
At
the
end
of
the
day,
yeah
I
mean
you've,
you've
nailed
this
so
succinctly
in
the
document,
which
is
there
is
a
schism
between
the
sig
power
structure
and
the
code
inherent
power
structure
of
our
of
the
owners,
files
and
approvers,
so
until
until
that
gets
reconciled
until
there's
a
direct
correlation
between
those
things
that
we're
still
gonna
be
in
this
boat,
because
I
could
spin
up
a
sig
fantastic
tomorrow
and
have
zero
authority
over
anything
in
the
project.
C
F
I
do
still
feel
like
holistically.
There
needs
to
be
somebody
who
can
take
a
look
at
the
set
of
all
features
that
are
going
like
what
what
is
all
the
work
that's
happening
for
kubernetes.
That
problem,
you
just
said,
was
really
difficult
to
visualize
right
now,
Brian,
it
still
seems
like
sig
cam
is
maybe
the
closest.
G
F
That
human
effort,
right
now,
like
I,
still
feel
like
somebody
needs
to
have
the
authority
to
look
at
the
zeitgeist
of
the
release.
To
say,
like
you
know
what,
even
though
you
six
are
saying,
it
looks
like
what
everything
you're
doing
is
in
the
name
of
stabilization
that
doesn't
seem
to
line
up,
and
we
disagree
with
that
needs
to
do
something
about
yeah.
G
And
the
way
I
would
like
this
to
work
is
at
least
my
current
mental
model,
unless
it's
proven
not
to
work
is,
as
you
said,
let
this
provide
top-down
guidance
to
things,
but
let
them
make
informed
decisions,
but
then
clearly
the
people
who
are
reviewing
the
content
of
the
release,
which
will
be
multiple
horizontal
suits
like
sick
release,
Suqian
docks
at
etc
should
all
have
the
power
to
push
back.
If
the
Stig
still
disagrees
and
that's
where
we
need
an
escalation
process
to
somebody
who
can
make
the
call.
G
So
that's
where
maybe
the
steering
committee
would
be
relevant,
hopefully
that
wouldn't
be
exercised
every
single
release
for
every
feature,
because
hopefully
most
people
on
the
project
are
reasonable
and
if
reasonable
objections
are
made,
it
will
get
resolved.
But
definitely
the
steering
committee
should
not
be
deciding
on
a
feature
by
each
true
basis
for
every
release.
G
What
goes
in
the
release
and
what,
if
we
provide
people
with
the
right
information,
I
hope
you
can,
they
will
make
the
right
decision,
but
we
have
had
cases,
for
example,
where
you
know
what
is
people
writing
the
documentation
or
reviewing
documentation
changes
that
it
was
exposed
that
well,
you
know
for
people
who
are
outside
the
little
bubble
of
developing
this.
You
know
what
you're
doing
doesn't
actually
make
sense.
So
we
need
to
revisit
that.
G
So
having
that
you
know
and
other
pairs
of
eyes
on
the
problem
sometimes
does
help
put
it
into
the
bigger
context.
So
I
feel
like
it's
gonna,
be
there
gonna
be
multiple
people
who
are
doing
not,
and
they
all
need
to
feel
like
they
can
say
they
can
question.
You
know
whether
this
should
really
be
happening
and
push
back
so.
H
I
pop
in
here
I
agree
with
pretty
much
everything
Brian,
saying:
I,
think
you
know
we
need.
We
need
a
way
to
be
able
to
to
empower
states
to
actually
make
rational
decisions
around
this.
For
me,
the
thing
that
that
I'm
having
trouble
with
is
that
we're
squishing
in
terms
of
what
the
definition
of
a
cig
is,
who
the
decision-makers
are
and
how
those
decisions
are
made
and
and
I
feel
like.
H
Like
you
know,
some
things
are
run
in
a
relatively
you
know:
efficient
sort
of
top-down
manner.
Other
states
are
more
of
a
cooperative
type
of
thing
and
I
think
that
that
the
different
styles
of
SIG's
meshes
differently
with
with
our
goals.
Out
of
this
and
so
I,
don't
know
well
I'm
pleased
you're
in
committee.
G
Yeah,
that's
where
the
point
Jase
mentioned
becomes
relevant.
Reconciling
owners
and
Sigma
membership
by
totally
agree
that
it's
really
kind
of
squishy
and
confusing
right
now
and
in
general,
the
owners
do
you
participate
in,
that
is
the
reviewers
and
approvers
in
the
owner's
files
do
participate
in
the
SIG's.
So,
for
example,
and
say
API
machinery,
the
people
who
attend
the
sig
and
then
people
who
are
in
the
owners
files
and
the
people
are
writing.
The
code
are
all
pretty
much
the
same
people.
G
C
C
We
want
it
to
be
something
that
we
all
decide
collaboratively,
but
at
some
point
there's
a
there's,
this
lever
that
can
be
pulled
about
how
much
process
or
how
much
authoritarian
needs
to
be
exercised
to
meet
our
goals,
and
so
I
think
your
your
proposal
specifically
and
there's
a
threat
I,
don't
have
a
link
to
it.
Basically,
splatting
something
out,
do
not
take
that
as
gospel.
That
was
just
like
a
little
straw.
C
Man,
no
I,
think
that
the
the
spirit
of
what
you
said
is:
let's
let
SIG's
self
organize
as
much
as
is
reasonable
and
responsible,
with
the
caveat
that
they
need
to,
at
the
end
of
the
day,
come
up
with
some
sort
of
way
of
shepherding
the
work
that
goes
into
the
project.
Components
with
the
overall
benefit
of
the
project.
I
mean
really.
What
we're
trying
to
do
is
make
sure
that
SIG's
are
all
rallied
around.
What
is
it
that
we
as
a
community
agree
on
and
SIG's.
C
You
are
essentially
a
structure
around
a
development
team,
more
or
less.
You
know
if
we
are
running
this
as
an
enterprise.
If
this
was
an
enterprise
software
organization,
you'd
have
the
the
SIG's
would
essentially
be
feature
teams,
and
so
there
there's
a
certain
amount
of
patterning
that
can
happen
around
feature
teams.
That's
that's
well
known
and
expected.
So
it's
like
how
do
we
capture
the
responsibility
of
future
team
with
the
right
amount
of
governance,
so
it
doesn't
choke
I.
C
H
Want
anyone
comes
being
modeling
too
much
against?
You
know
how
big
companies
work,
because
at
the
end
of
the
day
you
know
stuff
gets
done
when
people
are
willing
to
pony
up
and
write
code
and
documentation,
roll
up
their
sleeves
and
do
work,
and-
and
we
can't
do
like
like
we
can
have
the
Future
teams
owning
the
implementation,
but
we
can't
do
a
centralized
sort
of
planning
of.
Like
you
know,
it's
got
to
be
herding
cats.
H
I
And
so
we've
said
things
like
we
want
to
do
stabilization
and
everyone
else
says
yeah.
Yes,
yes,
we're
doing
stabilization
and
then
they
throw
20
features
until
they're,
saying
because
they're
sure
that
those
features
are
important,
but
then
a
neighbor
else's
six
features
right
and
I
think
that
actually
a
level
of
top-down
is
the
only
way
we're
gonna,
actually
I.
I
I
would
agree
with
that.
I
I
think
we
need
to
very
strongly,
but
we
have
to
have
that
message
of
we're
gonna
act
as
a
filter
and
sometimes
we're
actually
gonna
act
as
an
unfair
filter
right.
We're
gonna
say,
like
you
know
what
no
features
this
release
period
into
the
story,
sorry
and
people
will
say
but
but
we're
all
stable,
and
we
have
to
be
willing
to
say
because
we've
said
this
before
like
when
we
did
a
stabilization
release.
A
G
This
is
where
we're
lacking,
you
know
comparison
to
a
company
was
mentioned
and
we
have
200
monthly,
active
contributors
and
that
might
just
be
a
kubernetes
to
kubernetes,
so
we're
at
a
scale
where
our
company
would
have
a
lot
more
management
and
infrastructure,
project
management,
people,
management
and
so
on,
and
at
this
scale
it's
just
really
hard
to
have
visibility,
nor
to
audit
everything
that's
going
on.
So
we
talked
about
favor,
eating
automation
over
process
and
that's
that's
where
I
really
hope
that
can
invest
more
in
mechanisms
like
metrics
dashboards
or
so
on.
G
A
The
other
thing
to
look
at
in
terms
of
Brian's
point
about
larger
organizations
than
more
hierarchy
and
to
Brendan's
point
about
the
peer
relationships
cross
project
that,
at
some
level,
in
my
mind,
was
in
fact
mystic
leads
and
the
state
leadership
summit,
and
that
peer
group
was
being
built
to
hold
people
accountable
in
that
cross
project
way.
And
we
have
that
as
a
solid
peer
group,
and
we
have
discussions
in
those
groups,
so
I
think
there's
a
way
to
bolster
it
more,
as
opposed
to
saying
that
it
has
to
be
top
down.
C
Yeah
I
think
that's
that
we
really
need
to
just
I.
Think
say
it
right
is
that
sig
leads
should
not
be
invested
with
more
power
or
more
privileges
than
other
people,
and
that's,
of
course,
they're
they're
doing
the
work
that
would
warrant
that
otherwise
and
I
think
that'll
help
a
lot
with
this.
This
power
structure
problem,
because
really
leadership
is
about
influencing
others
and
allowing
others
to
do
their
best
work.
A
I
All
right
like
it's
there's
someone
who
owns
networking
who
is
the
you
know
the
lieutenant
who
owns
that
has
their
get
repo
where
they
slowly
merge
things
in
and
then
only
things
out
of
that
get
repo
merchant
in
the
environment.
That
implicitly
is
a
management
structure,
even
though
it's
not
an
explicit
like
HR
manager,
yeah.
H
I
Especially
in
the
code
I
feel
like
it
in
any
elevation
of
the
code
into
the
like.
It's
like
it's
one
thing,
that's
for
the
sig
to
say.
Yes,
this
code
is
good
for
the
from
the
SIG's
perspective,
but
we
don't
have
a
separate
step
where
we
say
this
code
is
good
for
the
projects
perspective
and
that's
actually,
when
you
do
the
two-phase
commit
or
the
two
two
different
steps
of
commit
where
it's
like
commit
to
the
storage.
I
You
know,
whoever
owns
the
storage
part
of
the
kernel
and
then
commit
to
the
main
line
of
the
repo.
Like
that's
those
are
two
different
statements
and
it's
possible
that
we
should
separate
those
two
out
and
I
know
that
we're
trying
to
separate
projects
out-
and
maybe
that
will
be
the
way
that
we
said
that
would
way
to
achieve
this.
I.
G
I
C
G
E
Would
second
it
in
terms
of
the
features
and
in
terms
of
barons
in
the
future
so
before,
and
until
now,
we
still
don't
have
any
like
specific
rules.
How
can
we
say
some
person
as
how
they
deliver
the
feature
or
features
old
you
ready
for
to
be
submitted
and
to
be
Oh,
ginger
release,
just
just
to
say
no
go
despite
the
fact
that
we
have
had
some
formal
agreements
on
like
some
guidelines
for
this
reason
so
like
we
had
for
for
the
current
release
that
week?
E
Yes,
we
have
initially
agreed
that
this
release
will
be
externalization
release
and
our
initial
agreement.
That
was,
that
means
that
we
expect
them
to
have
more
beta
and
stable
features
than
alpha
features.
At
the
same
time
as
Brian
as
Brian
mentioned,
we
have
now
60
opened
features
under
the
features
report,
and
most
of
them
are
alpha
features
because
most
of
these
features
have
been
already
started
develop.
The
process
has
already
been
started
a
few
iterations
ago
and
now
they're
ready
to
be
delivered.
E
J
Sure
so
I
can
give
an
update
sort
of
on
what
we're
working
on
for
1.8.
We
just
went
over
this
that
are
sitting
on
Tuesday,
so
it's
pretty
fresh
in
our
minds
sort
of
long,
the
lines
of
working
toward
from
stabilization.
We
had
a
goal
of
closing
about
10
percent
of
issues
that
were
labeled
kind,
bug
or
documentation
improvement,
which
we've
actually
already
hits
sort
of
early
in
a
cycle.
It's
somewhat
balanced
by
new
bugs
and
documentation
issues
being
opened,
but
I
think
we
are
the
middle
east
moving
in
the
right
direction.
There.
J
Up
on
this
and
adding
more
automated
testing
for
kube
admins,
we
were
again
moving
the
needle
there
in
the
right
direction
in
terms
of
sort
of
new
things
that
we're
working
on
and
Q
Bevin
in
1/7
did
not
have
a
great
story
for
upgrades,
and
so
you
can
sort
of
spin
this
as
a
new
feature
or
as
trying
to
fix
something.
It
didn't
work
very
well
before
in
terms
of
stabilization,
but
we're
trying
to
add
an
upgrade
command,
so
you'd
run
cube.
J
Admin
upgrade
if
you
guys
are
interested
to
see
how
that
works
in
the
it's
not
yet
merged.
In
the
in
a
pre
merging
form,
Lucas
gave
a
great
sort
of
a
15
or
20
minute
demo,
with
with
conversation
back
and
forth
on
Tuesday,
so
you
guys
can
go
check
out
that
video
and
once
it
merges
I,
think
we'll
try
to
do
a
similar
demonstration.
This.
This
larger
group
meeting
as
well,
along
with
upgrades
we've,
also
been
working
a
lot
on
self
hosting.
J
How
hosting
was
initially
intended
to
be
the
mechanism
by
which
we
got
upgrades
to
work
more
smoothly.
We've
actually
figured
out
that
we
can
do
upgrades
without
self
hosting,
so
we
have
sort
of
a
split
model
going
forward
where,
if
you
create
a
new
1.8
cluster
with
cube
admin,
you
will
get
self
hosting
by
default.
J
If
you
upgrade
from
one
seven
to
one
eight,
you
will
stay
on
the
static
pod,
manifest
cluster
and
when
you
upgrade
from
once
the
one
eight
to
one
nine
during
the
next
really
cycle,
your
static
pod
cluster
will
be
transitioned
automatic
us
self
hosting
cluster
and
lets
you
explicitly
so
we're
trying
to
take
sort
of
a
sort
of
slower,
more
moderated
approach
to
how
we
do
upgrades
to
make
it
a
little
bit
less
painful
for
users
and
I.
Think
we've
also
got
a
couple
of
sort
of
smaller,
smaller
things
and
it
works.
J
Bootstrap
tokens
have
been
moved
to
beta
and
we've
got
more
test
coverage
at
it
for
those
and
we've
also
I
guess
lost
our
representative
to
the
sig
PM
group,
and
so
I'm
just
begin
to
do
that
for
the
1.8
release
cycle
and
we've
decided
that
we're
gonna
sort
of
rotate
through
different
people
for
each
release
cycle.
So
this
might
be
a
pattern
that
other
folks
want
to
follow
where
we
nominate
sort
of
a
different
person
to
represent
the
sig
for
each
release.
J
J
Justin
at
the
beginning
of
the
release
cycle
signed
up
to
try
to
get
out
of
management
to
alpha
by
the
end
of
the
1.8
release.
So
that's
one
of
the
Alpha
features
in
the
futures
repository.
It's
not
clear.
He
wasn't
at
the
meeting
on
Tuesday,
went
over
updates
on
our
1.8
progress,
so
I'm,
not
sure
where
that
is
I
haven't
seen
any
parts
good
bye
thanks.
J
J
As
long
as
I've
got
the
mic,
I'll
mention
we,
we
have
a
number
of
sort
of
groups
from
a
lifecycle
that
informed
that
have
sort
of
additional
meetings
during
the
week.
So
we
have
a
group,
that's
specifically
working
on
some
minutiae
of
cube
admin
where
it's
much
more
sort
of
detailed,
focused
meeting.
We
had
one
of
those
yesterday
where
we
were
lucky
enough
to
have
Clayton
and
Jordan
join
us,
so
give
us
some
outside
perspectives
on
how
we
were
implementing
self-hosting,
in
particular,
we're
working
on
adding
a
checkpointing
features
at
couplet.
J
So
there
was
a
long
discussion
about
that.
People
are
interested,
and
then
we
have
another
breakout
group
for
work.
You
have
an
adoption,
so
we
have
a
number
of
installer
tools
in
the
ecosystem
and
we're
trying
to
start
figuring
out
what
it
would
take
to
rebase
each
of
those
different
installer
tools
on
top
of
cube,
and
these
cube
admin
is
a
common
building
block
for
us
all
over
them.
So
that's
another
separate
feature.
B
K
K
Sparc
is
an
engine
for
large-scale
data
processing.
We
have
an
upstream
issue
that
is
filed
that
tracks,
although
just
work
what
we
did
since
the
last
time
we
gave
an
update,
was
two
new
releases.
We
made
announcement
of
stream,
we
have
people
that
are
actually
trying
these
things
out
and
thousands,
of
course,
and
it
giving
us
feedback
and
so
on.
So
the
ongoing
focus
now
is
adding
a
few
more
features,
bringing
parody
with
yarn
and
mesas.
In
this
respect,
and
also
up
streaming.
K
K
K
We
did
a
lot
of
performance
benchmarking
and
they
have
looked
a
couple
of
plugins,
because
some
some
notions
and
some
of
the
assumptions
with
respect
to
data
locality
are
kind
of
broken
when
you
bring
them
on
on
on
kubernetes
and
their
ongoing
efforts
to
have
better
affinity,
support,
node,
selectors
and
we're
reading
on
the
persistent
volume,
local,
persistent
storage
improvements
in
Q&A
discord
to
help
our
lifecycle
management,
their
airflow
is
just
it's
a
new
project.
It's
a
workflow
management
solution
that
is
pretty
popular
when
it
comes
to
orchestrating
data
processing
applications.
K
Typically,
you
might
Express
take
data
from
source,
a
transform
it
in
this
manner
by
running
it
through
spark
or
hive,
and
then
do
this
subsequent
action.
So
this
this
effort
is
led
by
Bloomberg
Andrew
and
a
ton
of
community
members
are
there.
There
is
an
external
roadmap.
We
have
consensus
from
the
upstream
community
to
have
given
any
support,
live
the
air
flow
itself.
So
this
is
fairly
new,
but
we
have
some
ongoing
design
and
development
discussions
here
and
find
the
cube
arbitrator.
It
is
owned
by
six
scheduling.
It
is
meant.
A
K
Add
some
of
the
features
that
yarn
has
with
respect
to
being
able
to
share
a
cluster
fairly
with
data
processing
workloads
into
communities.
So
this
is
being
developed
out
of
core.
It
was
recently
championed
by
Tim,
Sinclair
and
incubated
by
Joe
Joe
Peter
yeah.
So
mostly,
our
involvement
here
is
to
go
back
your
feedback
on
various
things
that,
because
the
users
this.
K
B
All
right
great,
thank
you
very
much
all
right.
Moving
on
to
the
announcements.
We
only
got
three
today.
The
first
is,
you
should
have
seen
the
mail,
the
kubernetes
dev
from
Tim
Hawking,
talking
about
the
steering
committee
voting.
If
your
name
is
not
on
the
list
of
members
in
good
standing,
there's
a
little
forum
link
that
you
can
click
on
there
and
you
can
kind
of
fill
in,
and
you
know
why
you
feel
you
should
be
on
there
so
make
sure
you
check
that
out.
Action
might
be
required
or
might
not
be
required
by
you.
B
There
was
a
interesting
bug
that
was
filed
by
Paul,
about
generating
a
kubernetes,
developer,
guide
and
I
know
a
bunch
of
us
has
kind
of
been
talking
about
it.
It's
one
of
those
things
that
everyone's
like
it
would
be
a
nice
to
have,
and
he
found
a
bug
at
just
the
right
time
when
everyone
was
paying
attention
and
it
seems
like
it's
getting
a
lot
of
traction
and
people
are
starting
to
commit.
B
So
if
you
want
to
get
involved
in
this
in
this
effort,
please
check
out
that
bug,
leave
a
comment
and
get
a
hold
of
us.
If
you
want
to
help
I'm
gonna
try
to
tackle
that
as
best
as
I
can
when
I
get
back
from
holiday
and
lastly,
it's
gonna
be
two
weeks
until
office
hours
go
ahead
and
follow
the
link.
That's
gonna,
be
on
23
August.
E
B
F
F
One
quick
question
it
on
the
on
the
email
thread
about
people
who
are
listed
as
members
of
standing.
What
I
don't
see
is
like
what
a
definition
of
a
member
of
standing
is
I'm,
not
looking
for
a
super
strict,
formal
definition
I'm
just
looking
for
for
somebody
who
might
want
to
nominate
themselves
what
I
need
you
to
you
get
to
vote,
they
want
to
write.
No
I
know
that's
what
you
get
to
do,
but
what
that's.
G
F
L
I'm,
what
a
member
of
standing
is
and
what
the
standing
confers
you
knew
that
whatever
is
here,
is
to
be
picked
for
defining
the
list
of
members
of
standing
was
going
to
be
insufficient.
So
we
just
think
here
is
think
that
we
could
actually
auto-generate,
and
we
said
we
aren't
there.
The
intention
is
pretty
lenient
if
people
feel
like
they
fit
an
active
contributor
and
they
want
Ted
standing.
L
F
That's
that's
what
I
was
asking
the
question
is:
is
I
got
some
of
that
I'm
just
trying
to
clarify
like
why
they
might
went?
That's
my
my
fault
for
searching
for
member
of
standing
instead
of
members
of
standing
or
standing
in
the
dock.
I
didn't
find
it
on
my
first.
Try
sorry
about
that.
There's
thanks.