►
From YouTube: Kubernetes SIG Architecture Office Hours 10-4-2017
Description
A discussion on conditions and "what is alpha/beta" and how we move through these stages
A
Design
dock
that
we
had
or
the
second
one
right-
so
that's
remember:
P
1,
beta
1.
So
what
it
was
was
we
said
the
vast
majority
of
names
they
mean
type
of
every
resource
that
anyone
could
ever
create
should
follow
the
the
minimal
DNS
label
that
we
support
for
pods
for
right,
because
I'm
thinking
is
that
you
never
know
when
these
things
are
gonna
show
up
in
DNS,
right
right
and
then
for
some
resources
that
people
reasonably
want
to
represent
that
character
set
is
insufficient.
A
B
A
A
C
D
B
D
D
A
C
E
F
The
office
hours
week
and
can
talk
to
me,
I,
don't
know
over
a
week
ago
about
getting
this
on
the
agenda,
so
I
do
want
to
make
sure
that
we
into
it.
I
would
also
like
to
keep
this
me
or
it
possible.
If
there's
not
a
huge
agenda
item,
we
made
good
progress
on
the
proposal
process.
I
think
we
could
iterate
on
that
more
and
but
the
main
next
step
is
to
try
on
something
on
some
proposal.
A
F
Was
going
to
work
on
that
and
then
highest
priority
for
the
sig?
Is
the
conformance
tests
so
I
actually
had
some
people
will
put
together
a
spreadsheets
with
a
list
of
the
current
tests
and
an
English
description
of
what
the
test
is
intended
to
test,
and
not
a
hundred
percent
of
the
conformance
tests
were
had
that
information
filled
in,
but
most
of
them
were
testing
topic.
I
thought
the
conformance
stuff
was
being
driven
out
a
cig
testing
from
know.
F
C
F
C
F
The
spreadsheet
was
produced
a
lot
of
sig
testing.
Yes,
like
the
sonobuoy
was
used
to
generate
the
initial
list
and
then
various
people,
I'll
Tamiya,
are
going
to
need
a
process
by
which
we
can
push
this
down
primarily
to
the
SIG's.
So
the
SIG's
are
responsible
for
deciding
what
parts
of
their
functionality
should
be
covered,
and
then
it
will
just
be
bedded
by
cigar,
textured
element
and
observe
or
escalated
like.
There
was
an
escalation
you
know.
F
F
I
think
that's
the
way
in
order
to
scale
that's
the
way
it's
gonna
need
to
operate
from
reviewing
the
tests.
It
is
pretty
clear
that
we
have
major
major
issues
that
need
to
be
addressed
with
this
whole
idea,
so
I'm
working
on
figuring
out
what
to
do
about
that.
The
first
thing
is
gonna
need
to
happen,
is
gonna
kneecap
staffing
other
than
me
to
go
drill
down
is
the
problems
that
have
been
identified.
F
C
I
think,
as
this
gets
more
formal-
and
you
know,
there's
real
there's
real
skin
in
the
game
in
terms
of
sort
of,
what's
conformance,
what's
defined
by
containment,
what
is
getting
sort
of
a
process?
That's
sort
of
tracked
and
accountable
there
right.
So
you
said
you
made
the
call
of
like
hey
calling
out
to
the
Internet.
It's
not
part
of
conformance.
We
yeah.
F
C
C
A
A
To
a
conformance
doc
in
the
in
a
high-level
sense,
like
the
two
things
we
have
is
that
I'm
calling
out
to
the
public
Internet
is
not
because
of
X,
like
that's
a
good
thing
that
even
if
we
didn't,
even
if,
though,
we
want
to
change
that
in
the
future.
Just
recording
that
we
say
that's
true,
the
other
one
that
we
went
through
was
Paola.
Api's
are
not
part
of
a
conformance
definition.
F
F
This
was
more
of
an
expedient
thing,
since
they're
trying
to
get
the
components
and
the
approach
I've
taken
is
be.
Conservative,
like
don't
include
performance
that
poor,
not
confident
but
we're
trying
to
go
to
war
with
the
army.
We
have
right.
So
the
approach
is,
you
know,
have
a
set
of
tests
that
we're
not
we
don't
think
are
totally
bogus
start
with
that
and
then
including
them
over
time.
Is
everybody.
A
F
F
There
were
a
bunch
of
there,
a
bunch
of
gaps,
so
I
actually
have
a
list
of
reasons
for
why
there
are
gaps,
and
some
of
them
are
going
to
be
hard
to
address
so
anyway.
I
don't
quite
have
a
doc
on
this
yet
to
share,
and
we
will
need
to
work
with
stick
testing
ultimately,
I
think
we're
gonna
need
a
new
test
framework
to
address
the
biggest
problem
or
one
of
the
biggest
problems
I
mean.
Obviously,
the
biggest
high-level
problem
is
that
the
set
of
test
wasn't
systematically
chosen
for
this
purpose.
F
F
So
therefore,
the
only
test
that
could
be
conformance
tests
are
the
ones
that
are
not
other
types
of
tests
and
we
actually
have
a
big
drive
to
create
more
unit
tests,
more
integration
tests,
more
component
level
tests
and
none
of
those
tests
are
included
in
the
conformance
suite,
so
the
set
of
tests
even
looking
at
the
set
of
tests
we
have
most
of
those.
If
we
were
writing
them
today,
we
would
have
written
them
as
different
kinds
of
tests
and
then
the
end-to-end
test
would
have
had
almost
nothing
in
it.
C
F
Agree
and
their
issues
with
the
conformance
test
as
well
like
we
usually
try
to
make
into
in
test
tolerant
some
level
of
version
skew,
and
things
like
that.
So
I
think
we
need
to
rethink
the
mechanism
for
the
conformance
tests
and
the
approach.
One
thing
idea
that
I
was
you
know:
I
was
just
writing
this
up
this
morning,
but
if
we
could
somehow
run
tests
both
as
unit
or
integration
tests
and
as
into
in
tests
like
have
a
framework
that
obstructs
the
execution
model,
that
could
be
one
way
to
approach
approach.
F
A
A
Repeated
runs,
I
do
think,
there's
a
pragmatic
aspect
to
the
conformance
test,
even
as
they
are
having
gaps
like
they're
kind
of
evolvable
in
the
right
direction.
I
would
say,
I'd
like
to
spend
the
next
two
years
growing
that
suite
and
making
it
more
efficient,
which
benefits
everybody
versus
like.
If
we
spending
too
much
time
on
refactoring
some
classes
of
test
might
like
there
been
various
proposals
like
we
have
integration
tests.
That
kind
of
do
some
of
this,
but
they're
almost
a
completely
different
framework.
Whatever
assumptions
so
yeah.
F
So
the
set
of
tests
we
have
right
now
cover
I
think
Heuer
than
ten
areas
of
the
system
like
they're,
a
ton
of
compute
Maps
tests,
a
ton
of
sequence
test,
a
bunch
of
projected
volume
tests
like
Paul
Maury
wrote
a
lot
of
tests.
Clearly,
basically,
is
what
it
looks
like,
and
nobody
else
did
so
just
as
an
example,
pod
scheduling
in
execution
is
not.
We
don't
have
a
specific
test
for
that.
F
It's
only
tested
accidentally
as
a
side-effect,
so
the
other
tests,
and
so
anyway
yeah
but
I,
went
through
an
enumerated
categories
like
test
tested
by
other
types
of
tests
are
not
covered.
Newer
functionalities
not
covered
because
basically
these
things
were
mostly
identified
at
the
beginning
of
time.
Basic
functionality
is
at
best
accidentally
tested.
A
I
just
made
like
in
general
D,
maybe
that
conformance
but
the
eating
sweets
that
are
on
the
PR
jobs,
do
a
reasonably
good
job.
I
would
I
would
almost
argue
like
that.
Slow
evolution
towards
like
taking
that
said
whittling
it
down
is
a
very
pragmatic,
like
it
won't
hurt
anything
to
do
that
because
it
benefits
both
sides
of
the
project
like
having
lost
consistent,
reliable
test.
A
C
What
one
thing
that
I
think
would
it
help
be
helpful
if
we
get
to
get
some
clarity
again
between
sort
of
what
this
group
is
doing?
What's
interesting
is
doing
I
think
as
we
see
questions
of
what's
in
and
what's
out
instead
of
looking
at
the
specific
test,
like
you
know,
just
you
know,
can
we
extract
some
sort
of
broader
rules,
then
that
people
can
apply
right
and
I?
Think
over
time?
C
C
Yeah
this
mechanism
of
like
how
do
we
actually
like
what
we
can
say
is
like
we
prioritize
we'd
love
to
get
more
coverage
over
these
areas
right,
that's
sort
of
a
blended
type
of
thing,
the
actually.
How
do
we
do
that
using
evolving
you
know,
integration
tests
or
unit
tests
or
like
that,
I
think
is,
is
maybe
more.
You
know
more
than
weeds
for
us.
I
agree
I,
just
we're.
G
You
know
so
the
gist
of
it
is
this
right
deployment
and
replica
set
and
my
believe,
replication
controller
all
have
conditions
that
are
used
to
communicate
status
to
the
end-user
right
for
the
other
controllers,
daemon
set
for
a
core
workloads,
daemon
set
and
staple
set.
Primarily
we
communicate
status
using
the
eventing
system
and
there
aren't
any
conditions
we're
going
to
try
to
promote
the
entire
surface
to
be
one,
and
my
concern
is
that
it
should
be
consistent.
G
There's
been
a
lot
of
talk
about,
we
can
kind
of
remove
conditions,
but
keep
the
same
information
by
spreading
them
out
across
the
status.
There's
been
a
lot
of
data
collection
pertaining
to
the
usage.
There
is
my
primary
concern
there
is
that,
like
removing
conditions,
potentially
when
migrating
from
extensions,
be
one
beta,
one
deployment
to
V
one
deployment
could
be
a
significant
cost
for
pauses
like
open
shift
right.
But
let's
still
think
primarily.
A
Like
so
I
know,
we've
had
this
kind
of
I
know:
there's
been
the
discussion
Brian
that
you
kicked
off,
which
was
you
don't
think?
Conditions
are
as
useful,
so
like
I
guess
like
as
a
so
I
see
this
a
lot
because
we
tried
to
make
extensive
use
of
conditions,
so
the
big
push
to
get
conditions
added
to
all
of
the
api's
came
as
that
second
wave,
as
we
were
going
through,
the
exercise
of
the
controllers
did
not
report
enough
information
for
a
good
user
experience
around
actually
using
deployments
replication
controller
staple
said
statements,
etc.
A
So
we
went
through
that
big
push
last
year,
where
we
added
conditions
that
reflected
like
not
progressing
on
replica
sets
or
on
deployments,
and
then
those
showed
up
in
various
UI
is
on
our
side.
We
use
them
a
little
bit
in
queue,
control
and
a
few
other
places.
I,
don't
know
if
the
cube
dashboard
extensively
uses
them.
Do
you
have
data
on
can
I
can.
F
Look
I,
don't
believe
it
does
difference
between.
You
know,
I
totally
agree
that
progressing,
for
example,
is
needed
in
order
to
build
any
continuous
deployment
system.
On
top
of
deployment
you
need
to
be
able
to
tell
you
know,
make
a
call
whether
it's
gonna,
succeed
or
gonna
fail.
So
I
think
we
need
to
distinguish
the
form
in
which
the
information
is
expressed
and
which
information
is
expressed.
Yes,.
G
To
be
clear,
we're
not
proposing
that
we
remove
any
of
the
communicated
information
from
the
status
presentation
and
to
sculpt
it
further
I.
Don't
think
we
need
to
solve
whether
we
want
conditions
in
the
API
and
the
general
piece
across
the
entire
service
today,
I'm
talking
about
the
workloads
in
specific,
does
it
make
sense
like
if
it
does
make
sense,
and
perhaps
when
this
information
should
be
communicated
via
staple
set
and
demon
sent
via
conditions
as
well?
If
not,
then
we
should
probably
clean
up
the
status
of
deployment
and
replica
set
yeah.
A
So
I
just
wanted
to
like
I,
was
trying
to
frame
it
in
the
context
of
we.
We
didn't
get
enough
information
from
controllers.
We
added
it
to
deployments
and
replica
sets
and
replication
controllers
to
get
more
information,
because
at
the
time
that
was
the
I
was
we
use
it
on
nodes,
pods
and
other
lower-level
things
and
then
there's
various
extension
things
out
in
the
world
that
use
it
for
things.
F
C
A
F
A
A
I
was
saying
is
like
we
have
a
pattern
today.
It
has
deficiencies.
We
have
a
last
opportunity
for
some
of
these
core
ones
to
set
to
avoid
a
big
cost.
I
guess
the
question
I
have
is
introducing
a
net.
New
pattern
is
going
to
make
kubernetes
harder
to
use
and
right
for
for
things
that
already
exist.
When
you
even
have
two
different
ways
of
getting
this
there's
some
level
of
I
know
you
had
to
evolve
cube
over
time.
Is
it
worth.
F
It
was
like
hard
to
explain-
and
you
know
the
analysis
that
Eric
and
I
did
show
that
actually
a
lot
of
mostly
information
in
most
of
the
conditions
and
most
of
the
api's,
the
use
conditions.
The
information
is
not
well
utilized
and
it
just
makes
the
whole
structure
cumbersome,
and
it
makes
certain
things
hard
actually
hard
to
express,
like
indexing
into
a
index
structure
in
a
way.
That's
not
in
non-indexed
it's.
F
A
A
If
we
change
the
mechanism,
we're
not
going
to
have
less
work,
we're
going
to
have
more
work
because
we'll
have
to
continue
improving
the
old
things
that
we
can't
get
rid
of
and
then
add
new
things
that
people
have
to
come
up
with
new
patterns
for
and
so
for,
two
years
or
so
we'll
have
two
different
patterns
is
changing.
The
pattern
like
so
just
I
got
a
really
high
level.
A
Is
changing
the
pattern
worth
it
given
that
we
have
existing
data,
or
do
we
drive
to
conclusion
and
say
at
some
point
in
the
future
we'll
come
back
like
doing
it
now,
for
workloads
actually
creates
more
work
for
anybody
building
clients,
because
they
have
two
different
ways
to
do
it
for
workloads
and
for
pods
or
whatever?
Is
that
worth
it
like
I'm?
Just
asking
like,
because
I
think
this
is
a
really
fundamental
pods.
F
Have
the
additional
problem
that
conditions
are
woefully
inadequate
like
there's
no
way
you
can
look
at
the
conditions
and
really
report
anything
useful
about
the
pods
alone
like
if
you
look
at
print
pod
base
in
keep
control.
It
actually
does
this
really
a
complicated
thing
where
it
walks
the
containers
and
pulls
container
status
and
and
looks
at
Fay's
and
looks
at
other
information
honestly
that
needs
to
be
moved
into
code
into
cubelet,
so
usually
summarize.
Well
so
that
so
I
would
say
for
notes
and
for
pods
the
conditions
are
pretty
useless,
as
is
well.
A
So,
but
we
expose
it
and
they
have
information
that
various
clients
are
using.
It
I
guess
like
useless,
is
a
strong
statement,
because
people
use
it
to
go
figure
out
what
they're
doing
I
guess
like
I'm,
worried
that
we're
saying
we're
gonna
go,
create
a
new,
better
thing
that
also
needs
to
have
all
this
work
done
and
we're
gonna
have
two
ways
to
do
it
over
time,
but
in
a
couple
of
years
we'll
have
a
better
mechanism.
It's
consistent
versus,
like
I'm
kind
of
making
the
argument.
Why
don't
we
I
think.
C
A
Completely
useless
for
pragmatic,
you
eyes,
because
it
requires
you
to
do
a
very
complex,
lookup
and
correlation
part
of
the
reason
whatever
it
is
like
message
and
reason.
The
reason
that
they're
very
useful
on
the
objects
is
because
a
naive
client
can
look
at
them
and
see
data
and
then
report
it
to
a
user
I.
A
C
Guess
I
mean
so,
it
seems
to
me-
and
you
guys,
I
think
thought
about
this
more
than
me.
Is
that
there's
an
analog
here
between
annotations
and
like
having
like
explicit
fields
in
spec
versus
conditions
and
having
explicit
fields
and
status
right,
and
we
have
this
trade-off
between
extensibility
of
being
able
to
expose
all
sorts
of
random-ass
things
without
having
to
plummet
through
the
API
versus
strong
type
it
nests
and
and
like
just
like,
there's
always
going
to
be
a
time
in
a
place
for
annotations.
C
G
That's
kind
of
thing,
the
reason
that's
associated
the
reason,
that's
associated
with
these
conditions.
People
are
using
it
like
trying
to
build
a
state
machine
off
of
it,
and
it's
really
just
an
arbitrary
string.
It's
not
an
enumeration,
so
the
reason
in
theory
can
change
arbitrarily
at
any.
Given
time
break
your
client
message,
you
definitely
shouldn't
be,
depending
on
the
specific
specific
content
for
all
the
other
fields
of
status
had
clearly
defined
semantics
that
are
like
this
is
what
it
means.
These
are
the
allowable
values.
C
Think
as
we
move
towards
like
say,
more
implementations
behind
CRI
we're
gonna
have
more
ways
where
we're
gonna
want
to
bubble
up
sort
of
special-purpose
things
about
sort
of
pod
status.
That
are
you
know
and
like.
But
if
we
don't
have
something
like
conditions,
we're
not
going
to
be
able
to
do
that.
I.
A
Think
Jo
you
hit
it
on
the
head,
which
is
it
is
like
annotations.
It's
not
that
it's
like.
Maybe
the
argument
here
that
I
would
make
would
be
every
new,
like
the
discoverability
of
conditions
that
are
of
fields
is
better.
What
we
really
should
be
doing
is
looking
for
the
opportunities
to
turn
core
behavior
that
we
think
conditions
represent
into
status
fields
like.
A
F
F
Stuff
is
fields,
yeah
and
conditions
will
be
for
it's
for
kind
of
an
extension
like
mechanism,
or
you
know,
did
CRI
plugins
or
volume
plugins
or
things
like
that
to
report
information
I
think
we
should
officially
recommend
to
get
rid
of
the
last
updated
last
heartbeat
last,
whatever
fields
that
mostly
don't
people
don't
use
and
when
they
do,
it
ends
up
having
a
huge
cost
performance
wise
so
prune
the
set
of
information
to
the
set
of
information.
That's
actually
useful,
then
write
a
style
guide
similar
to
what
Marek
and
I
are
doing
with
events
find.
A
A
way
to
use
conditions
as
a
way
of
exposing
useful
information
that
the
use
case,
the
fact
that
someone
is
exposing
conditions
and
that
it
is
persistent
when
people
consume.
It
is
a
reason
it
should
go
to
a
field.
Arguably,
we
could
treat
it
as
well
as
the
way
that
we
bring
status
information
through
an
alpha
beta
style
transition,
which
is
your
organic
approach.
Joe.
Your
point
about
annotations
is
I,
do
think
of
conditions
like
annotations.
We
didn't
see
a
lot
of
use
of
annotations
for
the
first
two
years,
kubernetes
and
now.
A
C
A
The
absence
of
that
the
it's
a
little
bit
like
the
argument
for
CR
D,
which
is
the
barrier
to
attaching
data
that
provides
real
value
for
your
automation,
is
so
much
better
than
like.
The
one
thing
that
differentiates
cute
from
every
other
API
I've
ever
used
in
my
entire
life
is
I
can
work
around
the
API
designers
flaws
and
I
can
find
value
like
like
we
are.
A
We
are
all
human
we
all
have
flaws
like
we
have
there's
a
ton
of
great
ideas
in
the
cubic
is
far
from
perfect
annotations
labels,
some
of
the
other
mechanisms
we
have
actually
given
some
mechanism
whereby
people
can
find
value
above
in
the
bottom.
You
know
system,
and
we
don't
want
to
take
that
way.
We
just
want
to
say
we're
gonna
formalize
it
and
we
shouldn't
abuse
it
like.
We
learned
not
to
abused
annotations
ourselves.
Well,
so
I.
F
F
G
So
my
concern
would
be
would
be
like
if
we
use
conditions
as
a
general
mechanism
to
incorporate
arbitrary
status
and
if
it
becomes
important,
we
promote
it
into
a
field
later
that
we
think
about
it
enough,
so
that
we
know
we
know
how
to
do
it
without
breaking
backward
compatibility
during
that
promotion.
Actually,.
F
G
A
Say
the
lesson
we
learned
from
annotations
to
API
fields
is
no
matter
what
we
will
break
people,
and
so
it
is
impossible
to
my
grainy
pies.
It's
an
API,
it's
going
to
peoples.
We
just
need
to
minimize
the
cost
we
put
on
our
users
by
being
very
clear
about
how
we
communicate
and
then
encouraging
them
to
do
the
right
thing
so,
like
people
abusing
available
today
are
doing
it
because
they
have
no
other
way
to
get
that
information
and
it's
a
fundamental
gap
in
the
system.
A
The
if
there's
some
level
of
I,
don't
know
that
we
should
just
add
status
fields
willy-nilly
because
of
the
concern
about
like
we
need
to
be
somewhat
cautious,
and
so
in
that
balance,
it's
at
a
condition
when
we
are
unsure
whether
it
is
something
that
is
informational
versus
status,
use
that
to
guide
us
and
we'll
break
like
people
will
get
broken
depending
on
conditions.
Just
like
people
get
broken
depending
on
annotations.
We
just
have
to
keep
that
appropriately
and
say:
here's
what
we
expose
these
may
change,
etc
and.
C
I
think
you
know
technically,
we
can,
you
know
which
is
technically.
We
can
be
correct,
which
is
the
best
kind
of
correct,
but
by
saying
that,
like
you
know
that
that
conditions
and
annotations
are
not
part
of
the
API
and
the
API
promises
around
v1
and
beta
and
all
known
GA
right,
they
are
exempt,
and
so
you
know
it's
a
little
bit
of
a
Wild
West
available.
A
Out
we
would
break
a
lot
of
real
world
systems.
We
will
have
to
think
about
that
on
our
side,
but
we
need
to
set
the
tone
for
like
no
matter
what
that's
a
field,
then
in
the
in
the
conditions
like
the
moment
like.
If
we
stop
setting
available
as
a
condition
today,
we
would
break
production
workloads
well.
A
That's
a
great
example
is
like
will
promise
to
be
stable
for
the
ones
we
have
today.
We
will
introduce
new
fields
when
we
introduce
new
fields,
will
give
you
a
warning
and
a
deprecation
notice.
In
a
time
period,
you'll
transition
over,
we
reserve
the
right
to
add
new
conditions,
new
conditions
added
from
here
on
out
or
something
like.
A
G
Let
me
just
put
this
out
there
what
I'd
like
to
do
for
v1,
then,
is
this
I'd
like
to
add
staple
set
conditions
as
part
of
the
field
not
populated
with
anything,
but
leave
it
there
for
future
growth?
If
we
want
to
actually
potentially
use
them
later,
it
should
be
part
of
the
b1
API.
So
we
don't
have
to
add
new
tire
type
to
the
field.
G
I'd
like
to
do
the
same
thing
for
daemon
set
yeah
not
populate
it
until
we
find
an
actual
use
for
it
alone,
as
is
don't
do
any
work
on
it,
but
potentially
we
can
always
add
to
status
without
breaking
backward
compatibility
and
promote
existing
conventions
later
and
just
reserve
the
right
to
do
that.
You're.
G
F
A
There,
a
cost
of
populating
them
I
mean
look
at
the
end
of
day,
like
pragmatically
I,
like
we're.
Treating
v1
like
a
cliff
I
guarantee
you
that
no
one
who's
using
the
planner
today
thinks
of
deployments
is
anything
other
than
v1
and
they
they're
gonna
want
to
change
a
couple
things,
but
if
you
like,
don't
I
mean
we
shouldn't
kick
people
like
we
should
we
should
poke
them
or
prod
them
like
there's
some
like
level
of
I,
don't
know
how
like
I
would
say
we
could
air
on
duplicating
data
having
conditions
in
fields
being
duplicated.
G
We
can
keep
it
and
I'm,
not
saying
we
never
get
rid
of
it,
but
you
can
keep
it
for,
say:
okay,
we're
we're
out
in
the
status
field,
for
the
next
several
releases
will
continue
populating
the
condition
and
then,
when
we're
comfortable,
removing
it
and
people
have
moved
off
of
it.
We
can
do
it
that
way,
I'm
also,
okay,
with
doing
a
couple
of
them
now,
I,
don't
think
it's
like
that.
Much
of
the
Aloise
and
so
highly
I
think.
C
C
This
field
is
actually
exposing
this
condition,
and
then
you
can
collect
those
for
the
type
and
you
can
actually
mask
those
conditions
when
people
are
listing
stuff,
so
they
don't
see
that
the
same
information
twice,
but
it's
actually
there
so
there's
a
tool
ability
fix
to
actually
have
this
data
twice
and
be
able
to
deal
with
it
over
the
long
term
is
not
confusing
users.
The
other
thing
I'd.
G
B
F
C
F
F
The
general
pattern
of
these
things
is
it's
either
you're,
either
good,
in
which
case
there's
no
real
reason
or
you're,
not
good,
in
which
case
there
are
lots
of
unbounded
numbers
of
reasons
expressing
these,
as
where
you
have
like
empty
string
in
the
good
case,
means
that
they're
all
have
to
be
the
field
all
have
to
be
expressed
in
the
negative
right,
not
ready,
not
available
whatever
so
I
suggest.
We
don't
do
that.
It
ends
up
being
really
awkward.
C
F
G
But
that's
always
say
like
based
on
this
idea
that
we're
going
to
keep
conditions
at
empty
conditions
for
a
staple
set
and
demon
set,
at
least
for
the
workloads
API,
allows
us
to
take
design
proposals
later
for
exactly
what
the
status
field
should
be.
That's
what
I'm
saying
it's
not
possible,
though
ken
right.
F
G
C
A
So
every
change
we
do
is
going
to
take
time
away
from
valuable
time
away
from
the
public
when
I
go
fix
as
well
like
in
terms
of
any
effort
we
spend
over
living
conditions
has
to
be
worth
the
return
because,
like
Ken
and
I
and
other
people
like
McCall,
it's
like
other
people,
Janet
we'll
go
and
we'll
be
spending
time
fixing
breaks
on
that,
whereas
we
probably
want
to
go,
spend
time
on
like
I.
Think.
C
F
C
So
I
think
there's
two
issues
here
this
so
there's
number
one
is
the
idea
that
conditions
are
sort
of
like
status
annotations.
We
want
to
promote
them
to
being
really
fields.
That
seems
like
a
good
thing
to
put
a
pin
in
the
second
thing
is
like
when
we
do
promote
these
things
to
fields.
What
is
the
form?
How
do
we
actually
do
it
I
think
that's
going
to
be
a
case-by-case
thing,
I'd
love
to
see.
C
F
B
F
G
A
So
I
had
one
that's
along
a
similar
line,
which
was
I,
think
we're
getting
a
lot
of
pressure
right
now
to
graduate
extension
mechanisms,
because
we've
said
everybody
should
use
the
extension
mechanisms
and
it's
putting
a
lot
of
pressure
on
the
extension
mechanisms
to
move
to
beta,
maybe
faster
than
is
safe,
and
this
is
kind
of
a
project
level
trade-off.
That
I
think
needs
to
be
kind
of
discussed
a
little
bit
here.
So
concrete
example,
initializers
and
dynamic
admission
you
take
webhooks
condition,
I'm
fairly
complex.
A
F
Longer
for
this
particular
case,
I
think
there
are
q.
Can
a
few
concerns
and
I
know
I'm
gonna
actually
try
to
come
to
the
epi
machine.
Any
discussion
on
this.
You
I,
am
concerned
that
an
alpha
they're
not
going
to
get
adequate
usage
to
discover
the
issues
that
we
might
be
concerned
about.
So
I,
don't
really
see
an
alternative
I
think
we
can
just.
We
could
potentially
identify
a
subset
of
the
functionality
and
say:
look
we're
going
to
take
this
functionality
to
beta,
so
we
can
at
least
get
that
feedback
with
initializers
versus
mutable.
F
Read
books
specifically
I
think
it
does
deserve
a
discussion
about
the
trade-offs.
I
think
the
biggest
concern
with
respect
to
initializers
really
is.
Are
we
going
to
keep
it
or
get
rid
of
it
in
favor
of
mutable
books?
If
you
think
we're
going
to
keep
it,
then
we
should
find
a
way
to
get
a
subset
of
the
functionality
to
data.
So
it
can
get
real
testing
to
surface
additional
issues
that
we
won't
get
without
real
usage.
Yeah.
E
Oh
I
was
gonna
just
say
you
know
a
forcing
function
on
this
is
gonna,
be
the
release.
Cycle
of
1.9
is
gonna,
be
pretty
short
and
the
time
that
people
would
be
reviewing
any
of
this
functionality.
That's
going
to
be
included
in
1/9
is
going
to
be
during
the
holidays,
which
is
traditionally
the
lowest
input
time
for
any
kind
of
extended
use.
E
People
don't
want
to
be
changing;
they
don't
want
to
be
doing
it
at
the
holidays,
so
it
seems
like
1.9
would
be
a
great
time
to
do
any
hardening
around
the
existing
functionality
as
opposed
to
adding
more
into
it
and
then
look
at
any
kind
of
feature.
Richness
or
expansion
in
1.10,
starting
in
2018
yeah.
F
I
think
the
hardening
is
what
people
were
looking
to
do
in
terms
of
getting
into
data
fixing
performance
issues,
correctness,
issues
sorting
out
semantic
aspects
that
weren't
well
documented
things
of
that
nature.
You
know
actually
make
it
he's.
What
has
been
built
be
usable
for
some
set
of
scenarios
so
that
we
can
get
that
real-world
some
amount
of
real-world
usage
and
with
beta
we
try
to
make
it
stable
such
a.
We
can
evolve
the
API
in
a
forward
compatible
way.
I
mean
I
might
need
to
read.
The
beta
version
like
I,
said
I.
F
Think
the
biggest
question
is:
how
confident
are
we
that
we're
going
to
keep
the
mechanism
and
anything
remotely
resembling
its
current
current
form?
If
you
have
reasonable
confidence,
you
know
it
doesn't
have
to
be
it's
never
going
to
be
on
a
percent
confidence.
We
have
reasonable
confidence.
Then
we
should
got
to
make
it
debate
if
we
think
no,
this
was
a
bad
idea.
We
need
to
rethink
it.
That's
a
different
kind
of
consideration.
I.
We
should,
on
this
particular
issue
specific
issue.
F
A
Like
stateful
sets,
we
could
conceivably
put
this
in
the
category
of
things
that
we
want
longer
soak
time
on,
but
we
do.
We
would
prefer
that
people
are
using
it
versus
people
or
not,
and
so
setting
a
reasonable
expectation
that
the
first
few
releases
of
beta
we
run
a
little
bit
larger
caveats
than
normal,
which
is
we
may
have
the
need
to
do
something
somewhat
dramatic
on
them.
Do.
A
A
H
Reminding
everyone
that
we
do
have
pretty
clear,
beta
definitions
and
if
we
just
need
to
make
sure
that
we
don't
compromise
on
those
if
we're,
if
we're
rushing
stuff
through
I,
don't
think
the
beta
definitions
are
crazy,
but
I
Clayton
says
it's
I
eat
your
data
and
reasonableness
that
your
cluster
will
stay
up.
I
think.
C
F
I
mean
on
Brandon's
point
and
Eric
and
I
wrote
the
current
version
of
the
the
definitions
for
alpha
beta
and
stable,
so
I
think
I
understand
the
intents
pretty
well,
you
know
it
says:
support
for
an
overall
feature
will
not
be
dropped.
Though.
Details
may
change
right.
We're
gonna
make
pretty
significant
efforts
to
make
it
forward
compatible
and
convertible,
but
we
will
sometimes
screw
it
up
right.
So
I
think
this
baby,
so
is
okay.
C
Okay,
is
it
just
a
thing
of
naming
I
mean
like
if
we
called
it's?
Not
it's
not
aiming
I,
don't
know,
because
people
here
beta
and
people
have
like
you
will
not
use
beta
features
in
terms
of
in
terms
of
shape,
but
it's
not
beta
necessarily
in
terms
of
stability.
It's
not
beta
in
terms
of
in
terms
of
long
term
commitment
right.
So
it's
there
is
a
long
term
commitment
to
the
feature.
There
are
certain
betas
that
are
stable,
like
deployments
stable
right
in
terms
of
like
it
doesn't
break
well,.
A
A
Like
we're
trying
to
set
like
this,
this
tension
around
beta
we've
had
this
over
to
the
last
two
releases.
We
we
want
to
make
sure
that
we
are
giving
people
the
ability-
and
the
XM
of
this
is
artificial.
We
create
for
ourselves,
which
is
don't
turn
an
alpha,
we're
gonna
iterate,
but
we
don't
iterate
enough,
so
we
run
beta.
We
set
the
bar.
We
just
I
think
we
we
may
want,
like
the
Joe.
Your
point,
like
I,
think
we're
trying
to
get
a
little
bit
better.
A
We
communicate
to
both
the
internal
teams
working
on
cube
the
community,
as
well
as
the
people
consuming
it.
What
the
reasonable
expectation
is
like
we're
doing
this
so
that
you
can
use
it
we're
going
to,
as
Brandon
said,
like
we're
going
to
we're
going
to
provide
these
guarantees,
but
you
need
to
understand
that
theta
means
theta
it
would
it
could
change,
do
it
in
this
fashion,
and
we
want
to.
F
Goodings
the
things
that
were
alpha
in
the
past,
like
just
take
deployment
as
an
example,
had
some
pretty
severe
implementation
problems,
known
functionality
gaps.
We
knew
we
were
gonna
break
the
API
specifically
with
the
initial
deployment.
They
used,
the
old
label
selector,
and
we
knew
we
were
going
to
change
it
in
a
non
backward
out
of
a
way.
It
couldn't
be
addressed
by
conversion.
B
F
C
C
I'm,
not
gonna,
name
names
that
a
project
came
out
a
couple
of
weeks
ago
and
like
I
poked,
like
four
holes
into
it
and
like
the
response
I
got
back
is
like
oh
well
still
very
early,
but
it's
marked
as
like
a
GA,
no
alpha,
no
beta
type
of
label,
and
it's
like
what
the
hell
dudes
right
so
like
we
take
this
stuff
really
seriously
and
that's
good
but
I,
don't
think
I.
Think
everybody
assumes
that
we're
actually
using
beta
to
mean
the
same
thing
that
everybody
else
means
beta.
We.
C
Okay,
so
I
think
it
might
be
worthwhile
to
actually
think
about.
Can
we
condense
this
stuff
into
a
chart
that
really
clearly
gets
across?
What
are
the
qualities
of
beta
here?
Consider
like
I,
don't
we
probably
can't
change
the
name
beta
but
like,
but
you
know
maybe
have
some
statement
about
like
how
we're
not
doing
great
inflation,
even
though
everybody
else
is
right.