►
From YouTube: Kubernetes SIG Node20210629
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
C
I
think
we,
what
was
the
specific
numbers?
I
posted
them
in
the
slack
as
well,
but
we
definitely
closed
over
100
bugs
when
we
squashed
bugs
last
week.
So
thanks
everybody
who
helped
out
with
that.
Let's
see
what
are
the
exact
numbers
and
sergey
made
some
graphs
too,
which
were
really
great.
Yes,
we
closed
136
issues
and
we
updated
over
200.
So
I
should
say
we
updated
over
200
that
were
still
open.
I
don't
think
that
counts
all
of
the
ones
that
we
closed
as
well.
A
C
Oh,
it's
me.
I
thought
that
vinay
was
in
front
of
me
yeah.
I
think
that
I
just
need,
like
final
approval,
jordan
finished
up
api
review
and
I'm
just
pushing
out
some
stuff
to
fix
nits,
but
other
than
that,
I
think
it's
basically
good
to
go.
Seth
reviewed
the
implementation
a
couple
weeks
ago.
Now
I
think-
and
there
was
no-
there
were
no
really
big
changes.
A
C
C
Oh
wow,
it's
just
the
whole
agenda
is
me
today
yeah,
I
have
requested
approver
access.
I
hope
that's!
Okay
with
folks
somebody
pestered
me
saying
you
have
reviewed
something
like
500
node
prs.
Why
are
you
not
an
approver,
so
I
said
okay,
I
will
apply.
I
think,
I'm
waiting
on
don
and
some
of
the
folks
from
google
to
take
a
look
at
the
request.
A
A
Iran
has
been
leading
and
facilitating
1.22
leeds
cohort
training
group
which
I've
had
the
opportunity
to
experience
kind
of
first
hand,
and
that
has
been
kind
of
a
great
great
learning
opportunity
for
me,
as
as
a
representative
from
sig
note,
and
there
are
other
representatives
from
other
sig
sigs
as
well,
and
this
is
part
of
the
contributor
ladder
growth
program.
So
if
people
want
to
sign
up
for
like
the
following
releases,
it'll
be
kind
of
a
great
learning
opportunity.
D
Like
the
growth
path
for
cygnode,
others
have
expressed
interest
as
well,
and
so
one
of
the
things
I
wanted
to
do
was
get
the
existing
set
of
approvers
together
to
write
down,
maybe
their
path
to
approver
and
maybe
some
common
criteria
that
we
can
evaluate
these
things
going
forward.
And
then
hopefully
we
can
meet
this
week
and
then
proceed
from
there.
But.
D
E
Yeah,
so
we
don't
have
like
the
clear
written
requirement.
Explicit
site
is
being
issued
in
the
past,
so
this
is
why
signaled
and
also
work
with
some
other
thing,
have
some
like
the
some
written.
But
it's
not
the
word
clearing,
because
one
issue
we
realized
in
the
past.
It
is
so
some
of
the
sick.
Big
sticks
like
sticking
like
the
signal
large
enough
and
a
poor
means
three
different
laws,
and
so
there's
no
final,
granular
definition.
So
that's
why
this
is
is
missing.
E
And
then
we
can
come
back
because
we
think
about
the
a
fair
fox
includes
avalanche
on
the
past
towards
that
one,
and
we
should
make
that
more
clear,
and
so
we
have
a
constant
standard
for
the
community
can
follow
and
also
it's
written
down
publicly
and
then
we,
the
people
can
follow
and
they
can
really
just
self
exams.
They
are
where
they
are.
D
C
A
F
A
G
F
F
I'm
wondering
I
don't
know
if
tim
hawkin
got
a
chance
to
look
at
the
api
changes
so
I'll
ping
him
again,
he
mentioned
that
he's
got
me
in
the
queue
I
just
don't
know
how
backed
up
he
is.
I'm
wondering
if
lantau
had
a
chance
to
look
at
the
core
implementation.
Most
of
this
is
report
from
what
david
ashbal
had
already
looked
at
pretty
closely.
F
I
kept
it
kept
the
code
structure,
the
the
key
piece
of
how
the
cubelet
processes
changes
and
how
it's
plumbed
down
to
the
cri
and
how
the
container
status
is
queried
and
then
the
the
the
api
status
is
generated
for
part
status.
They
mostly
remain
the
same.
The
new
thing
is
the
checkpointing
code
and
I
put
that
under
status.
F
H
F
I
didn't
want
it
to
be,
you
know,
considered
for
merge
ready
until
it's
pretty
close
to
ready
I'll,
remove
those
labels
now
because,
okay,
I
I
want
to
remove
it
after
I
get
done
with
the
scheduler
and
resource
quota
changes,
although
it's
pretty
small,
I
want
to
make
sure
that
I
do
this
by
hand
as
in
manually
to
make
sure
that
I
don't
miss
anything
or
so.
This
was
already
done
in
the
last
iteration
we
switched
from
using
requests
because
requests
can
now
change.
F
Previously
request
was
immutable,
so
when
you
create
the
part,
it
is
what
it
is
so
now
we
have
to
do
a
max
of
requests
and
resources
allocated.
That's
what
we
agreed
we
decided
to
do
and
I
think
it
is
reasonable.
It
might
even
be
simpler.
I'm
planning
to
do
that
in
a
couple
of
days.
Just
I've
been
backed
up
with
other
things,
so
I
haven't
gotten
to
this.
I
know
time
is
running
short,
but
I
think
the
rest
of
the
code
is
ready
for
review.
F
C
F
F
A
I
I
I
I
I
work
on
gardner,
so
it's
an
open
source
kubernetes
as
a
service
and
yeah,
because
that's
the
first
time
I'm
presenting
something
here.
I
want
to
say
hi
here:
okay,
let's
jump
right
into
it.
Currently,
setting
cube
and
system
reserved
is
basically
a
static
configuration
right
in
the
configuration
file,
cubesurfed
system
reserved-
and
it's
typically
done
prior
to
the
cubelet,
startup
and
updating
cuban
system.
Reserves
requires
a
cubelet
restart
and
how
it
is
typically
done
for
kubernetes
manage
kubernetes
offerings.
I
Is
they
calculate
the
cuban
system
reserved
based
on
the
machine
size?
Gke
is
apparently
doing
it.
Azure
openshift
has
an
enhancement,
open
and
also
gardner
is
doing
that.
What
we
have
observed
is
that
calculating
reserved
resources
prior
to
the
cubelet
process,
starting
is
an
approximation
in
the
best
case,
and
we
have
had
some
troubles
because
on
particularly
busy
clusters,
we
have
seen
that
the
resource
reservations
were
too
low
and
for
mostly
idling
clusters,
not
a
lot
of
parts
running
on
it,
and
the
resource
reservations
were
too
high,
based
on
the
machine
size,
calculation.
D
I
I
D
Yeah,
I
guess
so
I
was
just
trying
to
some
some
folks,
you
know,
might
tune
for
particular
workload
characteristics
I
guess
and
so
like.
If
you
are
trying
to
bin
pack,
your
nodes
or
you're,
trying
to
you
know,
plan
your
notes
for
20,
40,
80
or
just
the
pods
per
core
calculator,
I
think,
is
what
10
pods
per
core
right
now
is
the
default
and
cable.
I
just
wasn't
sure
if
those
other
knobs
were
going
in
the
heuristic
beyond
either
ram
or
cpu.
I
I
Yeah,
that
makes
sense
so
just
real
quick.
Why
is
that
even
important
consequences
over
reservation
over
reservation
leads
to
lower
note
allocatable
you
have
that
has
effects
on
scheduling.
All
of
that.
In
the
end,
we
increase
your
costs
lower
the
utilization,
as
you
were
mentioning
regarding
bin
packing,
for
instance,
the
bigger
problem
that
we
have
faced
is
under
reservation
for
a
cpu,
I'm
just
mentioning
cpu
and
memory
here,
but
I
think
it's
similar
for
other
resource
types
cpu
here.
I
Maybe
something
like
plaque
is
unhealthy,
so
yeah
it
can
surface
in
various
ways
and
it's
hard
to
to
debug
and
then
to
know
why
memory,
the
the
major
issue
that
we're
seeing
here
is
when
you're
under
under
reserve
memory
is
that
the
the
global
om
linux,
om
killer
hits
before
the
c
group
level
om
killer.
So,
basically
that
the
node
is
running
out
of
physical
memory
before
the
q
parts
c
group
limit
is
hit,
and
that
has
some
bad
implications
because
then
any
almost
any
process
on
the
host
can
can
be
terminated.
I
Yes,
it's
influenced
by
the
quality
of
service
class
yeah,
but
we
have
also
seen
here,
problems
also
always
deadlocks
due
to
when,
when
this
global
out
of
memory
happened.
So,
ideally,
of
course,
the
the
c
group
limit
on
the
coupon
slice
would
hit
first
because
before
there's
a
global
out
of
memory
happening.
I
So
that's
that's
the
goal
for
the
memory
setting
the
right
limit
for
the
memory
here,
yeah
just
to
show
it
real,
quick,
usually
we
under
reserve,
so
the
the
c
group
memory
limit
is
quite
high.
Actually
almost
like
almost
at
capacity
level.
I've
indicated
that
here
it's
a
physical
capacity
level,
and
the
only
thing
I
want
to
show
here
is
that
the
the
memory
limit
on
the
q
port
c
group
is
not
at
all
reached.
I
Yet
there's
a
lot
of
there's
a
lot
of
capacity
left
technically,
but
the
host
itself
is
almost
running
out
of
memory.
So,
even
though,
by
adding
a
little
bit
of
of
memory
usage
to,
for
instance,
cue
parts
or
any
other
was
process,
the
the
limits
on
the
cubot
slides
are
not
hit.
But
before
that
happens,
the
the
whole
machine
is
running
out
of
memory
and
that's
typically,
what
we
are
seeing
when
we
under
reserve
memory
and
that's
problematic
one.
I
I
And
now,
then,
the
question
is
what
drives
the
cubelet
and
container
runtime
resource
usage.
What
we
have
observed
is
the
number
of
parts
running
currently
on
the
node.
I
think
that
also
makes
sense
because
the
cubelet
and
the
container
runtime
have
to
handle
more
parts,
and
there
are
also
additional
container
runtime
shim
processes
for
each
part.
I
In
addition,
a
big
influence
is
the
kind
of
work
like
running
or
deployed
on
the
node
currently,
and
that's
something
that's
very
difficult
to
predict
or
impossible
to
predict
if
you're
running
a
managed
service,
because
yeah
people
can
deploy
any
kind
of
workload
on
it
and
we
are
unsure
exactly
why.
That
is
the
case.
I
think
that
would
need
more
deep
investigation
to
why
exactly.
But
we
we
see
that
across
a
lot
of
clusters
showing
you
here,
the
parts
deployed
just
from
one
to
one
10
to
100
parts.
You
can.
I
I
What
you
can
see
here
is
for
in
this
test.
Cluster
docker,
for
instance,
is
using
2.6
gi
and
the
cubelet
is
using
120
and
comparing
that,
with
the
real
world
usage
that
we
are
seeing
there,
it
is
almost
more
than
double
it's
6
gi
and
300
mm
mi
for
the
cubelet.
Even
though
we
are
running
the
same
amount
of
parts,
it's
the
same
operating
system,
it's
the
same
machine
and
size
so
yeah
the
workload
has
some
influence
on
it.
D
I
I
Basically,
the
main
idea
would
be
to
because
we
are
seeing
all
these
problems
try
to
find
a
better
way
to
or
a
different
way,
how
to
reserve
resources,
especially
for
memory
and
cpu,
and
that
also
takes
into
account
the
current
usage
on
the
system,
because
it's
really
hard
to
predict,
at
least
for
us,
and
what
kind
of
workload
is
running
on
it,
how
many
parts
and
then
how
much
cpu
and
memory
is
going
to
be
consumed
by
that
and
has
to
be
reserved
yeah
yeah.
I.
F
Just
want
another
question:
to
clarify
sorry,
the
the
real
world
system
and
the
test
system.
They
were
the
pod
specs
were
the
similar
in
terms
of
both
the
init
container
and
the
actual
container
spec,
except
that
it's
not
doing
any
work,
reserving
the
same
amount
of
memory.
But
I
I
just
want
to
make
sure
the
init
containers
were
not
missed.
I
F
J
J
E
So,
alexander,
you
are
right
yeah,
so
maybe
we
leave
let
the
daniel
finish
the
proposal,
but
you
are
absolute
writer,
so
this
is
so
we
consider
I
daniel
I
post
what
we
discussed
in
the
past
and
but
the
giving
today's
the
quantity
of
the
services
chase
structure
uni
would
propose
to
have
to
pass
down
to
the
c
group
on
the
on
the
disk
on
the
file
system
system
file
system.
So
so
that's
make
those
things
more
complicated,
but
we
we
we
can
finish
this
and
then
there's
some
things
that
we
need
to
consider.
E
I
Yeah
definitely
I
mean
there
are
a
lot
of
things
to
consider
and
I
had
the
first
thing
I
definitely
wanted
to
ask.
First
is:
what
are
your
your
thoughts
on
it?
Is
that
feasible?
Do
you
have
similar
problems?
That's
the
main
thing
I
mean
I
come
to
that
in
a
second
in
the
question
part,
but
that's
basically
it
regardless
of
the
actual
implementation,
because
I
haven't
detailed
that
out.
I
first
wanted
to
ask
I'll
just
jump
here
or
I'm
already
just.
D
I
I
D
And
to
be
fair,
I
think
that's
perfectly
fine,
but
we
and
like
here
with
red
hat,
we
were
doing
the
same
right
and
while
we,
I
think
in
the
community,
talk
about
ways
of
splitting
them
out.
I
think
very
few
have
done
it
in
practice.
So
that's
good
and
then
the
other
question
I
was
curious
about
is,
if
you've
you've
done
any
testing
on
what
happens.
D
If
you
have
the
enforce
node
allocatable
feature
turned
on
to
be
enforcing
on
the
system
c
group
so
like
right
now,
there's
nothing
actually
inducing
pressure
back
on
system
slice
to
force
reclaim
because
it's
unbounded-
and
there
is
a
knob
that
lets.
You
set
a
bounding
limit,
but
it's
kind
of
risky
to
set,
because
you
don't
really
know
what
the
moon
killer
is
going
to
do
when
it
gets
to
pressure
on
system
slice.
But
it
would
naturally
point
so.
D
I
was
just
curious
like
if
you
have
explored
either
bounding
the
keyblade
in
run
time
in
a
in
a
separate
c
group
where
node
allocatable
is
enforceable
on
that
c
group
and
seeing
different
results,
because
that
was
one
question
and
the
other
question
was
renault
and
I
were
chatting
a
little
bit
in
the
background.
But
one
of
the
reasons
we
at
red
hat
have
been
so
motivated
to
look
at
secret
speed.
2
is,
we
think
we
would
see
improvements
in
this
space,
and
so
I'm
curious
if
sap
has
explored
that
at
all.
I
Enforcing
the
node
allocatable
on
on
the
separate
on
the
system,
slice
and
then
also
on
the
runtime
slice,
but
currently
that's
not
being
done
yet
because
it's
just
as
you
as
you
see,
the
problem
is
just
that
the
memory
and
the
cpu
requirements
are
so
vastly
different
that
at
least
I
am
not
feeling
very
comfortable
on
on
enabling
that
because
yeah
stuff
in
system
slice
and
might
getting
killed.
As
you
were
saying
yeah.
So
I
have
not
done
a
full-blown
investigation
on
on
adding
yeah.
D
Is
that
something
we've
ever
evaluated?
I
can't
recall
if
we've
ever
tried
to
parent
or
run
time
and
cable
in
a
separate
c
group
and
turn
it
on
or
not
in
our
own
preference.
But
am
I
off
that
nothing's
going
to
be
putting
pressure
on
that
to
to
force
reclaim
that
the
numbers
will
just
grow?
I
don't
know.
E
So
the
number
could
be
go
and
here
based
on
your
system
level
of
those
config
and
the
trigger
system.
So
then
the
system,
what's
the
trigger
the
whole
note
the
performance
and
also
which
one
even
we
have
the
score
side
right.
Oh,
it
is
the
best
effort,
because
when
colonel
look
at
the
kernel
wheel,
because
the
kernel
will
also
try
to
proven
of
the
kernel
dialogue,
which
is
really
bad
after
this
room,
so
they
will
try
to
pick
up
which
whatever
process
based
on
available
of
those
kind
of
things
and
actually
explicitly.
E
This
is
not
unkilled
even
like
the
new
kernel
version.
There's
not
a
lot
to
like,
like
the
mark,
certain
process,
not
unkilled,
but
you
could
still
so
then
they
will.
Basically,
it
is
just
random
or
some
process
has
some
range
of
the
um's
circle
range
and
then
we'll
think
about
which
one
have
the
most
can
we
can
reclaim
the
memory
most
and
then
they
will
cure.
So
you
make
this
a
whole
system
and
predictable
performance
and
predictable
and
at
the
same
time
will
be
rendered.
E
E
We
do
have
some
signal,
but
occasionally,
if
you
don't
handle
very
well,
you
may
be
end
up,
kill
certain
process
in
that
c
group,
but
the
whole
holy
work
node
is
not.
The
company
could
be
also
don't
get
around
to
kill
the
entire
path,
so
you
may
paper
over
the
real
problem,
but
the
customer
maybe
suffer
so
so
all
kind
of
those
complexity.
E
I
think
the
executive
complexity
is
being
discussed
even
at
the
earlier
kubernetes
time,
so
so
so
hopefully,
this
is
why,
when
the
seekable
version
two
come
out,
I
hope
we
can
do
a
better
job
on
that
one
giveaway.
We
have
more
signal
from
kernel
and
we
also
they
have
the
hub.
They
have
the
clubs
and
we
can
passing
more
doing
dynamic
during
the
time
we
could
trigger
more.
E
I'm
not
sure
version
sql
version
2
can
do
that.
Also,
there
are
one
things
because,
based
on
our
today's
layout,
no
matter,
you
are
using
the
slides
or
using
the
old
way
with
them
c
group,
so
they
always
have
the
not
reclaimable
memory,
so
a
q
which
is
accumulated
at
the
top
level
of
the
c
group.
So
that's
also
make
that
node
unlockable
over
time
will
be
not
represented
at
a
given
time.
So
there's
the
many
complexities
you
just
share
here.
I
So
I
guess
for
over
reservation,
then
less
resources
right
would
be
advertised
to
the
scheduler
and
less
parts
would
be
able
to
run
on.
On
that
note,
and
also
the
c
group
limit
on
the
q
parts
right
would
be
lower
and
basically
you
would
be
wasting
some
resources
on
the
node
because
you're
over
reserving
for
the
cubelet
and
the
container
runtime.
If
I
understood
your
question
right,
I'm
not
sure.
L
L
L
I
don't
see
what
issue
it
have,
because,
because,
yes,
when
it's
empty
it'll
it'll,
have
you
know
extra
headroom
that
could
be
consumed
but
nobody's
there
to
consume
it
anyway.
If
the
note
is
completely
full,
you
already
know,
then
that's
how
much
system
reserved
you
need
for
a
full
node
and
you
couldn't
take
any
more
in
your
size
correctly
at
that
point.
E
E
That's
also
could
be
the
cases
earlier,
like
direct
medicine
on
the
new
medicine
earlier.
There
also
have
some
other
thing.
I
also
mentioned
another
thing
that
could
be
not
reclaimable
usage
accumulated.
There
could
be
one
another
thing:
it
is
today's
situation.
If
customer
like
the
uncertain
node,
they
have
the
running
job
and
the
user
have
to
constantly
send
the
kubercato
execute
and
kubercutter
logging,
which
is
also
that's
not
a
chat
too.
Unfortunately,
today
is
not
all
charged
to
the
pod.
E
I
I
I
guess
that's
another
point
of
of
why
the
the
cube
and
system
reserve
is
not
really
determined
to
be
able
to
be
determined
prior
to
the
kubele
startup.
I
guess,
and
so
there
are
some
variants
there,
what
would
make
some
sort
of
reconciliation
or
at
least
being
able
to
update
it
at
runtime
handy
if
I
understood
it,
correct.
E
You
are
so
right.
This
is
so.
This
is
why
the
nomad
is
the
cubos
reserve.
Those
kind
of
node
equivalent
reserve
is
the
best
practice
and
also
it
is
the
best
what
we
can
share
based
on
the
production.
So
it's
more
like
that.
We
generate
those
kind
of
things
through
the
monitoring
and
as
the
average,
and
so
this
is
also
like
earlier.
We
say
that
we
cannot
guarantee
those
things,
because
if
we
guarantee
then
we
have
to
enforce
you.
E
E
D
One
thing
I'm
thinking
about
here
is
like
if
it.
If,
if
this
is
an
area,
you'd
want
to
do
further
study
or
how
hard
it
is
to
maybe
tweak
your
setup,
I
I
would
be
curious
to
know
if
you
did
go
and
parent
the
cubelet
and
runtime
in
a
different
c
group
and
did
enforce
node
allocatable
on
the
cube
reserve
c
group
only
and
not
system
slice.
D
C
K
Out
before
I
think
so,
with
v1,
the
io
and
memory
aren't
as
well
behaved
in
v2.
They
have
proper
accounting
between
the
two
and
another
issue.
We
have
really
is
like
when
you
get
memory
pressure
like
since
we
don't
have
swap
your
executables
will
start
getting
so
the
file
pages
will
start
getting
swapped,
leading
to
system
instability
and
like
during
recent
conversations
with
kernel
engineers,
like
they
really
said.
Oh,
you
cannot
like
totally
pack
it.
K
You
need
to
leave
some
headroom
and,
depending
on
your,
like
workload,
characteristics
how
much
io
they
are
performing,
how
much
memory
they
are
requesting.
You'll
always
need
some
headroom,
so
I
think
it's
like
you'll
have
to
balance
stability
versus
wasting
some
space
for
like
for
head
room
and
to
address
some
points
like
don
mentioned
about
c
groups,
killing
some
process
in
the
part.
So
in
v2
we
have
a
knob
where
we
can
say:
oh
okay,
kill
at
the
c
group
level,
so
the
whole
thing
goes
away.
So
what.
E
K
So
that
will
help.
The
second
thing
is
with
psi
and
like
ilana
is
working
on
swap
with
those
things
in
place,
we'll
be
able
to
get
in
something
like
d
and
will
be
able
to
get
earlier
notifications
and
be
able
to
take
better
decisions
on
what
processes
to
kill.
But
then
the
own
killer
doesn't
work
well
at
all
under
load.
It
will
end
up
like
killing
processes.
It
shouldn't.
Do
you
think
it
it
shouldn't
be
and
only
way
to
protect
against.
K
It
is
like
setting
a
minus
thousand,
which
you
pointed
out,
one
more
thing
like
I'm
not
sure
like
on
the
cryo
side,
what
we
are
doing
is
our
shim,
which
is
called
con
mon
is
running
under
the
pod
slice,
and
so
it
gets
charged
to
the
workload,
but
it
is
also
protected
by
a
minus
thousand,
and
we
don't
like.
We
wrote
it
in
c,
so
it
doesn't.
You
have
a
lot
of
overhead
so
that
way
we
always
get
a
notification
and
also
we
are
not
like
charging
it
to
the
system
slice.
K
K
So
there
are
a
couple
of
things:
jobs
in
c
groups.
We
do
like
the
memory
high
and
low
and
then
where
we
are
kind
of
trying
to
use
the
min
or
the
system
slice
and
then
we'll
see
how
it
helps.
The
idea
is
like,
as
opposed
to
like
the
high
and
max
the
pressure
starts
happening
based
on
overage
and
min,
gives
you
some
like
a
higher
level
of
guarantee
that
okay,
you
won't
get
till.
You
really
start
it
by
a
lot.
G
E
I
also
can
attack
why
the
memory
accounting
fighter
can
have
this
situation
so
another
beyond
the
water
menu
and
the
david
said
earlier
so
just
earlier.
I
also
mentioned
that
this
is
actually
the
user
space
problem,
but
we
do
have
the
same
problem
for
kernels
right
right,
so
kernel
takes
some
behavior
and
to
have
certain
part
of
workload
container
most.
E
E
A
C
M
D
A
N
Yeah
I
have
some
contact
with
that.
I
can
give
a
brief:
introduce
okay,
cool
yeah,
yeah
hi,
everyone,
I'm
chipton,
I
I
reviewed
the
the
ax
cap.
So
it's
about
it's
about
the
the
security
capability
api
we
have
in
kubernetes
and
it
has
a
people
know
it
has
a
add-on
drop,
but
the
problem
is
the
the
ad
doesn't
work
for
non-root
user
in
a
straightforward
way.
N
So
so
in
the
original
cap
he
proposed
to
change
the
kubernetes
api
by
adding
a
new
field
and
ambient
and
also
add
a
new
field
in
the
cri
correspondingly
and
but-
and
I
talked
with
him-
I
I
kind
of
hesitating
of
changing
the
kubernetes
api
in
this
way.
So
we
think
about
the
alternative
that
we
reduce
the
current
api
but
changing
the
behavior
in
a
transparent
way.
That
is
the
current
current,
the
pl
he
mentioned
in
the
in
the
in
the
notes,
contented
apl
and
cryopl.
N
K
C
K
N
H
Okay,
I
think
both
options
were
discussed
before,
but
the
the
actual
field
was
preferred
just
because
of
the
backward
compatibility
right,
given
the
part
object.
If
we
just
change
the
meaning
of
add
capability,
it
may
cause
some
unexpected
behavior
like,
for
example,
there
is
a
part
that
they,
a
non-good
part.
They
have
at
some
point
capability
by
by
mistake,
and
we
with
this.