►
From YouTube: Kubernetes SIG Node 20200915
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Good
morning,
everyone
today
is
the
september
15th
and
it's
our
week
may
of
the
signal
meeting
community
meeting
so
reuven.
Oh
sorry,
before,
like
that,
you
you're,
we
are
great
circuit.
Do
you
want
to
update
our
current
pr
status.
B
A
So
I
noticed
that
you
also
asked
some
questions
you
need
to
the
test
actually.
Originally,
I
want
to
ask
you
about
the
test
ci
pro
sub
project
status.
Maybe
we
can
hold
that
one
along
with
your
test,
your
question
later?
Okay,
so
riven,
do
you
want
to
talk
about
the
the
report
issue
related
to
the
device
plug-in
yeah.
C
So
a
little
bit
of
background
here
is
that
google
has
been
releasing
an
hour.
A
Your
voice
a
little
bit
broken
and
there's
some
like
the
ico.
A
lot
yeah.
A
Maybe
we
move
to
the
next
topic
until
the
later,
when
you
enjoy
rejoin
and
get
ready,
do
you
want
to
talk
about
container
notifier.
F
Yeah
sure
so
I
just
chanted-
and
I
want
to
bring
this
up-
that
we
are
working
on
this
feature
called
container
notifier.
F
F
So
we're
proposing
to
do
this
in
several
phases.
In
the
first
phase,
we'll
be
adding
alpha
apis
and
the
implementation
of
the
control
controller
logic
will
be
in
a
a
single
trusted
controller
that
will
be
handling
those
container
notifiers
and
in
phase
two.
We
want
to
move
that
logic
into
cubelet
and
also
in
phase
one.
F
F
So
this
is
roughly
we
are
trying
to
do
for
this
feature,
so
we
are
working
on
a
cap.
I
have
a
link
to
a
doc
there
in
the
in
the
agenda.
F
G
Oh
good
thanks,
we
probably
will
be
needing
a
lot
of
help
from
this
community
to
review
the
code,
etc.
You
probably
will
be
bothered.
E
So
I
know
I
know:
we've
met
previously
on
this
topic
and
I
think
there
was
a
last
meeting
where
maybe
seth
you
have
this
in
your
memory.
But
do
we
have
an
allocated
like
approver,
reviewer
and
a
sig
who
wants
to
try
to
shepherd
this
through
and
then?
My
other
question
is
if
the
code
is
being
explored
in
a
phase
one
outside
of
the
cubelet,
where
in
the
kubernetes
github
org
structure
or
is
that
code
living.
F
So
it's
good
so
that
I
still
need
to
figure
out
exactly
where
that
should
be.
So
it's
going
to
be
a
controller.
So
it's
going
to
be
part
of
the
cube
controller
manager.
I
would
think,
but
I
need
to
look
into
that
implementation.
Details
we'll
add
that
to
the
cap
so
yeah
so
who
should
we
add
as
the
approval
from
signaled.
F
H
G
A
Now,
american,
I
can
be
the
approver,
but
I
remember
there's
a
couple
open
issues.
We
haven't
like
the
the
scope
and
the
because
I
remember
my
first
goal
price,
so
we
tried
to
let
her
down
the
smaller
scope.
Hopefully
we
already
because
I
missed
the
last
meeting
we
had
hopefully
already
second
one
so
seth
was
there
right.
F
So
yeah,
so
I
think
last
time
we
kind
of
narrowed
the
scope
quite
a
bit
so
for
phase
one.
This
will
only
be
for
the
comments,
so
we
wouldn't
be
handling
signals,
but
because
signal
will
require
more
a
lot
of
changes
to
cri,
I
think,
and
also
since
the
control
logic
will
not
be
incubated.
I
think
that
that
will
be
because
I
think
we
are.
We
are
going
to
adding
a
section
for
cubelet
impact.
I
think
that's
requested
by
seth,
but
for
phase
one.
F
F
No
yeah
but
by
the
stats
was
yeah
derek,
but
I
think
I
think
seth
was
there
in
the
whole
meeting.
Oh
yes
right,
but
derrick,
I'm
not
sure
if
he
joined
the
meeting
with
during
the
late
yeah.
He
added
some
comments
there.
Yes,.
G
I
F
Okay
right,
yeah
yeah.
I
think
that
was
after,
I
think,
derek
added
some
comments.
After
the
meeting
yeah.
E
Yeah,
so
I
guess
the
key
thing
I'm
curious
about
is
just
to
make
sure
I
understand
when
you
do
put
the
cap
out
there.
E
I
understand
it'll
be
behind
a
feature:
gate
you'll
have
to
do
some
code
and
keep
controller
manager,
but
then
just
clarifying
where
the
node
local
agent
will
be
in
the
kubernetes
github,
like
code
org
structure,
if
you're
going
to
put
that
in
a
new
project
or
in
the
current
kk
tree,
that
would
be
good.
I
think.
F
E
Then,
if
you
have,
when
you
go
through
the
cap,
template
there's
sections
on
testing
and
production
readiness
reviews,
I
think
just
be
curious
how
we
could
integrate
this
in
node
ede
testing
flows
if
it's
outside
of
the
cubelet,
so.
F
Initially,
yes,
test
yeah,
that's
yeah!
If
it's
afar
yeah,
I'm
not
sure
I
so
that
something
that
I
still
need
to
figure
out.
You
know
if
you
know
how
this
should
be
handled,
should
we
add
e3
test
for
this
controller
before
moving
this
to
cubelet,
of
course.
Well,
we
won't.
You
could
definitely
need
to
add
those
e2
tests.
So
that's
something
I
think
it
depends
on
the
code
structure.
F
E
If
I,
if
I
could
I'd,
ask
that
we
have
end-to-end
testing
as
a
part
of
the
alpha
criteria
and
then
like,
I
said
that
that's
the
part
I'll
be
curious
to
see
between
seth
dawn
and
myself
if
we
can
work
out
a
clean
plan
on,
but
I
wouldn't
really
want
to
move
testing
of
this
only
to
happen
in
the
beta
phase.
G
Yeah
to
answer
your
question
at
this
moment,
I
don't
think
we
have
made
any
decision
where
to
put
the
controller
logic
yet,
but
it's
reasonable
that
we
have
a
good
coverage
on
the
test
so
that
we
feel
more
comfortable
in
the
future.
If
we
want
to
move
to
kubernetes.
H
So
I
think
I'm
missing
some
context
here,
but
if
we're,
if
we're
going
to
start
with
an
alpha
feature
gate,
is
there
a
reason
why
we
wouldn't
just
start
from
the
cubelet
by
the
way,
because.
A
H
A
Also
read
constantly
at
the
meeting,
and
I
couldn't
refresh
my
memory
for
this
one:
it's
just
the
zero,
because
initial,
the
scope
is
too
big,
and,
and
so
we
questioned
about
why
we
need
the
kubernetes
to
deal
with
all
those
kind
of
the
signal
and
also
we
couldn't
have
the
all
the
use
cases
to
come
up
to
drive
off
those
end
to
end.
So
we
ask
a
lot
of
questions
and
but
a
lot
of
those
questions
don't
have
answered.
A
So
that's
what,
because
initial
proposal
this
is
for
one
special
storage
cases
right
so,
but
then
we
try
to.
I
believe
that
came
from
the
team
which
is
based
on
our
experience.
Basically,
I
also
share
the
same
experience
with
team
on
the
board.
So
we
do
have
those
kind
of
problems,
but
the
problem
is,
we
don't
think
about
the
kind
of
proposal
and
cover
all
those
cases
and
address
all
those
problems
and
also
those
use
cases
is
today.
A
It
is
real
for
bulgar
and
also
with
the
new
issue
for
some
of
customers,
but
not
necessarily
what
we
propose
is
the
best
answer
for
those
customers
address
those
problems.
So
so
that's
why
I
post
dark
and
I
read
the
concept
there
and
I've
been
so
I'm
glad
that
we
like
regard,
I
forgot
the
detail,
maybe
like
the
shin
and
and
the
and
you
can
you
can
refresh
the
our
memory
and
see
what's
the
concept
and
what's
the
problem,
it
is
there.
G
G
Just
to
answer
the
why
it
is,
it
is
already
under
an
alpha
gate.
While
we
still
don't
do
this
in
the
phrase
one
in
couplet,
there
are
a
couple
of
reasons
right.
One
is
what
don
was
saying:
the
concerns
around
whether
this
logic
should
be
incorporated,
and
the
other
thing
is
that
we
don't
know
how
complex
the
logic
is
at
this
moment
from
what
I
can
see.
G
Even
given
this
small
scope,
the
the
logic
we're
going
to
add
into
kubernetes
is
going
to
quite
a
bit
so
adding
a
lot
of
logic
for
a
feature
like
this
right
now.
Intercoupled
that
certainly
concerns
don
and
derek.
That's
one
and
the
other
one
is
actually.
It
gives
us
as
well
more
time,
a
smaller
scope
to
implement
that
in
a
separate
controller,
rather
than
incorporate,
because
otherwise
we
need
to
understand
the
full
stack
of
accuplacers
direct.
G
So
that's
another
reason
to
think
about
this
way.
Making
this
into
three
phrases
is
gonna
to
cause
more
turnaround
time.
We
have
to
admit
that,
but
meanwhile
they
also
give
us
more
time
to
validate
whether
this
future
feature
is
highly
desired
by
the
community.
By
introducing
the
api
only
into
the
core
apis.
E
Yeah
so
andrew,
I
think
some
of
my
concerns
that
we
raised
in
our
earlier
discussions
were
around,
like
maybe
healthy,
skepticism,
on
the
security
posture
associated
with
with
the
design
and
then
some
concerns
on
potential
abuse,
vectors
and
so
just
wanting
to
experiment
on
that.
Outside
of
the
cube
first
made,
I
think
much
much
of
the
group
that
was
talking
about
that
comfortable
on
proceeding.
But
there
there's
this.
E
Agent
with
very
high
privileges
to
do
this
action,
rather
than
delegating
another
agent
of
the
system
with
the
same
privileges
say
as
the
cubelet,
but
a
lot
of
unknown
unknowns
are
around
this
feature
when
used
in
use
cases
outside
of
the
storage
use
case
that
was
presented
here.
That
gave
like
death
dawn
and
seth
and
myself
some
concerns.
So
I'm
really
happy
to
see
that
we
can
explore
this
outside
of
the
core
cubelet
tree
and
to
me
it's
no
different
than
saying
like
q,
proxy
wasn't
in
cuba
either
right
we
can.
E
We
can
make
evolution
and
evaluate
during
each
step
afterwards.
Yeah
make
sense
thanks.
G
Just
to
us
ask
a
question
john
derek
and
said
anyone
else
in
this
community:
do
you
guys
feel,
and
it
is
necessary-
we
schedule
photo.
I've
been
with
a
smaller
group
of
people
to
go
through
the
cap
and
to
refresh
your
memory
before
shin,
and
I
put
the
cap
out.
A
So,
let's
move
to
the
next
topic,
thanks
xing,
and
so
let's
move
to
next
topic.
Do
you
have
you
joined?
Can.
C
Yeah
finally,
yeah
so
yeah
this
pr,
I
put
there
is
about
creating
a
new
repo
in
the
oss
community.
A
little
bit
background
here
is
that
google
has
been
releasing
our
gpu
device
plug-in
using
the
jersey,
kubernetes
add-ons.
So
it's
part
of
the
open
source
code
and
there
was
a
effort
of
vanity
domain
fleet.
There
is
a
link
in
the
dock
on
and
that
vanity
domain
fleet,
basically
deprecated
on
the
image
paths
that
our
device
plug-in
has
been
using.
C
So
we
are
going
to
change
it
to
the
community
image
path
yeah,
so
that
pr
is
basically
to
create
a
repo
so
that
we
can
publish
our
new
device
plug-in
image
there,
and
also
I
want
to
bring
to
our
discussion-
is
that
whether
we
should
keep
publishing
google's
about
plugin
to
open
source,
sorry
to
community
rebel
or
it'll,
be
better
if
we
publish
that
to
a
google-owned
registry.
C
C
Because
it
was
using
the
kubernetes
add-on
initially
right,
so
that
is
the
part
that
makes
this
a
little
bit
confusing.
E
Yeah,
I
I'm
not
aware
of
general
community
use,
I
guess
I
I
don't
have
a
strong
opinion
on
this
versus
where
I
would
expect
a
lot
of
users
would
go
for
a
device
plugging
to
be
nvidia
itself,
and
so
as
long
as
it's
clear
where
and
how
people
go
to
which
source
that
would
be
probably
good
to
make
it
obvious.
C
Yeah.
Okay,
because
my
thinking
is
that,
because
this
is
a
google
device
plugin,
it
only
runs
on
in
this
case.
It
only
runs
on
gke
hosts,
so
it'll
be
easier
for
google
for
us
to
make
changes.
If
we
cannot
just
to
host
the
image
and
go
on
registry,
that.
E
C
I
I
don't
know
that
either.
That
is
way
before
I
joined.
C
But
anyway,
I
think
the
long
term
here
is
that
we
want
to
well
move
google's
device
plugin
off
from
open
source
kubernetes.
A
I
think
the
yeah,
I
agree
with
you,
bring
this
one
things
because
initially
kinda
like
the
sounds
like
provide
the
device
plugin
from
google
to
the
community,
but
actually
so
far
at
least
we
didn't,
we
don't
think
about
the
code.
So
so
you
you
brought
this
up.
It's
a
good
thing.
I
think
that
both
me
and
the
dark
don't
know
why
it
is
offered
from
the
open
source
this
one
I
can
follow
up,
be
offline
and
but
I
think
the
community
don't
think
about
that.
D
Derek
you
may
remember
as
well,
but
I
thought
that
originally
the
reason
for
hosting
this
in
open
source
was
that
the
nvidia
device
plug-in
required
nvidia
docker,
and
we
wanted
to
host
a
version
that
didn't
require
that
I'm
not
sure.
If
that's
still
the
case
today
or
not.
A
The
media
also
evolved
so
they're
also
involved.
They
didn't
really
require
the
offer
they
do
have
some
like
the
hook.
A
They
still
try
to
work
with
the
community
and
enable
those
who
can
add
to
the
cia
level,
but
they
are
not
required
of
the
special
docker
special
continuity.
They
they
they
kind
of
work
around
those
kind
of
problems
so
but
but
to
us,
but
still
nvidia's
device.
Plugin,
there's
the
api,
and
if
I
require
the
last
time
I
check
the
api
still
a
little
bit
different
from
the
open
source
one.
So
so
there
you
you're
right.
This
is
the
open
source
one,
but
the
rule
when
come
up
is
like
the
this
one.
A
K
K
A
Have
always
those
different
one
and
what
you
will
want
to
separate
and
have
the
google
house
and
then
that's
the
google
host
so
right
now,
I'm
aware
of
the
signal
the
height.
So
I'm
talking
about
the
open
source
things
and
the
google
things,
and
I
want
to
understand
what's
the
reason
to
talk
about,
but
it
started
to
mean
like
the
open
source:
don't
offer
a
default
one,
but
production
offer
that's
the
separate
wall.
Sorry.
E
Yeah,
I
guess
what
I'm
wondering
is-
I
don't
know
if
kevin
or
renault
or
anyone
from
nvidia
is
on
the
call,
but
most
usage
of
nvidia
gpus
I've
seen
these
days
has
them,
has
users
being
directed
to
the
nvidia
gpu
operator,
which
maybe
maybe
to
move
forward
on
this?
We
can
just
assign
an
owner
in
the
community,
someone
like
kevin
or
renaud,
to
give
a
an
nvidia
perspective
on
the
right
way
of
directing
users
to
best
consume.
E
K
Right
so
from
the
kids
on
your
side,
the
only
other
thing
I
can
add
is
like
give
us
a
reason,
and
after
that
we'll
approve
it.
A
Dean-
you
are
talking
about
this
different
story.
You
did
talk
about
actually
the
host
that
try
to
solve
this
google
production
each
and
host
the
different
repo.
A
So,
but
I
think
the
reason
also
came
here
is
talk
about
the
native
the
current
device
plugin
and
which
is
the
default
one,
which
is
the
open
source
offer
the
it
is
moved
to
the
google
special
repo,
and
my
first
reaction
is:
if
google
wants
to
host
that
one
and
please
go
ahead
and
host
your
own
copy,
your
own
things,
but
but
then
the
director
actually
is
another
person.
It
is
like
the
is
that
a
media's
one.
A
It
is
the
standard
one
right
now
what
it
is
the
api
discriminant
and
can
we
call
consistent?
Can
we
converting
those
two
together
and
as
fast,
I
know,
there's
the
do
still
have
some
api
difference,
but
very
minimized.
It's
not
that
huge
difference
and
they
also
in
introduce
some
node
agent
node
demon
and
to
enable
some
special
cases.
K
C
Right,
I
think
that
is
a
long-term
thing
to
basically
merging
this
to
different
versions
of
debug
plugin,
the
google
ones
and
the
nvidia
ones,
and
as
for
my
pr,
I
think
it
is
okay
for
us
to
well
for
now
not
publishing
the
device
plug-in
images
to
the
community
registry,
and
once
we
figure
out
if
there
is,
if
we
can
basically
merge
the
two
different
versions
of
device
plugin,
we
can
publish
that
to
the
community
registry.
A
L
Brilliant,
so
yes,
we,
we
created
the
second
operator
a
few
months
back
and
it's
pretty
much
working
with
developing
a
few
features
on
that
and
but
then
recently
we
we
realized
that
we
could
extend
quite
a
few
of
those
features
for
things
like
app
armor
and-
and
even
you
know,
potentially
in
the
future
c
linux
and
all
so.
What
we
proposing
is
to
rename
the
second
operator
to
security
operator.
So
we
don't
need
to.
You
know,
create
three
different
operators
to
to
do
those
features.
L
Given
that
there's
a
massive
overlap,
so
you
know
pretty
much.
You
just
wanted
you
to
get
this
past.
The
c
note,
because
you
guys
pretty
much,
gave
the
okay
to
create
the
operator
in
the
first
place
on
kubernetes.
So
just
wanted
you
to
see
what
the
community
thinks
about
it.
E
So
this
feels
like
an
expansion
of
the
sub
project
scope
is:
is
there
a
write-up
that
describes.
L
That
is
a
really
good
point.
I
don't
think
we've
done
something
as
as
good
as
we've
done
initially
for
the
second.
So
second,
we
have
like
a
brain
dump
or
a
brain
map
of
all
the
ideas
and
and
when
we
would
implement
them,
we
haven't
really
got
to
the
bottom
of
that
for
app
armor
and
sc
linux.
But
I'm
more
than
keen
to
to
come
up
with
that
and
present
this
again.
E
I
guess
what
I'm
wondering
is
like
when
you
add
app,
armor
and
sc
linux.
Are
you
I'm
not
even
sure
what
the
breadth
of
the
features
are
that
you're
talking
about
evolving
around
those,
and
so
I
kind
of
feel
like
before
we
rename
something
we
should
understand
what
scope
increase
might
be
happening
or
not.
L
That's,
that's
absolutely
fine,
so
I'll
do
that
and
come
back
potentially
next
week
with
some
more
details.
So
I
have
another
topic
as
well,
which
is
a
really.
M
Much
comment
on
the
naming
before
we
move
on
sorry
yeah.
I
agree
with
derrick,
I'm
also
supportive
of
merging
some
of
those
different
things
together
in
one
package,
essentially
to
make
deployment
management
easier.
I'm
a
little
worried
about
the
naming
of
security
operator
because
that
kind
of
related
to
the
scope
thing,
that's
just
a
huge
scope
and
I'm
I
would
like
it
if
we
could
come
up
with
something
that
was
a
bit
more
descriptive
than
that.
I
don't
have
a
suggestion
right
now,
though,.
L
Yeah
that
that
was
one
of
the
points
that
we
were
actually
thinking
about
as
well,
because
security,
I
completely
agree,
it's
quite
broad.
You
know
all
right
so
we'll
come
back
with
those
two
things,
maybe
a
few
names
and
and
also
the
the
initial
scope
that
we're
planning
for
this
extension.
Could
we
maybe
queue.
E
Up
10
minutes
or
so
in
our
next
meeting,
for
you
to
give
a
like
a
readout
on
the
current
state
of
the
subproject
like
make
sure
everyone
has
seen
a
demo
of
its
latest
state,
and
maybe
we
can
go
from
there.
L
Cool,
so
for
the
second
topic:
well,
it's
pretty
much
to
to
get
some
momentum
on
the
cap
for
making
the
app
armor
ga.
So
it's
pretty
much
in
the
same
kind
of
state.
As
second
was
a
few
months
back
and
we
we
pretty
much-
you
know
suggesting
to
the
minimum
just
to
get
what
we
have
there
rounded
up
and
and
and
mark
the
sga
so
yeah.
L
E
Yeah
so
tim,
were
you
the
owner
on
this
who,
who
was
picking
up
app
armor?
This
is
one
of
those
things
I
thought
we
called
out
in
the
future
health
check.
L
Yeah
he
actually
asked
me
to
come
and
and
talk
about
it
today.
E
Okay,
we
still
need
someone
to
do
the
review.
I
guess
I
don't
think
sasha
could
do
review.
I
thought
he
wanted
to
help.
Do
the
implementation.
I
don't
want
to
put
tim
eau
claire
on
the
spot,
but
I'll
put
tim
okay
on
the
spot.
M
Is
this
I'm
happy
to
do
a
review?
I
feel
like
I'm
a
little
too
close
to
the
project,
to
give
sign
up,
but
also
happy
to
do
so.
E
Yeah,
unfortunately
I
am
not.
I
will
admit
that
I
am
not
the
deepest
app
armor
expert
at
red
hat.
I
see
sc
linux
more,
so
I'm
hoping
there's
someone
who
can
better
represent
the
app
armor
community
in
this
review.
M
I
did
have
a
question
on
this.
This
has
a
lot
of
similarities
to
the,
as
you
said,
to
set
comp
and
in
the
process
we
went
through
to
getting
that
to
ga.
Do
you
feel
like
there
were
any
kind
of
lessons
learned
or
or
things
that
you
wish?
You
had
done
differently
with
the
second
ga
process
that
we
could
apply
here.
L
Well,
I
think
there
was
in
terms
of
the
implementation
because,
well
you
know,
I
implemented
that
with
sasha
and
then
and
and
a
few
things
we
kind
of
learned
through
the
process,
but
in
terms
of
the
capping
itself
yeah,
I
would
I
wouldn't
be
able
to
to
come
up
with
any
learned
lessons
from
the
previous.
Oh
second,
j.
N
Hi
hello,
yes,
I
just
wanted
to
to
let
you
know
that
as
we
talk
in
the
last
thing
note,
I
opened
a
vr
last
week
that
addressed
all
the
concerns
that
were
raised
previously,
it's
basically
the
same
following
the
suggestions
and
that
were
raised
in
the
previous
vr
or
the
suggestions
in
the
previous
single
meeting.
So
thank
you
very
much
for
your
help.
In
the
previous
meeting,
I
wanted
to
ask
if
there's
anything
else,
I
can
do
to
move
this
forward
or.
N
E
I
will
review
your
cap
I'll
just
be
transparent
around
my
own
time
pressures
this
week
that
I
I
won't
be
able
to
get
to
it.
The
remainder
of
this
week,
given
issues
in
my
own
personal
life,
but
next
week
I'll
look
to
get
a
review,
and
so
apologies
for
for
that
lag,
but
I'll
take
over
the
review.
N
No
need
to
apologize
the
best
of
luck
with
your
things.
O
We
have
a
kep
available,
it's
currently
in
a
google
doc
form,
but
we're
going
to
transfer
into
an
md
file
and
go
through
the
pr
process,
since
we
don't
have
too
much
time
today
to
kind
of
discuss
too
much
in
depth
from
a
high
level
we're
taking
a
pretty
different
implementation
method
than
other
windows
containers
and
that
we're
using
a
job
object
instead
of
a
server
silo
and
with
that
we
get
some
privileged
container
capabilities.
O
With
that
kind
of
difference
and
lighting
up
this
feature
for
windows,
it
would
be
great
to
get
some
review
of
this
cap
and
have
different
concerns
or
cases
called
out
as
we
kind
of
move
forward
with
this,
and
with
that
we're
looking
for
signaled
reviewers
if
possible,
and
if
there's
time
kind
of
in
the
next
meeting
for
next
week
to
kind
of
go
in
depth
with
any
questions
that
get
kind
of
added
in
the
next
week.
O
O
I
think
one
of
the
best
locations
that
kind
of
look
at
the
comparison
is
the
kind
of
psp
support
table
that
we
have,
and
there
is
some
kind
of
call
out
as
to
psps
that
might
be
expected
for
linux
type,
privileged
containers
that
might
have
different
applications
to
windows
and
kind
of
how
it
influences
different
use.
Cases
like
diamond
sets
and
node.
O
O
Yeah,
it
would
be
great
to
get
some
time
next
week
to
kind
of
to
go
over
it
to
address
any
comments
that
need
kind
of
in
over
call
discussion.
Otherwise,
you
know
we're
actively
looking
at
any
comments
that
come
into
this
google
doc
and
once
we
have
an
md
file
created,
we
can
also
address
any
kind
of
comments
or
issues
that
come
on
the
pr.
P
Yeah
and
just
fyi,
we,
we
have
presented
this
in
sig
windows
and
got
through
one
round
of
comments
and
feedback
from
the
sig
windows
community.
P
A
I
cannot
see
that
next
week
can
have
the
dedicated
of
the
meeting
just
for
this
one,
because
just
you
already
heard
earlier,
we
asked
her
actually
see
another
topic
come
back,
so
that's
why
we
can,
but
do
you
think
about
how
what's
the
minimum
time
you
require?
You
think
about
we
needed
to
review
this
one.
O
E
I
guess
just
in
a
quick
browse
of
the
document,
I
guess
someone,
I'm
wondering,
is
it
actually
in
a
state
that
is
ready
to
implement?
It
looks
like
there
were
pointers
out
to
maybe
changes
that
were
needed
in
the
oci
spec
itself.
Just
so
I
yeah
when
reading
this
myself
is.
It
are
all
the
prerequisite
requirements
before
the
cube
with
satisfied.
I
guess.
O
Yeah,
so
we
actually
have
an
internal
implementation,
that's
kind
of
ongoing
and
we're
working
out
some
internal
testing
on
some
of
the
kinks,
but
we
do
actually
have
a
lot
of
everything.
That's
below
you
know,
kind
of
in
the
container
d
layer
and
any
of
the
windows
bits
that
I
have
to
get
addressed
are
are
working
and
we're
just
kind
of
in
the
past.
O
Several
weeks
with
feedback
from
the
sig
windows
community
have
identified
the
areas
kind
of
above
that
layer
that
will
need
changes
and
are
kind
of
addressing
how
we
might
get
those
working,
but
we're
looking
for
feedback
kind
of
continuing
feedback
on
the
different
scenarios.
As
we
try
to
move
into
the
alpha
stage.
Q
And
there's
also
a
demo
video
I
looks
like
there
is
a
link
to
the
video
in
the
risks
and
mitigation
section
of
this
working
with
windows
and
container
d.
So
the
layers
below
the
keyboard.
E
Yeah
and
then
my
last
question
is
like:
was
there
a
discussion
with
sig
off
on
the
pod
security
policy
bits.
O
E
Okay,
just
because
signo
doesn't
actually
maintain
pod
security
policies,
so
I
want
to
make
sure
that
the
feedback
that
you're
looking
for
in
the
dock
was
it's
probably
going
to
be
grouped
from
multiple
sigs.
P
Yeah
we
can,
we
can
take
it
to
to
say
god
we
can
post
it
there
as
well
awesome.
H
P
Sorry,
I
I
I'm
curious
about
what
should
be
the
next
step
from
here,
so
we
posted
the
cigarette.
This
ignored
community
is
going
to
look
at
the
enhancement
issue
in
the
the
dock.
The
cap
should
we
come
back
next
week
and
like
take
five
ten
minutes
to
go
deeper
into
any
comments.
E
Doc
so
at
least
those
of
us
in
the
node
community
who
can
review
it
we'll
see
which
areas
were
pertinent
or
sig,
but
it
just
in
advance.
I
was
just
want
to
make
sure
that
you
understood
that
some
of
the
sections
here
were
were
outside
the
purview
of
of
just
the
sick,
so
it
sounds
like
maybe
visiting
sigoth
to
talk
about
any
pod
security
policy.
Changes
desired
or
or
not
would
be
a
good
parallel
action.
A
Okay
suggest
next
week
you
come
back
just
if
you
feel
needed,
because
the
feedback,
but
also
you
think
about,
do
you
want
proactively
looking
for
signal
to
support,
because
they're
obviously
have
the
note
related
things.
If
you
want
to
unblock
you
and
make
sure
risk
awareness
and
and
also
make
sure
we
are
planning
to
proactively
allocate
the
approver
and
the
reviewer.
A
So
then
you
come
back,
but
if
you
think
about
actually
parallel
of
those
negative,
just
like
the
direct
earlier
mention
that
for
the
stickers
support,
if
you
didn't
got
that
one,
then
you
think
about,
then
you
don't
need
to
came
here,
because
obviously
you
need
to
address
some
other
issues
first
right.
So
so
something
like
that.
So
it's
up
to
you,
but
I
don't
think
about
next
week.
We
can
dedicate
one
meeting
just
for
this
topic
if
we
lead
it
like.
A
P
Yeah
yeah,
I
think
we
weren't
proposing
like
a
whole
meeting
dedicated
for
this
review.
It
was
more
like
addressing
the
comment,
but
it
makes
sense.
So,
let's,
let's
let
us
go
to
cigars.
If
there
are
no
concerns
there,
then
the
only
thing
would
be
signed
and
we'll
come.
M
A
K
Yeah
I
can,
I
can
get
the
wall
rolling
and
derek
can
join
in.
So
there's
a
whole
bunch
of
work
that
we've
already
done
for
this,
including
the
dockerless
tag,
including
switching
around
the
ci
jobs,
to
do
more
container
d
instead
of
docker,
so
that
kind
of
stuff
so
and
so,
basically
a
whole
bunch
of
things
have
been
already
done
right
now.
What
we
are
looking
at
is
how
do
we
actually
remove
it,
the
remote
docker
gym
and
when
do
we
remove
docker
shim?
K
So
the
biggest
issue
is
not
the
city
itself.
It's
the
users
who
have
to
switch
over
from
docker
to
another
cra
implementation,
so
that
how
do
we
address
that
question
is
basically
you
know
what
came
up
when
I
opened
up
a
pr
for
deprecating.
The
docker
shim
so
ended
up
writing
the
cap.
It
has
three
stages:
one
is
actually
adding
the
deprecations.
K
The
second
one
would
be
at
some
point
to
stop
building
cubelet
with
docker
shim
and
then
eventually
getting
rid
of
docker
shim
completely
from
our
tree.
So
those
are
the
three
three
steps
that
I
could
think
of.
If
the
main
issue
right
now
seems
to
be
well,
there
are
two
one
is:
how
do
we
help
or
guide
people
who
are
currently
using
docker,
say
in
bare
metal
scenarios
where
they
have
to
switch
over
from
docker
to
container
d,
for
example
or
cryo,
then
the
other
one
is.
K
How
do
we
make
sure
that
we
support
the
windows
community?
That
currently
depends
on
docker
and
they
are
slowly
moving
to
continuity.
So
those
are
the
two
things
that
came
up
as
concerns
and
the
the
timeline
itself
accommodates
both
those
things.
The
main
thing
that
we
have
to
do
right
now
is
tell
people
actively
that
they
have
to
move
out
and
give
them
time
to
prepare.
K
You
know,
however,
they
want
to
do
it
right.
There
will
be
plethora
of
options
of
moving
in
place,
upgrades
just
making
sure
that
new
clusters
are
created
using
alternate
crm
implementations,
there's
plenty
of
strategies
that
people
can
adopt,
but
then
we
have
to
write
them
down
as
well
as
a
migration
guide,
so
that
would
be
another
deliverable
for
the
cap.
K
So
at
this
point
in
120
I
want
to
like
deprecate
the
user,
visible
things
and
add
deprecation
in
the
logs,
so
people
know
and
more
importantly,
adding
an
action
item
in
the
release
notes.
So
people
have
a
long
period
of
time
to
think
about
this
to
make
it
happen.
So
that
was
my
so
box
derek.
Did
you
have
any
other
thoughts.
E
Yeah
so
juan
thanks
james
for
sharing
a
a
version
of
this
before
the
cap.
Yesterday
I
had
put
some
comments
on
there
and
I
have
to
catch
up,
but
you
had
here,
I
think,
to
lead
into
the
next
topic.
I
think.
E
I
think
it's
healthy
that
we
identify
the
reality
that
docker
shim
is
kind
of
in
maintenance
mode
itself
and
that
as
a
sig
community
messaging
out
to
the
users
that
our
energies
are
going
towards
cri
based
implementations
for
net
new
features.
E
I
think
that's
that's
very
healthy,
and
so
I
like
the
language
of
maintenance
mode,
I'm
not
sure
if
that
language
maps
to
everyone
else's
view
of
that
so
but
the
prereq
I
wanted
to
get
to
complement
this
behav
behavioral
change
outward
is
to
kind
of
sit
back
and
actually
ask
what
does
it
take
to
get
the
cri
out
of
the
alpha
state
that
we
have
and
what
does
it
mean
to
beta
or
gi
the
cra
itself
like
what
is
its
version
skew
relative
to
changes
in
cuban
and
stuff?
E
I
didn't
feel
like
that
was
a
document
I
wanted
to
put
together
in
isolation.
So
I
guess
the
the
call
out
is
renault-
and
I
were
chatting
about
this
a
little
bit
prior
to
the
call
we'd
like
to
get
up
set
up
a
meeting
for
next
week
with
anybody
who's
interested
in
the
topic
to
talk
through.
E
Less
on
an
evolution
of
what
you
aspire,
the
cri
to
be
and
more
of
a
requirement
to
take
the
present
state
and
identify
it
for
what
it
actually
is
is
the
thing
that
most
every
vendor
is
using
in
production
today
and
close
out
those
issues
that
are
annoying
us
in
production
readiness
or
in
upgrading
readiness
issues
to
just
kind
of
define
a
a
a
unit
of
work
that
has
completed.
E
I
guess,
and
so
I'll
send
a
note
out
to
the
signal
mailing
list
to
try
to
get
a
doodle
together
with
some
times
for
that
and
if
we
can
get
some
folks
interested
in
helping
draw,
this
forward
hope
to
get
it
kept
out
in
a
couple
weeks.
But
I
I
think
it's
important.
We
point
to
that
cap
before
making
a
final
statement
on
dems's
cup,
but
thanks
tim
for
being
the
impetus
to
make
us
finally
act
on
this.
S
A
small
comment
regarding
we're
helping
with
people
to
upgrade
from
doctor
shin
to
something
else,
so
the
current
docker
versions
when
they
start
where
container
d
is
explicitly
disabled
with
cri
plugin.
If
we
can
help,
if
you
can
talk
with
docker
guys
to
disable
that
behavior,
so
when
migration
for
container
d
will
become
a
really
transparent
and
our
tools,
what
we
are
shipping
as
kubernetes,
so,
for
example,
like
cube
adm,
can
automatically
detect,
wet
and
help
with
migration.
S
E
I
want
to
if
it's
okay,
james,
I'm
sorry,
I
don't
really
want
to
expand
the
responsibility
of
sig.
So
in
my
perspective,
we've
never
truly
supported
in
place
upgrade
of
a
node
in
kubernetes,
and
so
it's
possible
that
a
user
may
have
to
reprovision
their
node
or
to
change
their
node
configuration.
I
kind
of
view
that,
as
outside
the
purview
of
this
sig,
I
would
applaud,
say
cluster
lifecycle
on
what
they
could
pursue
in
that
environment.
E
But
I
definitely
don't
want
to
have
to
pursue
something
that
says
you
can
change
the
cubelet
and
run
time
and
not
drain
a
node
between
actions
that
just
doesn't
seem
like
a
a
realistic
goal,
and
so,
when
we
get
into
the
details
of
these,
I
guess
maybe
that's
a
topic.
We
just
write
down
as
a
known
issue
as
we
write
through
requirements,
but
I
really
don't
want
to
expand
the
surface
area
of
what
we
have
to
support,
because
I
think
we
could
go
too
far
on
that
honestly.
K
Yeah,
I
agree
with
derek,
but
I
do
have
a
suggestion
for
alex,
which
is
to
open
up
an
issue
in
moby
moby,
so
I
can
go
ping
other
people,
you
know
outside
of
the
sig.
A
I
think
no
matter
the
cri
api
issue
actually
a
little
bit
not
irrelevant
honestly.
The
most
problem.
People
cannot
off
the
docker.
It
is
the
some
is
just
because
the
legacy
and
they
don't
want
to
and
because
we
never
set
the
time
right
so
we've
been
hand
away
for
in
the
past,
and
we
call
out
to
the
container
dga
and
I
had
and
with
the
hand
and
but
we
didn't
really
put
effort
to
make
that
happen,
that
need
investment.
A
Another
one
actually
is
real
problem.
It
is
the
usability-
and
this
is
why,
when
I
first
started
cri
project,
I
also
started
test
project
and
tool
project,
because
the
docker,
as
the
cli
obviously
have
the
really
good
of
the
usability,
but
we
invest
of
the
engineering
from
the
signal
and
there's
the
ci
tool.
Actually
it
is
talk
about
the
power
api
container.
Api
supports
should
be
by
design
and
should
be
better
than
the
darker
ci
for
the
kubernetes
use
cases.
But
but
obviously,
implementation
is
different
story
different
from
the
like
the
design.
A
So
so
we
shoot
the
neck.
The
co-art
at
the
community
and
the
really
set
timeline
timeline
could
be
one
year.
So
then
people
have
the
next
honestly,
ironically,
even
google
not
move
off
from
the
docker.
Obviously
that's
the
engineering
investment
issue
right,
so
the
resources
issue.
So
if
we
go
out
and
then
the
all
those
production
vendors
will
be
put
effort
to
move
off
with
the
dependency
on
the
docker.
That's
that's.
The
basically
is
the
top
one
issue
here,
instead
of
say
I
and
the
api.
I
also
for
the
say
I
appear.
A
I
comment
because
I
saw
that
we
are
going
to
run
out
of
time.
So
I
I
put
some
high
level
comment
because
we
have
something
sort
of
what
it
is
vitamin
and
obviously
version
school.
That's
the
top
issue.
We
never
really
solve
that
problem
and
we
keep
have
the
new
feature.
I
did
so
that's
why
we
keep
end
up
the
stock
at
the
alpha.
But
again
that's
the
internal
api.
So
we
are
not
really
it's
not
really
blocking
us
to
move
off
from
the
docker.
E
Yeah
so
I'll
take
a
look
at
your
comment
on,
I
think
generally,
my
thought
was
cri
can
continue
to
be
versioned
with
cubelet
and
that
you'd
update
your
cri
when
you
update
the
cubelet
but
I'll
take
a
look
at
what
you
had
pointed
there.
But
if
folks
want
to
help
jump
in
on
this
discussion
next
week,
I'll
try
to
find
a
doodle
that
can
best
maximize
participants
to
share
their
story.
A
And
then
there
are
also
have
the
more
issue
reads:
the
best
circuit
about
to
the
test
and
also
runtime
ga
plan
and
other
thing.
So,
unfortunately,
we
are
runtime
of
time.
Today
we
have
too
many
topics
and
can
we
follow
up
next
week
on
those
topic
or
circuit,
you
can
follow
the
email.
I
also
comment
of
one
of
your
tasks
there
and
because
that's
basically
the
what
you
asked
the
question
is
that
exactly
youtube
that
I
tried
to
address
the
two
years
ago,
so
we
had
the
proposal.
A
A
E
Yeah
it'll
get
on
my
queue
for
caps
to
look
at.
A
I
think
we
don't
have
time
sorry
about
and
thanks
everyone
and
looking
forward
for
next
week.