►
From YouTube: Kubernetes Community Meeting 20160324
Description
We have PUBLIC and RECORDED weekly video meetings every Thursday at 10am US Pacific Time.
https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY
Demo checkin, community feature governance, wiki changes, 1.3 timeline, SIG-Federation update.
A
Push
the
recording
button:
this
is
a
public
and
recorded
meaning
of
the
Cooper
Nettie's
community
and
today
is
Thursday
march
three.
Fourth,
our
agenda
is
relatively
late.
We
had
a
cancellation
in
demos
this
morning,
so
I'm
going
to
take
the
opportunity
to
talk
for
a
moment
about
whether
or
not
the
demo
space
is
meeting
people's
needs,
and
so
we'll
do
that.
In
a
minute
we
have
TJ
gold
sermon
as
soon
as
I
see
him
join
talking
through
the
proposed
1.3
milestone
timelines.
A
Last
week
we
had
a
bunch
of
different
special
interest
groups
report
out
about
the
work
that
was
going
to
happen
in
1.3,
and
everybody
had
a
lot
to
digest.
So
I
want
to
draw
comments.
If
you
want
to
talk
a
little
bit
about
that,
and
then
we
have
a
couple
of
special
interest
group
reports.
If
we
have
time
and
it's
interesting-
we
can
I
saw
a
bunch
of
new
faces
on
here.
So
we
can
do
a
couple
of
introductions
if
people
are
interested
but
we'll
see
how
the
timing
goes.
A
C
D
E
That
sentiment
as
well,
I
think
that
the
demos
are
very
employment
and
for
those
of
us
who
are
really
heads
down
on
particular
features
just
to
get
a
chance,
what
other
people
in
the
community
are
doing,
how
other
people
perceive
cooper
Nettie's,
and
you
know
what
vendors
are
doing
with
two
brunette.
It's
all
super
fascinating,
good.
A
A
Yeah
I
am
actually
actively
back-channel.
This
is
why
I
look
for
people
to
take
notes,
speaking
of
which
we
need
someone
to
be
taking
notes.
This
is
why
I
asked
people
to
take
notes
for
me
is
because
I
am
a
generally
actively
back-channeling
with
people
going
okay.
So
two
more
minutes,
let's
go
so
that's
very
helpful.
Don't
have
a
volunteer
to
take
notes
and
thank
you
rob
okay
and
Lee.
Thank
you
for
taking
notes.
Last
week.
A
A
A
F
Mind
I
think
the
interesting
thing
here
is
not
the
list
of
what
people
want
to
do
as
a
project.
How
are
we
going
to
prioritize
because
there's
going
to
be
stuff,
that's
going
to
require
you
know
external
work,
for
people
to
review
and
and
sort
of
bring
stuff
on
board.
So
you
know
I
feel
like
we're
in
this
face
of
like
let's
do
all
the
everything's
right
and
there's
going
to
be
a
certain
amount
of
prioritization.
That
needs
to
happen,
and
that's
that's
where
the
heart
decisions
come.
Okay,.
A
And
I
know
you
and
I
Joe
have
had
some
conversations
about
what
that
might
look
like
and
we're
pulling
together
more
conversations
and
proposals
and
such
on
that
so
defining
things
that
look
look
like
a
path
that
is
more
clear
for
features
how
to
get
a
feature
reviewed.
How
to
get
a
future
accepted
committed,
get
all
of
this
information
in
so
that
is
I
hope
coming
next
week
for
a
longer
conversation
on
that
will
be
sharing
the
the
draft.
A
B
My
concern
is
people
back
back
door
and
say
they
said
no
to
me,
but
I'm
gonna
do
it.
Anyway,
that's
that's
been
and
it's
a
community,
so
you
don't
want
to.
You
have
to
there's
an
Avenue
where
that
happens
and
there's
an
Avenue
more
like
you
know
what
we
actually
needed.
This
wasn't
our
priority.
Sorry
well.
A
And
there
are
two
very
different
nose.
Not
now
is
one
of
them.
This
is
not
a
priority,
but
there
is
also
that
is
out
of
scope.
That
does
not
fit
the
vision
and
that's
a
different
problem
and
can
potentially
be
a
stickier
one,
but
there
is
also
then
the
you
know.
Is
there
an
edge
or
an
extensibility
point
that
can
be
built?
So
you
can
do
your
thing.
A
I'll
swear
if
you
find
that
there
is
a
customer
base
for
user
base,
for
it,
I
kind
of
in
so
there's
a
it's
like
improv,
yes
and
yes
and
we'll
build
it
as
an
extensibility
point
for
you,
but
not
right.
Now:
okay,
but
yes,
we're
talking
through
different
processes
and
suggestions
about
how
we
can
make
this
more
clear
because,
right
now
it
is
not
as
clear
as
it
could
be.
Any
other
bits
that
people
want
to
talk
about.
Ron,
yeah,.
E
I'll
raise
something
real,
quick
where
it
seems
like
ultimately,
the
13
roadmaps
right.
The
12
roadmap
ended
up
on
the
KU
brunetti
Zwicky
last
time.
Yes
and
the
Gubru
Nettie's
wiki
is
be
available
for
edit
to
those
people
who
have
lgtm
pritchett
is
correct:
logistical
now,
as
somebody
who's
part
of
a
sick.
A
I
have
a
to
do
to
write
an
update
to
your
wiki
ticket,
which
actually
suggests
that
we
break
out
the
wiki
into
actual
repos
so
that
we
its
own
space
in
order
to
give
each
cig
its
own
control
over
whatever
they
want
to
put
in
this
and
not
have
to
even
go
through
a
gating
factor
of
docs,
so
that
we
don't
again,
we
don't
have
to
give
the
broader
lgtm
privileges
to
people
who
either
either
or
especially,
don't
want
it
or
shouldn't.
Have
it.
E
Or
they
agree,
but
just
to
sort
of
go
back
to
the
13
release
notes.
Do
we
think
that
those
are
going
to
end
up
in
this
new
place
and
what
do
we
think
the
process
might
be
to
sort
of
update
that
that
roadmap,
as
we
sort
of
realize
what
scopes
looking
like,
or
course,
maybe
that's
the
time
where
we
look
at
actually
using
the
milestones
a
little
bit
sooner.
I
would.
A
G
Our
plan
is
to
use
the
milestone
and
the
fundamental
problem
we
had
with
a
natural
roadmap
doc
checked
into
the
repo
is
that
it
was
always
willfully
out
of
date.
Also
with
our
old
doc
process.
We
had
the
additional
problem
that
it
was
very
out
of
date.
Copies
of
it
were
were
made
and
were
then
people
update
forever.
G
You
know
just
again
a
lightweight
wait
to
post
information
like
right
there
on
the
spot.
It's
sort
of
you
know
the
wiki
explosion
at
SIDS
in
particular,
yeah.
That
content
is
really
difficult
for
the
signal
indicators
to
keep
up
to
date
being
on
the
wiki.
So
one
option
definitely
would
be
to
move
it
off.
The
wiki.
H
G
Know
definitely,
in
general,
we're
discussing
separate
repose
for
the
cigs,
so
they
can
use
wiki's
or
put
whatever
content
they
want
their.
As
far
as
the
miles
the
road
map
in
particular
I'm,
not
a
big
fan
of
Doc's,
it
seems
to
be
impossible
to
keep
them
up
to
date,
so
we
are
going
to
try
to
aggressively
use
the
milestone
and
keep
the
milestones
to
date.
This
time
is
it
done.
E
G
And
then
general,
I'm
in
favor
of
that
I
mean
it's.
Unfortunately,
we
have
to
work
around
cubs
playing
lock
mechanism,
but
you
know
definitely
feel
free
to
our
number
of
issues
filed
against
github
and
various
github
repos
that
you
can
+1
on
now
that
they've
finally
implemented
the
+1
feature,
but
in
lieu
of
that
I
am
in
favor
of
giving
lots
to
do
this.
You
know
if
you
want
to.
We
have
our
bot
machinery
is
in
contribs
know.
If
you
want
to
submit
a
PR
to
do
something
like
this,
you
would
definitely
entertain
it.
E
G
As
I
was
saying
in
general,
I'm
in
favor
of
creating
separate
repose
for
various
purposes,
we're
creating
more
and
more.
I
think
one
of
the
main
gating
factors
is
sorting
out
how
dependencies
would
work
between
repos
and
getting
all
of
our
automation.
Working
like
automatic
PR,
an
issue
assignments,
CLA
bots.
You
know
all
the
different
bots,
but
you
know
for
now.
If
we
just
wanted
to
create
repose
for
the
cigs
and
let
them
manage
issues
and
wikis
and
not
totally
uncool
so
yeah.
If
you
want
a
repo,
just
let
us
know.
E
Okay,
so
I
just
I
apologize
for
hijacking
the
meeting
with
this
discussion,
but
like
I'm,
just
trying
to
figure
out
what
the
right
forum
is
to
discuss
these
kinds
of
issues
going
forward.
As
you
know,
it's
fur
to
open
up
the
github
issue
and
cc'd
some
people
and
there's
been
a
lot
of
discussion
internally,
but
I
haven't
seen
that
externally.
So
if,
like
slack
or
the
mailing
list,
is
a
better
forum
to
sort
of
hash,
this
stuff
out,
I'm
super
in
favor,
taking
it
to
the
venue
where
we
can
talk
about
this.
This.
G
Meeting
is
fine,
as
in
you,
I
mean
in
general,
just
realized.
For
the
past
few
weeks,
we've
been
absolutely
slammed
by
1
q,
onda
three
planning
Google
next
quarterly
planning.
You
know
it's
just
an
avalanche
of
stuff,
so
I
apologize
for
not
being
responsive
but
literally
get
notifications
every
30
seconds,
24
hours
a
day.
So
sometimes
it's
hard
to
get
the
signal
to
the
noise
and.
A
This
is
y
SI.
Lo
second
brian's
a
point:
this
forum
is
about
what
you
guys
is
the
community.
It
shouldn't
be
all
about
reporting
out.
So
this
is
a
perfect
space
to
say.
First
I
raised
an
issue.
Is
that
the
right
place?
Yes,
I,
think
that's
the
right
place
and
beat
it.
You
guys
didn't
know
you
I
didn't
get
the
follow-up
I
expected
wanted
hoped
for.
Let's
talk
more
about
it.
A
I
No
I
meant
okay.
Can
everyone
see
that
yep,
okay
cool?
So
this
is
this-
is
on
the
Cooper
Nettie's
wiki,
just
wiki
release
one
dash
three
and
basically
I
just
laid
out
a
strawman
schedule
for
1.3
and
the
assumption
is
it
should
look
like
1.2
of
some
tweak.
This
is
not
really
envisioning
anything
crazy,
so,
first
off
I,
kinda
and
I
also
sent
out
an
email
yesterday,
the
day
before
to
Cooper
nice
dev,
and
so
most
people
should
have
this
in
their
inbox
is
buried
somewhere.
I
If
we
look
at
one
point
to
the
sort
of
gist
of
it-
and
this
is
not
how
we
planned
it,
this
is
how
it
kind
of
actually
happened,
because
I
think
that's
probably
more
valuable.
We
did
about
eight
weeks
of
coding
and
then
declared
feature
complete
two
weeks
of
bug,
fixes
and
testing
and
then
put
head
in
a
code.
Wall
head
was
in
a
coat
slush.
Another
two
weeks
is
bug,
fix
and
testing
and
then
declare
up
beta
and
actually
branch
and
then
from
beta
branch
to
final
was
about
another
two
weeks.
I
I
In
some
cases
you
know
we'd
get
seven
weeks
in
and
we
discover
that
something
is
is
well
off
on.
So
we
should
check
back
on
those
sooner
also,
just
in
general,
being
more
conservative
with
the
release
the
number
of
features
in
the
release
and
and
be
willing
to
release.
You
know
if
a
features
not
quite
ready,
tell
ourselves.
Yes,
it's
okay
for
this
to
go
in
1.4,
like
minimize
the
number
of
things
we
truly
hold,
the
release
for
and
then
more
tactically
feature,
coatings
seemed
to
take
a
little
longer.
I
We
fooled
ourselves
a
little
bit
with
declaring
that
and
we're
still
letting
some
features
finish
up
and
out
past
that
it
seems,
like
we
could
probably
add
one
more
week
to
the
future
coding
part
of
it
and
remove
one
week
from
hug
fixing
and
I
would
say.
This
is
with
a
big
caveat
as
long
as
we
stay
on
top
of
test
flights,
because
that
was
another
thing
that
did
us
and
cost
us
probably
a
week
or
two
future
coding
during
1.2
yeah.
G
And
general
I
have
a
couple
of
things
to
say
about
that.
One
is
if
we
can
keep
features
better
tested
all
along
the
way.
That
would
certainly
help
a
lot,
rather
than
sort
of
waiting
until
the
end
to
go,
write
a
bunch
of
tests
and
fix
a
bunch
of
tests
that
uncovered
problems
very
late,
some
in
some
cases
some
very
severe
problems.
G
G
There's
a
lot
of
a
compressed
schedule
this
time
due
to
all
the
test,
flakes
and
feature
complete
slipped,
but
you
know
in
general,
we
didn't
get,
has
serious
testing
of
the
beta
releases
as
I
would
have
liked,
whereas
once
we
announced
120
within
hours,
we
got
feedback
that
could
have
been
exposed
weeks.
So
I'm
going
to
just
pick
up
the
data.
So
so
we
need
to
figure
out
how
to
how
to
instead
of
eyes.
G
People
will
actually
keep
the
tires
a
little
harder
on
the
betas
you
know,
and
if
we
are
going
to
slip,
features
from
from
one
release
to
the
next.
Definitely
keep
that
in
mind
as
you
implement
it,
because
we
need
incomplete
features
to
not
be
confusing
to
users
right.
So,
if
a
feature
is
not
fully
baked,
it
needs
to
be
invisible
right.
It
needs
to
not
appear
in
the
API
means
to
not
appear
in
documentation.
It
needs
to
not
potentially
cause
problems
than
any
of
the
components.
Do
it
only
partially
existing?
B
G
We're
absolutely
going
to
have
to
have
a
lot
more
rigor
around
this
if
we
want
to
get
to
shorter
release
cycles
right
the
past
to
release
cycles
have
each
been
about
four
months,
even
though
our
target
has
been
three
months.
You
know
if
you
want
to
get
to
three
months
or
two
months
or
than
one
month
we're
going
to
need
a
lot
more
rigor
around
this
kind
of
a
thing,
and
you
know,
but
definitely
better
test
for
backward
compatibility,
upgrade
testing
and
the
like
as
well
so
we'll
get
there.
G
I
I,
so
that's
great,
we
do
need
non
flaky
coverage.
One
thing
we
discovered
in
1.2
is
you
can
write
in
two
ends
and
be
very
convinced
that
they're
great,
but
as
soon
as
you
actually
submit
it
and
turn
it
on
the
fact
that
our
test
infrastructure
is
just
running
those
tests.
All
the
time
uncovers
flakes
quickly
in
those
tests
so
for
feature
that
sort
of
come
down
to
the
lot
wire
and
they
get
committed
on
the
feature
complete
date.
G
F
Introduce
another
so
so
I
mean
one
one
option
here
is
to
make
sure
that
new
features
are
under
some
sort
of
flag
for
that
release
so
that
they
can
easily
be
turned
off
or
the
default
for
actually
exposing
that
feature
late
in
the
game.
If
we
had
that
framework,
then
if
we
find
that
okay
you're
there
for
feature
complete,
but
then
the
things
just
a
bug,
far
more
flaky
or
whatever
you
can
actually
pull
that
out
at
you
know,
as
you
go
down
to
the
wire
the
two
bit
clearer.
If
they
were
optimistic,
yeah.
J
I
think
it's
quite
reasonable.
Pj
to
you
know,
we've
got
this.
Eight
weeks
provide
your
feature
gets
in
before
that
eight
week
deadline
and
it
has
end-to-end
tests
associated
with
it.
Even
if
those
are
not
100
send
coverage.
But
you
know
your
feature.
Basically
works
and
you've
run
those
repeatedly
and
then
you
know
they're
they're
submitted
as
part
of
your
PR.
As
you
say,
if
the
flakes
happened
shortly
after
that
we
just
roll
back
everything
we
just.
J
G
So
one
challenge
there
is
that
we
need
to
make
test
resources
available
to
people,
because
when
the
test
can
run
by
the
PR
builder,
they
run
hundreds
of
times
more
frequently
than
people
running
them
on
their
own
right,
and
it's
just
hard
for
people
to
do
that
without
you
know
a
lot
of
resources
and
infrastructure
to
do
that
for
them.
So
you
know
practically
speaking
it.
We
can
roll
things
back
or
turn
things
off,
but
then
we
immediately
lose
coverage
that
we
were
getting
that
expose
those
flakes
in
the
first
place
right.
G
So
what
we
saw
was
returned
features
on
there
cause
flakes.
We
turn
them
off
fix
those
problems
turn
on
get
more
flakes,
turn
off
again
right,
so
eventually
like
with
deployment
we
just
left
there
on,
and
we
just
put
concerted
effort
into
pounding
out
all
the
flights
and
that
it
actually
allowed
us
to
make
faster
progress.
You
know
was
annoying
I
understand
for
like
everybody
else
who
had
to
kick
their
pr's,
you
know,
and
maybe
there's
some
automation.
We
could
build
that
way.
Make
that
better.
G
Like
automatic
patterns
like
for
board,
we
have
a
pattern
detector
to
catch
warnings
in
and
errors
and
logs
and
things
like
that,
and
we
automatically
file
bugs
for
new
ones.
But
we
have
patterns
saying
ignore
this
one,
because
we
already
investigated
it
and
we
know
where
it
is
and
we
fixed
it
or
it's
not
fixable
or
whatever,
whatever
it
is,
so
we
could
create
some
sort
of
framework
like
that
they
would
say
you
know,
we
know
what
this
is
automatically.
G
We
start
the
tests
and
put
in
the
issue
number
there
corresponds
to,
and
then,
when
someone
fixes
the
test
that
can
go
clean
up
that
pattern,
you
know,
but
we
need
to.
We
need
to
find
a
way
that
we
don't
lose
the
coverage
that
exposes
the
flakes,
because
if
it's
a
like
1
in
500
flake,
it's
those
are
pretty
hard
to
find
on
your
own,
especially
if
you're
running
an
isolated
environment
a
lot
of
times
they
don't
get
exposed
ever,
even
if
you
run
it
a
thousand
times
in
a
row.
It
sounds.
J
To
me
like
what
we're
missing
at
the
moment,
you
know
if
you,
if
you
commit
a
test,
that
that
goes
into
the
main
repo
and
that's
the
only
way
that
you
can
get.
Actually
that's,
not
true.
It's
it's
the
best
way.
You
can
get
your
tears
to
actually
run.
It
then
potentially
blocks
all
other
mergers
if
it
fails
all.
E
J
E
J
E
Really
we
would
really
like
to
get
to
a
point
where
all
the
tests
are
run
all
the
time,
but
some
subset
of
tests
become
blocking
or
gating
for
merges,
and
that
really
should
be
the
definition
of
when
a
feature
has
fully
landed
and
as
part
of
a
release,
it's
been
stable
enough
and
non
flaky
enough
over
some
subset
of
history
that
we
can
verify
as
a
community
publicly
and
that's
what
will
allow
us
to
add
a
tag.
That's
as
okay,
please
block,
may
stop
on
this,
something
that
I
really
think.
There's
no
reason.
E
G
E
I
mean
we
sort
of
had
these
really
long
documents
that
describe
what
it
means
to
write:
a
good
e
2e
test,
what
it
means
to
write,
something
that's
very
conformance
based
so
it'll
work
across
multiple
clusters
and
multiple
deployments
across
multiple
cloud
providers
and
I.
Think
as
we
can
improve
the
level
of
test
coverage
across
all
of
those
dimensions.
That
will
then
allow
us
to
decide,
give
us
enough
confidence
that
the
tests
are
worthy
to
gate
on
so.
G
G
I
E
Sorry
I
had
one
other
quick.
He
succeeds
that
conv,
it's
a
testing
which
was
just
that
I
noticed
we.
We
called
the
release
done,
but
then
there's
this
additional
period
where
we're
still
working
on
the
docks
and
the
release
has
been
cut
and
we
announced
it
loudly
and
proudly
to
the
community.
But
there's
all
this
other
stuff.
That's
not
quite
documented
correctly.
E
G
I
I
So
alpha
is
as
a
reminder,
go
out
every
two
weeks
as
the
project
moves
on,
so
we
were
sort
of
always
cutting
an
alpha
two
weeks
of
bug,
fixing
test
to
Claire,
beta
and
then
branch
and
then
two
weeks
of
bug,
fixes
and
then
calling
out
doc
works
explicitly
here
and
releasing
1.3
final
again.
This
is
similar
to
what
we've
had
in
past
milestones.
I
One
if
you
get
down
that
would
be
the
end
of
coding
would
be
May
twentieth
as
our
goal,
roughly
well
nine
weeks,
two
months
away
and
then
I
actually
call
that
a
few
times
check
in
on
the
status
of
all
1.3
features
in
the
community
meeting.
I,
don't
know
what
the
right
way
to
sort
of
get
a
feel
for
this
is,
but
if
one
of
our
really
key
important
1.3
features
is
trending
way
behind,
we
need
a
way
to
catch
that
and
either
adjust
the
dates.
I
J
E
F
F
B
The
I
guess
I'm
thinking
through
some
of
what
I
saw
an
OpenStack.
It
was
all
PTL
technical,
like
shepherding
of
these
projects
and
it
ended
up
causing
it
just
it's
you're
overloading
people
who
are
trying
to
get
the
code
done
management
responsibilities.
I
actually
think
that
this
is
a
place
where
management
is
actually
helpful
and
empowering
to
people.
You
know
weren't
actually
contributing
the
code
ever
mistake
and
getting
it
done
just
said
literally
having
a
discussion
about
this
and
OpenStack
context
last
night
over
dinner.
So
it's
a
dress.
I
B
B
Who
those
people
aren't
I've,
so
yeah
fully
admit
to
having
a
second
agenda
on
this?
You
want
those
people
involved.
You
want
their
names,
we
want
to
know
who
they
are,
so
don't
want
the
developers
to
proxy
for
the
product
managers.
You
want
the
opposite
and
an
OpenStack.
One
of
the
big
fail
points
was
that
we
had
a
lot
of
hidden
product
managers
and
this
would
expose
them
well.
B
Those
and
if
they,
if
they
have
the
resources,
then
they
can,
they
can
product,
provide
this
role
in.
If
not
it's
a
bigger
company.
Doing
I'm
not
saying
it's.
Only
one
company,
organizing
only
their
people,
I'm
saying
this
is
a
management
role
in
the
community
for
somebody
who's,
not
coding.
So
they
have
the
objective.
Atita
talk
to
multiple
people
and
say:
here's
what's
going
on
yes,
you're
on
track,
no
you're,
not
they
can
hear
it
you're.
The
technical
people
had
bring
a
bias
into
those
conversations
that
doesn't
give
us
it's
the
wrong
involvement.
I
B
J
Tokiya
disagree
with
you,
I
guess.
One
point
I
can
offer
is
that
an
alternative
approach
is
to
make
it
a
much
more
objective
thing
or
have
a
significant
objective
measurement
of
these
things.
So
you
know:
are
the
tests
written
and
passing?
Is
the
design
doc
submitted
and
approved
merged
the
code
complete
or
not?
And
you
know
you
don't
really
need
a
product
manager
to
make
those
kind
of
assumption
or
judgment
calls
I
all
means.
B
I
We
definitely
want
more
more
people
involved,
more
transparency
on
this
and
then
to
have
these
explicit
check
backs
on
on
the
features
as
we
get
through
the
coding
part
of
the
milestone
so
may
twentieth.
Assuming
we
hit
that
and
all
of
our
great
features
are
done
and
working.
We
that
would
look
like
bugfix
week,
one
here
and
then
a
reminder,
I
think
may
30th
is
a
cent
Memorial
Day
in
the
US.
That's
the
u.s.
I
holiday
on
there
aren't
a
whole
lot
of
other
holidays
on
this
schedule,
and
then
we
get
into
our
you
know,
sort
of
four
weeks.
Cutting
alpha
cutting
beta
and
releasing
june
twenty-fourth
would
be
the
the
friday
of
that
week
if
we're
on
track
and
then
there's
one
more
week
after
that
which
would
still
fall
in
q2
for
anyone
that
actually
cares
about
quarter
boundaries,
but
that's
about
where
we'd
be.
I
And
then
sort
of
the
last
note
here
is:
this
is
a
totally
not
finished
section,
but
I
do
want
to
denote
all
the
features
going
in
with
one
clear
query
like
there
should
be
one
github,
syntax
query
where
I
can
find
all
1.3
features,
and
so
what
I'm
proposing
here,
which
I
think
a
lot
of
people
have
agreed
with
off
lines.
This
Prairie,
not
controversial,
is
be
better
about
using
the
milestone
tag.
Everything
is
v
1.3
and
for
the
handful
five.
I
Maybe
ten
really
key
high
level
features
tag
them
feature
blocking
label
and
then
for
other
features.
There
might
be
50
of
these
again
tag
them
would
be
1.3
and
the
feature
label.
So
the
very
quick
check
is
how
many
feature
blocking
things
are
closed
and
done,
and
how
many
other
features
that
we're
trying
to
get
in
our
are
closed
and
done.
I
C
I
I
So
that's
that's
it
for
this
I
guess:
feedback
on
overall
schedule
like
if
this
is
too
aggressive
or
feels
right
or
we
you
know,
I,
guess
it
we
can.
We
can
cut
features
to
make
a
schedule
or
extend
the
schedule
to
include
features
we
kind
of
own
that
designation,
but
if
we
want
to
stay
on
the
roughly
early,
this
is
probably
what
it
looks
like
so.
A
The
only
point
that
I
would
make
on
the
schedule
is
if
we
sleep
slip
a
week.
We
are
running
right
up
into
the
fourth
of
July
for
any
sort
of
release
present
for
any
sort
of
release,
press
release,
community
engagement,
noise
support
things
like
that,
so
I
would
say
if
we
slip
from
jun
20
the
week
of
June
twentieth,
we're
looking
at
after
the
fourth
of
July,
because
if
you
slip
into
that
next
weekly
right
knocks
against
deadly
yeah.
I
J
B
F
This
document
is
how
big
the
bag
is.
We
don't
know
how
much
stuff
we're
trying
to
put
in
the
bag
right,
so
whether
we
need
to
limit
features
are
not.
Who
knows
right,
I
mean
we
really
don't
I
mean
the
best
we
can
do
is
prioritize,
set
some
goals
and
hope
that
things
land.
If
we
move
to
a
more
you
know
a
you
know,
a
real
release,
cadence
then
it's
going
to
be
much
easier
to
say.
Sorry,
this
thing
didn't
make
it
this
time.
I
F
F
F
I
feel
like
I
feel,
like
you
know,
the
the
you
know
the
three
months
three
or
four
month
release
cadence
is
too
long
to
sort
of
have
it
like
be
like.
Oh
I'll,
just
wait
for
next
time.
What's
you
sure
to
actually
do
all
the
work
that
everybody
wants
to
get
in
it's
kind
of
in
this
no-man's
land,
which
is
kind
of
unfortunate
I,
agree.
D
D
Every
three
to
four
weeks,
if
there's
going
to
be
a
lot
of
hesitancy
for
people,
I
actually
take
and
upgrade
that
in
a
production
market-
and
I
don't
mean
to
be
putting
issues
or
the
amount
of
testing
that
goes
on
just
that
level
of
cadence
of
actually
picking
up
and
used
it.
As
the
other
than
meeting
need
to
ask
a
question
about
whether
or
not
what
the
appetite
for
that
is.
I
mean.
F
We
could
do
something
like
a
boon
to
where
you
have.
Essentially,
you
know
minor
and
LTS
releases.
I
don't
know
what
the
non
LTS
version
is
right
with
the
idea
that
they'll
be.
You
know
for
people
who
are
reticent
to
upgrade.
It's
like
this
is
the
release
that
you
know
bundles
a
bunch
of
stuff
and
like
me,
if
we
do
that
that
every
six
months
right
it
but
then
there's
more
frequent
releases
with
features
for
people.
Wanna
live
on
the
bleeding
edge
I,
don't
so
yeah,
it's
it's
worth
talking
about!
G
J
Another
comment
about
your
it's
too
short
to
get
everything
done.
I
think
we
need
to
get
out
of
the
mindset
of
you
know,
starting
something
at
the
end
of
release,
X
and
finishing
it
at
the
beginning
of
release,
X
plus
1,
it's
totally
reasonable
to
spend
six
months
building
something,
and
you
just
don't
release
it
in
the
next
release,
but
the
one
after
it
and
I
think
we
need
to
get
comfortable
with
that.
Yeah.
F
And
especially
as
you
know,
we
get
it
like,
you
know,
hopefully,
I
I
hope
that
we're
going
to
get
a
little
bit
more
rigorous
about
design,
docs
and
actually
vetting
out
the
features
before
they
go
in
I
mean
that's
just
going
to
take
time
to
do
that
process
and
getting
that
and
coding
and
testing
and
documentation-
and
you
know,
from
future
from
conception
to
GA
in
in
four
months
is
going
to
be,
is
going
to
be
difficult.
It's.
J
E
E
Mccreery
did
a
lot
of
work
on
really
breaking
up
the
tests
to
actually
automatically
roll
a
cluster
forward
and
verify
backwards,
compatibility
and
all
of
that
and
I've
actually
heard
no
feedback
about
whether
or
not
that
improved
things
short
of
the
discussion
last
week
where
it
seems
like
the
official
designation
is
once
the
stable
file
has
changed.
That's
going
to
be
our
determination
that
things
are
good
enough.
Ji
ke
will
roll
at
some
point,
but
we
don't
really
care
whether
or
not
that's
going
to
validate
the
stability
of
Cooper
Nettie's,
so
I.
E
What
I
took
from
that
was.
It
sounded
like
folks.
Internally
are
confident
enough
that
ji
ke
will
just
seamlessly
upgrade.
Is
that
is
that
the
case?
Is
there
some
level
of
improve
confidence
and
upgrade
testing
or
as
Brian
sort
of
saying
that
people
internally
are
still
having
a
real,
tough
time
being
confident
in
upgrades.
G
Think
we
had
a
couple
of
particular
challenges.
One
is
the
way
we
were
testing
and
we
continuously
tests
upgraded
from
one
dot,
one
whatever
the
last
one
dot
one
patch
released
was
22
head
or
to
the
latest
alpha
that,
because
that
didn't
enable
certain
alpha
features
in
the
one
dot
one
release
it
didn't
uncover
problems
that
users,
who
did
that
would
hit
when
upgrading
for
real.
G
You
know
so
users
who
had
you
know
one
issue
is
we
should
have
test
for
that,
so
we
should
at
least
be
aware-
and
we,
you
know
this
comes
back
to
getting
the
documentation
out
ahead
of
the
release
as
well.
But
you
know
some
of
these
issues
or
how
users
would
precede
the
issue
would
have
been
uncovered
earlier
if
we
had
actual
user
feedback.
G
No.
As
far
as
the
automated
testing,
we
are
somewhat
slow
to
get
actual
testing
on
the
release
branch
up,
including
the
upgrade
testing,
and
then
there
were
a
bunch
of
sort
of
annoying
standard
problems.
We
have
getting
getting
these
things
to
work,
getting
all
the
quotas
in
place,
and
everything
like
that.
So
you
know
I
think
at
the
the
time
around
the
time
we
wanted
to
cut
the
release.
G
H
H
So
we
always
think
about
our
customer
to
doing
upgrade
of
the
things
certain
upgrade
other
things
they
are
going
to
drink
the
node
and
upgrade
so
that's
assumption
it
is
we
made
in
the
1.1
release
and
didn't
have
any
problem
so
for
1.2
we
the
end
to
really
change
any
decision,
so
so
by
to
the
customer
actually
use
in
a
different
way.
So
we
didn't
capture
that
difference
and
in
the
open
source
community,
a
customer
some
of
those
customer
and
that
that
difference
between
the
tce
and
the
jeep
JK
customer.
G
F
G
A
E
Is
definitely
one
of
the
big
road
map
items
for
sig
testing
for
13?
We
are
looking
at
how
to
try
and
better
describe
upgrades
and
deployments
in
a
little
more
modular
fashion,
so
that
customers
who
deploy
their
crew
benetti's
clusters
in
a
different
manner
than
what
Cooper
ete
co2,
can
still
have
some
level
of
automated
coverage
there,
a
particular
snowflake
of
a
deployment.
A
E
G
E
Definitely
can
I,
don't
think
it's
really
going
to
be
that
in
fact,
I'd
really
encourage
the
sorts
of
folks
who
need
to
be
involved
in
discussions
that
are
going
to
block
development
to
attend
the
next
cig
testing
meeting.
So
we
can
start
to
hash
this
sort
of
stuff
out
I.
Think
a
lot
of
people
are
assuming
that
testing
is
going
to
solve
some
problems
and
and
I
just
want
to
better
understand
what
the
expectations
are
and
who
all
the
stakeholders
are.
So.
E
B
E
A
J
J
So,
in
brief,
summary
Ubben
eddie's
is
the
cluster
Federation
project.
For
those
who
don't
know,
the
grand
plan
is
to
be
able
to
federal
it
multiple
coup,
benetti's
clusters
together
in
a
controlled
fashion,
so
that
you
can
do
useful
things
like
my
great
applications
between
clusters,
spread
them
across
multiple
clusters,
where
cluster
in
this
case
might
be
kubin,
eighties
installation
on
a
different
cloud
provider.
So
you
could
migrate
from
a
cluster
in
AWS
to
a
clustering
GCE,
for
example,
or
vice
versa,
UNMISS
to
cloud
cloud
or
on-premise,
etc.
So
there
a
whole
bunch
of
use.
J
J
So
if
you
deploy
your
application
into
a
multi-zone
cluster-
and
you
do
nothing
else,
and
your
configuration
files
stay
exactly
the
same
as
they
were
before
you
magically
get
high
availability
application
at
for
no
effort
on
your
part
at
the
potential
cost
of
a
small
amount
of
additional
network
bandwidth
charge
in
parallel,
we're
working
on
what
is
internally
nicknamed
uber
Nettie's
proper,
which
is
a
completely
separate
control
plane
which
looks
in
architectural
quite
similar
to
the
control
plane
of
KU
benetti's.
For
example,
it
has
a
persistent
snow
in
the
form
of
by
default.
It's
ed.
J
J
There
are
detailed
designs
in
place
for
what
that
thing
looks
like
what
federated
replication
controllers
look
like
what
federated
services
look
like
up.
For
example,
you
could
deploy
your
application
across
multiple
clusters
in
different
cloud
providers
and
have
traffic
load
balanced
across
them,
have
them
failover
between
clusters
and
cloud
providers,
etc.
J
We
have
an
implementation
of
the
sort
of
first
phase
of
that
control
plane.
We
have
some
testing
in
place.
I
think
the
unit
tests
are
pretty
much
passing
at
the
moment,
give
or
take
a
few
small
things.
The
code
is
still
in
review,
it's
not
merged
into
the
main
repo.
Yet
we
also
have
a
detailed
design
and
a
work
in
progress,
almost
complete
implementation
of
a
basic
scheduler,
and
we
are
hoping
to
release
some
of
this
stuff
in
1.3.
J
The
idea
would
be
to
make
it
easy
to
have
that
thing
aware
of
multiple
clusters
and
allow
you
to
flip
between
them
and
similar
work
with
Q
control,
which
currently
is
not
that
easy
to
have
it
work
across
different
clusters.
There
is
some
work.
There
is
some
existing
stuff
there
on
profiles
and
API,
endpoints,
etc,
but
we
need
to
just
tie
that
together
into
something
a
little
more
friendly,
and
in
that
scenario
you
will
be
able
to
control
multiple
clusters,
either
with
Q
control
or
with
the
UI
and
I
fit
it
into
my
time
limit.
J
A
J
J
You
know
reasonably
small,
not
because
we
don't
like
people's
input,
but
just
because
it
makes
it
easier
to
move
forward,
but
definitely
if
offline
you
could
go
through
the
meeting
notes
there
if
you're
interested
in
this
area
and
tell
us
if
we
have
forgotten
something
or
made
some
silly
decisions
that
you
disagree
with.
We
are
very
open
to
those
kinds
of
things.
A
F
Clinton
I
just
wanted
to
say
real
quick
I,
really
appreciate
the
fact
that
you
guys
are
doing
a
more
incremental
approach
to
Auburn
Eddie's
you
just
sort
of
in
total
versus
trying
to
sort
of
you
know,
hit
it
out
of
the
park.
The
first
time,
I
think
that
that
pragmatic
approach,
you
know,
serves
customers
in
the
product
really
well.
So
thank
you.