►
From YouTube: Kubernetes SIG Windows 20210504
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
All
right,
hello,
everybody
and
welcome
to
the
may
4th
iteration
of
the
sig
windows
kubernetes
community
meeting.
As
always,
these
meetings
are
recorded
and
uploaded
to
youtube
so
be
sure
to
adhere
to
the
cncf
code
of
conduct
and
standards.
A
Let's
kind
of
get
into
this
all
right,
let's
see
if
there's
anybody
kind
of
new
to
the
call
who
would
like
to
do
some
introductions
or
anybody
else
who
just
like
to
introduce
themselves.
I
think
I've
seen
pretty
much
everybody
on
the
call,
so
we
could
probably
skip
that
bit
and
go
right
to
some
of
the
announcements.
The
first
big
announcement
here
is
that
enhancement
freeze
is
next
week
it
is
may
13th.
A
The
release
team
has
decided
to
move
up
the
enhancement
deadline
rather
than
pushing
out
the
code
freeze
deadline
for
the
122
release
to
hopefully
give
more
coding
time
for
enhancement
implementation,
so
just
let's
make
sure
to
get
all
the
enhancements
that
we
want
kind
of
up
and
in
there,
after
the
next
announcement,
we
can
go
through
some
of
the
current
enhancements
for
tracking
and
just
make
sure
slayden
is
in
sync
with
everything
that's
going
on,
but
I
did
have
one.
We
did
have
one
other
announcement
that
we
wanted
to
make
today.
B
Hey
mark
sure,
so
pretty
much
over
the
past
quarter,
I
have
not
had
a
lot
of
cycles
to
contribute
effectively
to
sick
windows
and
yeah,
given
certain
changes
in
personal
life,
etc.
I
have
planned
to
step
down
from
the
tech
lead
role
in
sig
windows.
B
It's
been
awesome
working
with
all
of
you
over
the
past
couple
of
years
and
been
super
rewarding
and
enjoyed
it
a
lot.
I
wish
you
all
the
best
of
success
still
planning
to
continue
the
work
on
csi
proxy
and
get
that
to
the
finish
line.
A
Yeah
for
those
who
are
kind
of
newer
to
the
project
deep
was
very
instrumental
in
a
lot
of
the
very
early
initiatives
to
get
windows
workflows
running
on
kubernetes,
the
push
to
to
beta
the
push
to
alpha
or
a
ga.
A
lot
of
the
storage
related
work,
just
kind
of
he
had
us
hands
in
lots
of
different
pieces
early
on,
and
we
really
appreciate
all
of
the
work,
and
I
wanted
to
thank
you
and
hope
that
you'll
continue
working
in
the
project.
Even
if
it's
in
a
little
bit
reduced
capacity.
A
So
with
that,
some
of
the
leads
and
we're
discussing-
and
I
think
current
plans-
and
we
wanted
to
open
this
up
for
the
process
of
the
kind
of
selecting
the
replacement
for
deep
and
we've
kind
of
come
to
the
consensus
that
claudio
baloo,
who
is
also
on
the
call
we
wanted
to
promote
him
to
tech.
Lead
cardio,
also
has
had
a
lot
of
kind
of
long-standing
contributions
in
sig
windows.
A
With
the
you
know,
with
all
the
same
efforts
he's
done
an
amazing
work
over
the
past
to
18
plus
months
to
get
the
test
images
building
in
tree
and
kubernetes
kubernetes
and
which
had
a
huge
impact
in
the
velocity
and
reliability
of
our
test
signal
and
he's
just
kind
of
been
all
around
helping
with
bug
fixes
and
everything.
C
Sure,
thank
you,
although
you
have
already
done
that
for
me.
You
pretty
much
said
everything
that
I
wanted
to
say.
I'm.
A
C
Yeah,
first
of
all,
thank
you
so
much
deep
for
all
your
contributions
and
surely
I
will
have
some
big
shoes
to
fill,
but
hopefully
we
will
still
continue
to
work
on
the
same,
see,
windows,
projects
and
so
on
and
so
forth.
Thank
you
for
the
opportunity
and
chance.
I
have
worked
a
lot
on
the
image
building
processes
and
so
on
and
so
forth.
I
kind
of
got
to
if
I
may
brag
a
little
bit
master
them.
A
Yep
thanks
again
deep
and
claudio
so
for
anybody,
who's
kind
of
unfamiliar
with
the
process.
The
next
steps
here
are:
we
open
it
up
to
a
period
for
either
comment,
or
I
guess,
complaints.
If
anybody
has
any
objections
to
to
the
nomination
and
we
will
be
sending
a
mail
with
announcing
this
to
a
bunch
of
lists,
including
the
kubernetes
sig
windows
mailing
list
and
with
kind
of
instructions
on
how
to
contact
any
of
the
sig
current
leadership
team
here.
A
If
anybody
does
have
any
concerns
about
that,
and
if
not
there's
a
lazy
consensus
period
and
then,
in
a
couple
of
weeks,
we'll
kind
of
make
this
official
so
stay
tuned.
For
that
all
right,
let
I
think
we
can
go
back
to
talking
about
the
current
122
enhancements
for
a
little
bit.
I
think
that
we're
still
tracking
two
enhancements.
D
A
So
the
two
enhancements,
I
believe,
we're
still
tracking,
are
the
host
process
cap
and
that
one
is
more
or
less,
I
think
we're
reaching
consensus
so
that
one
slipped
from
121
the
and
the
implementation
pr
just
didn't
merge
in
time.
There
was
a
couple
of
open
questions
on
the
implementation.
Pr
that
I
think
are
now
resolved,
based
on
a
slack
conversation
so
that
actually
the
implementation
pr
for
alpha
should
be
ready
to
merge
anytime.
A
E
Yeah
sure
so
I
think
what
has
happened
is
tim.
Hawkin
was
asking
for
sort
of
a
heuristic
approach
for
getting
the
logs
rather
than
us
being
explicit
about
whether
we
want
to
get
logs
from
a
file
or
a
or
a
process.
So
I'm
guessing
it's
trying
to
do
that
and
give
it
a
shot.
So
I
I'm
I've
not
had
cycles
to
go
back
and
update
that
cap
to
reflect
the
sort
of
heuristics
that
we
discussed
in
the
pr.
So
hopefully
I
should
be
able
to
get
it
in
and
you
know
tim
should.
A
Yeah-
and
I
think
tim
even
said,
he
is
not
convinced
that
this
is
like
this
isn't
necessary,
but
he'd
like
to
see
it
at
least
attempted
and
if
it
turns
out
to
be
a
bad
idea,
we'll
go
back
to
just
the
original
implementation,
so
hopefully
we'll
get
that
all
merged
and
marked
as
implementable
in
the
next
week
or
so.
A
If
anybody
else
is
planning
on
introducing
any
caps
for
sig
windows
in
this
release
cycle,
please
reach
out
to
myself
slayden,
who
is
the
enhancement
liaison
for
this
release,
and
any
of
the
tech
leads
to
make
sure
that
that
gets
marked
and
tracked
for
this.
F
Release
one
other
thing
I
bring
up
is:
there's
the
psp
pod
security
policy
v
next
kep,
that
has
some
questions
on
open
questions
on
windows
and
tomorrow
we're
to
be
discussing
it
at
the
sigoth
meeting.
So
we
have
there's
quite
a
long
kind
of
back
and
forth
on
a
couple
different
ways
to
achieve
this,
and
if
you
have
any
thoughts
or
opinions
or
strong
feelings,
please
let
them
be
known.
A
G
Yeah
yeah,
I
had
a
thing
so
thank
you,
jay.
By
the
way
for
the
amazing
shout
out.
Since
the
release
team
was
announced.
Last
week
I've
been
selected
as
the
release
note
shadow
and
according
to
discussions,
I
don't
think
we
can
take
up
two
rows
like
the
release
liaison
as
well
as
a
release.
Note
shadow,
so
I
might
not
be
able
to
do
the
release
layers
on
just
like
windows
and
yeah,
so
I
might
just
be
able
to
do
one
role
for
this
release
so
yeah.
G
I
guess
I
had
to
make
that
announcement
in
this
meeting
yeah,
so
I
might
be
able
to
help
you
folks
find
another
liaison,
but
yeah
I
might
just
have
to
do
one.
A
Okay,
that's
good
to
know
yes,
if
anybody
is
interested
in
potentially
either
helping
out
or
just
acting
as
the
sigma
news
release
liaison.
Please
let
us
know.
D
D
Okay
cool,
I
mean
I'm
supportive
of
either
way
slade
and
I
know
you're
new.
So
I
think
picking
your
bandwidth
and
letting
us
know
is
is
great
so,
but
if
you're
gonna
continue
to
stick
around,
then
I'm
gonna
yeah.
I'm
gonna
be
very
happy
to
hear
that
yeah
great,
definitely,
okay,
cool.
D
Do
I
have
a
should
we
go?
Oh
yeah,
so
dan
winship
wrote
a
cap
about
three
four
months
ago
about
the
idea
of
micro
versioning
and
for
the
windows
conformance
stuff.
I
think
we're
gonna
start
ramping
up
on
it
me
and
me
and
perry
are
working
hard
to
talk
to
our
pm
about
getting
some
upstream
cycles
and
I
think
he's
okay
with
it.
D
So
so,
and
you
know
the
idea,
the
question
is:
you
know
like
when
dan
wrote
this
cap,
it
was
about
network
stuff,
but
like
it
was
kind
of
a
cool
idea
right.
The
idea
was-
and
I
think,
windows
sort
of
might
fall
into
this
category
like
there's
just
a
lot
of
ways
to
define
network
security
and
it's
tricky
to
say,
pass
fail,
and
so
he
had
this
concept
of
like
micro
versioning.
So
I
was
like
well.
D
If
we're
going
to
explore
this
idea
of
making
our
own
conformance
definition,
then
I
think
it
would
be
kind
of
cool
to
do
what
this
to
to
to
to
sort
of
look
at
it
a
different
way
than
what
we
currently
look
at.
We
currently
look
at
linux
conformance
as
this
black
and
white
thing
right.
But
what,
if
we
didn't,
look
at
it
that
way,
and
we
actually
looked
at
it
as.
D
Okay
with
people
telling
me
I'm
crazy,
because
because
I
know
this
whole
micro
versioning
thing
is
very
controversial
and
do
we
want
to
think
about
it
more
or.
F
D
Well,
so
the
micro
versioning
thing
for
for
for
from
the
pers
from
dan's
perspective,
and
I'm
kind
of
using
that
term
loosely
here
but
like
from
dan's
caps
perspective
the
way
I
kind
of
define
it
is
like
well,
certain
cni's
support
certain
cni
support.
You
know
named
ports.
They
support
that
as
a
as
a
as
a
as
a
security,
primitive,
you
can
define
a
policy
against
a
name
report.
D
Other
cni's,
don't
support
that,
and
so
right
now
our
current
policy
suite
it
just
fails
if
you're
one
of
those
cni's
that
doesn't
support
that-
and
you
know,
there's
drift
right
between
ovs
and
cilium
and
calico
and
andrea
in
terms
of
what
can
and
can't
be
supported,
based
on
the
underlying
hardware
of
how
the
cni
works,
if
it's
ebpf
or
if
it's
you
know
whatever
so
in
windows,
I
think
that's
that
there's
this
idea
of
a
I
don't
know
if
micro
versioning
is
really
even
the
right
term.
D
Now
that
you
ask
me,
but
like
the
idea
that
like
well
when
we
define
the
actual
conformance
set,
should
we
be
actually
defining
like
okay
windows
supports
active
directory,
we've
got
20
active
directory
tests
and
when
we
run
the
tests
you
know
we
can
give
you
a
green
or
a
red
that
you
support
active
directory
in
terms
of
the
way
we
define
it
for
windows
conformance,
which
is
that
you
can
launch
a
pod
that
has
a
name
that's
injected
from
a
from
an
ad
server
blah
blah
blah
and
and
so
you
either
pass
or
you
failed
that
battery
of
of
tests.
D
But
we
don't
really
define
it
as
pass
fail.
We
define
it
as
we
output
here
are
the
features
that
you
support
and
then
that
winds
up
being
windows,
conformance
right
and
and
as
a
and
so
so
the
output
of
our
tests
is
not
a
pass
or
a
fail,
but
rather
like
a
like
a
matrix,
not
a
bunch
of
ginkgo
sentences,
don't
make
any
sense
right
like
a
higher
level
categorization
of
stuff.
F
Is
adelina
on
the
call?
I
don't
think
she
is.
She
was
looking
into
this
and
okay.
I
think
the
the
new
direction
at
least
there's
some
conversations
happening
in
for
the
performance
test,
where
you
would
have
a
conformance
profile,
which
would
be
a
subset
of
tests
based
on
you
know
the
features
that
you're
trying
to
implement,
and
so
I
don't
have
a
ton
of
information
on
that,
but
this
might
be
kind
of
similar
to
what
you're
looking
for
there.
D
D
D
D
Yeah
I
mean,
I
guess
yeah
I
mean
I
guess
what
we
could
do
is
we
could
that
could
be
what
we?
What
we
do
then
is.
We
could
actually
define
a
windows,
so
we
could
write
our
so
when
we
write
our
definition
or
our
cup
or
whatever.
We
could
write
it
as
basically
saying
look
we'll
define
this,
and
our
goal
is
to
integrate
with
the
conformance
profiles,
work
that
way
we're
not
blocked
on
on
this
graduating.
If
we
don't
want
to
be.
A
All
right
thanks,
I
think
that's
a
good
discussion
to
have
jeremy
did
you
want
to
discuss
node
problem
detector.
H
Sure
so,
basically,
we've
actually
made
a
lot
of
progress
on
on
this
area.
Michelle's
actually
with
me
today,
and
I'd
actually
like
to
give
it
over
to
her.
If
she's
here,
to
talk
about
the
mvp
for
no
problem
detector.
I
Yeah,
I'm
here
hello.
Most
of
you
don't
know
me.
I
am
with
google
off
about
five
months
now,
so
I've
been
working
on
the
node
problem,
detector,
for
windows
and
for
windows.
We
have
a
few
critical
services
that
are
we're,
checking
right
now,
docker
cry,
cuddle,
container
d,
we're
planning
to
add
some
more
health
checks
as
we
go.
I
We
have
kind
of
a
proof
of
concept,
ran
on
our
own
windows,
nodes
ran
locally
and
I
think
jeremy's
working
towards
building
out
the
the
release
for
mpd,
and
so
basically
we're
just
trying
to
let
you
guys
know
that
this
is
the
progress
we're
making.
This
is
what
we're
doing
it's
exciting
news
that
we're
actually
seeing
things
being
caught
and
being
reported
to
the
exporters,
and
if
anybody
has
any
thoughts
or
any
issues
that
they'd
like
to
see
covered
or
detected
by
mpd
by
all
means
we
are
open
for
feedback.
I
We
are
also
open
to
collaborate
with
any
of
you.
If
you
are
all
interested
at
all
in
working
on
this,
we
have
like
some
high
level
plans
of
what
we
want
to
do
and
what
we
want
to
continue
integrating
with
mpd.
I
So
if
anybody
has
any
questions
with
that,
we
would
definitely
be
willing
to
meet
up
and
talk
and
chat
more
about
the
details.
Does
anybody
have
any
questions
for
from
that
so
far?
I
know
it
was
brief,
or
does
anybody
have
any
questions
about
no
problem
detector
itself,
or
can
I
assume
everybody
here
is
kind
of
familiar
with
it.
F
A
Yeah
I
had
thought
at
one
point:
there
was
a
document
that
I
believe
jeremy
started,
that
was
outlining
a
lot
of
the
or
that
we
were
using
to
collect
feedback
for
what
types
of
like
problems
that
we
want
to
detect.
Let
me
try
and
find
that
again,
and
we
can
add
that
to
the
agenda
here,
because
I
have
some
ideas
of
things
to
look
for,
but
I'm
not
entirely
sure
what
the
current
set
is.
So
I'll
hold
some
comments
until
after
I
review
that.
I
For
sure,
are
you
talking
about
the
node
detector
problem
for
windows
with
the
summary
motivation?
All
I
would
not
yeah,
I
think
so.
F
Tyler
you
you're
on
slack.
We
can
coordinate
for
maybe
a
demo
next
week
or
whenever
appropriate,.
A
Yeah,
I
see
okay,
jeremy
linked
the
doc.
Let
me
do
this.
Keiko
did
ask
she'd
like
to
understand
more
on
the
note
detector.
Do
you
want
to
dive
into
that
a
little
bit
now
for
the
rest
of
the
meeting
or
james?
Oh,
I
see
you
added
an
agenda
item.
I
I
can
give
like
a
quite
a
high
level
over
detail,
and
then
we
can
go
into
more
details,
keiko
a
little
bit
later,
but
basically
no
detector.
The
no
problem
detector
is
a
windows
service,
that's
running
on
a
node,
a
windows
node
and
it's
scanning
for
problems
and
issues
that
are
going
to
determine
this
node
to
be
unhealthy
and
the
goal
is
basically
to
stop.
I
You
know:
scheduling,
pods
or
stop
scheduling
new
things
on
a
node,
that's
corrupt
or
unhealthy.
There's
also
a
few
different
kind
of
segways
for
like
plug-ins,
where
we
detect
something
is
down
and
we
try
to
actually
restart
it.
For
example,
like
docker
credit
cuddle
container
d,
those
are
one
of
the
ones
that
we
detect
and
see.
Okay,
can
we
restart
and
see
if
we
can
mitigate
having
to
mark
this
node
as
unhealthy?
So
that's
kind
of
essentially
what
it's
doing.
I
I
am
kind
of
compiling
another
dock
of
use,
cases
that
we're
going
to
try
to
get
ready
for
public
public
use
public
viewing
for
people
to
actually
take
a
look
and
add
their
thoughts
and
and
see
what
we
want
to
actually
detect,
and
so
we
want
to
make
sure
we're
detecting
issues
that
will
determine
this
node
as
unhealthy,
if
that
makes
sense,
caico
yeah.
No.
I
This
is
great
because,
like
that's
one
of
the
things,
that's
missing,
I've
worked
on
the
linux
side,
but
like
never
on
the
windows,
so
this
is
cool
like
definitely
thank
you
for
the
documentation
too.
A
Yeah,
there's
there's
a
lot
of
kind
of
details
in
that
doc.
So
that'd
be
good
for
everybody
to
review,
but
I
think
yeah.
We
could
use
this
to
eventually
start
detecting
performance
problems,
setting
thresholds
for
certain
performance
counters
that
cluster
operators
would
care
about,
and
all
of
that
after
we
kind
of
tick
off
all
the
basic
requirements
like
make
sure
the
services
are
running,
the
windows
features
are
installed,
there's
no
updates
and
all
that
goodness
yep
thanks
a
lot
for
this
work.
A
And
I
think
yeah
as
mentioned
here,
this
is
an
area
that
if
anybody
is
interested
in
getting
and
helping
to
contribute,
there's
I
think
a
lot
of
work
and
this
is
fairly
well
scoped
and
defined.
So
this
might
be
a
great
place
to
start
getting
some
contributions
or
start
contributing
for
sig
windows.
A
All
right
with
that
james,
do
you
want
to
take
or
discuss
this
next
item.
F
Yeah,
so
at
the
end
of
release
121,
we
had
a
just
a
short
slack
conversation
around
some
of
the
release
informing
tests,
and
I
just
wanted
to
bring
it
back
up
and
see.
If
we
wanted
to
do
anything
about
this.
F
We
have
there's
quite
a
few
of
the
gce
tests
on
there,
which
are
are
in
much
better
shape
than
they
were
initially
thanks
to
a
lot
of
good
work
that
jeremy
and
folks
have
done,
but
the
it
was
kind
of
proposed
to
potentially
move
the
some
of
the
aks
engine
tests
onto
the
release
forming
dashboards.
This
wouldn't
necessarily
remove
any
tests.
F
They
would
all
still
be
on
our
all
of
our
dashboards,
but
there's
been
just
a
little
bit
more
activity
on
the
aks
engine
tests
and
they're
a
little
bit
greener
right
now.
So
I
just
want
to
bring
that
up
and
see
if
anybody
had
any
thoughts
or
objections
to
transitioning
to
some
of.
A
Those
yeah,
I
think
some
of
the
outcomes
of
the
discussion
were
that
the
some
of
the
aks
engine
tests
tend
to
be
investigated
a
little
bit
more
promptly
than
some
of
the
gce
ones.
So
it
might
make
sense
to
keep
those
as
the
release
and
forming
tests.
Since
that's
where
the
release
team
looks
at
at
the
near
the
end
of
the
release
cycle,
and
as
james
mentioned,
we
wouldn't
be
changing
the
frequency
or
set
of
tests
that
run
anywhere
just
which
ones
are
presented
as
a
signal
to
the
release
team.
A
A
A
J
Thank
you.
So
I
just
want
to
double
check
the
container
d
status,
because
what
I
see
for
gc
entry
driver
it
does
not
work
on
container
d.
J
A
Problems,
one
of
them
is
for
smb
shares,
and
that
was
with
the
the
way
the
paths
were
constructed
and
those
need
to
have
a
trailing
slash
for
anything.
That's
a
physical
disk.
There
is
another
issue
with
container
d
that
we
there's
some
devs
in
the
container
d
project
that
are
working
to
address
that
and
I
believe
that
there's
an
issue
that
is
almost
has
consensus
in
getting
merged,
see
james
just
linked
into
this.
A
This
might
be,
this
will
hopefully
address
the
issue.
We
are
still
seeing
this
with
the
azure
disk
tests
on
container
d
as
well,
and
this
fix
determined
needs
to
be
addressed
in
container
d
itself,
and
that's
where
this
pr
is.
A
I
mean
yes
and
no
that
which
container
runtime
to
use
for
windows
notes
is
really
determined
by
whoever
is
setting
up
the
cluster.
I
don't
think
we
have
said
forcing
windows
to
use
one
or
the
other.
I
think
we've
said
that
most
of
that
that
both
work
with
a
couple
of
caveats
and
this,
the
azure
or
I
guess
any
persistent
disc
csi
driver-
was
called
out
as
an
issue.
That
is
an
issue
here.
So
if
you're
not
using
this,
then
I
think
you're
fine
to
use
container
d,
but
I
I
don't
know
if.
A
A
At
this,
take
a
look
at
this
issue
and
see
if
this
looks
like
it
will,
if
it's,
if
it's
the
same
issue,.
I
Sure
so,
for
this,
like
pri,
what's
blocking
us
from
releasing
this,
except
for
this
conflict,
that's
actually
here
for
the
go.
A
I
am
not
entirely
sure
what
the
process
is
for
getting
pr's
merged
in
the
container
d
project,
so
that
would
be
up
to
any
of
the
maintainers
from
that
project.
To
comment
on
that,
it
looks
like
it's
got
all
of
the
approvals.
A
I
don't
know
if
they
have
some
some
of
the
same,
like
ci
bots.
That
will
just
merge
this
once
the
merge
conflicts
are
gone
or
if
somebody
needs
to
manually
merge
it,
but
it
looks
like
there's
activity
and
reviews,
so
I
would
hope
that
this
will
get
merged
pretty
soon.
A
J
A
F
Sounds
good
so
this
will
end
our
normalcy.