►
From YouTube: Kubernetes SIG Windows 20210817
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
A
Let's
just
get
started
does
any
we
can
do
some
introductions
if
any
folks
wants,
I
haven't
been
a
lot
of
people
or
like
we
haven't,
had
a
lot
of
use
for
this
section
of
the
meeting
notes.
So
if,
in
the
future
we
don't
might
consider
dropping
this
and
just
seeing
what
happens
going
forward
with
that.
A
But
I
don't
see
too
many
new
folks
on
the
call,
so
we
can
just
go
right
into
announcements.
I
don't
have
any
other
announcements
for
today.
If
anybody
has
any
announcements,
please
raise
your
hand.
A
A
B
So
we
had
a
report
a
while
back
that
when
the
metrics
summary
endpoint
gets
called,
there's
a
context
deadline
exceeded
and
we
this
was
reported
a
few
different
times.
There's
a
couple
different
scenarios
where
this
this
happens,
but
it
we
thought
we'd
fix
it
with
bumping
up
the
priority
of
cubelet
and
q
proxy
and
some
other
services
like
that,
and
it
did
seem
to
eliminate
it
for
the
most
part.
B
But
we
still
got
a
report
of
it
and
I
was
looking
into
it
a
little
bit
further
and
added
some
more
metrics
and
I
was
able
to
reproduce
it.
It
doesn't
happen,
it's
very
hard
to
reproduce,
but
essentially
what
I
found
was
that
if
there's
multiple
concurrent
calls
to
the
stats
endpoint,
it
can
one
of
those
calls
can
kind
of
hang
out
and
take
a
fairly
long
period
of
time
to
return.
B
In
most
cases,
it's
only
at
over
a
minute
to
maybe
two
minutes
and
some
really
some
really
long
cases.
It
can
be
much
longer
than
that,
and
so
I
started
looking
into
this
further
and
the
metric
server
has
a
60
second
timeout
and
when
the
metric
server
calls-
and
it
takes
over
that
minute,
it
the
metric
server
times
out
and
then,
when
you
do
cube,
cl
ctl
top
nodes.
B
You
don't
get
those
metrics
back
for
that
node
for
that
time
period,
and
this
also
happens
if
you're
using
hp
as
you'll,
also
see
this
kind
of
manifests
itself.
The
hpa
can't
query
the
metric
server,
because
the
metric
server
doesn't
have
the
metrics
for
those
logs
and
then
your
stuff
doesn't
scale.
B
So
I
started
looking
into
the
code
a
little
bit
further
and
that's
when
I
opened
up
a
few
of
those
other
issues
there
there
happens
to
be
in
docker
shim,
and
this
actually
is
the
case
for
container
d
as
well.
There
we
make
two
separate
calls
to
hcs
stats
endpoints
for
the
containers.
B
I
think
we
used
to
go
through
docker
and
then
we
went
back
and
go
directly
to
hcs
when,
when
that
happened,
we
also
clicked
network
stats
on
a
separate
part
of
that
call,
and
so
we
actually
open
up
the
containers
twice
and
then
call
the
stats
on
those
twice,
which
adds
quite
a
bit
of
cpu
load
to
the
the
system.
When
I
removed
that
I
saw
about
a
40
increase
in
see
our
40
decrease
in
cpu,
and
so
so
I
went
to
go.
B
Try
to
fix
that
and
I
noticed
that
container
d
doesn't
have
network
and
network
stats,
and
this
is
because
the
network
stats
for
container
d,
so
container
d
creates
a
container
and
the
v2
hcs
shim
api.
B
And
when
we
query
for
metric
stats
for
the
network
stats,
we
use
the
v1
api,
and
so
you
don't
get
any
stats
coming
back
for
those
containers,
and
so
what
I
did
was
went
back
to
hds
shim
and
exposed
out
the
the
network
stacks
and
then
white
and
plumb
them
in
to
a
pr
that
I
have
open
yeah.
B
It's
that
work
in
progress,
one
I'm
waiting
on
a
release
of
hcs
shim,
which
should
come
out
this
week,
and
then
I
was
gonna,
remove
what
we're
gonna
bender
in
the
new
hcs
shim
and
then
go
ahead
and
I'll
rebase
this
pr
one
other
thing
I
did
here
was
when
I
was
testing
the
the
metric
stats.
B
I
ran
a
couple
four
to
five
concurrent
calls
to
the
metrics
endpoint
at
the
same
time,
and
this
can
happen
because
the
the
eviction
component,
we'll
call
it
the
metrics
endpoint
that
the
metric
server
might
call
it
and
then,
if
you
have
any
logging
components
in
our
case,
it
was
azure.
Container
insights
also
call
it.
You
get
three
or
four
of
these
stacked
up
on
top
of
each
other
and
what
happens
is
within
the
docker
shim
case.
B
Docker
shim
opens
up
the
named
pipe
for
everyone,
and
so
it
causes
a
right
to
the
file
system
which
causes
a
higher
cpu
during
that
time
period,
and
it
exponentially
goes
up
as
you
make
more
calls
to
this
stats,
endpoint
or
there's
other
actual
things
happening
on
the
system.
So
if
there's
other
containers
starting
or
stopping-
and
you
make
a
call
to
this
end
point
it-
it
exponentially
goes
up.
So
the
other
thing
I
did
was
I
refactored
the
the
metric
endpoint
to
not
make
any
docker
calls.
B
We
weren't
collecting
any
extra
information
there
that
we
didn't
already
have
and
so
yeah.
So
that's
that's
kind
of
a
summary
of
all
the
things.
It
was
kind
of
a
little
rabbit
hole
as
I
went
through
through
it.
But
if
you
ever
take
a
look
and
get
some
feedback
be
useful,
I
don't
know
if
other
folks
are
also
seeing
this,
but
I
wanted
to
just
bring
it
up
here
and
share.
What's
been
going
on.
A
C
I
haven't
seen
it,
but
I
haven't
done
a
lot
of
extensive
testing
of
hpa.
To
be
honest,
so
it
might
be
something
that
I
might
have
a
little
bit
of
a
play
with
just
see
see
what
I
spot.
A
Yeah,
as
james
mentioned,
like
at
least
over
in
azure,
we
were
seeing
this
quite
a
bit
and
then,
when
we
did
start
setting
the
the
press's
priorities
for
the
the
cubelet
that
did
help.
But
we're
still
seeing
this
under
kind
of
a
lot
of
system
pressure.
B
D
B
This
this
so
it
doesn't
because
the
the
call
to
collect
stats
for
the
hcs
v2
api
doesn't
return
stats
at
all
and
v1
for
hcs
stats.
It
did,
and
so
we
have
an
internal
bug
to
to
fix
that
the
that's
going
to
become
important
when
we
go
to
the
cryo-only
stats.
B
But
in
the
meantime,
by
using
by
exposing
these
stats
through
hns,
we
will
get
those
stats
exposed
until
that
that
until
we
were
able
to
cut
over,
which
is
probably
still
a
couple
releases
away.
So.
E
Yeah,
I
haven't
noticed
yeah
issues
with
timeouts,
but
yeah
one
point
to
confirm
is
yeah
the
network
stats.
So
I
noticed
this
with
container
d
versus
docker
that
yeah
the
summary
endpoint
doesn't
return
any
additional
network
stats.
So
it
would
be
great
yeah
when
we
get
this
fixed.
A
I
also
mentioned
that
I
did
see
the
cri.
Only
stats
was
added
to
the
signate
agenda
today
to
discuss
some
issues.
I
think
on
linux,
they're
having
issues
with
some
file
system,
stats,
I'll,
try
and
kind
of
mention
this
as
well-
that
this
will
help
that
moving
to
the
crm
stats
will
definitely
or
should
definitely
help
with
windows
performance.
A
We
have
one
very
basic
test
that
I
believe
I
added
a
while
ago
when
we've
tried
to
fix
this,
when
we
tried
to
fix
the
stats
timeouts
hanging
in
like
1
17
118
time
frame,
and
what
that
test
does.
Is
it
just
creates
a
number
of
containers?
I
think
it's
like
10
containers
in
parallel
and
then
queries
the
metric
endpoint
a
number
of
times
and
checks
to
see
if
the
average
duration
of
that
call
is
below
a
certain
threshold.
A
F
D
Regarding
stats
collection,
there
is
one
use
case
that
they
are
actually
pulled
and
used,
for
example,
pod
horizontal,
auto
scaling
in
which,
basically,
if
the
cpu
switch
goes
over
a
threshold,
the
pods
should
increase
in
number
or
decrease
accordingly,
but
I'm
those
are
not
conformers.
So
I
don't
think
all
the
jobs
are
running
them.
A
Yeah
we
marked
that
as
serial
because
we
were
seeing
when
we
were
running
it
as
part
of
the
daily
test
pass.
Sometimes
there
wasn't
enough
space
on
it
on
one
of
our
test
nodes
to
schedule,
10
containers
in
parallel,
so
we
just
marked,
and
so
we
were
seeing
test
flakes
with
the
timing
out
waiting
for
all
the
containers
to
start,
but
we
do
exercise
that
regularly
in
our
ci
jobs
under
the
serial
slow
test
pass.
B
It's
a
good
thought
to
maybe
see
if
I
can
come
up
with
some
sort
of
test.
Mm-Hmm.
C
I
was
gonna
say
it
would
be
quite
cool
to
just
like
at
least
know
we're
getting
each
like.
We
could
have
a
test
that,
like
said,
checks
would
get
in
cpu
for
the
pods,
whether
we're
getting
memory,
whether
we're
getting
disk
usage
network.
Obviously,
when
it's
there
things
like
that,
and
then
that
way
at
least
we
can
just
see
that
a
result
is
returned,
that's
expected
and
not
just
zero
on
it
on
them
or
something
yeah.
B
Dude
I
added
there's.
There
is
one
test
that
does
some
like:
like
sanity
checking
it.
Doesn't
it
just
make
sure
that
there's
a
value
there,
and
I
added
that
for
the
the
log
collection
metrics
that
that
are
there
that
I
added
in
120,
I
think,
and
so
maybe
we
can
extend
that
a
little
bit
more
extensively
to
like
catch
the
network
tests
make
sure
we
don't
drop
those
again.
F
I
think
it's
just
deserializing
what
we
already
have,
but
I'm
not
sure
if
anybody
wants
to
dig
in.
I
feel
like
this
might
be
a
great
getting
started
issue
for
the
e2es
for
windows.
Right,
I
don't
know
like.
Basically,
it
would
be
like
investigating
our
test
coverage
of
metrics
I'll
write
it
up.
So
it's
like
a
good
good
first
issue.
A
D
And
I
can
help
with
that,
if
needed,
I
did
some
time
ago,
basically
a
matrix
collection
for
create
integration,
testing
container
d,
including
for
windows,
so
I
can
basically
copy
paste
that
code,
if
needed.
Now
it's
testing,
cpu
and
memory,
and
so
on.
A
All
right,
I
guess
that's
some
really
good
investigations
and
really
good
exploratory
work
here.
Is
there
anything
else
to
discuss?
Otherwise,
we
can
move
on
to
a
couple
more
of
the
agenda
items.
A
So,
let's
do
that
next
one
is
a
test
flight
that
we've
been
seeing
occasionally
and
during
the
last
iteration
of
the
backlog
refinement
we
decided
to
bring
it
up
to
the
community
meeting
because
we're
seeing
this
kind
of
consistently.
So
I
wanted
to
discuss
this
here
so
there's
an
issue
in
the
the
test.
Job
pods
should
delete
a
collection
of
pods
on
windows
and
there's
a
bunch
of
comments
here
that
I
try
to
investigate
this.
A
lot.
D
Yes,
basically
one
idea
so
looking
through
the
issue.
D
Basically,
I
noticed
that
that
test
in
particular
is
spawning
three
pods
and
immediately
release
them
like
in
a
matter
of
milliseconds
apart,
but
in
the
way
cubelet
works.
It
goes
through
with
the
plot
creation
and
including
all
the
necessary
steps,
including
image,
polling
and
so
on
and
so
forth.
D
So
that
got
me
thinking
for
a
little
bit
what,
if
you
actually
spawn
a
pod,
and
you
just
decide
to
delete
it
afterwards
and
especially
if
it's
a
part
which
would
use
a
really
huge
image,
you
would
still
want
to
cancel
that
context,
and
that
request,
though
you
don't
want
it,
you
wouldn't
want
it
to
continue
to
pull
a
few
gigabytes
of
data
just
to
get
it
afterwards,
but.
D
D
Apparently,
there's
there
has
been
quite
a
lot
of
flakes
from
what
they
saw
in
kubernetes
when
it
comes
to
racing
events
between
creation
and
deletion
of
pods.
So
this
might
be
something
that
they
don't
particularly
want,
but
it
might
be
useful
for
us
at
the
very
least,
since
we
tend
to
have
bigger
images.
A
Yeah
that
makes
sense.
We
should
let
me
tag
signal
down
here
and
then
we
should
also
bring
this
up
with
sig
node.
A
I
don't
think
that
I,
I
don't
really
remember
ever
hearing
discussions
about
that
behavior
before
so
I
don't
know
if
that,
if
there's
good
reason
for
not
canceling
that
from
the
signoid
folks,
but
I
think
that's
the
next
place
to
to
do
that.
Is
anybody
else,
seeing
issues
kind
of
similar
to
this
or
testing
or
would
have
any
use
cases
that
would
test
this,
or
does
anybody
see
a
reason
why
we
would
not
want
to
cancel
the
context
of
starting
the
container
in
situations
like
this?
A
D
Yeah
no
problem,
I
can
only
tell
from
my
experience
it
happened
a
couple
of
times
to
wrongfully
pull
a
wrong
image
when
I
wanted
to
spawn
another
container,
and
I
had
to
wait
for
it
to
finish.
A
A
Yeah,
okay,
yeah:
let's
I'll,
try
and
get
signate
involved
in
this
discussion
too.
All
right,
I
think
I
saw
our
evan.
She
was
adding
a
couple
of
things
here.
G
G
So
david
eats
was
telling
me
that
we
should
add
like
a
blurb
or
something
in
this
section,
or
at
least
that's
what
I'm
thinking.
We
should
do
like
add
a
node
inside
projected
volumes
stating
how
it's
working
today
or
not
working
today
with
windows,
pods
and
then
also
point
it
out
here
that
there
could
be
an
issue
with
protected
volumes
or
windows.
I'm
just
wanting
to
know
what
what
you
folks
think
about
it,
or
is
there
a
fix
for
this
the
horizon?
A
Yeah,
I
don't
think
I
think
you
were
out
when
we
discussed
this
last
week.
We
don't
have
a
fix
in
the
horizon
are
coming
in
the
horizon
and
we
did
kind
of
decide
that
the
best
thing
to
do
would
be
to
document
this.
I
was
don't
remember
if
we
decided
to
document
this
on.
You
know
the
kubernetes
dot
io
docs
only
or
in
some
of
the
microsoft
like
msdn
docs
brendan.
Is
this
something
that
you
could
help
irvin
with
us
figuring
out
where
we
want
to
document
this
issue.
H
G
G
A
G
I
So
what
will
happen
when
you
do
them?
Is
you
just
hit
the
link
and
then
just
do
it
in
the
browser,
like
whatever
changes
you
want
to
make
and
then
it'll
go
into
review
and
it'll
happen
pretty
fast,
typically,
okay,
yeah.
G
So
what
I'll
do
is
I'll
I'll
write
up
a
pr
for
like
in
some
in
maybe
the
wmc
openshift
repo
just
so
that
we
have
a
place
say
that
this
is
the
stuff
that
I
want
to
add,
and
then
I
can
work
with
brandon
to
figure
out.
Okay,
this
part
goes
into
the
microsoft
docs.
This
part
goes
into
the
kubernetes
docs
and
I'm
I'm
fine
writing
helping
write
up
all
that.
J
G
E
B
A
Yeah
as
one
container
user,
if
you
mount
like,
add
a
host
mount
and
then
try
and
access
and
then
know
where
to
navigate
to
the
other.
To
these
projected
volumes
are
on
the
host.
I
believe
that
that
container
user
can
see
the
projected
volumes
from
other
container
users,
but
if
you
block
host
mounts
you
can't
just
like
magically
hop
over
to
the
other
containers
projected
volumes,
you
need
to
search
for
it
yeah.
My
understanding.
G
Yeah,
the
only
the
only
the
only
thing
we
need
to
make
sure
is
because
of
the
way,
because
of
the
fact
that
we're
not
applying
the
correct
permissions
on
on
a
user
basis
for
these
files.
Is
there
something
that
we're
missing
here
that,
even
without
mounting
the
host
path?
Are
we
running
into
some
some
trouble
here.
A
A
So
if
you
start
multiple
containers
with
the
as
like
as
the
same
well,
even
as
different
users,
when
you
try
and
pop
out
of
the
container
and
access
host
resources,
those
all
look
like
the
same
user
to
the
like
to
the
containers.
So
and
that's
where
this
is
a
little
bit
complicated
and
there's
no
easy
fix,
is
that
there
is
no
right
now
that
we
don't
have
the
mechanisms
in
windows
to
say
if
you're
running
in
a
container
as
this
user.
G
B
G
A
Yeah
continue
to
missing
a
direct
conclusion
all
right
folks,
I
need
to
hop
over
to
sig
node
now
discussing
caps
and
everything,
so
I'm
gonna.
Do
that
I'll
hand
it
over
to
jay
and
james
if
we're
doing,
if
you
guys
are
all
doing
pairing
today,
bye
and
thank
you,
everybody
see
ya
participating.