►
From YouTube: Kubernetes SIG-Windows 20230808
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
get
started,
I
think
I've
been
out
for
over
a
week,
not
really
sure
what
the
status
of
everything
is
so
James.
It
looks
like
you're
ending
in
some
announcements,
yeah
the
128
releases
next
week
and.
A
A
Nope
all
right
next
is
include
some
space
if
there's
any
new
contributors,
but
it
looks
like
everybody
on
the
call
is
what
we've
seen
before,
but
I
can
still
pause.
If
there's
anybody
who
wants
to
introduce
themselves
or
say
anything.
A
C
Might
be
very
important,
so
prameters
here
we
have
this
we're
doing
some
metooie
stuff.
This
isn't
a
major
announcement
or
anything,
but
the
operational
Readiness
stuff,
where
we're
at
is
pramita,
has
sort
of
discovered
a
couple
of
kinks
in
the
host
Network
host
paths-
sort
of
stuff.
C
For
some
of
these,
some
of
the
e2es
that
she's
fixing
and
we
got
some
feedback
from
Sig
tests
last
week.
So
we're
gonna
have
to
do
some
broader
refactoring
inside
of
the
e2e
testing
repo.
Before
we'll
be
able
to
run
more
of
the
Sig
Network
tests
on
windows,
so
I
I
was
kind
of
excited
about
the
fact
that
we
uncovered
all
that
stuff
and
so,
but.
C
A
C
So
if
we
can't
then
well,
then
we're
just
going
to
have
to
make
some
tests
explicitly
not
run
in
Windows
that
do
things
with
host
networked
pods
right
so
yeah.
So
that's
the
discovery
that
we
stumbled
into.
A
C
The
other
issue
is
that
one
of
the
things
she
noticed
was
that
the
old
Sig
Network
tests
that
we're
trying
to
get
running
for
the
operating
of
stuff-
actually
they
used,
can
replication
controllers
instead
of
deployments
and
so
she's
like
we
should
fix
that
and
then,
when
she
started
fixing
it
it's
interesting
story
like
she
fixed
it
and
then
well
typical
thing
right.
Someone
else
was
like
actually
this
library
that
makes
deployments.
We
should
have
deprecated
that
a
long
time
ago,
so
there's
some
old
code
inside
of
YouTube.
D
Just
don't
leave
us
yeah,
they
suggested
to
use
actual
framework
code
that
uses
the
deployment.
So
we
kind
of
like
use
we're
going
to
use
that
code,
not
the
one
that
I
was
using.
So
we
raised
that
bug
also
that
yeah.
This
is
the
old
code
and
we
should
not
be
using
that.
C
B
C
A
C
A
A
D
One
One
Thing
Mark,
like
today,
I
have
like
the
one
of
the
bugs
that
we
raised
was
marked
as
a
Sig
Windows
buck.
So
I
have
commented
whatever
I've
been
doing
on
that.
So
just
have
a
look
on
that
I
think
that's
there
in
the
track,
the
track
sheet
that
you
create
tracking
the
issues.
D
Yeah
I
think
I'll
just
fix
it
then
I
mean
I,
have
I've
commented,
whatever
I
have
I
have
done
till
now,
but
yeah
further.
If
I'll
see
anything
I'll
just
have
a
word
with
you,
yeah
okay
sounds.
A
Good,
can
you
drop
something?
Do
you
want
to
link
to
the
either
Jay
for
me?
Can
you
link
to
that
bug
in
the
agenda
too,
so
we
can
go
and
reference
it
again.
E
So
there
is
update
from
my
site
too.
I
am
also
working:
okay
on
end-to-end
test
on
store,
like
storage
test,
so
like
so
basically
like
in
in
Ops
Readiness
repo.
There
are
only
four
storage
tests
at
the
moment
and
some
some
of
them
can
be
enabled
for
Windows
by
just
adding
a
Windows
selector
tag
yeah.
That
change
is
easy,
but
one
of
the
test
like
actually
is
executing
commands
on.
D
E
Itself,
which
is
like
line
so
that
code
is
executing
Linux
commands
on
node,
so
for
that
I
think
changes
are
bigger,
like
so.
I
was
just
wondering
like
if
we
need
to
create
a
replica
of
that
whole
test
just
for
Windows
or
how
should
we
proceed
with
them?.
A
Some
of
the
storage
tests,
Jay
I,
think
we
should
probably
look
and
see
how
different
they
are.
Is
it
a
lot
of
setup
that
happens
and
then
the
tests
like
in
a
is
it
like
a
privileged
container
or
something,
and
then
the
tests
are
under
not
or
and
then
the
tests
run
or
is
the
kind
of
the
code
that's
executing
on
the
Node
interspersed
throughout
the
tests?
So.
E
A
Which,
if
you
have
a
busy
box
windows
image
that
I
think
I
think
cardio
can
character
from
wrong,
but
I
think
it
supports
all
the
tools
in
BusyBox
but
they're,
basically
other
it's
they're,
not
all
the
same
tools,
but
there's
like
the
binary
that'll
do
the
same
thing
in
there.
F
Yeah
we
do
we,
we
do
have
a
BusyBox
image
for
Windows
and
that's
been
working
for
a
couple
of
years.
It
doesn't
have
all
of
the
opportunities
of
the
Linux
busy
box,
but
it
has
the
most
common
ones
and
you
should
have
most
of
them.
Typically,
the
ones
you
could.
You
know,
because
that's
because
that
they're
not
included,
would
be
mostly
a
complex
networking.
Networking
operations
and
foreign.
F
E
I
think
they
are
using
test
framework,
but
I
saw
like
still
like
the
image
was
not
getting
deployed
deployed
on
Windows
node
like.
F
One
thing
when
it
depends
if
it's
a
hard-coded
BusyBox
image
like
the
docker
dot,
IO
BusyBox
image-
that's
going
to
be.
You
know
it's
a
basically
manifest
list
which
only
contains
Linux
images.
Then,
of
course
it
won't
be
able
to
spawn
on
Windows
If.
Instead,
it's
using
the
kubernetes.
F
Slash
images
busy
box,
which
is
listed
there.
It
is
going
to
work
because
we
have
created
a
manifest
list
which
includes
Finos
images
and
published
it
there.
So
that's
what
image
is
currently
in
use.
Let
me
just
send
a
link
to
that
image
and,
what's
being
used,
give
me
one.
Second,
please,
foreign.
F
F
Yeah
so
pasting
in
chat.
Basically,
that's
the
BusyBox
image,
which
is
most
typically
used
in
the
kubernetes
e-tweetest,
for
which
we
also
have
Windows
images
as
well.
You
can
actually
find
the
image
Docker
file
here,
which
is
being
built
regularly
whenever
a
new
push
is
being
sent
to
the
test
images.
Busybox
folder,
which
is
here.
A
F
E
F
Problem,
oh,
and
also
by
the
way
you
can
see
in
this
Docker
file,
you
can
actually
see
all
the
commands
that
we
actually
have
in
the
windows
busy
box.
E
Yeah,
so
so
yeah
so
container
image
was
first
telling.
I
will
take
a
look.
Maybe
this
will
solve
that
problem.
Another
thing
was
the
commands
which
were
getting
executed
on
host
and
those
those
plants
are
mostly
related
to
mount
like
since
the
Tesla
related
to
storage,
so
they
are
mounting
some
volume
or
something
and
then
checking
if
it
is
getting
yeah
if
it
is
available
in
in
pod
or
not
some
those
kind
of
stuff
so
like
those
commands
are
for
Linux.
Maybe
we
need.
E
F
Yeah,
that's
a
good
point
among
comments
are
typically
Linux,
specific
and
yeah.
That
was
the
other
category.
That
I
was
forgetting
yeah,
that's
a
good
point.
If
it's
among
commands
there
should
be
a
Windows
equivalent,
which
should
be
rated
and
passed
in,
but
yeah
networking
and
volumes
typically
are
very
little
specific.
F
Yeah,
that
sounds
good.
Typically,
you
should
have
you
know
the
the
command
argument
for
the
pods
for
the
containers,
which
could
be
set
conditionally,
based
on
whether
or
not
it's
being
run
on
Windows
or
not.
Typically,
the
test
framework
receives
an
argument
to
know
which,
on
which
OS
the
tests
are
being
run
on.
That's
also
what
we
are
passing
in
in
our
CIS.
F
And
basically,
in
the
E3
framework
you,
you
actually
have
a
function
which
will
basically
give
you
that
not
those
distro
and,
of
course,
if
it's
Windows,
you
could
run
some
commands.
If
not,
if
it's
not
Windows,
you
could
run
the
regular
commands
or
Linux
or
whatever
other
OS
is
being
run,
but
yeah,
that's
I
think
you
are
on
the
right
path.
With
that
train
of
thought,
yeah.
E
So
yeah,
so
basically
the
point
was
like
so
earlier.
Like
I,
we
were
thinking
that
just
adding
OS
selector
for
test
cases.
That
will
be
enough
to
run
test
case
on
on
for
Windows,
but
but
yeah.
This
test
case
requires
more
than
that,
so
yeah
I
will
look
into
it.
Make
the
required
changes
and
submit
appear.
Another
thing
I
wanted
to
discuss
was
currently
Ops.
Readiness
only
have
four
storage
test
cases.
I
think
that's
not
enough.
We
need
to
increase
the
coverage
there
yeah.
E
So
what
more
test
cases
should
we
include
like
I,
am
going
through
all
the
storage
test
in
common
common
folder
in
end-to-end
test
I
think
some
of
those
tests
can
be
executed
very
simply
yeah.
Should
we
go
ahead
yeah?
This
is
a
question
for
you.
Should
we
include
those
tests
or.
C
I
mean
I,
don't
I
think
that
we
can
do
whatever
we
want
right
like
if
we
change
the
spec.
We
should
just
update
the
cap
and
make
sure
other
folks
are
okay
with
it
right,
like
CC
someone
else
outside
of
our
little
group,
CC
James,
Mark
Arvin,
whoever
Claudio
you
know,
and
you
know
I
think
we
should
just
update
the
cap
and,
you
know
say
Hey.
C
A
A
B
C
Yes,
I
would
say
then
maybe
the
first
step
would
be
co-want
to
maybe
start
a
thread
and
see
Windows
about
this
and
just
and
get
some
consensus.
You
know
and
then
update
the
cap
based
on
the
consensus
and
you
know
and
then
we'll
just
work
towards
that
right.
Yeah.
F
C
E
F
Yeah,
so
typically,
most
tests
in
kubernetes
do
not
have
such
selectors
simply
because
they're
supposed
to
work
on
either
platform
and
I
think
this
is
the
case
for
this
as
well,
so,
basically
how
we
do
how
we
make
sure
that
we're
only
running
those
pods
on
Windows
or
testing,
only
Windows
not
running
on
news,
for
whatever
reason
is
that
retained
the
master
mode,
which
basically
means
that
no
other
pods
will
get
scheduled
there
unless
it
has
a
specific
tolerance
for
that
attained.
E
So
so
yeah,
so
basically,
the
thing
is
like
this
is
need
only
for
eks
I
mean
like
eks,
designed
in
such
a
way
that
Windows
pod
need
to
have
that
selector
because,
like
like,
we
have
some
resource
controller
running,
which
does
some
networking
related
stuff
for
Windows
when
it
file
and
it
that
Source
controller
need
needs
that
OS
lecture
tag.
So
this
is
just
a
requirement
for
eks
Windows,
otherwise,
for
other
Cloud
providers,
they
will
just
work
fine,
but
for
eks
Windows
they
won't.
E
Yes,
yes,
yes,
yeah
I
will
share
a
doc.
I
mean
it's
in
our
public
documentation.
So
currently
like
we
do
at
our
end,
like
we
have
some
internal,
you
know
a
web
hook
which
automatically
changes
Sports
deployment
dynamically
and
that's
how
we
have
been
running
the
test.
But
now
we
wanted
to
enable
it
by
default.
F
That's
interesting
to
know,
haven't
heard
about
this
before,
because
for
Azure
or
Google
or
gke.
We
do
not
need
any
such
labeling
to
actually
run
the
CIS
yeah.
D
Yeah,
so
when
you
run
this
operational
Readiness
on
vsphere,
maybe
but
whole
test
case
run
like
it,
you
can
see
the
reports
and
everything,
but
when
we
were
like
you
know,
shifted
all
together
to
eks,
none
of
the
tests
was
working,
so
that
is
where
we
get
to
got
to
know
that,
yes,
that
that
these
labels
are
needed,
so
so
there
are
like
two
parts
to
it.
D
So
even
we
add
so
some
of
the
test
cases
are
running
because
we
added
the
labels,
but
now
at
the
as
school
one
mentioned
right,
even
we
add
the
tags.
The
labels
we
need
to
you
know
change
how
the
test
cases
behaving
particularly
for
the
windows.
So
there
are
like
two
like
to
it:
yeah.
F
Do
you
have
per
chance
a
hybrid
environment
basically
have
both
Linux
and
windows
worker
nodes
in
the
environment.
F
Though,
if
I
would
be
running
tests
in
that
environment,
I
would
still
change
the
Linux
nodes,
but
I
think
that's
just
me
just
that
case,
but
yeah,
an
admission
controller
can
also
you
know,
enforce
a
node
selector
if
needed.
But
I'd
have
to
think
more
about
this
as
well,
but
yeah
yeah.
A
F
F
I
mean
having
a
hybrid
environment
is
an
interesting
scenario,
especially
since
you
know
should
actually
spawn
pods
and
the
container
images
are
not
necessarily
manifest
lists
which
have
Windows
images.
You
might
have
some
wrong
scheduling
on
the
wrong
node
OS
right.
So
that's
tricky.
F
Yeah
anyways
good
good
thinking
material
for
the
next
time,
I'm
waiting
for
that
dog
you
mentioned
yeah.
E
Just
give
me
when
I'm
trying
to
find
the
the
statement,
maybe
I
can
send
you
offline
in
in
in
Signal.