►
From YouTube: Kubernetes SIG Node 20230124
Description
SIG Node weekly meeting. Agenda and notes: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.adoto8roitwq
GMT20230124-180453_Recording_1600x720
A
Hello,
hello:
it's
a
signal
weekly
meeting,
it's
Tuesday,
January
24th
2023,
welcome
everybody
as
regular.
We
want
to
start
with
acknowledging
some
work
happening
in
signal,
so
we
have
14
PR
submerged,
some
of
them
related
to
signals.
Many
that
are
just
touching
signals
a
little
bit.
You
can
review
what's
happening
and
there
are
a
few
closed
and
I
think
one
of
the
closed
PRS
will
be
discussed
by
Jack.
It's
an
agenda
today,
yeah.
A
If
you're
interested,
what's
going
on
check
out
this
links
created
PR
is
also
what's
people
creating
and
what
kind
of
work
is
happening.
It's
all
interesting
links
and
I
hope
it
will
make.
You
feel
less
formal.
A
First
agenda
item
today
is
sidecar
continuous
cap
I
wanted
to
give
update
on
working
groups
that
we're
running.
There
is
a
cap
that
is
submitted
on
GitHub.
You
can
review
and
give
you
feedback,
I.
Think
I,
wrote
feedback
so
far
is
very
positive.
We
still
have
one
unresolved
naming
issue
that
you
need
to
solve,
but
rather
than
that
feedback
very
positive
and
I
think
we're
in
a
good
track
going
forward.
A
I
want
to
give
some
update
what
it
will
be.
So
if
you
before,
you
even
start
reading
this
cap,
you
know
what
to
expect
High
prepared
a
few
slides,
so
sidecar
containers.
So
we,
the
pattern
of
sidecar,
was
published
long
time
ago,
almost
when
kubernetes
started.
The
idea
is
that
you
run
some
small
container
alongside
your
regular
container.
It
runs
in
the
same
namespace
and
it's
very
close
to
what
your
container
has
like.
It
has
same
access
to
similar
resources
and
that's
how
it
can
be
useful.
A
You
can
get
resources,
you
can
extract
resources
and
the
best
part
you
can
configure
the
sidecars
the
way
you
want,
so
you
can
version
it
the
way
you
want
you
can
deploy
it.
The
way
you
want
so
there
are
many
benefits
of
having
a
sidecar
and
sidecars
are
quite
easy
to
implement
on
regular
web
services.
You
just
run
another
container
alongside
your
container
and
that
pretty
much.
A
Okay,
thank
you
for
seeing
me.
What
do
you
see.
A
Okay,
I,
don't
know
what
to
do.
Never
had
this
button
before
if
I
try
to
share
my
whole
screen
like
this,
let's
make
a
final
attempt
and
if
it
doesn't
work
it
doesn't
work.
Oh
I
can
just
speak
through
the
slides.
A
Yeah
I
posted
the
link
into
meeting
notes.
Okay,
if
you
want
to
follow
along
you,
just
click
on
link
in
the
meeting
notes
and
you'll
have
a
slice.
I
hope
the
sharing
permissions
are
yeah,
everybody
well,
yeah
pattern
is
well
known
and
it
works
generally.
Fine,
now
going
to
site
number
three,
this
implementation
of
sidecars
fall
short
on
some
specific
scenarios.
A
Mostly
people
have
problems
with
jobs
that
has
completion
if
a
job
runs
to
completion,
and
it
typically
has
a
restart
policy
on
failure
or
never
and
when
main
container
terminates
it
expects
the
sidecar
also
terminated
by
itself
and
then
Port
will
be
completed,
but
sidecars
generally
don't
know
about
any
other
container,
so
they
don't
know
when
to
terminate
they
just
they
typically
designed
as
a
demons
that
runs
forever.
A
So
to
solve
this
problem,
we
need
to
have
some
built-in
Primitives
today,
people
solving
it
with
all
sorts
of
hacks,
but
having
built-in
primitive,
would
really
help.
Then
we
have
a
problem
with
shutter
smash.
Shadow
smash
allows
you
to
configure
your
port
to
have
only
mtls
communication,
for
instance,
so
you
can
have
inbound
and
outbound
traffic
to
be
protected.
A
Unfortunately,
you
can
run
serious
mesh
during
unit
containers
in
runs,
so
you
can
protect
everything,
but
you
can
protect
init
containers
and
it's
not
very
good
from
security
standpoint
there's
something
we
want
also
wanted
to
solve,
and
the
general
pattern
when
you
collect
logs
many
log
collection
demons
want
to
be
implemented
as
as
an
endpoint
where
you
send
logs
to,
and
if
you
implement
it
this
way,
then
you
can't
get
logs
from
initialization
and
from
post
startup
on
container
startup.
A
It
will
be
much
easier
to
implement
with
a
sidecar
running
very
early
and
running
through
initialization
station
running
through
all
the
other
can
be
a
startup.
So
having
all
these
problems
the
and
having
sidecar
pattern
extremely
popular.
We
want
to
solve
this
problem
and
make
a
built-in
primitive
in
kubernetes
to
support
it.
So
the
proposal
are
going
to
site
four
I
see
many
people
switch
to
the
slide
proposal
is
to
have
a
restart
policy
always
to
be
applied
on
individual
containers.
A
In
this
case,
you
can
see,
on
the
right
hand,
side.
There
is
a
init
containers
collection,
it's
a
list
today.
It's
ordered
at
least,
and
you
can
Define
some
init
containers
that
download
certificates
that
will
be
used
by
a
sidecar
container,
and
then
there
is
a
istio
process
that
will
be
started
up
and
by
specifying
this
restart
policy,
always
in
init
containers
collection,
you
will.
We
will
make
it
such
that
it
will
not
be
terminated
to
the
port.
A
A
This
is
a
proposal
and
it
fits
quite
nicely
to
solve
all
the
problems.
At
the
same
time,
it's
very
targeted
and
small
change
that
doesn't
reduce
any
new
collection
or
anything
like
that.
So
we
believe
that
it
will
be.
It
will
work
in
best
for
most
scenarios.
A
Lastly,
like
if
you
look
at
the
service
mesh
implementation
on
site
number,
five,
you
will,
as
on
previous
slide,
you'll,
probably
get
some
certificate,
maybe
even
using
different
containers.
Some
implementation
use
sidecar
container
itself
to
download
certificate.
Some
implementation
will
use
other
containers,
the
download
search
here,
but
whatever
way
you
do
it,
you
do
some
pre
initialization,
then
container
will
update
this
IP
table
for
support.
A
So
all
outbound
connections
and
inbound
connections
will
go
through
the
proxy
and
then
we'll
start
the
procs
here
to
go
through
and
finally
when,
when,
when
this
proxy
already
started
and
ready
to
be
used,
you
proceed
with
in
all
other
containers
in
Civilization.
A
So
if
you
have
our
next
Port
doing
some
file
download,
this
download
will
already
be
started
through
the
proxy
and
then,
when
the
regular
containers
start
only,
then
you
will
make
the
Your
Side
characters
to
be
ready
and
all
other
containers
that
at
some
point
will
become
ready
and
they
will
start
receiving
inbound
traffic,
and
this
inbound
traffic
will
go
to
the
same
proxy
that
you
started
on
a
early
stage
and
finally
like.
A
If
proxy
fails,
we
will
restart
the
proxy,
so
it
will
be
running
and
while
it
will
be
restarting
the
whole
Port
will
be
not
ready,
because
you
have
a
Readiness
Probe
on
this
sidecar
container
and
all
the
inbound
traffic
will
not
be
sent
to
your
Port.
Outbound
traffic
will
fail
because
proxy
is
not
running
so
you'll
need
to
deal
with
that
in
your
application.
Somehow
and
finally
on
determination.
A
A
Some
more
highlights
very
interesting
and
very
unusual
for
containers.
Today,
sidecars
will
be
restarted
even
during
Port
termination.
So
you
have
very
long
grace
period
for
your
Port
termination
and
during
this
long
time,
sidecar
of
happen
to
fail.
We
will
restart
it,
so
you
don't
lose
connection
to
outside
world
in
case
of
service
mesh.
We
also
will
solve
some
ohm
score
adjustment
problem
today.
A
Ohm
score
is
calculated
based
on
percentage
of
request
of
a
container
and
sidecars
are
typically
super
small,
so
sidecars
are
often
the
first
Target
for
IQ
and
it's
it's
making
ports
a
little
bit
more
unstable
because,
like
you
have
a
huge
Port
that
requires
connection
and
this
connection
being
terminated
because
ohms
for
adjustment
is
so
small
for
sidecar
containers
in
general.
A
We
will
try
our
best
to
keep
side
cars
running,
but
we
wouldn't
do
I
mean
we
had
other
ideas
how
to
do
it,
but
all
this
ideas
was
rejected
because
they
make
sidecar
containers
too
special
and
we
don't
want
to
make
them
too
special.
Otherwise
all
conditions
will
be
implemented
sidecars
and
it's
not.
The
side
effect
you
desire.
A
Finally,
I
wanted
to
go
through
other
scenarios
for
restart
policy
field.
We,
since
we'll
introduce
a
restart
policy
per
container.
We
may
use
other
values
of
restart
policy
going
forward
and
some
scenarios
you
can
Implement
that
is
not
possible.
Today,
is
for
jobs
that
should
run
once
to
completion.
We
may
have
some
initialization
that
may
need
to
be
restarted.
Maybe
it's
flaky,
so
this
will
be
possible
with
if
you
will
Implement
peer
container
start
policy.
A
It's
all
part
of
this
care,
but
it
may
be
introduced
later
and,
as
example,
is
a
job
with
two
containers
running
with
different
tolerance
with
for
a
start,
and
it
also
will
be
possible
to
implement.
There
are
some
requests
to
have
this
functionality
and
it
will
be
done.
It
can
be
done
when
we
will
have
restart
policy
per
container.
A
There
are
some
alternative
was
rejected.
I
listed
it
here,
but
you
can
read
more
details
in
cap
that
I
sent
before
this
number
site
number
eight
site
number:
nine.
We
what
we
don't
want
to
implement,
which
is
asked
sometimes
especially
for
service
mesh
implementation-
is
this
final
scenario
of
a
serious
mesh.
When
sidecar
crashes
we
have,
we
will
not
provide
any
built-in
functionality
to
stop
other
containers
from
running,
so
other
conditions
keep
running
and
they
may
try
to
do
some
outbound
connection.
A
We're
not
going
to
solve
it
with
some
built-in
functionality,
but
you
can
work
around
it
by
implementing
some.
Thank
you
liveness
probes.
So,
for
instance,
you
can
put
a
liveness
probe
on
a
regular
container
to
point
into
Sidecar.
This
way
whenever
sidecar
is
down,
a
regular
country
will
also
be
killed
alongside
the
Sidecar
anyway.
Finally,
another
problem
with
here
a
lot
for
sidecars,
but
we
don't
plan
to
solve.
It-
is
security
boundaries
between
different
types
of
containers.
A
We
know
that
some
people
want
to
make
sure
that
any
like
app
containers
are
not
privileged,
so
they
don't
do
volume
mounts
like
don't,
don't
Mount
the
volumes
and
don't
change
IP
tables,
while
sidecars
and
some
installation
containers
can
be
restricted
either
by
time
or
by
a
scope
what
they
can
do.
So
you
can
make
service
mesh
to
be
able
to
update
IP
tables,
but
no
other
containers
will
be
able
to
do
that.
Foreign.
A
Sounds
more
spread
out
than
just
sidecars,
so
we're
not
following
it
in
this
cap,
but
we
can
try
to
approach
it
later
and
I
switched
to
zoom
and
I
see
hand
from
dawn.
Sorry,
then,
you
may
be
having
this
hand
for
a
long
time.
Please
pick
up.
It's.
C
Okay,
actually
most
of
my
problems
already
and
the
internet
later
so,
but
but
one
thing's,
one
comment:
I
think
since
anyway,
you
introduce
this
restarted
policy
for
the
static
car
actually
in
the
inita
phase,
right
so
kind
of
Reason.
Lastly
coverage.
So
it's
okay,
because
one
of
the
problem,
we
do
worry
about
the
resources
right,
because
the
set
count
didn't
have
the
resource
requirement
and
the
part
of
the
need.
So
you
think
anyway,
we
are
now
we
change
this.
You
need
to
Containers
semantics
with
this
restart
policy
right,
so
so
I
do
think
about.
C
The
use
also
can
consider
to
put
up
the
resource
request.
There
was
there
any
way
we
change
that
to
semantics
or
ID
right.
So
if
you,
if
you
have
a
container
and
request
this
one
before
we
feel
like
the,
we
don't
need
the
request,
those
kind
of
things
it's
just,
because
we
already
calculate
the
regular
containers
resource
usage.
C
So
you
need
container
anyways
just
to
to
do
the
preparation,
so
they
can
reuse
those
part
level
of
the
resources,
and
we
also
don't
want
to
over,
like
the
over
conservative
right,
so
next
reduce
of
the
node.
C
The
resource,
the
utilization,
so
that's
why
we
didn't
allowed
you
put
that
resource
required,
but
now
you
change
that
semantic
for
this,
for
you
can,
along
with
maybe
cost
user,
could
add
some
or
could
be
also
defaulted
now,
but
still,
if
you
need
additional
just
point
on
here,
so
you
don't
otherwise,
because
we
kind
of
heard
istio
all
the
said.
A
Just
allowing
topic
we
covered
it
in
details
in
cap,
so
we
will
change
the
formula
how
we
will
do
a
resource
calculation,
and
this
formula
is
now
quite
complex,
so
it
used
to
be
I
mean
not
trivial
but
easy
to
implement,
and
now
it
will
be
harder
to
implement
so
because
of
that,
we
plan
to
expose
this
result
of
computation
either
as
a
metric
or
some
Port
status.
A
So
this
will
be
changed
and
updated,
and
also
Francesca
and
swazi
did
a
good
job
of
looking
into
different
managers
like
topology
manager,
CPU
manager
to
understand
how
sidecar
containers
resource
usage
will
be
will
need
to
be
accounted
for
by
those
plugins
online,
not
plugins,
but
different
managers.
The
problem,
like,
as
you
said
today,
done
some
resources
being
reused
from
init
containers
by
regular
containers,
and
in
this
case
you
also
need
to
make
sure
that
reuse
will
be
properly
updated.
A
C
Another
comment,
which
is
the
main
minor
point
at
this
moment
because
we
have
to
do,
is
just
you
mentioned
that,
because
we
are
introduced
this
first
time.
This
is
per
container
restarted
policy
right,
so
so,
which
is
kind
of
the
change
you
need
to
continuous
semantics
become
to
the
static
container,
but
that's
also
actually
make
the
future
per
content
per
containers
restart
the
policy
actually
is
harder,
because
you
need
to
think
about
this
with
per
container
restarted.
C
How
to
say
you
need
the
because
in
the
past
we
can't
get
the
one
size
fit
all
like
you
need
container
anyway.
You
have
to
start
the
one
by
one,
because
it's
just
do
preparation
and
until
finish-
and
we
start
the
second
way
so
you
treat
this
is
totally
separate-
the
logical
and
then
you
are
introduced
up
the
regular
containers
and
then
regular
container.
Then
each
one
you
treat
that
logic
is
separate
right,
so
so
because
anyway,
they
can
concurrent
start
separate,
restart
all
those
kind
of
things.
C
But
now
you
have
to
have
the
additional
logical
say:
oh
this
is
in
the
init,
so
it's
set
a
container
restart
the
policy.
Imagine
the
different
from
the
rest
of
the
regular
container.
So
just
this
is
minor
point.
If
it's
not
the
block,
as
but
I
do
think
about
the
evil
risk
per
container.
Restart
policy
is
important
that
this
is
make.
That
is
more
complicated.
A
Yeah
and
I
have
a
section
about
it
in
cap.
We
really
want
to
scope
this
into
implementing
the
other
needed
things
for
sidecar
cap
and
all
the
future
scenarios
where
you
start
policy.
We
kind
of
put
on
a
shelf
saying
we
want
this
in
future,
but
we
don't
want
to
try
to
address
them
now,
implementing
those
introduce
all
sorts
of
complexity,
especially
for
cases
when
you
go.
A
You
change
the
restart
policy
to
restart
less
because
then
you
need
to
remember
the
state
like
if
this
country
already
been
run
to
completion
or
it
wasn't
around
the
completion
and
this
state
is
currently
not
preserved
for
regular
containers,
so
that
kind
of
complexity.
We
want
to
know
that
it
exists
and
put
it
in
writing,
but
we
don't
want
to
address
and
design
around
it
yet,
but
we
definitely
will
test
it
extensively
for
sidecar
scenarios.
A
Okay,
thank
you
for
attention.
I
took
20
minutes
of
a
meeting.
I
hope
that
we
will
still
have
time
for
all
other
topics.
I
know
we
have
a
lot.
If
you
have
more
questions,
please
go
to
cap
and
review
and
give
a
feedback.
Thank
you.
D
Yeah
I
think
one
comment
I
had
when
I
as
we
are
discussing
this
per
container
restart
policy.
Recently
we
were
looking
at,
we
know
in
resize
policy
we
have
explicit
for
restart
container
or
no
restart
or
restart
not
required.
Tim
is
discussing
we're
discussing
with
we're
discussing
making
that
more
explicit.
So
under
resize
policy
we
call
it
restart
policy
for
resize
and
I'm
wondering
if
having
this
is
gonna
cause
some
confusion,
and
if
there
is
a
way
we
can
make
it
more.
D
You
know
we
want
to
have
one
restart
policy,
not
two
or
three
I'll
I'll
share
the
link
on
the
cap,
and
then
we
can
discuss
this
offline.
A
That's
perfect,
thank
you.
Good
feedback
naming
is
always
hard
and
let's
try
to
make
it
less
hard
on
us,
but
good
feedback.
Thank
you
is
there
are
no
more
questions.
David,
do
you
want
to
go
through
another
life
cycle.
B
Yeah
sure
yeah
thanks
very
good
for
the
presentation.
I'll,
definitely
take
a
closer
look
at
the
cap,
yeah
for
node
life
cycle,
so
kind
of
wanted
to
share
this
connect
issue
and
kind
of
just
get
some
thoughts
about
it,
and
I
was
curious
if
there
was
any
prior
work
done
it
on
it.
B
So
the
context
here
is
that
I
was
chatting
with
with
Tim
a
little
bit
and
Tim
filed
this
issue
on
GitHub,
and
we
discussed
a
little
bit
and
so
the
context
here
is
basically
you
know.
We
have
quite
a
good
amount
of
work.
That's
going
on
going
on
right
now
regarding
pod
life
cycle,
I'm,
actually
working
on
a
doc
that
describes
products.
B
More
and
we
were
having
some
discussions
last
week
with
with
Clayton
and
other
folks
about
some
improvements
in
this
area,
but
one
of
the
things
we
haven't
really
looked
at
too
much
is
node
lifecycle.
Yet
the
context
here
is
that
node
lifecycle
isn't
really
well
documented
around
how
different
components
and
kubernetes
should
react.
B
When
you
know
nodes
come
and
go
so
a
good
example
to
explain
this
is,
for
example,
if
the
cloud,
the
cloud
provider,
for
example,
spins
up
some
resources
that
are
needed
and
prior
to
the
node
being
deleted,
the
other
resources
need
to
be
deleted.
So
there's
a
little
bit
of
dependency.
There
there's
no
real
way
in
kubernetes
for
Signal.
You
know
like
the
node
is
about
to
be
deleted,
so
cluster
Auto
scaler,
for
example.
B
It
has
a
specific
taint
that
it
applies
on
the
Node
and
then
you
know
it
says
like
this:
node
is
going
to
be
deleted,
but
that's
kind
of
very
specific
to
Cluster
Auto
scaler
and
it's
not
like
a
standardized
taint
and
if
other
components
want
to
implement
it,
they
would
have
to
use
their
own
team
so
kind
of
what
what
Tim
kind
of
proposing
this
issue
is.
Maybe
we
need
to
kind
of
standardize
a
little
bit?
B
What
is
the
node
life
cycle
and
specifically
the
termination
phase
of
it
so,
for
example,
for
other
kubernetes
objects
right,
there's,
finalizers
and
that's
kind
of
the
standard
way
to
to
block
deletion
of
resources.
If
you
need,
if
there's
some
other
dependent
resources,
so
maybe
we
could
do
something
like
you
know,
we
could
put
the
finalizers
on
the
Node
object
and
we
would
document
that
you
know
if
there's
finalized,
no,
no
object.
The
other
component
shouldn't
delete
that
underlying
VM,
for
example
right
something
like
that.
C
David,
we
might
have,
they
wrote
down
dog
both
in
the
open
source
and
also
gke.
C
Some
of
those
might
be
not
up
to
date,
so
talk
to
reach
out
to
Nato,
and
so
so
we
do
have
some
things
and
we
might
help
you
yeah
yeah.
But
this
is
good
idea,
because
I
remember
this
topical
come
up
last
year
sometimes-
and
we
do
suggest
people
document
that,
where
I
have
the
new
new
document
up
to
date
and
I
didn't
see,
people
doing
this.
So
I
think
this
is
good
to
start
foreign.
B
Some
discussion,
okay,
I
I,
can
reach
out
to
see
what's
done
and
I
think
the
the
outcome
here
is
maybe
eventually
we'll
try
to
write
this
up
somewhere
and
kind
of
standardize
it
so
that
other
components
could
could
follow
some
existing
model
instead
of
having
like
a
taint
per
per
component
that
you
know,
no
one
else
would
would
know.
E
B
B
Think
I
think
I
think
some
of
those
things
are
a
little
bit
missing
today,
like
the
a
good
signal,
especially
if
there's
other
resources,
other
controllers
that
need
to
be
watching
and
doing
some
type
of
cleanup
and
reaction
to
this,
especially
that's
prior
to
the
deletion
instead
of
after
the
deletion
yeah
exactly.
E
A
Just
a
couple
days
ago
about
one
of
the
things
that
we
Implement
sustain
is
used
for
post
VMS
that
are
not
killed
but
they're
still
around,
but
not
running,
so
that
maybe
also
interesting
discussion
and
I
think
it
restarts
I
I,
remember
agent,
documentation
about
like
not
with
the
same
name
appearing
after
some
time
that
we
try
to
treat
it
as
the
same
null.
But
then
it's
not
the
same.
So
that
may
be
also
part
of
the
discussion.
Foreign.
A
Okay,
next
one
is
I'm
sorry
I
share.
D
F
So,
but
we
are,
we've
been
thinking
about
how
to
improve
a
container
security,
specifically
how
to
detect
the
containers
where
files
have
been
modified.
The
containers
are
having
compromised
somehow
We've
looked
at
the
IMA
resources
that
they
are
available
in
the
Linux
kernel,
the
Integrity
measurement
architecture.
F
F
Convenience
inside
the
container,
so
we
could
actually
check
whether
containers,
fast
files
inside
containers
have
been
modified
or
not.
The
end
goal
is
to
push
this
into
the
entire
kubernetes
stack
so
to
to
change.
Maybe
the
port
security
context
CRI.
F
We
are
also
talking
to
the
open
community
and
Community
to
try
to
put
changes
as
well,
so
they
can
add
so
in
in
a
nutshell.
The
whole
idea
is
to
understand
that
when
you
spawn
a
container,
it
creates
a
number
of
namespaces
in
Linux.
We
want
to
add
a
new
namespace
that
we
call
it
Ima
namespace
that
will
help
us
detect
and
file
changes
inside
containers
and
eventually
kubernetes
be
able
to
detect
when
a
container
has
been
compromised.
G
H
G
In
draft
status,
because
the
Linux
kernel
changes
aren't
merged,
so
other
kernel
changes
merge.
First,
then
we
can
do
the
spec,
then
run
C
and
then
you
know
start
making
opening.
F
F
Right,
so
we,
and
basically
they
tell
the
IMA
name.
Space
is
not
merge
still
into
Linux
kernel.
We
are
working
on
merch
net
and
we
expect
to
be
merge.
Maybe
in
first
iterations,
maybe
a
few
moments.
We
felt
an
issue
also
with
a
run
C
and
the
mountainous
in
runs.
He
told
us
that,
okay,
we
will
not
merge
now
anything
even
the
oci
specifications,
because
we
don't
have
support
in
the
Linux
kernel
yet,
but
we
are
working
just
in
in
every
part
of
the
stack
on
run
C.
F
G
C
I
I
totally
agree
with
I
feel
like
we
definitely
want
to
support
if
the
Lorenzi
and
the
container
runtime
have
this
feature
right
so
which
is
if
the
which
is
mean
like
the
kernel
to
support
this
feature
right.
So
so
once
that
is
ready,
because
once
the
we
don't
definitely
kubernetes
is
ready
to
support.
C
But
right
now
is
a
little
bit
earlier.
You
you
need
the
maybe
like
the
kernel,
merge,
and
at
least
you
can
try
to
do
some
POC
right
on
a
single
note.
You
do
see
this
naming
space
work
a
while
with
the
residency
and
and
the
container
runtime
right,
so
the
single
node
and
then
come
to
here,
and
then
we
can
talk
about
how
kubernetes
enable
this
okay.
A
Thank
you.
Oh
Kevin,.
G
A
Okay,
thank
you.
Another
Kevin
for
both
resource
API
I
think
there
is
a
conversation
of
having
a
meeting
Francesco.
Maybe
you
can
talk
about
it.
I
Hello,
so
let
me
check
about
no
I.
We
are.
We
are
reviewing
the
cap,
this
cap
and
it's
about
extending
for
CDI,
which
is
the
dra
use
cases
and,
from
my
perspective,
so
far
so
good.
So
the
content
itself
looks
okay
to
me
and
I'm
gonna
have
more
comments
or
keep
reviewing
in
the
next
day.
So
long
story
short.
If
there
is
a
meeting
Planet
not
aware
about
that.
A
Sorry
I
I
thought
about
previous
one
about
I,
believe
there's
some
discussions,
talk
about
updating,
CRI
and
solving
the
problem.
Is
it
addressed
during
the
in
the
GitHub
or
there
is
a
conversation
going.
I
Just
for
completeness
sake,
just
see
right
things,
I'm
not
up
to
speed
the
the
cat
about
CDI
for
producers.
Repair
is
much
simpler
and,
while
meetings
are
always
possible,
I
don't
think
we
we
we're
gonna.
Have
it
maybe.
A
Thank
you,
hi
Renee,
what's
happening
in
in
place,
producers
Club.
D
Sorry
about
that
yeah
the
status
remains
unchanged
as
of
I,
just
rebased
it
and
resolved
a
test.
Failure
from
the
rebase
and
I
think
I
see
one
more
failure
from
Golden,
CI,
cozy
Island
I'll
fix
that
today
afternoon
or
Pacific
time
and
where
we
I'm
Tim
and
direct
is
direct
here
and
I
didn't
see
him
on
the
meeting.
D
No
he's
sick,
oh
he's,
sick,
okay,
yeah
we've
been
trying
to
get
together
like
we
just
need
10
to
15
minutes
and
we
wanna
we're
syncing
up
offline
to
see
which
way
to
go.
Do
we
want
to
merge
the
API
and
then
follow
up
with
the
main,
the
mothership,
PR
or
Tim
favors,
just
merging
the
whole
thing
in
one
shot
and
I'm?
D
A
Okay,
going
to
the
next
item,
it's
me
I
wanted
to
highlight
this
box
that
was
sold
this
week.
It's
about
HTTP
props,
so
the
situation
here
is
that
if
there
are
many
HTTP
props
and
many
containers
defined,
then
we
can
run
out
of
sockets
or
like
not
sockets
so
I'm.
What
was
it
so?
A
What
is
happening
we
open
socket
and
we
there
is
some
time
frame
when
so
like
connection
already
closed,
but
we
keep
socket
open
for
some
time
and
default
is
60
seconds.
So
if
we
have
a
lot
of
containers
with
a
lot
of
probes,
then
we
can
get
into
hit
some
limits
on
node
and
once
we
hit
this
limits
on
the
nodes
and
we
start
failing
any
HTTP
connection,
so
some
it's
kind
of
noise
enabled
problem
on
steroids
that
was
addressed.
A
If
you're
interested
in
details,
you
can
read
this
presentation.
I
didn't
find
the
recording
from
Sig
Network
meeting,
but
maybe
it
will
be
up
soon,
so
this
was
fixed.
If
you
see
any
customers
can
complaining
about
client
timeout
from
HTTP
props,
then
you
can
probably
then
you're
probably
hitting
this
issue.
A
A
Any
questions:
okay,
yeah,
it's
very
unfortunate
when
probes
are
not
reliable.
In
this
case
it
was
a
situation
when
HTTP
props
didn't
work,
but
but
exact
props
did
work
because
exact
props
didn't
use
the
same
resources,
resources
so
yeah.
It
was
very
unusual-
and
we
know
now
that
if
customer
has
a
host
port
and
they
actively
using
connections
to
many
IP
addresses,
they
also
can
exhaust
node
resources
and
make
other
ports
unusable,
so
as
opposed
liveness
crops
can
start
failing.
Because
of
that.
H
Yeah,
so
the
first
item
that
I
have
is
it's
related
to
topology
manager,
GE
graduation.
We
are
close
enough
to
the
cap
phrase,
so
I
just
want
to
release
everyone's
attention
and
request
for
reviews
on
that.
I've
noticed
that
we
haven't
added
milestones
and
the
leads
opt-in
label
and
things
like
that.
So
that
was
something
I
wanted
to
point
out
as
well.
H
Perfect
thanks
Don.
The
second
item
I
have
is
it's
related
to
a
device
manager
bug
that
I've
been
working
on
so
just
to
give
a
high
level
overview
of
it.
This
there's
a
scenario
where
you
know.
If
you
were
to
restart
cubelet
or
reboot
your
node,
you
have
no
control
over
how
the
pods
are
recovered,
so
your
application
pod,
which
is
requesting
devices,
could
get
recovered
before
the
device.
H
Plugin
part
has
had
a
chance
to
register
itself,
and
in
that
case,
from
cubelet's
point
of
view,
we
are
not
actually
returning
any
errors
and
until
the
point
the
device
plugin
called
or
the
device
plugin.
Actually
the
application
pod
tries
to
access
the
device.
There
is
no
error,
manifested
so
with
with
this
PR
that
I
have.
What
I'm
trying
to
do
is
make
sure
that
we
are
checking
that
the
device
plugin
thought
has
registered
and
it's
healthy,
so
I
I
would
really
appreciate
if
people
could
take
a
look
at
this.
H
It's
a
bit
complicated
in
terms
of
how
we
are
how
we
reproduce
this
issue
and
in
order
to
do
that,
especially
for
the
end-to-end
tests,
I
had
to
modify
the
sample
device
plugin,
which
is
a
test
plugin
used
to
use
for
testing
device,
plugin
scenarios.
H
So
so
the
changes
that
were
made
to
the
sample
device
plugin
was
to
intentionally
prevent
it
from
registering
itself.
So
the
second
point
that
I
have
it's
related
to
sample
device,
plugin
changes,
and
we
need
to
make
sure
that
the
image
is
promoted
and
it's
accessible
for
end-to-end
testing.
So
just
just
as
an
ovary
for
everyone,
and
if
people
have
time.
Please
take
a
look
at
this
because
I
know.
Next
week
onwards
everyone
is
going
to
get
busy
with
gaps
and
stuff.
B
So
just
a
quick
question
about
that.
Last
thing
you
mentioned:
if
the
device
plugin
is
not
available
and
the
pods
tries
to
come
up
is
the
idea
that
the
Pod
will
be
projected
during
admission
or
how
does
that
failure
handled?
Okay,.
B
A
J
A
Okay,
I
think
we
can
go
to
the
next
one.
A
K
Hello
yeah,
so
this
is
just
a
quick
update
on
the
the
updating
of
the
cap
to
basically
reflect
the
the
new
condition
that
we
introduced
as
an
alpha,
which
was
part,
has
Network
like
basically
renaming
it
to
something
that
Sig
network
is
more
aligned
with,
which
is
spot
ready
to
start
containers.
So
this
was
after
a
pretty
long
discussion
with
the
Derek
and
Tim,
where
there
were
some
concerns
about
the
condition
being
named
for
as
Network
and
what
other
things
it
might
imply.
K
So
I
think
we
converged
on
a
separate
name
and
basically,
let's
just
update
to
the
cap.
So
if
someone
has
some
time
to
take
a
look,
that
would
be
great
thanks.
D
So
is
the
idea
here
that
pod
has
network
is
one
of
the
conditions
that
tie
into
the
union
of
what?
What
defines
what
this
rate
is
not
containers.
K
No,
so
basically,
it
would
suggest
condition
for
his
Network,
because
that's
the
part
in
the
code
where
that
situation
is
basically
becoming
true
right
now,
so
so
I
think
like
what
we
did
is
analyze
like
what
would
be
better.
What
would
be
a
better
name
for
it,
because
a
Sig
network
was
trying
to
introduce
this
concept
of
multiple
networks
and.
H
K
One
of
the
main
things
that
they're
trying
to
do
is
basically
say
that,
even
though
you
have
an
IP
address
in
the
sandbox
status
from
CRI,
it
does
not
necessarily
does
not
necessarily
mean
that
that
won't
change
over
the
lifetime
of
the
pod.
So
that's
why
they
were
opposed
to
the
name
and
they
say
like
what
is
it
that
you're
really
trying
to
say
so?
Basically,
what
we're
really
trying
to
say
is
sandbox
is
ready,
but
there
was
also
opposition
to
that.
So
the
name
we
came
up
with
is
ready
to
start
containers.
Basically,
yes,.
C
Yeah
makes
sense,
but
to
me
part
ready
to
start
the
container,
it's
kind
of
superset
for
Paul
that
has
Network
only
so
so
the
the
the
reason
they
think
about.
Oh,
we
are
kind
of
the
two.
What
I
should
say:
two
generic,
because
and
once
we
have
the
math
for
medical
support.
This
is
not
the
let's
assuming
that,
but
then
they
propose
an
even
more
generic
name
and
they
supersite
of
the
name
part
the
Israeli
to
start
the
content
anyway,
I'm
not
good
at
naming.
C
D
It
fits
well
with,
if
you
have
to
have
policy
based
Readiness
like
okay,
Network,
a
and
network
b
or
network
C.
If
we
have
that
condition
and
Google,
it
wants
to
enforce
that
or
CRI
wants
to
enforce
that.
Rather
that
makes
sense
either
is.
A
Okay,
we're
moving
on
Jack
exact,
prop
timeout.
L
All
right
folks,
so
dims
pinged
me
on
an
issue
that
Antonio
was
driving
to
remove
the
exec
probe
timeout
feature
gate
which
was
introduced,
I
think
in
the
120
release
cycle.
So
it's
been
a
while
and
that
addressed
a
bug
for
execro
timeouts,
not
firing
in
Docker
shim,
so
we
I
think
Sarah.
You
may
even
remember
this.
L
Like
a
year
and
a
half
ago,
we
tried
to
remove
the
feature,
gate
and
Jordan
very
reasonably
asked
that
we
get
some
user
feedback
on
whether
that
would
be
safe
for
folks,
because
the
feature
gate
exists
to
protect
back
compatibility,
even
though
Backward
Compatible
Behavior
was
sort
of
buggy
for
Docker
Sim
users,
so
fast
forward
to
today
and
dockershim
was
deprecated
in
124..
L
I
noticed
that
123
is
still
getting.
Did
it
get
its
last
patch
release
last
week,
but
it's
it's
going
to
be
end
of
life
really
soon
so
I
wonder
if
simply
the
removal
of
Docker
shim
from
the
kubernetes
ecosystem
entirely
gives
us
permission
to
remove
the
the
feature
gate.
We
can
go
through
the
process
of
locking
it
to
true
and
then
waiting
a
few
versions.
If
we
want
to
do
that
correctly,.
A
A
Problem
on
continuity,
problems
still
exists,
it's
surfaced
differently,
but
still
breaking
customers
when
when
enforced,
and
we
observe
that
on
some
scenarios
that
enforcing
it
may
break
customers
unexpectedly,
so
you're
referring
to
the
situation
when
dockersham
used
to
wait
till
completion
of
exact
crop
and
then
react
on
the
status
true
or
false,
it
does
react
on
it
and
just
says
through
even
like.
If
it
falls,
the
problem
is:
when
you
enforce
it,
it
suddenly
became
false
and
it
can
start
killing
containers.
A
So,
even
though
functionality
is
not
working
for
container
G
is
expected,
it's
still
working
worse
when
you
enforce
the
timeout,
because
it
can
break
customer
unexpectedly
and
that's
the
biggest
problem.
So
what
we
discussed
is
we
wanted
to
have
a
plan
and
like
help,
customers,
migrate
and
I,
think
you
created
this
metrics
for
customers
to
understand
which
timeout
to
set
and
I
don't
think
we
interest
any
documents
like
how
to
help
customers
transition.
A
L
Cool
that
sounds
fair
to
me.
So
I
will
I'll
work
on
on
building
up
a
set
of
documentation
that
folks
can
can
walk
through
which
AIDS
them,
how
to
to
Leverage
The
the
new
metric
to
make
their
own
measurements
in
their
environment,
and
then
I'll
just
submit
a
PR
and
then
I'll
work
during
the
pr
process
where
that
documentation
should
land
in
upstream
kubernetes.
L
And
then,
after
that,
we
can
do
some
sort
of
field
work
and
reach
out
to
the
community,
give
a
reasonable
amount
of
time
for
folks
to
get
exposed
to
this
new
documentation
and
have
chance
to
assess
their
own
environment.
So
I'm
happy
to
own
that
over
the
next
it'll
probably
take
a
while.
So
next
couple
of
release,
Cycles.
A
Foreign
agenda
I
think
it
will
be
good
to
remind
that
next
Friday
will
be
prr
product
regions,
review
deadline
for
caps.
So
if
a
cabin
flight
make
sure
you
have
somebody
assigned
from
product
residence
review
and
make
them
redo
stuff
and
then
a
week
later,
the
enhancement
series
I
think
it's
February,
10th,
so
I
think
maybe
next
signal
meeting
monomic
we
can
go
through
the
list
of
caps.
G
G
A
If
not,
then
happy
Tuesday
everybody
and
have
a
good
recipe
week.
Bye
thank.