►
From YouTube: Kubernetes SIG Windows 20200915
Description
Kubernetes SIG Windows 20200915
A
Hello,
everybody
and
welcome
to
another
single
dose
meeting
it's
the
15th
of
september,
as
always,
it's
a
recorded
meeting.
So
please
adhere
to
the
cncf
code
of
conduct.
Next
week
we
will
update
the
zoom
link,
so
you're
going
to
get
an
email
you're
going
to
get
a
new
zoom
link
for
sick
windows.
So
if
you
try
to
attend
next
week
and
you're
having
trouble
go
back
to
the
getting
started
page
come
back
to
this
document,
it's
gonna
have
the
new
links
so
I'll
try
to
update
them.
A
A
All
right
next
one
mark
created
this
awesome
document
on
to
track
features,
enhancements
and
everything
else
that
we
need
to
do
for
1.20,
so
mark.
Take
it
off.
B
This
is
a
little
bit
more
than
just
what
to
do
in
120,
so
there's
kind
of
an
initiative
that
was
brought
up
in
1.19
about
what
can
we
do
to
have
feature
flags
not
stay
in
permanent
alpha
or
permanent
beta.
B
B
We
have
first
thing
windows
and
kind
of
the
status
of
them,
and
it
looks
like
there
are
a
couple
that
have
been
around
for
many
releases,
so
we'll
probably
be
having
some
plans
to
either
promote
those
or
just
remove
them,
like
james
already
did
when
he
opened
an
issue
for
the
hyper-v
container
flag,
and
then
I
also
thought
it'd
be
good
to
categorize
the
catalog,
the
different
enhancements
that
sig
windows
has
going,
and
also
kind
of
just
make
some
of
the
same
recommendations
here.
A
B
B
Like
he
added
something
to
the,
I.
C
I
added
that
I
don't
know
if
david
is
going
to
join,
but
I
I
had
a
discussion
with
that
mike
and
there
is
some
confusion
even
like
within.
Like
our
team,
there
was
some
confusion,
so
the
the
thing
is
dsr
is
available
in
119.
the
it
went
through.
You
need
to
have
the
the
patch
for
2019
it
get
backboarded
as
well
from
the
os
perspective.
Now,
what
is
not
in
119
is
is
for
120
is
the
low?
C
A
D
D
So
now
the
versioning
will
include
all
of
the
back
parted
windows,
os
versions,
but
dsr
has
not
been
applied
to
additional
load
balancers,
so
csr,
like
we've,
had
dsr
for
a
while
and
it's
been
applied
to
the
cluster
ip,
and
so
there
has
been
additional
work
on
the
os
level
to
enlighten
that
for
different
types
of
load,
balancers
and
also
like
before.
It
only
really
worked
on
the
outbound
path,
but
now
it
also
works
on
the
inbound
path.
D
So
that
includes
ingress
and
any
traffic
that
comes
from
external
ips,
but
that
work
like
even
though
it's
enlightened
at
the
os
level
has
not
been
enlightening.
Q,
proxy,
and
so
that
is
going
to
be
coming
in
120,
along
with
the.
D
A
D
Yeah,
so
local
traffic
policy
is
coming
in
120
and
also
increasing
the
scope
of
dsr
to
cover
a
wider
range
of
load.
Balancing
scenarios.
C
D
A
B
Good,
can
we
also
talk
about
the
win
overly
feature
flag
for
a
minute?
I
just
noticed
that
that
one
has
been
in
alpha
since
114..
It
looks
like
we've
had
overlay
test
passes
on
test
grid
for
quite
a
while
kaya.
Do
you
have
any
context
on
that?
If
that's
something
that
we
can
just
move
to
beta
since
looks
like
we've
had
some
pretty
consistent
test
coverage
on
with
win
overlay.
A
D
Oh,
no,
oh,
really
should
definitely
be
like
it's
a
fully
fledged
option.
So
the
only
reason
it's
an
alpha
is
just
because,
like
we
haven't,
moved
it
to
beta.
So
if
there
are
like
test
passes
that
break
microsoft
is
committed
to
fixing
them
but
yeah.
The
only
thing
is
like
that
feature
was
introduced
before
the
cap
process
really
became
like
what
it
is
now
so
there's
no
cap
for
when
overlay.
D
A
D
Yeah-
okay,
all
right
so,
but
would
that
just
be
updating
the
feature
flag.
B
See
an
enhanced
like,
I
didn't
see
an
enhancement
issue
tracking
this
feature,
so
I
think
it
would
just
be
updating
the
feature
flag
in
in
that
cube
feature.
I
think
these
came
from
a
different
from
acute
proxy
flags,
but
in
119
they
consolidated
all
of
the
feature
flags
into
just
the
cube
features.go
yeah.
A
So
I
mean,
I
would
say,
just
update
it
now
and
let's,
let's
start
a
pr
for
it
and
see
if
anybody
tells
us,
oh,
you
need
a
cap
for
this
and
and
then
we'll
figure
out
if
we
need
to
additional
process,
but
I
think
we
might
just
be
able
to
just
get
it
in.
This
has
been
there
for
a
while.
It's
just
incorrectly
labeled
and
I
love
the
work
that
has
gone
in
already
is
stable.
A
B
Feeling
people
from
sig
api
may
suggest
to
go
to
beta
as
well,
because
usually
when
things
are
stable,
you
cannot
disable
the
feature
flag.
B
A
B
D
D
If
people
are
using
it
in
production,
especially
because
it
is
alpha,
but
like
people
have
been
using
it
like
people
that
I've
worked
with
not
just
that,
I've
worked
with
like
I've,
helped
people
like
debug
issues,
so
they've
definitely
been
using.
It.
A
I
don't
know
if
anybody's
using
window
relay
directly.
I
know
that
for
sure
a
lot
of
the
code
base
and
capabilities
of
window
relay
went
into
flannel
support
for
for
windows
right.
So
so
you
know
verbatim
some
of
the
code
and
some
some
of
what
the
capabilities
of
win
overlay
are
are
in
flander,
calico.
D
Has
a
cni,
that's
overlay
with
like
windows,
support,
so
yeah.
B
One
other
thing
for
the
enhancements.
I
noticed
that
there
was
an
enhancement
issue
with
no
cap
for
storage
or
the
storage
resources,
government,
governance
or
class.
I
don't
have
any
of
the
context
around.
That
is
that
something
that
was
just
thrown
out
as
a
possible
idea,
or
was
this
something
that
it
looks
like
patrick,
was
driving
a
lot
of
this,
something
that
we
actually
would
like
to
turn
into
a
cap
and
start
making
progress
on.
A
Who's
krisha
kumar
krishna.
B
He
was
he's
still
at
microsoft.
He
was
working
on
some
of
the
csi
proxy
work
with
deep
and
jing,
but
he
transitioned
teams
a
couple
of
months
ago.
I'm
not
sure
how
much
involved
he
is
here,
but
I
can
reach
out
to
him
as
well.
A
Okay,
I
mean
who
can
leave
it
dormant,
but
if
you
can
reach
out
to
kk
and
see
if
anything's
any
any
update
on
this
on
their
end
or
if
anybody
else
picked
it
up
since
he
left
and
then
maybe
we
can
resurface
it,
probably
not
the
priority
for
one
to
twenty
right
now,.
B
Okay,
yeah
yeah,
looking
at
the
technical
details,
real
quick,
it
looks
like
this
was,
if
would
be
nice
if
people
wanted
to
kind
of
be
able
to
control
storage
iops
for
the
containers.
B
E
B
I
think
it
is
related
to
windows.
Oh
okay,.
B
A
B
A
Rather,
have
customers
or
users
come
and
ask
it
for
us,
rather
than
ask,
go
and
implement
it
like?
If
nobody
has
brought
this
up,
it
probably
means
not
import
not
as
important
right
now,
all
right
david.
I
guess
we
did
talk
about
the
dsr
issue.
Explanation
already,
so
is
there
anything
else
we
want
to
talk
about
this.
C
One
quick
question-
and
this
is
related
to
marcus
lippert's
comment.
If
you
look
at
from
our
previous
meetings
note
so
dsr,
what
we
have
enabled
119
is
required
for
enabling
calico
open
source.
So
so
that's
that's
good,
but
just
keep
that
in
mind.
C
A
So
I
think
maz
number
one.
I
think
this
documentation
needs
to
land
on
calico
right
on
caligo
side.
They
need
to
put
all
the
requirements
of
what
it
requires
for
them
to
run
right
then.
The
second
thing
is
marcus
and
I
was
gonna
pop
this
up
earlier.
He
actually
asked.
Are
we
gonna
document
that
calico
is
included
here
so
in
the
list?
So
we
should
actually
ask
the
calico
team
to
come
in
and
file
a
pr
to
update
this
table
and
include
both
the
requirements
as
well.
C
Or
do
you
have
a
connection
with
the
calico?
I
mean
we
do
have
a
connection
microsoft.
I
can
talk
to
mike
and
david
who
talk
to
them
or
or
do
we
have
a
direct
connection
with
from
kubernetes
perspective.
A
I
don't
have
a
direct
connection
from
kubernetes
perspective,
I
think,
but
if
you
don't
know
someone
I
can
find
out
so
so
miles.
If
you
can
start
an
email
thread,
that'd
be
great.
Okay,
that's.
G
Good,
I
think,
for
all
these
questions,
you
should
go
through
that
there's
plenty
of
other
yeah
plenty
of
other
projects
involved
and
by
the
way
for
wind
overlay.
We
also
have
hybrid
overlaid,
vienna
hybrid
of
the
light
that
is
using
overlay
internally.
So
that's
another
solution
as
well,
and
that's
when
I
participated
in
writing
the
hybrid
overlay
for
audience.
So
I
can
talk
about
it.
H
Yeah
hi
everyone
I'm
also
having
some
internet
connection
issues.
So
sorry,
if
I'm
dropping
it
out,
while
I'm
speaking
and
do
let
me
know
if
that's
happening,
yeah
main
updates
is
that
we've
continued
to
do
some
internal
testing
and
I've
gotten
some
feedback
and
are
kind
of
working
on
it
internally
to
to
iron
out
some
of
like
the
big
main
scenarios
that
were
outlined
in
the
cup.
Otherwise,
we
have
moved
forward
to
create
an
enhancement
issue.
H
A
lot
of
the
feedback
is
still
kind
of
in
the
form
of
comments,
because
I
think
currently,
the
only
people
who
can
incorporate
the
feedback
into
the
document
are
james,
mize
or
I
I
mean
we're
still
kind
of
working
through
that.
So
it's
going
to
be
converted
into
an
md
file
sometime
in
the
next
coming
week
or
so,
but
being
that
we
have
the
cap
available.
We're
gonna
do
a
similar
thing
to
introduce
this
work.
To
sig
note
starting
today,
and
today
is
just
gonna,
be
a
light
introduction
of.
H
Like
you
know,
please
look
at
the
cap
kind
of
similar
to
what
we
did
with
this
group
and
then
hopefully,
following
that
next
week,
we're
gonna
have
a
little
bit
more
in-depth
conversation
or
some
comments
going
on
as
well.
I
think
we
actually
had
some
people
start
to
look
at
it
because
we
did
add
it
to
the
signate
agenda,
but
there
hasn't
been
too
much
activity
quite
yet
so.
B
Keep
in
mind
that
I
think
the
enhancement
freeze
cut,
our
deadline
for
120
is
the
first
week
of
october
and
that's
when
they
expect
the
kept
prs
to
have
been
merged
as
well.
So
the
more
time
people
can
review
the
actual
pr,
the
the
better.
B
Yeah,
so
I've
been
going
back
and
forth
with
ben
on
trying
to
figure
out
what
is
needed
to
get
pre-submit
tests
for
windows
right
now.
So
there's
a
link
to
github
issue,
where
I
kind
of
outlined
like
what
I
thought.
The
next
steps
were.
B
One
of
those
steps,
I
think,
would
be
to
enable
some
pre-submits
that
would
be
optional
for
sig
windows
to
run
on
a
regular
basis.
Right
now,
we
have
in
the
second
link
there's
the
list
of
pre-submits
that
we
do
have
running.
One
doesn't
get
run
regularly.
The
other
ones
run
any
time.
Windows
files
change
the
the
ones
that
are
purple
and
but
they
don't
test
a
whole
lot
of
the
windows
functionality.
B
It
just
tests
the
end
to
end
which
does
help
ensure
that
cubelet
comes
up,
but
I
think
one
of
the
things
that
was
suggested
was
that
the
cigs
could
potentially
agree
upon
a
set
of
pre-submit
tests
that
they
run
optionally
on
all
related
when,
like
all
the
all
the
functionality,
that's
related
to
windows,
and
so
I
was
trying,
I
think
we
should
maybe
kind
of
come
to
agreement
as
a
community
as
what
we
should
run
there.
And
then
that
would
also
help
show
some
stability
for
those
pre-submits.
B
As
we
talk
about
trying
to
get
them
into
the
sig
release
ci
as
well.
We
have
a
set
of
those
in
there
now
from
gce
that
were
on
on
2019
and
2000,
I
think
to
our
2009
or
1909,
and
those
were
failing
for
a
while.
But
there's
been
some
work
to
improve
those
since
then.
B
But
I
wanted
to
get
folks
thoughts
on
pre-submits
for
tess
our
container
d,
one
container
g-test
has
been
incredibly
stable,
even
more
stable
than
docker
for
the
last
couple
months,
except
for
one
or
two
little
issues
that
weren't
related
to
any
of
the
container
d
work.
And
so
I
was
thinking
that
that
might
actually
be
a
good
one
to
start
running
as
pre-submits
to
this,
since,
especially
since
we're
moving
towards
container
d
ga,
but
I
also
listed
out
a
few
other
ones
in
the
issue
there.
A
The
floor
now
yeah,
I
think
james.
First
of
all,
this
is
this
is
great
right,
because
google
beat
before
by
presumably
jobs,
not
not
testing,
what
you
need
and,
and
things
don't
work
in
my
view,
we
need
to
select
jobs
that
are
fairly
reliable,
as
in
like
you
know,
they
run,
and
this
and
they're
successful
most
of
the
time
and
then
the
test
basic
functionality
right
beyond.
Just
the
cubelet
being
able
to
come
up
and
running,
like
you
know,
show
deploying
a
couple
of
containers.
A
Routing
and
networking
is
working
like
you
know
the
two
three
basics
that
the
signal
that
work
and
and
if
the
jobs
for
container
d
are
fairly
stable.
Like
you
mentioned
it's
also
another
great
candidate
for
that,
because
as
a
direction
we're
going
and
moving
away
from
container
from
docker
demon.
So
I
think
in
my
mind,
let's
pick
the
ones
that
are
don't
take
too
long
and
there
have
a
very
high
passing
rate
in
their
architecture.
The
right.
A
B
B
Great,
I
think,
then
I'll
keep
moving
forward
with
that.
One
of
the
other
things
that
came
up
during
the
conversation
is
to
have
pre-submit
like
blocking
pre-submit
tests
running
we
need
to
be
able
to
run.
They
need
to
be.
The
ideal
is
about
30
minutes
is
what
they're
targeting
there's
a
couple
priesthoods
that
they
have
that
run
longer
than
that,
but
they
are
trying
to
phase
those
out.
B
They
also
want
those
pre-submits
to
be
cloud
non-cloudy
so
that
anybody
can
run
them
without
having
to
have
a
cloud
job.
This
isn't
the
optional
ones
that
we're
talking
about
here,
but
going
forward.
So
that's
why
they
developed
kind
to
be
able
to
run
like
docker
and
docker
and
make
those
jobs
fast
and
quick
kind,
doesn't
work
for
windows
containers.
B
I
also
put
up
the
idea
that
maybe
we
could
look
at
adding
support
for
minicube,
but
they
don't
run
vms
in
during
the
ci,
and
so
we
need
to
come
up
with
some
sort
of
idea
on
how
we
could
potentially,
if
we
do
really
truly
want
pre-submits.
First
for
windows:
we
need
to
come
up
with
an
idea
on
how
we
can
run
those
things
as
containers
in
that
pre-submit.
So
I'm
still
looking
into
it
a
little
bit,
but
I
thought
if
anybody
has
any
brilliant
ideas,
we
can.
B
Yeah
and
a
lot
of
this
is
being
discussed
in
an
issue
that
has
been
opened.
We
can
try
and
link
that
back
into
the
meeting
documents
yeah.
It's
that
issue
right
there
that
I
that
this
conversation
here,
oh
yeah,
nine,
three,
two,
seven
six!
So
if
anybody
has
any
ideas
or
wants
to
read
up
on
it,
just
jump
in
there
and
start
talking
away.
A
Yeah,
so
we
have
a
few
more
minutes.
There's
two
readouts.
I
would
like
to
get-
maybe
maybe
not
for
this
week,
but
one
of
it
was
the
docker
stream
deprecation,
that's
happening
in
an
email
and
all
the
dims
and
mark
have
been
going
back
and
forth
for
the
last
few
days
and
the
other
one
was.
I
know
there
was
a
meeting
on
the
csi
proxy
for
windows
for
vsphere
and
other
areas.
B
B
The
intention
was
to
just
print
a
warning
message
at
cublet,
startup
time,
if
you're
using
the
docker
shim,
because
sig
node
would
really
like
to
kind
of
remove
the
docker
shim
code
base
from
the
kubernetes
repos
because
of
the
maintenance
kind
of
burden
that
that's
causing,
and
I
think
so
most
of
the
discussions
around
that
were.
What
actually
does
this
mean?
Where
is
the
user
facing
documentation
about
a
phased
plan?
B
What
are
the
timelines
and
everything
around
that
so
derek
and
derek
and
dims
are
working
on,
and
I
think
they
haven't
kept
pr
for
this
up
right
now,
I'll
find
it
didn't
like
it
here
for
for
anybody,
who's
interested.
Some
of
the
other
feedback
was
that
cri,
the
crap
api
itself
is
still
in
alpha.
So
it's
not
ready
we're
not
ready
to
deprecate
decker
shim,
because
that's
the
only
you
know
quote
unquote
stable
api
or
stable
feature.
B
We
have
for
for
cris
here
that's
kind
of
a
quick
summary
we
can
break
out
into
this
next
week
as
well.
A
E
All
there
and
yeah
it
was
a
pretty
good
discussion.
I
think
the
main
data
point
that
deviant
provided
us
was
that
a
vsphere
csi
plug-in
does
most
likely
use
the
standard
pjd3
mechanism
for
querying
disk
ids
and
matching
it
up
to
whatever
csi
is
providing
them,
and
since
that
page
83
mechanism
is
something
that
kali
already
implemented
in
csi
proxy
for
gcpd.
All
of
that
is
already
there,
so
they
can
just
directly
go
ahead
and
use
that
aspect.
E
The
missing
piece
is
a
simple
query:
to
get
something
called
the
bios
dmi
and
I
just
opened
the
issue,
and
I
think
we
were
discussing
yesterday
if
kalyan
cycles,
she
can
take
a
look
at
that.
So
I
need
to
tell
you
so,
with
these
two
pieces,
most
likely
vsphere
csi
should
have
everything
they
need
for
windows.
But
if
not,
we
can
further.
B
One
other
thing
has:
has
there
been
a
decision
made
yet
about
if
what
the
plans
are
for
csi
proxy
itself
and
progressing
that
to
stable?
I
think
that
last
I
heard
there
was
some
some
folks
would
like
to
see
that
go
to
stable,
to
get
more
kind
of
adoption
from
it
with
the
current
state
and
other
folks
are
wanting
to
keep
it
in
beta
in
case
or
in
favor
of
the
privileged
container
out.
E
Yeah
great
point:
we
were
indeed
discussing
this
yesterday
so
and
in
fact
this
is
where
I
think
we
need
a
little
bit
of
guidance
from
overall
sig
windows
is
what
should
be
our
path
forward
for
csi
proxy
with
privileged
containers
that
should
ideally
be
sort
of
the
future
and,
like
you
know,
it's
kind
of
like
an
interesting
time
now.
If
someone
is
setting
on
to
kind
of
build
their
new
csi
plugin
on
windows,
I
think
we
ought
to
provide
clear
guidance
on
hey.
E
E
You
just
package
in
the
csi
proxy,
as
is
as
part
of
your
container
image,
it's
kind
of
hacky
and
that
you'll
probably
have
to
still
spin
up
independent
exe
within
your
note,
plug-in
container,
which
is
not
the
ideal,
but
you
know
you
won't
have
to
rewrite
code
right
off
the
bat
either
yeah.
A
Thoughts,
I
mean
from
my
perspective,
you
know
csi
proxy.
We
need
to
get
it
to
ga
because
you
know
privileged
containers.
You
know
there
might
be
alpha
beta,
it's
going
to
be
around
nine
months
before
they
go
out
right,
so
we
can't
wait
that
long
for
for
enabling
customers
to
use
csi
and
potentially
move
to
csi
snapshots.
A
A
C
Yeah,
I
just
wanted
to
add
one
thing
I
mean
we're
about
to
amber
and
I
are
about
to
go
and
mark
to
the
signate
meeting
to
present
privilege
containers.
The
next
two
weeks
are
critical,
so
any
help
or
anything
you
can
do
to
like
get
privileged
companies
in
front
of
sig,
node
and
like
we
are
presenting,
but
because
once
we
get
clarity
and
we're
privileged
containers,
but
I
think
node
meeting
is
going
to
be
critical
and
once
we
have
more
clarity,
we
can
come
up
back
with
all
these
plans.
C
A
I'll
put
that
yeah
and
if
you
need
any
help,
just
ping
me
on
slack
and
send
me
a
link
I'll
take
a
look
at
it
or
deep
as
well.
Obviously,
okay
sounds
good.
Thank
you
all
right,
folks,
we're
out
of
time.
Well.
Thank
you
all
for
attending
today,
good
discussion
keep
making
forward
progress
on
your
cabs,
like
mark
said,
we
are
getting
up
on
the
two
week
deadline
and
then
remember
new
meeting
invite
next
week.
So
don't
join
the
existing
one.
I'll
update
everything
bye,
everybody.