►
From YouTube: Kubernetes SIG Windows 20210511
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
Welcome
it's
may
11th.
This
is
sig
windows
weekly
meeting,
and
this
is
a
cncf
meeting,
so
we
will
be
following
the
cncf
guidelines
and
code
of
conduct.
If
you
have
any
questions
or
concerns,
you
can
reach
out
to
myself
or
jay.
A
Mark
is
out
on
leave
for
a
few
weeks,
so
myself
and
jay
will
be
leading
the
meetings
for
the
next
few
weeks.
So
if
you
have
any
questions
or
concerns
or
things
that
you
were
following
up
with
mark
I'm
taking,
I
took
he
gave
me
access
to
quite
a
few
views
prs.
So
if
there's
any
comments
or
questions
there,
you
can,
let
me
know.
A
So
go
ahead
and
start
with
intros,
I
think
see
a
few
new
folks.
We
typically
try
to
start
off
and
have
new
folks
introduce
themselves
and
say
why
they're
here,
why
they're
interested
in
sick
windows
but
they're
trying
to
get
out
of
the
meeting
if
they're,
if
they're
interested
so
leave
it
open
there
if
anybody's
possible.
A
Okay,
then
we'll
move
on
to
announcements,
so
enhancement
stories,
oh,
go
ahead.
B
Sorry
I
had
like
a
double
mute,
so
hi
everyone,
my
name
is
carmel,
I'm
first
time,
I'm
here
on
sig
windows,
even
though
I've
been
sometimes
using
and
blogging
about
kubernetes
and
docker,
also,
of
course
on
also
on
windows.
So
I'm
today
I'm
just
here.
I
will
be
joining
normally
the
the
next
ones.
Also,
I'm
here
just
to
see
how
I
can
let's
say,
learn
first
and
also
contribute
and
help
yeah.
That's
it.
That's
me.
C
A
Okay,
yeah
so
keps
enhancement
freeze
is
this
thursday.
We
have
three
that
we're
tracking
that
I'm
aware
of
the
host
process
one.
I
think
that
we
we're
in
agreement
on
the
final
item
and
we're
just
waiting
for
you
from
sig
api,
but
I
think
we're
generally
in
the
pretty
close
to
getting
that
merged
that
the
actual
implementation
merged
average.
Are
you
on
the
call?
Do
you
want
to
give
a
quick
update
on
longview.
D
Yes,
so
the
log
we
are
kept
has
merged.
We,
where
I
was
able
to
satisfy
tim
hawkins
request
for
heuristic
based
approach
for
getting
the
logs
instead
of
specifying
whether
it's
a
log
file
or
a
journal.
So
that's
merged
me
and
christian
glombeck
from
red
hat.
A
And
then
the
other
one,
it's
we're
not
specifically
driving
this
but
been
participating
in
the
pspe
conversations,
and
so
we
had
a
meeting
last
week.
It
was
a
special
sig
off
meeting
for
psp
and
I
think
we
came
to
agreement
that
we
should
be
running
windows
under
the
baseline
policy
and
then
also
privileged
will
work.
A
And
then,
if
the
cubelet
and
the
runtimes
allow
it
and
strip
out
the
linux
specific
fields,
then
you
would
be
able
to
run
it
underneath
the
restricted
profile
as
well,
and
we
will
be
moving
forward
with
the
runtime
classes
for
doing
exemptions
similar
in
the
way
that
they're
doing
it
for
linux,
and
I
think,
there's
one
concern
there.
That
people
should
be
aware
of.
A
Is
that
if
you
are
using
docker
shim
and
you
use
the
runtime
classes,
it
would
potentially
be
possible
to
bypass
the
essentially
give
a
windows,
shim
or
windows
runtime
class
and
have
that
and
manually
schedule
it
using
node
names
and
land
it
on
a
linux,
node
and
and
essentially
bypass
all
privileges.
So
that's
that's
a
concern
that
they
called
out
in
the
cap.
There
there's
we've
also
been
working
with
the
gatekeeper
community
and
have
identified
like
a
two-phase
approach
to
eliminating
things
or
risks
like
that.
A
So
if
you're
interested
in
that,
we
can
I'll
drop
a
link
into
the
pr
that
where
we
discuss
that
for
jay
keeper.
E
James
as
far
as
the
the
next
phase
of
the
implementation
for
psp
v2
goes,
there
was
a
concern
around
identifying
the
windows
box
at
the
api
level,
like
like
one
of
the
things
that
came
up
was
like
in
the
restrictive
mode.
If
you
are
applying
non-judiciously
linux,
specific
security
constraints
to
a
windows
bar,
how
do
we
eliminate
them
like?
As
of
now
our
go-to
approaches?
Let.
F
E
Land
on
a
cubelet
and
and
on
the
cube
left
side,
we
are
going
to
strip
off
linux
specific
security
constraints,
but
there
are
certain
distributions,
like
openshift,
where
we
try
to
apply
everything
at
the
admission
level
at
the
pod
admission
level,
even
before
it
reaches
cubelet,
so
identifying
the
part
window
spot
or
a
linux
spot
at
that
level
would
be
beneficial
and
even
community
is
also
moving
in
the
same
direction.
E
A
Yeah,
so
I
think
the
the
same
idea
is
still
gonna
apply
where
it
would
come
in
like
because
I
think
you
did
the
pr
to
strip
out
the
fields
for
like
the
linux
specific
fields
in
the
cubelet,
and
so
the
same
idea
is
going
to
apply.
It
would
be
allowed
in
and
then,
if
cubelet
doesn't
check
those
fields
or
or
removes
them,
because
it
knows
it's
windows,
then
the
pod
would
still
be
scheduled
and
applied
through
there.
A
As
far
as
like
an
os
specific
field,
it
was
identified
that
we
definitely
need
this
os
specific
field.
That's
going
to
require
kep
and
I
think
quite
a
bit
of
investigation
on
how
to
to
make
that
work
and
implement
it,
which,
if
anybody's
looking
for
a
big
contribution,
that's
a
good
good
opportunity,
yeah
to
be
clear.
E
We
might
not
even
need
the
os
specific
field
within
the
pod
step
right.
We
can
actually
get
away
with
with
just
the
runtime
classes,
because
if
the
runtime
class
has
like
within
the
scheduling
constraints,
if
it
has
got
the
hostname,
sorry
the
I
the
os
as
windows
and
the
required
tolerations,
we
can
identify
that
it
is
a
windows,
specific
form.
A
Well,
but
I
think
that
comes
down
to
where
you
can
bypass
it
with
the
node
selector.
So
if,
if,
if
you
were
to
schedule
the,
if
you
have
the
runtime
class
and
you
had
all
those
fields
like
the
windows,
specific
fields
in
the
runtime
class,
if
you
specified
a
node
name
on
the
pod
template
it
and
it
was
linux,
you
would
bypass
those
runtime
classes
as
long
as
there's
a
runtime
class
with
that
name
on
on
the
linux
node,
and
so
that
that's
kind
of
the
docker
shim
situation
concern.
E
For
linux,
as
well
like
specifying
the
node
name
within
the
pod
spec,
that
will
be
a
problem
anywhere
to
bypass
the
scheduler
yeah.
Even
if
you
put
os
equal
to
windows
or
something
like
that,
it's
not
going
to
solve
the
problem
right.
A
Yeah,
so
right
now
we're
like
the
way
the
psp
is
written
for
alpha
we're
not
necessarily
identifying
windows
nodes,
we're
applying
the
same
like
the
same
type
of.
A
E
Right
but
when
psp
becomes
default
like
say
if
it
reaches
beta
or
sorry
ga,
I
believe
it
was
told
it
was
mentioned
that
we
will
apply
restricted
as
the
default
profile
going
forward.
E
If
the
profile
chosen
is
restricted,
yeah.
The
main
point
I'm
trying
to
make
is
like
by
the
time
we
reach
that
stage.
We
should
be
clear
in
saying
the
ip
api
folks
that
hey,
we
can
clearly
identify
windows
pod
using
this
mechanism.
It
can
be
either
the
os
field
within
the
pod.
Spec
say
if
we
go
with
that
approach
or
with
the
runtime
classes,.
E
Yeah
yeah,
I
just
want
to
bring
this
up.
We
do
not
have
to
make
a
call
now,
but
I
think,
as
a
community,
we
need
to
agree
upon
what
should
be
the
way
to
identify
a
windows
spawn
if
it
is
os
field.
We
need
to
introduce
it
like
I'm
fine
with
it,
but
I
just
want
to
make
sure
that
all
of
us
are
in
agreement
before
we
go
that
route.
A
Absolutely
I
don't
know
if
anybody
else
in
the
community
has
any
preferences
or
particular
directions.
They'd
like
to
see
this
move.
D
G
Yeah,
I
mean,
I
think,
I've
I've
been
using
runtime
classes
since,
since
I
pretty
much
started
on
on
windows
notes-
and
I
think
it
allows
you
to
kind
of
bunch
together
a
lot
of
things
that
you
might
not
necessarily
remember
to
do
so
like
taints
and
if
you
ever
tainted
a
node
or
whatever.
You
could
put
all
that
in
the
runtime
class
and
save
the
complications.
So
I
quite
like
it
as
a
personal
opinion,
but.
E
Yeah,
I
agree
I
mean
like
accusing
runtime
classes
is
the
is
to
me
personally
preferable,
but
at
the
same
time
we
have
been
in
the
documentation.
We
have
been
recommending
that
you
can
go
with
the
node
selector
plus
tolerations
or
you
can
go
with
the
runtime
classes.
If
you
want
to
make
runtime
classes
as
the
way
to
identify
windows
parts,
perhaps
we
need
to
call
that
out
in
the
documentation.
C
Maybe
this
plays
into
the
way
we
define
conformance
for
windows
too
right,
because
the
problem
is
like
eks,
I
don't
think
by
default.
Eks
puts
a
I
forget,
but
I
know
some
clusters
give
you
the
runtime
class
and
some
don't.
I
don't
think
eks
gives
you
one
for
free,
but
I
think
aks
does
right
james.
I
don't
know.
No,
we
don't
yeah,
you
don't
either.
Okay,
so,
like
I
mean
this
kind
of
is
like
okay.
C
Well,
neither
eks
nor
aks
by
this
definition
would
work
out
of
the
box
in
this
way,
and
I
think
that's
okay,
because
we
could
tell
aks
and
eks
and
whoever
else
that
like
look
if
you're
a
real
windows,
cluster
and
you're
actually
running
windows,
pods,
then
by
definition
you
have
to
have
a
runtime
class
for
that
defined
and
it
doesn't
matter
what's
in
the
damn
runtime
class.
But
it's
got
to
be
there
right
or
something
like
that,
and
if
you
don't
do
that,
then
we
can't.
A
Naming
them
also
we'd
have
to
have
we'd
have
to
say
this
is
a
standard
name
and
for
windows,
and
then
how
do
you
apply
that
across
the
different
os's
and
inversions?
And
how
do
you
add
additional
runtimes
that
you
might
want
to
implement?
So
I
think,
there's
more
to
be
explored
there,
but
I
also
want
to
make
sure
we
time
boxes
so
we'll
take
one
or
two
more
comments
and
then
because
I
see
a,
we
have
a
node
problem-
detector
demo.
But
then
here
too
I'd
like
to
have
time
for
that.
E
Perhaps
we
can
come
back
and
discuss
this
like
I
started
slack
thread
we
can
discuss
there.
That
would
be
awesome.
Thank
you
yeah.
I
already
did
that
on
kubernetes
last
week,
so
we
can
perhaps
continue
the
discussion
there.
H
For
the
caps,
I
also
want
to
mention
csi
proxy.
We
plan
to
go
to
ga
and
right
now,
I'm
updating
the
csf
windows
support
cap
to
include
ga
qualification
questionnaire.
H
So
if
anyone
like
interests
want
to
take
a
look
review,
it
please
and
also
is
there
a
spreadsheet
to
keep
track
of
sig
windows
caps.
I
just
want
to
put
csf
proxy
there
too.
A
H
Okay,
okay,
so
I
think
my
slack
id
is
jing
j.
I
ng
xu
97.
H
A
Cool
all
right,
so
windows,
containers.
A
I
Yeah,
so
I
can
speak
about
this,
so
basically
we're
still
seeing
an
issue
where
the
pod
gets
into
like
this
crash
would
back
off
from
these
weird
issues
and
there's
been
multiple
attempts
to
fix
this
bug.
But
it
comes
back
and
I
think
it's
coming
back
in
different
ways.
There
is
no
repro
yet
that
we
can
share
that.
We
can
reproduce
it
internally
at
google.
I
I
But
this
is
something
that
happens
quite
a
quite
often
is
when
we
kill-
or
we
try
to,
I
believe,
delete
the
container
and
it
gets
stuck
in
this
mode
and
it
can't
like
delete
a
file
or
something
like
that.
A
I
A
I
thought
we
were,
I
remember
seeing
this
in
120
at
one
point
and
then
I
haven't
seen
it
in
the
log
since
then,
and
there
was
there
was
a
set
of
access
to
like
vlogs
that
I
think
was
fixed,
but
I
I
don't
remember
specifically
so.
I
Do
you
mind
putting
the
pull
requests
for
that
and
see
if
we
could
patch
so
we
can
see
if
we
can
patch
it
in
and
see
if
we
can
still
re-throw
it
with
our
internal
testing.
A
A
Cool
michelle,
I
think,
do
you
have
enough
to
have
this
five
minutes
enough.
A
J
Oh
yeah
plants
again
let
me
share
my
screen.
J
Are
you
all
able
to
see
my
screen
should
see
like
a
chrome,
tab
and
powershell
script,
yeah
page
all
right
cool,
so
this
is
a
sample.
This
is
a
windows
node
that
we
that
I'm
running
with
the
npd
service
that
jeremy
had
built
up
and
integrated
with
this
windows
build,
and
so
basically
you
can
see
it.
If
you
were
to
look
at
get
service.
Let's
see
that
no
problem
detector
is
running.
J
This
is
our
dashboard,
where
the
node
problems
are
being
reported
to
prometheus
and
it
gets
reported
and
split
out
to
these
to
this
metrics
page
and
so
I'll.
Go
through
like
a
simple
demo,
where,
for
example,
if
we
were
to
look
and
see
that
cubelet,
for
example,
stops
running
you'll,
see
this
counter
increase
to
see
that
it's
failed
and
then
you'll
also
notice,
because
the
cooldown
was
longer
than
a
minute
or
so.
J
When
you
look
at
the
cuba,
it's
automatically
repaired
itself,
and
so,
if
you
were
to,
if
it
was
to
fail
within
less
than
a
minute,
our
cooldown
period
for
at
least
cubelet
is
a
minute.
Or
so
you
see
that
it's
stopped
and
it
will
basically
wait
for
that
time,
for
it's
basically
checking
every
10
seconds
to
detect
if
this
thing's
working
for
cubelet,
with
the
help
of
cubelet
help
with
container
d
health
of
we
added
some
more
features
as
well
in
newer
versions
like
hue
proxy.
J
But
I
don't
have
that
to
show
you
today
and
we
use
this
health
health
endpoint
to
check
the
health
of
cubelet,
and
so
since
it's
down,
you
wouldn't
see
it
working,
but
then,
when
it
starts
to
repair
itself
and
auto
repair,
this
should
start
working
within
a
few
more
seconds
or
so.
And
this
would
also
increment
here.
J
So
it
should
be
running.
We
should
be
able
to
hit
this
endpoint
now
okay,
so
this
is
a
very
simple
demo
of
mpd
running
as
a
service.
You
can
take
a
look
at
event,
locks
to
see.
We
use
the
win
events
to
determine
when
things
are
last
run
to
see
we,
we
use
the
q
proxy
for
the
health
endpoints
to
check
when
it's
up
and
running
for
container
da.
We
use
like
ps
and
same
way
docker.
J
If
docker
was
running
on
here,
it's
either
docker
or
container
d,
but
that's
the
demo
for
mpd.
If
anybody
has
any
questions
feel
free
to.
Let
me
know
this
is
like
a
very
minimum
minimal
products
that
we
have
we're
planning
to
add
more
features
as
we
go.
J
So
mpd
is
more
of
just
a
detector.
It
doesn't
look
into
super
extensive
details
and
stuff
for
now
with
the
things
that
you're
looking
at
the
repair
stuff,
that's
with
our
custom,
plug-in
health,
checker
and
health
checker
will
basically
give
a
config
has
allows
you
to
configure
it
to
either
try
to
auto
repair
it.
But
it
detects
to
see
when
that
critical
service
is
down
and
then
tries
to
bring
it
back
up.
J
There
are
some
other
custom
plugins
that
we're
going
to
have
to
create
for
for
windows,
specific
problems
that
we're
going
to
detect
that
we
know
we
won't
necessarily
be
repairing,
but
it'll,
be
more
of
reporting
to
prometheus
and
those
services
or
people
who
are
actually
using
and
consuming
mpd
and
looking
at
this
data
will
actually
then
act
accordingly.
But
basically
we'll
just
say:
hey
this
note's
unhealthy
and
basically
try
to
stop
scheduling
new
things
onto
it.
F
And
another
question
I
have:
is
it
only
looking
for
problems
in
cubelet
or
any
other
associated
service
like
container
d
or
docker
or
cni
or
so
forth?.
J
Yep,
so
the
newer
version
so
far
we
have,
and
if
you
look
at
github
we
have
we're
monitoring,
cubelet,
we're
monitoring
container
d.
If
docker
is
running,
we
were
monitoring
docker.
J
We
added
qproxy
we're
now
looking
into
windows
defender,
I'm
working
on
that
currently
now,
and
then
we
have
a
few
more
a
bunch
of
other
things
that
are
on
the
list,
so
you
can
take
a
look
in
the
the
design
dock
that
was
posted
last
week
or
so
let
me
see
if
I
can
find
it
and
send
it
to
the
group
within
a
bit,
but
there's
a
lot
of
proposed
items
that
we
want
to
detect.
J
I
know
jeremy
is
also
working
on
porting
over
or
simply
for
a
basic
of
metrics
of
the
metrics.
That's
the
dock.
F
F
So
I
think
this,
that's
a
that's,
that's
an
extreme
version
of
the
setting,
but
I
think
if
this
can
become
even
more
versatile
than
that
one,
I
think
it
would
be
a
really
great
feature
to
have.
C
So,
like
I
don't
know,
if
machine
help,
I
don't
know
how
what
the
extension
model
for
machine
health
checks
are,
but
you're
right
like
you,
could
potentially
use
the
node.
I'm
sure
they've
talked
about
this
right.
I'm
sure
that
the
folks
trying
to
build
machine
health
checks
are
looking
into
this
idea
of
how
to
how
to
use
node
problem
detector.
I'm
just
gonna,
I'm
gonna
search
for
that.
Actually,
right
now,.
E
Technically
for
the
linux
node
problem
detector,
they
integrate
with
the
remedy
system
like
they
have
a
recommendation
system
under
memory
system.
The
recommendation
is
what
I
think
is
being
presented
now.
It
can
be
integrated
into
a
remedy
system
like
a
cluster,
auto
scaler,
or
something
like
that.
That's
how
it
works.
On
the
linux
side,
at
least.
C
I
Also
like
there
are
some
metrics
and
stuff
like
that,
so
as
it
stands
right
now
for
windows,
it's
as
michelle
said
before
it's
very
minimal,
viable
products.
So
a
lot
of
the
features
that
linux
has
are
being
back
forwarded
to
or
ported
over
to
windows,
and
so
all
the
times
and
stuff
like
that
already
exists
for
the
linux
side.
I
F
F
A
more
specific
question
I
have
do
you
also
have
something
like
disk,
auto
cleanup,
for
example,
that
could
be
another
possible
problem,
especially
when
dealing
with
windows
images
and
especially
since
new
windows
layers
are
being
published
every
single
month
due
to
security
concerns,
you
might
end
up
with
dozens
of
unused
images
and
which
would
fill
up
your
entire
disk
so
wondering
if
that
could
be
also
added
as
a
possible
thing
to
to
detect
with
no
problem
detector.
F
I
Let
me
pull
up
the
pr
for
that,
but
these
types
so
we've
been
trying
to
get
feedback
on
like
what
kind
of
things
to
look
for
if
you
do
have
suggestions
and
want
to
contribute,
of
course,
the
design
documents
linked.
There
is
a
good
place
to
put
those
suggestions,
and
you
know,
of
course
you
can
just
implement
it
on
a
second.
Let
me
get
the.
I
The
metrics
and
and
the
pr
has
a
basic
dump
of
the
the
metrics
that
you'll
see.
Some
of
them
are
zeroed
out
because
they're
not
supported
but
like
disk
space
used
and
all
that
is
definitely
there.
C
Is
this
easy
to
like,
if
you're
a
vendor-
and
you
want
to
extend
this
with
your
own
opinionated,
I'm
sure
everybody's
thinking
the
same
thing
right
like
okay,
we've
got
some
specific
stuff
that
isn't
generic.
So
like
what's
the
extension
model,
I
haven't
read
the
cap,
so
I
know
this
is
a
dumb
question,
probably,
but.
I
So
it's
a
good
question,
basically
in
the
config
directory,
there's
like
these
json
files
and
you
can
basically
input
write
some
scripts
for
the
stuff
that
you
want
to
detect
and
you
basically
tell
the
json
file.
Hey
run
the
script
at
whatever
interval
and
success
fail,
depending
on
how
you
want
to
report
that
for
the
scripts-
and
you
know
that
plums
into
like
whatever
these
counters
are
here.
So
you
can
say
I
I
for
the
recovery-
that's
not
as
clear!
I
don't
I
don't.
I
I
would
have
to
come
up
with
so
I
can
write
a
powershell.
I
So
some
of
these
problems
are
detected
with
powershell.
In
fact,
michelle's
current
pr
is
using
powershell.
C
A
A
Guys,
and
so
I
think
that
kind
of
concludes
the
end
of
the
standard,
regularly
scheduled
sig
windows
meeting
and
then
I'll
hand
it
off
to
jay
to
do
after
hours,
where
we
do
kind
of
informal
pair
programming
and
yeah
mentorship.