►
From YouTube: Kubernetes SIG Architecture 20190912
Description
A
And
welcome
everybody.
I'm
gonna
be
slightly
quiet
today,
because
I'm
out
in
the
public
area
and
I'm
trying
not
to
disturb
my
neighbors,
so
I'll
be
a
light
headed
moderator,
but
I
want
to
call
it
that
this
is
the
cigarette
architecture.
Special
interest
group
today
is
Thursday
September,
12th,
2019
and
the
agenda
is
available
at
bit.
Dot
ly
/
cig
architecture.
If
you
want
to
follow
along
after
the
fact,
we
have
a
full
agenda
today
and
we're
gonna.
A
B
Can
everyone
hear
me
okay,
so
I
wanted
to
kind
of
brainstorm
a
little
bit
about.
There
are
a
lot
of
things
that
we
are
trying
to
keep
out
the
cloud
providers,
the
CSI
migration
stuff
going
on,
which
will
actually
help
remove
the
entry
cloud
providers,
the
credential
providers.
We
need
to
find
a
home
for
kube
CTLs
getting
to
staging.
We
had
discussions
about
hyper
cube
and
cloud
controller
manager.
B
There's
been
requests
to
remove
things
out
like
the
device
plug-in
API,
get
them
to
v1
first
and
then
move
it
out,
and
yesterday
we
were
talking
about
the
QB
API
server.
For
example.
In
you
know,
cig
a
be
a
missionary,
so
the
larger
question
I
wanted
to
ask
us:
how
do
we
want
things
to
look
say
a
year
or
two
down
the
line?
B
What
should
what
do
we
want
the
endgame
to
be
here
some
of
these
things
we
are
doing
for
you
know
we
want
to
reduce
the
size
of
the
binary,
for
example,
and
another
set
of
things
we
do
like.
We
want
somebody
else
to
use
it
without
entering
KK
right.
So
there
is
a
mixture
of
reasons
why
we
are
doing
some
of
these
things,
but
then
we
need
to
kind
of,
like
think
a
little
bit
about
where
we
want
to
be
and
see
how
quickly
we
can
get
there
from
here
right.
B
B
A
So
I
guess
one
of
the
things
I
was
hoping
to
get
at
is
sort
of
prioritization
in
terms
of
impact.
Some
of
these
feel
like
they're,
a
bit
higher
impact
than
others,
and
some
have
some
uncertainty
of
like
around
hypercube.
What
are
the
use
cases
that
are
currently
in
play
that
maybe
we're
not
aware
of
so
I
feel
like?
A
We
have
a
two-pronged
thing:
here's
what
what
are
the
uses
and
what
do
we
need
to
do
in
terms
of
deprecation
around
those
things
to
do
it
responsibly
and
then
the
other
is
in
terms
of
impacting
the
the
sort
of
vectors
that
you
mentioned.
What
are
what's
the
highest
party
to
do
that
I
see
those
as
sort
of
two
precursors
to
getting
to
that
answer.
Now.
C
To
be
clear,
not
all
impacts
are
going
to
be
felt
by
consumers
downstream,
for
instance,
if
you
look
at
something
like
taking
a
cube,
a
PS
or
a
Q
patroller
manager,
it's
a
strictly
code
organization.
Effort
for
improving
the
daily
lives
of
the
developers
who
work
on
it
right
being
able
to
express
I
depend
on
this,
and
not
on
that
is,
is
something
that
staging
is
exceptionally
good
at
I
can
accept
that
something
like
hypercube
does
have
an
end
user
impact
and
would
be
assessed
perhaps
differently.
B
Right,
one
of
the
reasons
for
bringing
up
hypercube
was
that
it's
traditionally
lacked
owners
and
there
was
nobody
taking
care
of
it.
This
is
almost
you
know,
beating
the
bushes,
to
get
people
out
to
actually
want
stuff,
and
we
might
not
even
have
to
deprecate
it
as
long
as
we
make
hypercube
available
to
a
team
to
maintain
it
outside
of
so
that's
the
slightly
different
thing,
but
then
I
also
want
to
check
ooh.
Is
there
anything
else,
people
think
that
is
important.
That
is
not
on
the
list
right
now,
as
well.
D
It's
a
lot
of
stuff,
it's
hard
for
me
to
figure
out
prioritization,
because
I
think
different
parties
will
have
different
vested
interests.
Like
me,
personally
have
I've
had
a
vested
interest
from
a
sink
coaster.
Life
cycle
perspective
I'm,
rationalizing
the
club
promoters
to
be
on
tree
because
the
installation
of
story
is
fragmented
and
if
you
tried
to
help
people
along
the
way
they
get
more
confused
than
they
would
be
otherwise.
D
So
I
think
it
depends
highly
upon
not
just
with
cigar
ch
wants,
but
who
are
the
people
are
gonna
show
up
to
do
the
work,
I
think
what
one
of
the
things
I
want
to
talk
about
later.
I
think
this
relates
to
this
topic
too,
as
well
as
who,
in
the
community,
wants
some
of
these
goals.
And
how
do
we
prioritize
the
people
they're
gonna
show
up.
How
do
we
incentivize
people
to
show
up
and
help
do
the
work.
C
Yeah
I
think
some
is
gonna
come
naturally
right
like
so
so.
I
have
a
personal
vested
interest
and
sake
ups
or
right,
so
I
may
not
go
in
and
try
to
I'm
up
with
a
cloud
provider
that
I'm
not
particularly
familiar
with,
but
I
am
familiar
with
a
cubicle
server
and
I
can
describe
what
I
do
that
so
I,
don't
think
the
people
who
would
do
this
are
fungible.
E
I
have
a
meta
comment,
which
is:
is
it
really
architectures
job
to
like
very
carefully
prioritize?
These
things
I
would
kind
of
more
expect
something
along
the
lines
of
Sagarika
tech.
Chure
sets
a
cap
on
how
much
disruption
we
can
survive
in
a
given
release,
and
it
should
be
up
to
the
relevant
owners
of
these
various
things.
How
how
important
they
are
does.
F
Don't
want
people
to
keep
adding
to
things
like
queue
proxy
I
want
them
to
fork
it
and
make
their
own,
and
it's
very
difficult
to
do
that
right
now,
because
it's
too
entangled
so
we
just
like
we've
done
this
process
before
we
need
to
do
it
again,
but
also
because
I
think
somebody
like
you
brought
to
you
should
have
its
own
suite
of
end-to-end
tests,
which
shouldn't
really
be
part
of
the
regular
communities.
Suite
I
can
exercise
queue
proxy
better
in
isolation.
F
H
G
B
F
F
E
Would
be
useful,
I
yeah
and
I
think
more
than
just
what
the
budget
is.
I
think
just
recognizing
that
there's
different
groups
of
people
that
different
changes
might
disrupt
like
there's
end-users,
so
which
cute
control,
making
substantial
changes
to
keep
control
would
disrupt
end
users.
There's
cluster
operators,
changes
to
hypercube
or
how
cloud
controller
major
terms
ROI.
E
I
E
When
I
talk
about
disruption
here,
I'm
talking
about
generates
extra
work
for
various
groups
of
people,
just
so
that
they
can
remain
in
the
same
place
that
they
started
out
it
right,
like
you,
change
how
you
operate
a
binary
like
that
means.
The
cluster
lifestyle
has
to
change
the
cloud
providers
all
have
to
change
like
that's
genuine
work,
and
it
makes
kubernetes
harder
to
use.
Then
maybe.
F
It
needs
to
be
so
I
think
there's
maybe
two
grades
of
change.
We're
talking
about
here.
One
is
simply
I'm
moving
the
code
from
one
place
to
another,
but
nothing
actually
changes
from
the
users
point
of
view
yeah.
There
is
I'm
taking
cloud
controller
manager
and
I'm
busting
it
out
of
the
controller
manager
I'm
introducing
a
lot
of
yeah.
E
C
I
think
that
the
biggest
one
for
cluster
admins
that
we've
been
considering
so
far
has
been
what
is
the
future
of
hypercube,
and
maybe
that
will
be
the
most
constructive
to
discuss
here.
I,
look
at
it
and
I
say
that
we
have
lots
of
different
processes
included
in
hypercube.
We
first
started
and
everything
was
definitely
gonna
live
in
one
repo.
It
made
a
lot
of
sense,
but
he
listened
to
what's
a
Tim
said
right
here
where
he
was.
J
E
I
F
Don't
think
that
bundling
them
into
hyper
queue
means
they're,
not
replaceable
and
I.
Don't
think
moving
them
into
a
separate
vote
means
in
our
hypercube
is
a
umbrella
project
that
says.
Look
if
you
conform
to
this
API
I
can
link
you
in
as
a
meta,
binary
and
I,
don't
care
whether
you
live
in
KK
or
some
other
repo
or
some
vendor
place
or
third
party
there's.
This
is
the
API
yeah.
F
Less
in
your
uncle,
if
somebody
let's
say
so
today,
we're
absence
and
real
owner.
Let's
say
somebody
steps
up
and
says:
I
want
to
drive
this
thing.
Cuz
I!
Think
it's
a
fun
and
interesting
project.
I
do
I,
just
don't
know
how
is
my
day
and
they
want
to
move
hypercube
out.
There's
a
practical
problem
which
is
venn
during
in
from
kk
is
a
disaster
right.
So
you
can't
vendor
in
scheduler
and
you
you.
C
F
C
C
A
D
We've
gone
from
meta
and
I
wanted
to
go
back
to
another
medic
question,
which
is:
if
we
don't
have
owners
and
maintainers
for
these
things.
Is
it
in
the
best
interest
of
the
community
to
kind
of
limp
it
along
in
this
state,
when
we
have
known
workarounds
that
a
person
could
create
their
own
hyper-connected.
B
So
good
question,
so
the
thing
here
is
for
for
the
hypercube
right,
it's
like
the
tip
of
the
iceberg.
You
know
we
have
to
get
that
out.
First
before
we
can
move,
you
know
there
are
other
things,
but
then,
if
we
take
it
out
and
people
don't
actually
form
a
team
and
it
bit
rocks,
it
doesn't
really
affect
the
rest
of
the
things
that
we
do
in
KK.
B
B
We
have
with
docker
shim
right,
there's
a
lot
of
people
who
are
not
using
docker,
especially
the
cloud
providers
who
have
you
know
like
GK,
for
example,
right
cloud
products
like
that
who
don't
use
docker
right,
but
then
we
have
to
ship
a
default
one,
and
currently
it
is
dakashin
and
we
try
to
do
the
best.
We
can
with
docker
shame,
but
there's
not
really
too
many
people
who
want
to
spend
time
on
docker
shot
at
this
point,
and
if
there
are
then
they
would
be
working
on
moving
the
darkish
em
out
as
a
CRI.
B
K
L
K
K
If
we
want
to
break
something
out,
is
we
have
to
have
a
list
of
names
of
people
who
will
sign
up
to
be
maintainer
before
it
can
be
broken
out
of
kaykai
I
mean
that
could
be
a
criteria
in
the
code
organization.
You've
got
to
have
so
many
sets
of
owners,
and
we
say
ok
now
can
be
considered,
because
otherwise
it
needs
the
support
structure
of
the
rest
of
it,
because
there's
a
lot
of
users
and
I
see
a
hand
up.
A
So
I
just
housekeeping
thing:
real,
quick,
we're
not
going
to
resolve
this.
Probably
if
we
spend
the
rest
of
the
meeting
on
it.
So
can
we
maybe
limit
discussion
to
the
next
5
minutes
and
move
on,
because
we
have
a
very
full
agenda.
Is
that
okay
with
everybody,
so
we
had
Valerie
and
I
couldn't
see
whose
hand
that
was
in
the
other
room?
But
oh
that
was
really
good.
Okay,
so
Valerie
and
the
judge.
B
B
If
you,
if
you
look
at
the
POC,
that
I
posted,
we
I
just
have
like
a
couple
of
go
files
and
the
rest
of
the
things
that
comment
from
KK,
but
then
the
signature
of
some
of
the
methods
in
KK
changes
and
nobody
is
keeping
track
of
those
changes
and
mirroring
whatever
needs
to
be
changed
in
hypercube
or
a
period
of
time.
You
know
you
will
no
longer
be
able
to
have
a
single
go
file.
You
will
have
to
either
copy
files
or
you
know,
make
modifications
and
things
like
that.
J
Yeah
I
thought
you'd
comment
on
that
as
well.
I
think,
actually
separating
them
out
is
exactly
what
we
need
to
do
to
prevent
things
that
are
important
all
right.
If
it's
all
in
the
big
bucket
of
all
the
communities.
You
guys
all
leave,
though
I
maintain
that
then
these
people
who
care
about
that
one
small
slice
I'm
going
to
take
their
time
today,
but
once
it's
separated
out,
they
don't
a
choice
or
they
they
decide.
They
don't
actually
care
about
and
they
go
on
and
use
something
else.
A
You
know
I
think
sometimes
disruptive
change
is
a
hammer
that
has
to
be
used
in
cases
where,
especially
where
awareness
is
hard
to
get
and
I
think
that
cluster
operators
are
notoriously
hard
for
us
to
reach.
So
you
know
for
better
for
worse.
This
may
be
a
method
through
which
we
can.
We
can
elevate
the
the
risk
associated
with
bit
right
on
that
too.
So,
let's
save
it.
If
there's
gonna
be
more
conversation
on
this,
then
we
move
it
to
the
mailing
list.
If
that's
okay
with
everybody,
can
somebody
volunteer.
D
Oh
wait
this
this
theme
that
Tim
seems
to
have
started
even
without
us
coordinating,
which
is
interesting.
It's
the
the
same
theme
is
that
I
wanted
to
put
out
a
call
for
help
or
for
more
folks
to
engage.
But
the
question
is:
how
do
I
do
that
within
cigar
CH
and
how
do
I
do
that
broader
within
the
community?
I
wanted
to
make
sure
that
we're
kind
of
mindful
of
we
have
all
these
efforts.
D
Ongoing
and
I
want
to
make
sure
that
I
want
to
make
impact
with
the
right
audience
and
also
with
the
community
and
making
sure
we're
doing
the
right
thing.
There's
a
lot
of
PRS
that
have
languished
on
the
backlog
for
conformance
we,
we
have
a
group
of
what
I
can
best
describe
as
people
who
care
about
this,
but
our
part
timers
right.
D
So
it's
not
their
full-time
effort
to
see
this
engagement
through
all
the
way.
So,
as
a
result,
there's
a
lot
of
languished
things
that
go
on
and
a
lot
of
fits
and
starts
so
I
guess
we
need
to
ruminate
on
it,
but
the
broader
problem
is:
we
need
people
who
are
devoted
to
this.
That
can
see
through
some
of
these
issues
along
the
way
and
help
Shepherd
folks
like
hippy,
as
he
tries
to
make
sense
of
the
universe.
From
the
external
viewpoint,
right.
A
So
this
is
partially
a
resourcing
thing
and
that,
as
we
know,
we're
all
bottle
necked
on
top
level
reviewers
is
there
a
way
to
like
is
the
API
review
process
has
done
to
maybe
do
some
sort
of
shepherding
of
new
people
into
this
process,
so
that
we
can
cultivate
me
of
folks.
Is
that
something
reasonable.
J
Yeah
I
think
that
that's
reasonable
we've
done
a
little
bit
of
that,
but
it's
it's
slow-going
much
inside
so
I
mean
I,
can
certainly
take
take
on
more
to
try
and
bring
more
people
on
board
with
that,
because
it
is
definitely
one
of
my
my
focuses
it's
you
know.
I
definitely
wanna
make
more
progress
with
it.
So
I
have
somebody
here
to
help
out
with
some
of
the
automation
around
the
test:
writing
not
automation
around
the
the
project
board
and
things
like
that.
I
But
yeah
I
do
have
to
say
about
the
conformance
test,
specifically
I'm.
One
challenge
we've
had
is
that
there's
a
lot
of
subtlety
in
detail
both
in
terms
of
the
functionality
that
needs
to
be
covered
and
how
the
tests
are
written.
So
getting
some
of
the
test
changes
through
was
quite
painful
and
took
many
many
many
iterations
and
that's
one
reason
why
some
of
the
PRS
may
appear
to
be
languishing
is
because
it's
actually
hard
to
get
the
issues
addressed
adequately
is.
J
Part
of
it,
yeah
I,
mean
sometimes
nobody's
subtle
things
in
the
test
that
just
need
revision.
We
have
we
had
hippie
and
his
team
as
well
as
some
other
folks
doing
a
lot
of
work
to
write
tests,
but
sometimes
they'll
be
things
like.
There
was
one
with
pod
template.
It's
like
hey.
We
wrote
a
test
for
content.
Lensing,
nobody
uses
an
API.
You
should
just
appricate
it
sorry,
so
there's
just
there's
a
lot
of
institutional
knowledge
or
or
tribal
knowledge.
H
M
Yeah
I
mean
I
was
gonna,
say
like
every
time.
I've
gone
to
final
approval,
I'd,
say
50%
of
them.
There's
something
settled
that
I
feel
like
it's
important
to
flag
before
merging
it's
things
like
something
requires
privileged
access,
something
that
forces
the
conformance
tests
to
not
run
as
a
user,
but
run
as
an
admin
things
that
not
all
tentative
distributions
might
run
things
that
imply
optional
features
that
we
have
to
go
negotiate
with
other
vendors.
So
it's
the
first
phase
of
it
has
definitely
been
somewhat.
We
need
the
get
the
process
in
place.
J
Part
of
my
goal,
like
personally
in
that
program,
is
to
work
on
liked
imposing
making
a
set
of
processes
and
functions
that
can
make
the
generating
simpler,
generating
the
test
easier
and
building
out
those
tests
easier.
But
I
think
that
for
the
deeper
questions,
I,
don't
necessarily
have
an
answer.
At
this
point
of
like
talking
about
here.
Yeah.
I
Or
you
know,
just
as
one
example,
someone
wrote
resource
quota
tests,
which
is
fine.
We
didn't
have
any
tester
resource
board,
except
some
of
the
resources
that
were
being
tested.
We
didn't
have
any
other
conformance
tests
for
and
wasn't
clear
that
we
should
add
them
like
implicitly,
he
required
that
as
part
of
conformance
just
accidentally
as
part
of
those
tests
right.
I
So
there
are
all
kinds
of
subtleties
that
surface
through
the
tests
where
you
know
someone
wants
to
get
a
result
from
a
container
that's
running,
and
they
do
it
by
accessing
some
incidental
API
that
actually
wasn't
previous
previously
covered
by
conformance.
So
we're
still
in
such
an
early
stage
that
we
encountered
that
almost
every
test,
I'd.
E
A
N
Ahead
of
that,
when
we
encountered
this
tribal
knowledge,
we
try
to
capture
it.
So
when
we
get
pushed
back
on
the
ticket
have
to
close
it,
we
try
to
go,
find
the
right
place,
an
updated
documentation
because
out
of
the
team-
and
we
put
it
together-
the
work-
the
output
either
needs
to
be
the
test
getting
written,
accepted,
promoted
or
we
write
documentation
to
improve
the
process
and
that
long
list,
I
just
heard
I,
think
it
was
from
Clayton
on
all
of
the
things
that
we'd
hit.
A
It's
half
past
I'd
say
we
move
on,
and
maybe
thank
you
for
taking
that
as
an
action
item,
because
I
do
believe
the
documentation
is
part
of
how
we
dig
ourselves
out
of
this.
It's
just
time
consuming
so
Tim.
Do
you
feel
adequately
covered
on
this
topic
so
far,
I.
D
L
L
A
H
Definitely
yes,
okay
thanks.
So
this
is
an
issue
that
came
up
recently.
There's
a
big
kerfuffle
on
the
mailing
lists
around
6:00
Eli.
Do
they
want
to
remove
CCT
or
not?
And
one
of
the
big
points
in
that
is
it's
a
very
large
maintenance
burden
for
the
sig
to
implement
properly,
and
that
kind
of
raises
the
question
that
we
don't
really
have
a
clear
rubric
of
what
kind
of
personas
we
are
prioritizing,
including
to
what
extent
we
prioritize
KK
development
above
these
are
features
and.
H
M
An
analogy,
I
might
add
to
this
point
is
there's
an
ownership
question.
So
six
Eli
owns
this
code
and
you
know
in
other
open-source
communities
depending
on
their
various
strictness
and
how
many
participants
like
Linux,
for
instance,
if
there's
no
maintainer,
that
code
sometimes
gets
removed,
whereas
we
do
not
have
an
equivalent
we.
M
This
is
maybe
the
first
of
the
examples
in
kubernetes
where
the
cig
doesn't
want
to
spend
the
time
on
something
that
they
don't
consider
as
important
as
their
other
jobs,
and
everybody
else
says
that
no
it's
important,
but
is
that
how
ownership
works
in
Tornai?
So
it
is
a
very
important
question
and
I'm
glad
that
we're
raising
it.
K
So
so
I'm
the
person
who
brought
up
the
personas
thing
on
the
list
and
and
who
the
users
are,
and
in
it
some
of
this
comes
down
to
and
and
I
referenced
helm
there,
because,
a
while
ago,
we
kind
of
had
some
discussions
about
that
of
who
is
the
target
right?
How
do
you
prioritize
different
users,
and
one
of
the
things
that
we
came
to
is
the
people
who
develop
on
it
we're
a
lower
priority
than
several
defined
roles
who
were
using
it?
K
So
we
were
willing
to
take
on
a
much
higher
burden
in
order
to
satisfy
their
needs
right
and
so
kubernetes
is
used
in
many
places.
How
do
we
look
at
that?
If
we're
maintainer
x'
of
things,
do
we
want
to
take
on
a
higher
burden
or
is
the
goal
to
ease
our
burden,
even
if
it
has
an
impact
on
end
users?
Who
may
not
be
happy
with
it?
How
do
we
compare
those?
M
Know
an
interesting
thought
that
I
had
while
this
conversation
was
going
on
like
I'm
kind
of
I
understand
the
security
risk
and
I
had
talked
to
a
few,
the
people
and
I
kind
of
agree
that
it's
a
much
worse
security
risk
than
code
and
it's
useful,
but
it's
not
useful
to
justify
the
cost.
There
was
an
interesting
from
my
perspective
is
not
a
single
person
in
that
thread
volunteered
to
step
up
and
take
ownership
of
every
security
related
bug
and
cute
control
CP
in
order
to
keep
that
code
in
the
codebase,
no
one.
M
M
The
maintainer
is
decided
to
keep
that
there
I
think
there
was
an
interesting
thing,
which
is
the
maintainer
z'
that
we
hear
is
sig
CLI,
not
everybody
else
who
chimed
in
and
if
someone
wants
to
get
involved,
that
really
strengthens
the
argument,
but
I
don't
think
it's
fair
or
I
mean
Affairs.
The
wrong
word:
it's
interesting
that
a
bunch
of
other
people
who
don't
work
on
this
code,
day-to-day
stepped
up
and
said:
no,
you
can't
remove
this
versus
the
opposite.
There's.
E
I
So
I
actually
took
a
look
at
the
code
when
the
thread
was
raised
and
since
the
bit
since
that
code
was
added
very
beginning,
it
had
to
use
to
solve
some
fundamental
problems
that
still
have
not
been
solved.
So
for
that
specific
issue,
I
think
you
know,
ownership
is
an
important
question
and
the
personas
are
an
important
question,
but
maybe
not
the
primary
ones
in
this
case,
because
I
still
hadn't
heard
proposal
to
how
to
solve
the
fundamental
problems
which
had
existed
since
the
command
was
introduced.
H
A
M
A
M
Really
interesting
part
is
part
of
the
reason
that
people
are
not
wanting
to
remove.
This
is
because
I
bet
every
single
person
who
is
looking
at
that
as
a
user
who
is
like,
if
they
remove
this,
it
will
never
come
back
and
it'll
never
get
done,
and
so
there's
there's
an
implicit
unstated
like
cuba's.
It
takes
a
long
time
to
get
things
in
the
cube.
K
M
K
I
think
there's
kind
of
two
things
in
my
mind
here:
one
is
irregardless
of
this
issue,
looking
at
who
the
people
are
right.
Who
are
the
roles
that
are
involved
in
this
and
what
do
they
need?
It's
a
user
experience
thing
this
issue
kind
of
brings
it
to
the
surface,
but
this
isn't
the
only
place
that
this
arises.
K
Quite
often
when
we're
creating
things,
we
look
at
what
do
I
want,
what
do
I
need
and
we're,
not
necessarily
thinking
of
who
those
end-users
are
and
if
we
actually
start
to
think
about
them,
look
at
them,
research
them
understand
them
and
maybe
even
prioritize
them.
Then
it's
easier
to
make
trade-offs
it's
easier
to
make
design
decisions
and
things
of
that
nature
so
as
a
whole.
I
think
this
is
useful.
K
I
think
were
part
of
this,
at
least
with
coops
ETL
really
spiked
it
for
me
was
when
there
was
the
idea
of
getting
an
exception
to
go
around
the
deprecation
policy
to
shorten
it,
which
puts
the
removal
of
it
in
the
holiday
season
when
everybody's
scrambling
and
debugging
things
and
is
stuff
like
that
worthwhile.
Is
it
that
much
of
a
priority
difference
and
who
the
users
are
and
what
they
need
in
order
to
drive
something
like
that?
K
I
think
that's
at
least
where
it
spiked
it
for
me
in
this
case,
because
it's
now
saying
this
is
such
a
high
priority
for
this
class
of
users
to
get
out
that
we
want
to
be
disruptive
outside
of
our
normal
processes
to
get
an
exception,
and
that's
when
I
really
started
to
think
about.
Well,
who
are
the
roles
and
how
are
they
impacted
and
how
do
we
even
think
about
those
so.
A
Housekeeping
thing,
real,
quick
we've
got
a
lot
of
people
with
hands
up.
We've
got
basically
one
minute
that
we
committed
to
for
this.
So
if
we're
gonna
move
to
the
next
few
opinions
or
hands
whatever
that
is,
then
we
should
extend
this
and
we
will
cut
down
time
on
the
other
things.
So
I
want
to
make
a
conscious
decision
about
that.
B
G
G
H
H
How
do
we,
possibly
from
like
a
governance
organization,
view
to
figure
out
how
to
balance
things
like
reliability
and
developing
sustainability
and
like
giving
the
users
the
firehose
of
features
that
they
want?
I
think
that
getting
into
like
what
our
quarter
priority
is
is
here
is
maybe
counterproductive,
but
I'm
curious
as
to
what
folks
think
about
is
the
best
venue
to
decide
this,
because
it's
going
to
be
a
fairly
long
and
complicated
discussion.
A
I'm,
just
from
an
administrative
standpoint,
we
have
a
value
as
a
sig
to
move
those
to
our
mailing
list
and
if
it's
crossed
sig,
then
there's
full
SIG's
get
included
on
the
mailing
list,
because
it's
not
it's
not
inclusive.
For
folks
that
can't
make
the
meeting
time.
So
if
we
can
do
that,
that
would
be
a
great
thing
to
do.
M
I
I
do
think
in
terms
of
long-term
sustainability.
The
ultimate
goal
is
that
people
have
to
maintain
an
own
code
and
ownership
is
comes
with
responsibility,
and
we
have,
in
this
project,
delegated
responsibility
to
our
owners
and
maintain
errs
with
a
set
of
checks
and
balances
from
outside.
That
is
advisory
and
in
the
best
interests
of
the
community
and
the
project
and
the
users.
But
maybe
this
is
a
good
opportunity
for
us
to
restate
or
to
wreak
lera
Phi
and
a
thread
or
something
along
like
on
the
mailing
list.
M
When
we
have
these
tensions,
do
we
delegate
and
allow
the
SIG's
to
make
the
right
decision
for
themselves,
even
if
there
is
disagreement
about
how
it
impacts
users?
This
is
a
really
tough
one,
because
we've
taken
a
very
strong
stance
towards
backwards
compatibility.
It's
one
of
the
things
that
makes
this
a
sustainable
platform
for
our
users,
but
I
think
about
things
like
the
security
issue
in
cubelet.
Around
volume,
mount
paths
that
took
about
six
months
and
at
least
ten
people
to
get
resolved
with
tens.
Or
you
know
tens
are
more
than
that
of
fixes.
M
If
we
can't,
we
kept
that,
because
that
was
such
a
fundamental
function
to
the
project.
If
we
can't
come
up
with
ways
of
saying
you
know
what
occasionally
something
that
we
merge
and
to
the
dual
of
Dericks,
we
might
put
something
to
GA
that
just
isn't
she
a
quality.
We
have
to
have
a
process
that
begins
to
recognize
that
without
saying
the
people
who
are
currently
maintained
errs
must
drive
this
to
conclusion:
we're
forcing
you
to
own
this.
K
Hey
with
cron
job,
which
is
not
GA,
yet
we
were
talking
about
it
recently
because
it's
it's
along
the
same
lines.
It's
not
ready.
We
can't
just
GA
the
current
code,
that's
there,
even
if
we
like
the
API,
but
there's
a
lot
of
people
using
it.
It's
it's
not
GA,
it's
not
released,
it's
not
the
door
and
it's
widely
used
in
production.
K
K
Why
should
anybody
care
but
then
there's
all
these
businesses
and
organizations
built
on
it,
even
though
we
haven't
shared
that,
and
so
this
kind
of
gets
into
that
hug
between
what
we
expect
and
what
we've
put
out
and
then
how
people
have
taken
it
and
gone
and
used
it
and
how
we're
supporting
it
and
I
don't
know
the
answer
there,
but
I
see
this
cropping
up
in
more
and
more
places
and
then
entirely
separate
from
that.
We
do
have
problems
of
enough
maintainer
x',
and
this
puts
in
my
mind.
K
C
So
I'll
know
one
thing
about
this:
this
is
available
for
anyone
to
maintain.
It
is
difficult
for
you
to
force
someone
to
maintain
a
thing
that
they
aren't
interested
in,
maintaining
or
don't
believe,
has
a
future,
and
if
we
can't
find
a
maintainer-
and
this
was
on
the
mailing
list
and
as
Clayton
noted
no
one
said,
I
want
this
feature
so
badly
I
will
maintain
it.
C
A
There's
a
little
bit
of
back-and-forth
in
the
chat
window
that
won't
make
it
to
the
video
just
to
raise
those
issues.
Real
quick
is
really
just
thinking
that
maybe
our
reach
isn't
big
enough,
necessarily
to
assure
that
all
the
voices
that
our
stakeholders
are
being
hit.
So
that
goes
back
to
the
personas
discussion
as
well.
So
Tim.
F
Today,
I
agree
with
what
David
just
said
frankly
to
the
point
of
the
cron
job
example.
This
one
weighs
on
me
because
I
didn't
even
realize
cron
job
is
in
GA,
yet
I've
told
users
she
was,
it
I've
told
customers
to
use
it
because
it
solves
a
real
problem.
They
really
have
and
have
had
for
literally
years
and
as
such,
without
you
know,
absent
a
solution.
This
is
it
I
think
you
know
early
on
in
the
project.
F
We
went
out
of
her
way
to
make
sure
that
people
who
used
bata
features
knew
they
were
using
beta
features
right
and
we
put
them
back
on
when
we
use
annotations
as
fields
we
put
the
word
beta
in
the
dang
annotation,
so
that
people
would
see
every
time
they
used
it.
They
were
using
beta
and
I.
Guess
beta
strictly
is
in
the
kind
of
or
the
API
group
of
the
cron
job.
But
nobody
sees
that.
That's
cardinal
cult,
galore.
F
Have
we
made
it
too
easy
for
people
to
use
beta
features
accidentally?
Maybe
we
need
to
go
back
and
revisit
this,
try
to
find
a
different
way
to
put
it
in
people's
face
without
carrying
the
burden.
On
the
back
end
like
we
had
to
deal
with
all
the
annotations
and
stuff
or,
alternatively,
maybe
we
need
to
take
a
different
approach
towards
pre
GA
features,
which
is
let's
just
not
urge
them
like
the
Linux
kernel,
doesn't
have
alpha
beta
GA.
F
It
has
things
that
are
merged
and
things
that
are
not
merged,
and
if
people
want
them,
they're
free
to
take
a
patch
off
with
somebody
else's
tree
and
build
it,
and
if
I'm
a
vendor
and
I
want
to
shift
that
thing.
If
I'm,
red
hat
or
a
bundu
or
whoever
I
can
take
that
patch
I
can
build
it
in
my
kernel,
I
can
volunteer
to
support
it,
but
it's
not
part
of
the
official
project
like
maybe
we
need
to
consider
something
bigger
like
this
social.
M
Clean
then
Bellary
I
don't
want
to
miss.
This
comment
may
sound
negative,
but
it's
actually
anymore,
like
I'm,
just
trying
to
be
pragmatic.
We
say
we
want
to
grow
the
amount
of
developers
and
contributors
in
the
project.
I
think
we
have
to
look
with
what
we
have
and
what
we
have
is
a
large
number
of
critical
functions
that
have
to
be
supported
with
a
a
slightly
growing
set
of
maintainer
x'
I.
M
Don't
think
it's
unrealistic
to
expect
the
large
influx
of
new
people
who're,
just
gonna,
magically
step
up,
not
that
we
should
stop
those
efforts
or
anything,
but
we
have
to
make
the
pragmatic
decisions
as
we,
which
is
when,
when
we
cannot
maintain
the
features
we
have,
we
have
to
give.
We
have
to
I
believe
the
right
thing
to
do
is
to
delegate
as
much
responsibility
as
possible
to
the
sig,
while
keeping
a
set
of
consistent
projects
that
at
least
notifies
users
I
do
feel
that
some
of
the.
H
As
someone
who
helps
maintain
patched
versions,
I
think
that
that
would
be
way
too
inaccessible
as
a
way
to
get
things,
especially
if
you
use
a
vendor
and
literally
can't.
But
I
would
like
to
see
way
more
in
your
face
and
way.
More
explicit.
Gating
for
a
feature
is
definitely
in
some
format
because,
like
I
use,
cron
jobs
I
have
never
hit
the
API
manually
and
never
noticed
their
data.
That
kind
of
thing
is
just
so
easy.
A
Alright,
let's
go
ahead
and
give
last
nine
minutes
to
P
hacker
and
the
discussion
around
that
and
I'm
sorry
that
it
got
pushed
out
so
far,
all.
N
Right
I'll
try
to
be
quick,
there's
three
main
points:
I
want
to
cover.
One
of
them
is
we've
been
asking
for.
How
are
we
doing
with
regards
to
pod
spec
pod
spec
has
34
fields,
and
we
initially
found
there
was
a
bunch
of
unhip
fields
in
our
test.
Suites
and
I
suggested
we
look
at
those
only
to
find
out.
They
were
alpha.
It
wasn't
clearly
marked
I
had
to
go.
N
It's
it's
documented,
but
you
had
to
know
to
look
in
the
documentation
for
those
fields,
and
we
wrote
some
things
to
capture
that
I'm
wondering
if
it's
something
that
we
could
mark
somehow
in
the
open,
API
spec
or
later
this
with
deprecated
deprecated,
is
available
in
open,
API
v3.
We
do
that
by
looking
for
uppercase
or
lowercase.
N
F
J
Just
discussed
because
of
the
stuff
with
hibi
I
just
discussed
this
one.
If
you
keep
on
here
and
not
an
IDL,
but
this
stuff
that
he's
talking
about
and
helping
to
put
something
out
in
the
next
couple
of
weeks
the
tops
you
know
that
tries
to
be
a
comprehensive
effort.
It
actually
like
four
or
five
different
efforts
to
do
this
in
different
slices
and
so
there's
just
no
overarching
organizing.
E
If
you're
parsing
the
human
documentation
with
reg
X,
that's
not
ideal,
you
can
add
an
arbitrary
number
of
like
plus
whatever
things
at
the
bottom
and
they
shouldn't
show
up
and
the
human
readable
documentation
and
they
would
be
machine
Parsifal.
So,
like
kind
of
knock
yourself
out
with
that
yeah
right.
J
J
F
E
F
N
Think
that
it
sounds
like
enough
time
on
that
topic,
we
can
visit
more.
The
other
thing
is,
we
are
both
wanting
and
requiring
that
we
we've
changed
the
limit
from
a
cycle
to
two
weeks
of
flink.
That's
a
flake
free
and
a
black
free
operation
before
promotion
for
running
tests
of
informants,
which
is
great,
and
we,
but
the
problem
is,
is
we
can't
have
those
conformance
tests
marked
as
GA
if
the
testing
it
if
the
endpoints
themselves
are
already
promoted?
So
we
have
this
chicken
and
egg
problem
that
we
need
to
address
its.
I
J
And
then,
and
that's
how
we're
doing
it-
the
issue
I,
don't
know
that
we
need
to
join
the
detail
here
that
the
issue
Jordan
had
during
the
web
book
and
stuff
was
partly
that
privileges
issue,
but
also,
if
what
you
automated,
then
those
can't
be
two
separate
PRS,
where
you
you
trigger
the
automation
that
you
must
have
confirms,
tasks
for
GA
and
the
promotion
to
G
out
of
those
tests.
So
this
is
really
a
question
around
automation
and
how
we
solve
it.
I
don't
have
time
yeah.
E
I
was
thinking
more
in
terms
of
I'm,
a
somebody's,
a
vendor
they're
they're,
offering
their
operating
kubernetes
for
people.
Is
it
really
fair
to
them
to
make
a
feature?
Go
stable
and
required
in
the
same
release
like
I,
would
kind
of
expect
it
to
be
stable
and
optional
for
a
release
to
give
people
time
to
actually
roll
it
out
and
then
become
required.
Okay,.
N
It
may
got
the
too
weak
for
like
free
needs
to
revert
it
to
a
cycle
just
so
that
we
can
have
what
you're
saying
have
the
it
out
in
front
of
the
world
before
we
force
conformance
in
the
next
cycle.
Let's
move
that
to
the
mailing
list.
That's
okay!
The
last
one
is
we're
trying
to
mark
test
as
this
disruptive
as
well
as
conformance
we've,
hit
a
point
where
we
promoted
something
that
we
need
to
be
able
to
evict
stuff
the
which
is
disruptive
and
it
should
go
everywhere.
How
do
we
do
that
together?
J
Yeah,
thank
you
for
raising
that
I.
Don't
know
that
we
have
time
your
address
and
I
think
that
we
will
we're
gonna
need,
there's
other
things
like
around
certain
types
of
workloads.
Eventually,
it
might
need
around
certain
nodes,
there's
privilege
issues.
We
had
that
whole
profile
discussion,
there's
probably
some
privileges
or
some
expectations.
We
have
to
give
to
people
running
these
tests
so
that
they
can
make
them
safe
in
their
environment.
I.
A
I
think
we're
good
on
that,
so
that's
gonna,
wind
up
in
the
maybe
sec
to
the
top-level
Milnes,
but
certainly
in
the
conformance
working
group-
and
I
guess
that
brings
us
to
the
hour.
Thank
you,
everyone
for
showing
up
and
participating
and
having
a
really
good
discussion
here
and
don't
forget.
Our
mailing
list
is
available
to
you
24/7
to
to
talk
about
these
things.