►
From YouTube: Kubernetes SIG Node 20210309
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
And
it
is
our
today
also,
it
is
the
120th
one
called
the
freeze
day
and
I
saw
several
proposals
already
to
the
so
we
need
to
the
code
phrase,
but
most
of
it
is
actually
it's
not,
and
I
also
want
to
go
through
that.
Our
planning
1.10
21,
I
think
most
it
is
already
update
either
already
almost
in
or
already
in
or
some
is
already
pounded
to
the
next
genies.
A
B
A
C
Let
me
kick
off
and
so
first
we
did
outstanding
work
this
week
there
are
kudos
to
people
standing
in
updating
prs
really
quickly
and
people
reviewing
it.
It's
great.
I
mean
we
did
way
more
than
we
typically
do
like
67,
pr's,
nourished
and
20
post.
It's
a
little
a
lot
of
progress.
C
One
I
mean
typically,
I
use
this
dashboard
to
review
what
happened
in
the
week
and
looking
at
the
67
pr
smurfs,
it's
like
it's
a
lot.
I
mean
you
need
to
understand
how
much
work
is
happening
in
our
sig.
So
yeah
I
mean
great
work.
Let's
keep
it
going.
I
mean
we
only
have
one
day
left
for
pr
emerges,
but
after
that
maybe
after
code
freeze
will
end
we
can
keep
up
the
space
again.
D
D
I
am
very
hopeful
that
the
release
team
will
give
us
an
extension,
at
least
for
the
cubelet
logging
migration,
just
because
having
a
half
migrated
cubelet
and
then
waiting
until
the
next
release
to
finish
migrating,
it
will
be
really
disruptive,
but
they
may
hold
off
the
graduation
of
the
rest
of
the
feature
to
beta,
which
would
be
fine,
but
I
asked
for
the
whole
thing
to
be
extended,
we'll
see
what
they
say.
I
have
not
heard
back
yet
I
don't
think
so.
D
That
has
certainly
been
responsible
for
a
lot
of
vlogging
a
lot
of
the
churn
and
I
can
share
the
board.
If
somebody
gives
me
co-hosts.
A
D
Great,
so
this
is
the
sig
node
board
and
I'm
just
gonna,
also
pop
in.
If
firefox
will
cooperate
with
me.
D
Structured
logging,
which
I'm
tracking
separately
and.
D
What
was
the
last
thing
that
I
wanted
to
show?
Oh,
the
ci
board
as
well.
D
So
yeah,
definitely
as
sergey
said,
velocity
has
been
very
good.
D
It
has
been
pretty
impressive
to
watch
things
go
and
I've
mostly
for
the
sick,
motherboard,
just
been
sort
of
dragging
things
into
triage
and
watching
them
get
triaged,
because
I
have
not
been
doing
triage
this
week
only
for
the
strong,
specific
stuff,
structured
logging
stuff,
because
there's
so
much
of
it
like
over
35
things
that
we're
tracking
specifically
for
that
I
have
a
board
just
for
structured
logging,
stuff
and
so
that's
kind
of
all
in
progress
and
making
its
way
and
then
in
terms
of
where
we're
at
for
the
signo
test
enhancement
stuff,
I
keep
dragging
stuff
on
here
and
it
keeps
getting
triaged.
D
So
if
you
want
to
get
involved
with
any
of
these
projects,
we
have
specifically
like
guidance
on
the
boards.
In
terms
of
like
how
do
I
help?
What
should
I
do?
I
don't
have
you
know
org
status
or
I
don't
have
like
reviewer
status.
What
can
I
do
in
order
to
help
out?
How
do
I
get
to
the
next
stage?
All
those
stocks
are
available.
B
Yeah
and
just
kudos
to
you
guys
for
getting
the
board
together.
It's
been
really
helpful
at
optimizing,
my
own
personal
time,
and
so
I'm
sure
it's
helped
others
so
big.
Thank
you
for
helping
this.
A
D
Well,
that's
great
the
chairs
meeting,
I
think
the
monthly
chairs
meeting
is
today-
and
I
am
gonna
be
talking
about
like
how
to
I
know,
lori
also
put
a
thing
on
the
agenda
for
different
sig
practices
and
best
practices
and
project
management,
and
that
kind
of
thing-
and
so
I
have
an
item
on
there
as
well,
for
like
training,
new
people
to
become
tech,
leads
and
sig
chairs,
and
that
kind
of
thing
for
some
of
the
other
sigs
that
are
wanting
to
bring
in
new
people
but
aren't
really
sure
what
to
do
or
how
to
improve
their
processes.
D
So
that's
happening
today
if
you
are
a
lead
or
some
for
some
reason
are
on
that
leading
invite.
A
Cool
thanks:
let's
move
to
next
topic
jack,
I
already
want
you
the
co-host.
I
know
you
have
the
dog
share.
Maybe
you
want
to
present
there.
So
next
one
we'll
talk
about
the
the
the
live
prop
timeout
issue,
that's
kind
of
a
regression,
but
it's
with
the
full
good
intention.
So
you
maybe
want
to
talk
about
this.
One.
A
A
A
Sure
so,
let's
move
to
next
topic
francisco,
do
you
want
to
update
the
power
resource
api?
Yes,.
F
Yes,
thank
you
dawn.
It's
me,
so
I
had
a
few
cycles
of
review
thanks
to
kevin
kudos
to
him.
He
did
great
reviews,
so
unfortunately
we
need
the
approval
he
he
cannot
approve
himself.
He
gave
it
looks
good
to
me,
though,
so
here
I
am
asking
for
approval,
because
I
added
the
feature
gates
which
were
in
turned
requested
during
the
product
showing
readiness
review.
So
that's
it.
Please
folks
have
a
look.
A
B
It
earlier,
and
I
think
I
asked
kevin
to
take
a
look
and
a
lot
of
my
comments
were
just
it
was
confusing
terminology
that
I
think
has
been
updated
now
in
the
pr,
and
so
I'm
I'm
at
this
point.
Okay,
with
as
long
as
those
changes
were
made,
it
looks
fine
to
me.
D
Oh,
I
just
wanted
to
I'm
doing
the
bad
thing
that
I'm
not
supposed
to
do,
which
is
tell
people
to
review
my
pr.
I
only
got
api
review
yesterday
on
it
and
I
am
nervous
about
the
code
freeze,
cutoff,
but
I've
addressed
all
of
the
comments.
So
I
think
it's
just
a
matter
of
hopefully
fingers
crossed
the
alpha
and
end
test
path.
D
Yeah,
I
finished
all
the
implementation
work
and
I've
had
the
pr
app
for
about
a
week,
but
nobody
has
really
taken
a
look
at
it
and
clayton.
I
poked
him
again.
He
did
the
api
review
yesterday.
There
was
a
bunch
of
stuff
that
I
was
not
aware
of
because
it
wasn't
documented.
So
I
went
and
did
all
of
that
and
I
think
it's
ready
for
another
round
of
review.
D
A
G
Cool,
I
know
I'm
not
sure
I'll
actually
share
the
doc,
because
it's
so
large,
but
I
will
happily
paste
in
some
link
matter
here.
Folks,
so,
hey
everyone,
real
quick.
I
just
wanted
to
bring
the
folks
attention
that
there
are
some
people
who
are
working
within
sig
note
and
cigar
and
wg
conformance
to
sort
of
figure
out
how
we
want
to
deal
with
the
exec
probe.
Timeout
feature
flag
going
forward.
So
a
little
bit
of
background.
G
A
side
effect
of
that
is
that
all
timeouts
have
default
values,
if
not
declared
in
the
user
spec,
and
that
timeout
is
one
second,
which
for
liveness
probes
is
arguably
a
little
going
to
be
a
little
impacting
for
folks
who
aren't
used
to
being
able
to
declare
those.
G
And
so
what
we've
been
doing
in
the
background
is
trying
to
make
sure
that
this
flag,
which
allows
that
behavior
to
be
disabled,
which
is
kind
of
funny,
because
it's
really
disabling
a
bug
fix.
But
we
want
a
little
bit
more
time
to
disable
that
so
various
kubernetes
providers
out
there
can
choose
to
kind
of
map
out
their
own
timelines
for
communication
to
their
user
community,
how
they
need
to
start,
including
timeouts,
with
all
their
exec
probes
and
then
possibly
in
a
best-case
scenario,
give
some
more
time
to
investigate,
possibly
increasing
that
timeout.
G
G
So
in
the
code
at
main
right
now
it
suggests
we're
gonna
remove
the
flag
in
121
which
we're
not
actually
going
to
do
as
dawn
mentioned
earlier.
We're
actually
feature
free,
so
nothing
further
is
going
to
merge,
but
I
wanted
to
advocate
that
we
sort
of
more
formally
define
when
this
flag
will
be
officially
disabled.
G
So
that's
what
that
issue
link
is
to
and
then
the
pr
updates
the
code
comments,
there's
also
another
pr
doing
the
similar
a
similar
thing
which
bumps
it
to
122..
So
if
folks
are
interested,
just
follow
those
two
issues
or
that
that
issue
in
that
pr
and
you'll
get
all
the
detail
and
then
I
also
finally
wanted
to
paste
a
link
to
sig
arch.
So
we're
going
to
talk
about
the
same
thing.
G
I'm
on
the
road
show
right
now
on
thursday,
at
11,
pacific,
1900,
utc,
basically
the
same
topic
in
cigar
as
this
touches
their
interests
as
well.
G
So
in
summary,
everything's
there's
no
emergency
or
fire
girl
from
our
perspective,
the
flag
exists.
So
if
folks
want
to
disable
timeouts
because
they
don't
want
that
default
one
second,
they
can
continue
to
do
so.
G
There
is
one
issue
that
we're
tracking
sort
of
more
aggressively-
that's
not
too
strong
of
a
word,
and
that
is
that
the
sig
conformance
tests
right
now
currently
fail
if
you
set
that
flag.
So
there
are
folks,
in
the
background
trying
to
make
this
feature
flag,
something
that
doesn't
inherently
fail
conformance
so
we'll
be
working
on
that.
H
G
H
Of
conformance
is
that
a
120
performance,
speed
against
a
120
cluster
or
or
is
there
like
working
skew
between
the
conformance
versions
against
the
cluster
that
is
causing
the
issues.
G
It's
the
former
lucky.
Are
you
familiar
more
with
the
nitty
gritty?
My
understanding
is
that
the
cluster
was
built
with
this
feature:
flag,
disabled,
which
is
a
way
of
saying
I
don't
want
exec
probe
timeouts
to
work,
and
the
conformance
test
has
a
new
test
that
validates
the
when
you
submit
a
spec
without
a
timeout,
but
it
times
out
after
one
second,
so
the
conformance
test
seems
to
be
not
sensitive
to
that
flag.
G
B
So
the
issue
was
specific
to
the
docker
shin,
given
that
I
think,
as
a
sig,
we
want
to
figure
out
a
you
know:
conclusive
state,
where
the
docker
shim
is
either
taken
out
of
the
cubelet
and
handled
separately.
Like
personally,
I
don't
like
giving
anybody.
You
know
this.
B
B
Is
that
okay,
if
that
was
the
case,
I
thought
maybe
my
memory
was
poor.
I
thought
it
had
just
been.
C
Yeah
there
is
a
difference
between
docker
shim
and
craig
on
on
dogersim.
You
know,
like
we
start
expecting
timeouts,
but
proto
is
still
running
after
we
kill
the
client.
That
makes
a
request.
So
that's
the
difference.
Your
memory
is
correct
in
there
is
a
difference,
but
actual
bug
was
fixed
on
both.
A
B
If
it
gives
people
you
know
heartburn,
you
know,
like,
I
don't
think.
As
a
sig,
we
want
to
upset
users
who
have
real
production
issues
or
concerns,
but
I
had
thought
that
this
issue
didn't
impact
cri
implementers
in
the
same
way,
and
so
sorry,
I
guess
I
have
to
refresh
my
memory
on
what
the
behavior
difference
was,
but
I
thought
the
timeout
was
respected,
but
there
was
something
related
to
the
grpc
called
flow
that
made
it
behave
differently.
So
I
have
my
own
homework
too,
to
refresh
on.
G
G
It
was
in
beta
2
that
we
suddenly
noticed
certain
tests
that
included
that
required
a
liveness
probe
to
take
longer
than
one
second
and
didn't
have
that
timeout
declared
those
tests
started
failing
we
do
test
container
d
and
and
moby
on
my
project,
so
I
can
do
some
homework
and
confirm
whether
or
not
this
is
particularly
related
to.
H
The
the
only
difference
with
calling
out
is
that
docker
shim
will
run
that
exact
probe
indefinitely,
and
it
doesn't
actually
do
like
a
context
cancel
on
the
process,
whereas
container
d,
it
didn't
respect
the
timeout,
but
then
after
the
timeout
it
would
kill
the
process
and
stop
it
from
running
indefinitely.
That's
the
only
difference.
G
E
And
I
think
you
know
just
advocating
for
the
users
here.
This
is
what
we've
seen
is
folks,
will
update,
upgrade
their
cluster
and
have
workloads
without
the
timeout
defined
and
they
will
not
pass
liveless
probes
on.
You
know
anything
that
takes
longer
than
a
second.
So
I'm
you
know
so,
as
a
you
know,
working
putting
my
you
know
work
at
azure
hat
on
in
something
like
aks.
E
We
either
have
to
choose
whether
we
want
to
break
users
or
break
conformance
apparently
so
we're
trying
to
not
do
both,
but
we
need
the
help
from
the
community
to
help
us.
You
know
guide
us
through
a
decision
here,
so
we're
we're
kind
of
advocating
to
leave
the
flag
off.
We
want
to
have
it
on,
but
it's
going
to
take
time
to
communicate
and
we're
worried
that
users
today
will
go
into
120
and
start
to
break.
E
So
that's
one
thing
and
the
other
thing
is:
we
don't
want
to
have
non-conformant
clusters,
and
I
don't
know
you
know
this
is
a
discussion
for
performance.
I
guess:
should
there
be
flags
dependent
on
their
state
that
break
conformance?
I
don't
know
of
too
many
flags
that
you
said
on
cubelet
or
otherwise
that
have
a
bubble
up
effect
that
break
the
conformance
profile
in
the
conformance
suite.
A
The
let's
now,
what
do
you
request
all
makes
sense?
I
believe
what
the
if
I
understand
what
you
earlier
proposed,
so
we're
going
to
leave
that
flag,
disable
that
and
at
the
same
time-
and
I
believe
he
and
the
work
with
the
people
to
fix
the
conform
test
once
that
flag.
A
It
is
on
so
so
the
basically
confirmed
has
wheelbase
on
agnes
for
this
feature
and
we're
based
on
the
feature
gig,
that's
what
I
understand
and
and
so
far
here
so
so
we
are
working
on
those
kind
of
things
so
that
in
but
how
to
long
term
and
to
turn
on
this
feature
and
still
not
break
of
the
existing
user.
A
That's
another
story
and
we
can
come
back
discuss
and
I
have
to
the
jacks
proposal
and
the
document
yet,
but
I
I
I
think
that
we
should
figure
out
away
from
the
community
because
that's
the
good
fix
and
but
how
we
are
going
to
mitigate
existing
customers,
which
have
the
dependency
on
the
broken
feature
and
that's
another
story.
Let's
discuss
come
back
and
discuss
more
on
this
one.
I
guess
the
jack.
Maybe
you
have
some
like
the
alternative.
A
G
Yes,
my
my
proposal
is
really
simple:
it's
to
continue
to
keep
the
flag
in
enabled
mode,
so
we're
not!
We
don't
want.
We
want
new
folks
landing
on
120
building
new
kubernetes
clusters
to
get
this
new
functionality,
because
this
functionality
that
should
have
been
working
all
along
and
then
to
just
extend
the
life
of
the
feature
flag.
G
So
certain
folks
can
choose
to
turn
that
off
because
they
run
kubernetes
services,
for
example,
that
support
lots
of
users
who've
been
on
kubernetes
for
a
long
time
and
have
built-in
production
workloads
that
assume
that
no
timeout
functionality
is
going
to
intervene
on
the
behalf
of
their
liveness
probes.
Hopefully
that
makes
sense
so
just
more
time.
For
that
feature:
flag
to
be
user,
opt-in.
B
E
If
you,
if
you
agree
with
that
derrick,
we
can
put
in
a
pr
to
fix
that
we
just
wanted
to
get
kind
of
high
level
approval
with
the
plan.
I
think
in
the
dock
jack
kind
of
lays
that
out,
but
we
didn't
want
to
go
just
jamming
prs
in
without
talking
to
you
all.
First.
B
Yeah,
I
think
that
makes
total
sense.
I
mean
we
should
still
verify
that
the
probe
occurs,
but
we
should
just
not
expect
a
one
second
timeout
so
find
some
other
reasonable
mechanism
that
represents
the
pre-120
behavior
seems
perfectly
fine.
H
G
I
I
would
honestly,
I
think,
that's
a
possible
solution
for
folks,
but
I
would
say,
let's
table
that
and
let's
come
to
a
consensus
around
the
fact
that
we're
going
to
extend
the
current
feature
flag
and
then
decide.
I
think
we
should
publish
like
let's
say
we're
going
to
make
this
available
until
124..
We
should
just
publish
that
so
it's
super
clear
and
then
I
think
those
conversations
are
super
interesting,
andrew
about
how
we
can
we
can
either
refactor
the
code
under
the
hood,
which
currently
assumes
a
common
type
definition
for
all
timeouts.
G
A
Andrew,
actually,
I
want
to
correct
feature:
gate
might
not
that
cheap
if
every
every
feature
owner.
I
did
that
one
and
the
level
calling
output,
but
I
just
want
to
make
sure
that
people,
because
we
we
we
spend
the
time
trying
to
clean
some
feature,
gate
over
many
release,
and
but
I
totally
agree
for
this
particular
issue
because
due
to
the
legacy-
and
we
can
make
this-
this
is
the
relative
compel
all
those
risks
we
can
expose
to
the
user.
This
is
much
cheaper
and
much
more
risk
I
just
want
to.
A
I
just
want
to
make
sure
that
people
don't
think
about
the
feature.
Gate
is
so
cheap
and
so
other
features
like
this
way.
So
so
so
I,
like
you
earlier,
say
that
if
we
could
for
a
long
time,
we
can
think
about
maybe
some
different
time
out
venue,
and
so
we
could
just
relatively
safe
to
enable
this
feature
and
reset
our
kind
of
status,
because
the
current
status,
basically,
we
just
have
to
live
with
that
back
right.
A
So
we,
but
we
do
the
reason
we
want
to
fix
that
bag
is
just
because
the
customer
came
to
up
to,
and
they
said
this
time
out,
venue
is
not
respected
and
and
which
is
make
them.
A
certain
feature
cannot
reliable
and
rely
on
this
kind
of
things
or
their
workload.
They
cannot
rely
on
those
things,
so
we
need
to
still
need
to
fix
this
problem,
but
how
we
are
going
to
safely
turn
on
this
feature.
A
It
is
harder
because
kind
of
problem
it
is
on
the
it's
not
on
the
user
side.
So
it's
our
problem,
so
so
so
so,
on
the
note
we
easily
enable
this
feature
or
disable
this
feature,
but
on
the
node
could
be
some
really
relay
on
the
bag.
A
Behavior
or
some
is
want
to
have
the
real
behavior.
So
we
need
to
think
about
some
like
the
better
way
to
handle
this
one.
That
could,
I
think
earlier
someone
mentioned,
maybe
like
the
user
config,
something
which
is
really
concerned
from
api
perspective,
but
we
could
discuss
more
yeah.
B
I
have
to
admit,
I'm
still
really
not
seeing
how
the
code
change
was
universal
to
all
cri
implementers.
I
I
see
that
there's
an
issue
that
says
conceptually.
If
the
probe
time
was
longer
than
any
grpc
timeout
we
allow
on
the
cubelet,
we
would
be
confused
and
it
seems
like
we
should
maybe
think
about
upper
bounding
and
some
validation.
That
says
this
is
the
standard
grpc
pro
timeout,
but
I
think
I
mean
renault
you
can
chime
in,
but
I'm
looking
in
the
background
here
and
it's
like
depending.
C
G
I
Yeah,
so
I
think
I
we
had
a
change
where
we
were
returning
the
error
that
the
cubelet
expects
on
a
timeout,
but
I
still
need
to
look
closer
to
see
like
what
would
happen
if,
if
you're
at
the
one
second
boundary,
we
may
still
get
a
deadline
exceeded
on
the
cubelet
side,
even
though
cryo
is
trying
to
return
the
the
message
that
cubelet
was
expecting
earlier,
so
I
pasted
a
link
in
chat.
If
you
guys
can
take
a
look
and
shaman.
B
Yeah
otherwise,
I
do
think
if
we're
gonna
look
at
this,
we
we
need
to
set
an
upper
bound
on
all
probe
timeouts
that
won't
exceed
our
grpc
timelines
or,
and
I'm
not
sure
how
to
roll
that
out.
But
that
seems
like
a
good
thing
to
also
do
as
a
follow-on
to
this
activity.
E
E
jack
has
put.
I
think
you
have
some
standing
prs
at
the
moment
that
somebody
could
review
to
extend
the
you
know
the
the
comments
on
the
deadline
of
that
flag
being
deprecated
and
then
the
other
thing,
that's
additional
that
we
haven't
done
at
the
moment
is
update
the
conformance
test.
To
basically
say
if
the
flag
is
on,
can
you
do
conditional
performance,
conformance
tests
based
on
flags
derrick?
E
B
Yeah
that
that
sounds
perfect
and
I'll,
give
you
an
example
of
like
the
pattern.
We
have
to
already
do
this,
so
here's
a
pr
I
did
last
week
that
skips
a
test
if
a
particular
feature
gate
isn't
on
yet
by
default,
and
it's
perfectly
fine.
We
do
this
in
other
elements.
E
Excellent,
so
we'll
come
back
to
the
next
meeting
and
just
give
you
a
laundry
list
of
prs.
J
A
B
H
A
K
Yeah
so
hello,
I'm
happy
to
meet
many
of
you.
I
was
here
last
week
there
was
much
lower
attendance,
so
I'll
just
do
a
real,
quick
overview
of
sort
of
what
I'm
proposing
here
and
I'm
hopefully
going
to
be
building
this
into
a
cap,
but
just
sort
of
gathering
some
information
beforehand
about
if
there
are
any
well-known
issues
that
would
would
make
this
a
horrible
idea.
K
K
With
with
system
d,
it
seems
that
systemd
has
a
fairly
high
cpu
utilization
when
you
have
a
large
number
of
mount
points.
The
reasons
for
that,
and
if
you,
if
you
follow
the
the
note
in
the
the
meeting
minutes
here,
there's
maybe
some
more
details
in
the
discussion
that
I
post
to
the
signoid
mailing
group,
but
basically
systemd
rescans
mount
points
and
when
you
have
a
huge
number
of
mount
points,
that's
exacerbated
pretty
significantly.
K
K
I'm
looking
right
now
to
see
if
there
are
any
specific
use
cases
that
we
know
that
this
would
break,
I
haven't
found
any
yet.
I
have
even
trouble
thinking
of
use
cases
that
that
would
break
because
top-down
mount
propagation
would
still
work.
So
something
mounted
by
the
host
os
or
something
running
in
the
host
would
still
be
available
to
the
container
runtime
and
containers
conditionally
based
on
the
mount
propagation
flags.
Of
course.
K
You
know
guarantee
of
what
the
environment
looks
like
where
kubernetes
is
running
and
since
that's
kind
of
a
small
change,
but
also
a
very
large
change,
that's
kind
of
why
I'm
in
this
information
gathering
stage,
if
that
makes
sense,.
D
So
jim,
I
I
listened
to
the
proposal
last
week
and
then
also
this
week
and
have
had
a
little
bit
more
time
to
think
about
it
and
to
me
like
this
sounds
like
a
system
debug,
so
I'm
not
sure
why
we
would
work
around
it
in
kubernetes
and
the
things
that
sort
of
stand
out
to
me
is
systemd
is
like
a
multi-purpose
init
system.
It
should
be
able
to
handle
a
large
number
of
mounts
and
it
should
also
be
able
to
handle,
saying
hey.
These
mounts
are
requiring
a
lot
of
scanning
and
rescanning.
D
K
K
Underway
to
actually
fix
this
inside
of
system
d,
unfortunately,
that
is
not
moving
very
quickly
and
the
there
are
two
other
reasons
why
this
would
be.
I
think
a
good
thing,
aside
from
the
systemd
workaround,
which
was
sort
of
the
original
impetus
for
actually
taking
on
this,
and
those
are
just
from
the
perspective
of
like
encapsulation
a
lot
of
these
mount
points.
If
not
all
of
these
mount
points
are
things
like
secrets
and
config
maps,
and
things
like
that.
These
are
really
like
implementation.
A
K
That
are
about
how
cubelet
exposes
resources
to
containers.
It's
not
really
something
that
the
host
os
needs
to
know
about,
and
that
in
a
way,
goes
to
what
I
think
is
a
minor
security
improvement,
which
is
if
these
mount
points
aren't
visible
to
that
sort
of
top
level
host
name
space,
a
regular
user
saying
you
know
fine
mount
or
just
mount
show
me
all
the
mount
points
right
now.
K
They
get
really
detailed
information
into
sort
of
the
exact
locations
where
all
of
these
secrets
and
config
maps
are
mounted,
whereas
they
would
not
get
that
information
anymore.
You'd
be
sort
of
hiding
that
information
from
regular
users
unless
they
have
the
capabilities
to
actually
enter
that
mount
namespace,
and
I
think
that
that's
gated
behind,
like
capsis
admin
and
and
something
else
so
not
a
huge
security
improvement,
but
I
think
it
just
one
level
of
inspection
that
a
potential
attacker
would
have
today
would
be
removed
in
in
this.
K
K
I
I
also
did
get
a
response
from
someone
who
was
saying
that
for
the
the
kind
it
might
be
a
useful
feature
to
allow
specifically
for
that
use
case,
but
that
was
just
sort
of
an
early
someone
perking
their
ear
to
say
this
sounds
like
it
might
be
aligned
with
what
we
want
to
do.
But
I
haven't
had
a
lot
of
discussion
with
them.
Yet.
D
Yeah,
as
far
as
the
mount
points
go
and
like
you
know,
oh
no,
there
are
a
lot
of
mount
points
that
are
exposed
to
the
system
and,
like
those
are
a
kubernetes
implementation
detail.
I'd
argue
like
trying
to
hide.
Those
to
me
seems
like
if
that's
an
implementation,
detail
like
it's
either.
It
is
valuable
for
that
to
be
exposed
to
the
system
as
is
or
it's
maybe
a
suggestion
that,
like
kubernetes,
should
reconsider
how
it
is
implementing
this
and
it's
a
smell
that
we
don't
want
to
sweep
under
the
rug.
D
So
I
don't
necessarily
think
that
it's
like
you
know
a
bug
that
we
see
this
right
now.
I
think
it's
important
to
be
exposing
that
yeah.
That
is
how
we're
doing
this
and
that
we
can
access
all
of
these
things
through
the
normal
mount
ways
and
that
they
are
treated
as
one
would
expect
any
other
mount
point.
Whether
or
not
that's
a
good
thing
right
now
I
mean,
I
think,
that's
a
much
wider
conversation
but
like
if
we
were
just
hiding
those
from
end
users
like.
I
So
I
think
one
more
angle
here
is
like
for
systemd
to
be
able
to
fix
this.
It
needs
change
to
the
kernel,
like
changes
are
proposed
to
the
kernel
in
the
way
that
it
propagates
changes
for
for
new
mounts,
and
that
is
something
that
isn't
going
to
land
anytime
soon.
So
I
think,
like
basically,
what
we're
trying
to
do
is
due
diligence
here
to
check
that
nothing
breaks.
I
If
we
make
this
change
and
so
far
like
based
on
the
responses
we've
seen
on
the
mailing
list,
we
haven't
found
a
concrete
example
of
a
case
that'll
break.
So
the
only
thing
that
we
would
really
need
change
is
this
one
test.
So
we
are
relaxing
that,
instead
of
propagating
to
the
host
just
propagating
to
the
cubelet
and
container
runtime
won't
break
you
and
then
it's
a
choice
for
you
like.
I
If
you
want
to
propagate
it
to
the
host,
no
one
is
stopping
you
from
doing
it
but
like
if
you
want
to
hide
it
like.
If
you
want
to
solve
the
system
d
issue,
if
you
want
to
hide
your
mouse,
if
you
want
to
kind
of
launch
multiple
kind
clusters
and
hide
their
mounts
from
each
other,
those
kind
of
use
cases,
then
I
think
this
is.
This
is
useful.
L
So
this,
so
this
is
going
to
be
entirely
dependent
on
how
a
node
is
configured
it's
like.
Does
somebody
run
services
on
that
node?
That
needs
those
kubelet
mounts
in
order
to
operate,
you
know,
maybe
it
is
a
csi
driver.
I
know
you
said
you
checked
everything,
but
it's
stuff
like
that.
That's
going
to
end
up
breaking
and
it's
very.
L
I
Right
so
the
case
you're
talking
about
would
mean
that
the
csi
service
is
running
outside
of
a
container
as
a
native
systemd
service
or
whatever
unit
service.
Whatever
internet
system
you're
using.
L
Sure,
or
you
know
whatever
could
just
be
something
on
the
node
that
that's
running
for
supporting
the
cluster
in
some
way.
I
Right
so
I
I
think,
we'll
point
that
out
yeah,
so
I
think
what
we
are
proposing
is
not
like
an
moving
from
the
current
model
to
the
other
model.
I
What
we
are
just
saying
is
just
relaxing
what
the
environment
requirements
are,
so
the
test
which
currently
looks
for
the
propagation
to
the
host
would
also
continue
to
work
if
your
cubelet
and
runtime
are
in
a
separate,
mount
namespace,
and
then
you
decide
on
the
basis
of
your
like
csi
implementation,
whether
your
csi
needs
to
run
as
a
host
service
or
within
a
container,
and
then
you
can
pick
whether
you
want
this
isolation
or
not.
B
B
The
only
issue
that
we
see
here
that
we
would
get
big
bang
from
or
is
this
like?
Should
there
be
concerns
on
this
as
a
a
slippery
slope
into
just
supporting
containerized
keyboards
again.
I
So
I
think,
like
so
far
for
this
particular
thing,
we've
only
used
looked
at
mount,
namespace
and
derek.
I
think
that's
what
came
to
my
mind
immediately
when
this
was
initially
proposed,
like
we
had
backed
away
from
this
in
the
past,
but
this
looks
like
a
narrower
thing
than
what
we
did
before
so
maybe
workable,
and
so
far
like
jim,
has
only
found
this
one
e2e.
That
is
failing.
M
D
M
I
was
just
saying
it's
a
level
set
on
it.
I
mean
we're
not
looking
to
make
a
change
to
the
cubic
code.
Only
that
test
and
the
and
the
the
higher
level
question
is
not.
Can
we
change
the
test?
It's
is
this
a
conformant
kubernetes
cluster
right
to
do
it
this
way,
and
if
it
is,
then,
if
we
decide
that
it
is,
then
we
can
relax
the
test
right.
If
it's
not,
then
we
need
to
have
a
reason
why
it's
not
and
the
test
stays
strict,
and
then
we
can't
do
this.
A
I
hope
other
people
from
other
side
came
in
because
this
the
propagation
feature-
initial
proposed
plastic
storage
and
those
like
the
too
many
mount
points
issue
actually
is
the
best
signal
and
we
do
with
one
consent,
but
is
insisted
for
certain
deploy
option,
but
because
we
have
to
trust
that
that's
the
front
of
sig
storage.
So
that's
why
we
take
that
and-
and
so
that's
also
is
based
on
the
deployment
from
red
hat.
And
then
I
noticed,
like
the
always
came
from
the
openshift
deployment,
and
then
we
saw
the
problem.
A
So
I
I
want
to
see
the
other
side
of
the
deployment
and
is
this
going
to
this
change
is
going
to
bring
some
negative
regression
or
not
because
we
do
have
monitored.
We
do
because
we
used
to
have
the
signal.
The
perf
test,
the
monitor
the
node,
the
resource
usage,
especially
for
the
docker
kubernetes,
and
all
the
other
daemon
sites
have
to
live
on
the
node.
A
A
I
don't
know
all
the
contacts
right
now
because
I
haven't
read
that
email
yet
so,
but
I
do
agree
either
a
lot
say
like
a
hider
from
the
from
the
user
and
hack
that
one
actually
maybe
have
the
potential
problem.
Also
in
the
past.
Actually
we
do
found
some
system
d
problem.
We
did
the
actually
kubernetes
kubernetes
community
did
push
the
system,
defects
right,
for
example,
when
we
first
talked
about
the
sql
version,
2
and
the
people
push
very
hard
on
the
system
d
and
enter
up
the
system.
A
G
cannot
support
the
hybrid
mode.
So
we
push
it
back
and
ask
him
to
support
both
the
sql
version,
one
and
secret
version
two.
So
there's
the
several
of
the
change.
This
is
one
change.
I
remember
there's
the
several
change
at
the
earlier
container,
runtime
interface
development,
and
we
also
found
some
systemd
related
issues.
So
we
pushed
back,
and
so
it
is
possible.
A
I
just
don't
I
just
kind
of
if
we
do
think
about
that's
the
initially
reasonable
use
cases
and
the
deployment
why
we
think
about
the
we
don't
need
that
one
could
be
situation
change,
because
I
do
remember
that
came
also
from
the
open
shift
deployment.
I
think
about
that's
the
reasonable
approach,
so
so
now
we
think
about
it.
Isn't
we
don't
need
that
one?
So
we
we
need
to
call
out
other
deployment
other
like
the
vendor
and
say
like
it.
Is
that
no
regression,
I
don't
see
much
people
come
chiming
here.
A
B
A
B
Yeah
yeah
does
the
does
the
issue
get
and
so
to
be
clear.
My
understanding
here
is
it's
not
a
system
debug,
so
it's
inaccurate
to
classify
it
as
such
right
and
so
given.
That
is,
is
the
kernel
patch
in
this
thread
here
that
people
could
go
review
because.
K
Yeah,
let
me
make
sure
that
I've
got
that,
but
basically
yeah,
there's
a
red
hot
bugzilla
that
was
sort
of
my
introduction
to
this,
and
it
looked
like
that
had
deeper
links
to
the
actual
changes.
But
I
I
can
double
check
that.
B
Yeah,
I
just
want
to
make
sure,
as
a
community
we're
not
disparaging
other
communities
when
the
bug
is
actually
not
that
community's
bug
and
from
that
perspective,
like
kubernetes,
should
work
well
at
minimal
levels
of
pod
density.
Where
my
understanding
of
this
issue
is
that
it's
not
working
as
well
as
it
should,
and
from
that
perspective
like
as
a
community,
I
would
think
we'd
want
to
bring
down
our
overhead.
B
I
just
want
to
make
sure
we
all
have
the
right
visibility
into
the
core
issue
and
maybe
some
understanding
on
when
the
colonel
itself
may
be
addressing
that
issue
or
not
to
make
an
informed
change.
D
Yeah
is
there
a
write-up
of
how
this
specifically
like
affects
cube
in
a
cube
context
on,
like
the
kubernetes
bug,
tracker.
K
Yeah
sure
I
could
write
something
up
for
that
and
it's
I
think
it's
it's
really
like.
Cubelet
itself
is
not
affected
by
this,
except
that
there's
less
cpu
available
to
it
and
other
pods,
because.
D
I
think
if
it's
like
a
node
level
concern,
then
it's
totally
valid
to
say
like
hey,
you
know
it's
not
necessarily
that
it
affects
the
cubelet,
but
it's
like.
Oh
all,
this
cpu
is
going
off
to
do.
A
D
Other
stuff
and
that's
bad
for
the
node,
because
that's
less
cpu
for
workloads
so.
B
Yeah,
so
my
understanding,
the
use
case
here
is
you're
in
an
edge
deployment,
and
you
want
to
be
able
to
use
your
cpu
as
you
see
fit,
and
the
fact
that
managing
a
process
under
kubernetes
is
more
expensive
than
maybe
traditionally
managing
under
systemd
is
an
impediment
to
adopting
cube,
which
seems
like
a
bad
thing
for
us
as
a
community,
and
so
I'm
I'm
far
more
open
to
this.
B
If
we
understand
the
root
issue
and
to
me,
the
root
issue
is
not
systemd,
it
is
the
kernel,
and
so
if
we
can
just
get
clarity
on
root
issue
and
maybe
revisit
this
next
week,
we
can
come
to
this
with
with
broader
perspectives.
I
guess,
but
I
to
me
managing
a
process
through
kubernetes
shouldn't
incur
such
an
overhead
to
make
someone
not
want
to
use
kubernetes
and
running
400
mount
points.
B
I
don't
know
if
that,
what
what
number
of
pods
that
map
to
does
not
seem
like
excessive
numbers
of
of
pods,
that
we
shouldn't
as
a
community
look
to
fix
so.
K
Yeah
I
mean
that
was
like
out
of
the
box
open
shift
with
no
workloads.
Basically-
and
that's
you
know,
systemd
was
sitting
around
10
effectively
idle,
but
just
keeping
the
the
cpu
nice
and
hot
okay.
M
Before
we
move
off
of
this,
I
mean
we're
talking
about.
Like
I
mean,
I
think
we're
talking
about
solution
space
here,
but
backing
up
to
the
to
the
initial
question
of
kubernetes
conformance,
and
that
is
like
we
have
api
guarantees,
and
things
like
that
is
this
effectively
like.
Is
this
a
functionality
version
of
an
api
guarantee
is
really
what
it
comes
down
to
me
is
it's
like
once
a
behavior
is
codified
in
a
conformance
test
like
do
we
say
we
are
not
going
to
change
it
like?
Is
that
behavior
not
changeable?
M
Is
that
like
a
guarantee
going
forward
or
is
a
conformance
chest
or
conformance
test
changeable?
I'm
not
sure
what
users
expect
right
if
you
go
into
the
conformance
test
and
you're
like
okay,
anything
that
a
conformance
any
behavior
that
a
conformance
test
guarantees
for
me,
I
can
assume,
will
always
be
this
way.
Is
that
reasonable
for
people
to
think
do
people
do
users?
Think
that
way?
I
guess
that's
that's
where
I'm
going
down
on
this
thread.
A
It
says
I
think,
if
we
change
it,
sound
like
the
user,
configurable,
api
library,
things
so
dramatically,
so
I
think
I
do
think
about
the
that's
kind
of
good
for
beta,
but
unless,
basically,
no,
even
as
the
user,
like
the
api
specific,
but
no,
we
already
migrated
user
off
from
that
particular
api.
We
have
confidence
right.
I
still
think
about
it
is
arguable
or
it
is,
could
be
redefining
that
behavior
the
system
always
have
to
evolve
so
have
to
be
the
case
back
is
in
these
cases.
A
I
I
already
see
that
jim
did
a
lot
of
due
diligence
and
try
to
say
do
we
have
use
cases
looks
like
we
don't.
I
don't
need
the
united
states,
the
I
also
don't
know,
but
I
just
want
to
call
out
earlier
because
that
be
have
actually
insist
by
the
previous
sig
storage
and
the
open
shift
and
also
other
my
problem.
It
is
right
now
at
this
moment
the
other
vendor,
maybe
even
don't
know,
they'll
rely
on
that
one.
A
So
it's
just
like
the
proper
liveness
proper
time
out
right
so
obviously
from
day
one
that
be
designed
by
design.
That's
not
the
right.
Behavior
but
the
customer
may
already
rely
on
and
the
winner
even
don't
know,
customer
already
rely
on.
So
that's
my
little
concern
here.
So
we
need.
We
need
to
think
about
how
to
obviously
the
water
jim's
data.
The
problem
is
really
not
acceptable
problem
and
but
but
I
remember
this
problem-
it's
been
raised
in
the
past
and
the
corresponding
answer.
A
It
is
basically
that's
the
knowing
issue
and
it's
going
to
fix
later
and
in
the
in
I
forgot
to
fix
it,
but
not
the
outside
of
the
kubernetes.
That's
going
to
be
addressed.
So
this
is
the
problem
and
are
we
going
to
show
so
we
maybe
could
say?
Oh
that's
actually
previously
claimed.
We
are
going
to
have
that
use
cases.
Actually
it's
a
fourth
claim
and
we
don't
have
the
use
cases,
but
we
need
to
have
confidence.
So
I'm
not
sure
I
don't
see
the
use
cases
at
least
from
gk,
but
I
don't
think
about.
A
I
know
all
the
use
cases
from
the
gke
and
then
I
don't
know
either
vendor
that's
the
problem
today,
but
I
do
think
about
the
openshift
already
stay
clear
because
do
the
due
diligence
maybe
see
that
when
they
don't
need
these
kisses,
which
is
good.
So
we
may
need
to
think
about
some
way
to
fix
this
problem
at
a
lower
level,
and
we
don't
care
about
it's
the
kernel
or
systemd
or
kubernetes.
We
are
open
to
fix
at
whatever
things
to
provide
the
best
for
a
customer
and
conform
task
also
could
be
changing.
B
I
just
think
gemma
thank
you
for
the
diligence
and
maybe
just
as
a
next
step
if
you
could
share
the
kernel
issue
and
we
can
revisit
this.
That
seems
like
a
clear
course
of
action,
but
I
don't
want
to
discourage
evaluating
what
we
can
do
to
be
more
efficient.
N
Yeah
hi,
so
this
is
pretty.
I
think
this
is
more
of
a
check
on
where
we
are
with
the
ask
was
to
review
two
pr's
one
of
them.
The
is
tim
hawkins
and
I
we
worked
on
the
changes
to
the
in-place
pod,
vertical
scaling
design
and,
I
think
direct
we're
waiting
on
direct
to
take
a
look.
This
is
pr1883.
N
If
you
get
the
chance,
please
take
a
look,
I
think
you're
the
last
person
to
look
need
to
who
needs
to
look
at
it
and
see
if
everything
you
know
smells
okay
to
you,
no
concerns.
If
you
have
any
questions,
I'm
happy
to
answer
them
here.
Have
you
had
a
chance
to
look
at
this
one.
N
Yeah,
we
won't
put
this
try
and
get
this
into
one
two
two.
I
just
want
to
get
an
early
start
on
this,
so
if
there
are
any
concerns,
if
you
could
look
at
it
and
then
whenever
you
get
the
chance,
that'll
be
great,
the
second
one
is
cri,
just
adding
it's
a
process
change.
The
prr
section
was
missing
from
our
older,
older
incarnation
of
the
cap,
and
I
added
that
so
that
can
possibly
just
be
merged.
N
If
there
are
no
flags
that
you
see
I'll
follow
up
next
week
on
this,
so
is
that
okay.
A
Thank
you
villain
and
the
next
last
topic,
this
condition
between
scheduler
and
the
kubernetes,
I
think,
related
to
the
memory
management.
So
I
guess
that's
what
you
proposed.
Sorry.
O
High
false,
can
you
hear
me
it's
not
it's
not
really
related
to
the
memory
measure.
I
found
this
issue
under
one
of
our
ci
jobs
to
be
more
specific
under
the
heat
page
job.
O
So
the
problem
that
I
saw
that
pod
was
moved
from
pending
face
to
scheduled
one,
so
it
passed
the
scheduler,
but
after
it
was
felt
because
cubelet
said
that
it
does
not
have
enough.
Resources
doesn't
have
enough
q
patch
resources
so,
like
you
are
welcome
to
to
leave
any
comments
under
the
issue
and
I'm
pretty
curious.
Why
do
we
need
like
checks
in
both
place
like
in
scheduler?
O
It's
the
same
check
like
we
have
a
feats
plugin
in
under
the
schedule,
and
we
also
call
to
fix
plugin
under
the
cubelet
during
that
mid
phase
and
like
in
both
places,
we
are
using
like
different
cache,
so
the
picture
of
currently
running
posts
can
be
different
and
it's
the
place
for
the
race.
O
A
A
I
think
we
run
out
the
time,
and
I
look
here,
though,
thanks
for
reporting
this
problem,
we
can
follow
up
through
the
issue
and
I
saw
your
pr
to
fix
of
the
docker
shim
already
be
merged,
and
I
think
that
we
we
need
to
call
out
and
to
make
sure
the
crowd
and
the
continuity
don't
have
this
problem
and
we
need
to
also
look
at
the
the
initial
issue.
I
have
to
figure
out.
What's
the
initial
issue
and
just
based
on
your
discussing,
we
can
follow
up
on
the
issue
here.
O
A
Okay,
this
is
confused
me.
I
don't
understand,
okay,
so,
okay,
so
let's
follow
up
in
the
issue
and
and
after
meeting
so
thanks
everyone
for
today's.