►
From YouTube: Kubernetes SIG Windows 20180814
Description
Kubernetes SIG Windows 20180814
A
All
right
well
good
morning
and
thank
you,
everyone
for
for
joining
for
this
week's
sig
windows
meeting
I,
just
added
a
couple
things
on
to
the
on
to
the
meeting
notes.
If
you've
got
any
other
topics,
you
know
please
either
drop
them
in
there
or
just
drop
it
out
in
the
chat
window
and
I'll
make
sure
we
have
time
for
them
Michael's
on
his
way
way
back
from
vacation
right
now,
but
he
should
be
back
I'm
expecting
him
back
next
week.
A
And
so
does
the
feedback
I've
had
from
Signet
working?
You
know
there
were
kind
of
two
overall
points.
One
of
them
was
talked
to
sega
architecture
because,
as
they
were
currently
starting
last
week
and
continuing
into
this
week,
my
understanding
is
that
they're,
looking
at
new
test
cases,
they're
being
proposed
for
conformance
and
so
their
recommendation
was
that
we
should
talk
to
them
about
the
test
cases
that
do
and
do
not
work
on
Windows
sooner
rather
than
later.
A
So
that
way
we
can
sort
of
get
ahead
of
the
game
there.
If
there
are
tests
that,
are
you
know,
testing
Linux,
specific
functionality,
so
Adelina
and
claudia
have
already
started
a
list,
so
I
was
going
to
take
that
list
there
as
a
point
of
discussion
and
and
let's
see
what
what
they
can
do
about
sort
of
better
defining
what
should
and
shouldn't
be
covered
in
conformance
and
how
we
can
work
around
the
ones
that
do
things
like
test
linux
specific
ads.
So
I
don't
have
anything
to
report
there.
A
So
today
there's
you
know
one
big
feature:
difference
between
Windows
Server,
2016
and
the
later
versions,
and
that
is
that
Server
2016
doesn't
support
network
namespaces,
so
we
can
only
ever
have
one
container
per
pod,
and
that
also
requires
some
special
workarounds
in
metamer
fits
in
the
cube
lid
or
the
CNI
or
both,
but
basically
there's
some
code.
That
is
specific
to
that
Windows
version,
and
so
there
suggestion
was.
If
we
are
only
planning
to
support
newer
versions,
then
can
we
go
ahead
and
formally
deprecated
the
old
windows
release
and
then
remove
that
code?
A
So
we're
not
maintaining
it
so
it
does
anybody
have
any
any
feedback
on
that.
Has
anybody
talked
to
customers
that
are
planning
to
use
just
2016?
You
know
with
the
known
limitations
of
one
container
per
pod
and
CNI
plugins.
Don't
work
as
well
as
the
mapped
volumes.
Don't
work
I
mean
to
me
personally:
I,
don't
think,
that's
really
a
viable
release
but
I'm
looking
for
feedback
from
others.
There.
A
B
C
A
And
did
the
other
thing
about
2019?
That's
important
is
the
fact
that
it's
going
to
be
on
a
five-year
support
cycle
from
Microsoft,
whereas
1803
and
1709
are
not
so
I
sort
of
so
I
think
what
I'd
like
to
propose
is
that
you
know
we
say
that
we
would
support
1803
with
caveats
for
like
roughly
the
next
year
or
so,
but
not
older
versions
and
then
drop
1803
and
just
support
2019
from
that
point.
On.
A
Main
reason
being
that,
if
we're
able
to
get
all
the
right
tests
passing
4:12,
that's
going
to
be
done
before
Windows
Server,
2000
19
is
ready
and,
furthermore,
like
the
work,
that's
being
done
in
container
D
will
work
fine
on
1803
as
well
as
2019
from
my
understanding,
I,
don't
know
what
did
you
any
thoughts
there?
Peter.
C
That
sounds
fine
to
me,
and
the
few
customers
I've
talked
to
you
I
think
would
be
fine.
With
that
you
know.
I
might
I
would
say
that
even
prefer
that
to
not
have
to
you
know,
test
those
old
versions
as
long
as
it's
written
down
somewhere,
I
think
that's
the
important
thing
so
that
we
and
customers
know
what
to
expect.
A
B
A
A
A
A
A
They
have
collected
I'm
planning
to
circulate
that
back
to
this
SIG
mailing
list,
even
though
we
don't
use
it
as
well
as
the
other
ones.
Just
to
sort
of
you
know
give
everybody
a
week
saying:
okay,
you
know
here's,
here's,
here's
the
final
version
of
the
doc.
You
know
if
we
don't
get
any,
you
know
objections
you
know
in
the
next
week,
then
we're
going
to
consider
the
doc
closed
and
then
you
know
continue
moving
forward
there.
A
A
So
then
we
can
also
use
that,
as
a
reference
of
you
know
whether
or
not
we're
ready
for
for
GA
so
I'd
like
to
do,
is
you
know
within
the
next
week
or
two
once
that's
up
on
test
grey?
Don't
want
us
to
be
able
to
review
that
within
these
sig
meetings
and
then
also
have
that
as
a
reference
there
for
sig
note
and
other
groups
to
sort
of
you
know
track.
What's
going
on
so
I
think
we're
very
close
to
getting
that
done
and
to
code.
A
It
looks
like
right
now
for
the
conformance
tests
latest
when
I
looked
at
we're
still
failing
around
20
test
cases,
so
we're
gonna
push
towards
opening
bugs
for
those
to
track
those
and
then
try
to
get
those
investigations
to
sign
out
to
different
people.
So
we
can
report
back
and
you'll
actually
measure
that
we're
you're
getting
the
right
things
done.
E
A
So
I
mean
you
know,
my
group
has
been
focusing,
of
course,
on
on
getting
the
azure
stuff
done,
but
we'd
be
happy
to
have
any
other
ones
uploaded
to
test
grid.
You
know
we're
using
cube
test
to
actually
run
all
this
stuff,
so
you
can
use
any
cluster
setup
tool
that
you
want
and
then
just
point
cube
test
to
it.
The
main
the
PR
that
I'm
referring
to
is
about
the
work
to
allow
cube
tests
to
create
a
cluster
on
Azure.
A
D
D
A
And
the
main
thing
it
does
is
it
basically
builds
out
as
your
templates,
and
so
it's
going
to
have
a
template
that
run
that
deploys
ax
and
you're
blind
to
know
runs
a
bunch
of
bash
scripts
on
it.
To
finish.
Setting
up,
you
know
the
coop
master,
you
know
and
all
the
roles
on
there
and
it
can
deploy
it
either
as
a
single
note
or
highly
available
configuration
and
then
they'll
create
a
number
of
of
agent
nodes.
A
F
A
A
B
B
Perhaps
some
I
should
also
address
part
of
like
the
testing
efforts.
I
know
the
call
D
team
internally
at
Microsoft
also
is
running.
B
For
like
deploying
kubernetes
right
now,
I
think
they're
still
fairly
basic,
but
the
test
infrastructure
is
there
I
think
they're.
Just
what
we're
doing
now
is
like
deploying
iis
and
nginx
container
workloads
and
that's
to
test
the
wind
C&I
networking
plugin.
So
it's
it's!
It's
not
it's
not
like
the
kubernetes
conformance
tests
that
try
out
like
ACS
engine
and
address
tonight.
This
is
testing
like
more
D
on
Prem
flavor
as
well.
So
I
want
to
have
a
meeting
with
them
next
week.
Here
talk
about
some
next
steps
on
this
cuz
extending
and
bullying.
A
A
So
there's
a
couple
different
ways
we
could
be
adding
to
one
of
them
is
that
if
there
are
things
that
are
windows
specific,
we
could
add
those
and
just
mark
them,
as
you
know,
as
owned
by
cig
windows.
Well,
I'm
gonna
use
a
feature
tag
of
Windows
to
do
that.
So,
if
we
wanted
to
do
like
a
window
specific
scale
test,
we
could
absolutely
do
that
and
check
those
tests
in
so
they'd
be
executed
by
cube
best.
A
The
other
direction
that
you
can
go
is
there's
also
the
cloud
provider
tests,
which
is
where
we'll
probably
be
taking
things
like
as
your
C&I
scale
tests,
because
those
ones
are
all
based
around.
You
know
things
that
are,
of
course,
cloud
cloud
provider,
specific
and
and
I
think.
The
last
group
is
that
I
know
that
the
C
and
I
for
container
networking
repos
also
have
their
own
tests
as
well.
So
that's
another
place
that
you
can
get
additional
Network
specific
plug-in
tests.
I'm
contributed.
F
A
A
F
A
So
like,
if
you
go
and
look
at
that
plug-in,
what
it
does
is
it
calls
out
to
you
know
the
azure
API
endpoint
to
attach
the
disk
matches
a
claim,
and
so
basically
the
pass
that
disk
is
stored.
I,
don't
know
if
it's
stored
in
that
CD
or
if
it's
stored
somewhere
in
the
Cooper
cluster
as
a
config
map
or
whatever,
but
anyway
it
gets
that
it
gets
the
URI
for
that
disk
asked
it
to
be
attached
to
that
node
and
then
there's
some
Windows
specific
code
in
there.
G
A
F
A
I,
don't
know
what
the
ETA
is
there,
but
the
entry
ones
for
I,
scuzzy,
NFS
and
Sif's
are
all
linux
specific,
correct,
okay,
listen,
and
so
you
know
the
feedback
we
got
was
rather
than
was
that
in
general
they
didn't
want
us
adding
more
entry
plugins,
and
so
that's
why
we
have
the
out
of
tree
one
available.
You
know
the
source
is
available
so
that
you
could,
you
know,
make
another
out
of
tree
plugin
for
another
cloud
provider,
because
I
fully
expect.
A
A
So
I
just
pasted
the
issue
there
in
the
chat
window,
but
basically
what
it
comes
down
to
is
that
the
way
that
the
DNS
servers
and
DNS
Search
Search
suffix
order
are
handled
in
Linux
is
that
it's
all
done
through
UTC
resolve
Kampf
and
on
linux.
The
cubelet
basically
creates
that
file
for
each
pod
and
then
map's
it
into
a
container,
we're
sorry
Maps
it
or
puts
it
in
the
pod
sandbox
so
that
it
can
be
mapped
into
each
container.
But
the
problem
is
that
Windows
never
parses
that
file.
A
A
So
we'll
probably
will
be
making
those
changes
in
the
you
know,
as
your
C
and
I,
and
when
C
and
I,
plugins
and
I
know
what
there's
a
slightly
different
workaround.
That's
already
been
applied
for
ovn,
but
if
anybody
else
is
working
on
a
CNI
plugin
once
this
change
is
made
here,
you'll
need
to
update
that
plug-in
as
well.
To
do
the
same
thing
and
then
once
that's
done,
then
we'll
be
able
to
follow
the
right.
A
A
Sounds
good
all
right!
Well,
thanks
everyone
and
have
a
great
rest
of
your
day.
You
know
and
then
we'll
get
the
recording
published
probably
next
week,
because
only
michael
has
access
to
the
YouTube
channel,
but
I
have
been
putting
them
over
on
the
G
Drive
account
if
you
need
them
so
all
right.
Well,
thanks!
Everyone
have
a
good
day
thanks.