►
From YouTube: Kubernetes SIG Windows 20181023
Description
Kubernetes SIG Windows 20181023
A
B
All
right,
so
the
main
update
that
I
had
for
today
was
your.
Last
last
week
we
took
a
discussion
on
a
test
approach
over
to
cig
architecture
around
how
we
were
going
to
run
conformance
tests,
so
I
have
some
updates
there
and
then
also
talking
about
the
other
thing.
I
want
to
cover
was
where
we
are
at
in
terms
of
the
Windows
releases
and
so
I
think
I'll
go
ahead
and
start
with
that.
Put
that
at
the
top
of
the
agenda,
since
it's
short.
B
Also
Microsoft
is
going
to
help
me
with
some
of
the
some
of
this
dumb
organizational
work
there
to
make
sure
that
we
could
the
test
passes
up
and
running
so
for
13
I
mean
you
know
the
would
the
new
version
Windows
servers,
not
not
an
option
at
this
point,
it's
too
late.
So
risk
is
stick
with
the
latest
and
greatest
1803,
and
that
means
that
we'll
also
be
using
docker
and
not
container
D
container
D
work
will
need
to
move
into
verge
into
a
new
feature
or
enhancement
for
version
14.
B
A
Yeah
that
makes
sense
to
me
I
think
that,
given
the
fact
that
you
know
we
don't
you
know
having
running
tests
around
soup
that
build
and
we
don't
have
it,
then
you
know
the
and
how
close
we
are
to
the
release.
It
makes
sense
to
go
to
1803.
I
know,
there's
a
lot
of
networking
stuff
that
were
expecting
to
get
from
from
that
release,
and
you
know.
C
A
B
B
And
then,
and
then
last
week
we
also
had
results
from
from
you,
jus
on
am
over
and
on
GCE
that
basically
matched
the
results
that
we're
getting
there.
So
I
think
that
you
know,
we've
got
got
good
confidence
that
we
can
get
get
this
stability
work
worked
on
over
the
next.
Yes,
we
have
what
about
five
weeks,
two
weeks
until
code
slush,
but
we
could
still
get
bug
fixes
in
between
that
and
the
release.
So.
A
B
Means
look
at
how
many
of
those
are
so
open,
so
one
of
them
was
being
able
to
set
cube,
reserved
and
system
reserved
for
Windows
nodes
and
Peng.
Pha
has
a
PRN
for
that.
That
always
makes
sure
that
we
can
set
aside
as
much
memory
as
needed
for
for
docker
and
the
cubelet
and
not
over-provision
those
nodes.
B
B
And
so
it's
moving
on
to
the
conformance
testing.
So
last
week
we
discussed
the
approach
for
how
to
how
to
deal
with
with
Windows
or
sorry
with
like
specific
tests,
when
we
were
testing
windows,
nodes
I,
just
pasted
the
current
PR
that's
there.
So
we
wouldn't
have
discussion
with
sega
architecture,
which
also
included
a
few
people
that
are
part
of
the
conformance
working
group,
or
I
don't
know
what
it's
actually
called.
B
But
our
initial
proposal
was
to
go
ahead
and
use
an
OS
flag
on
the
test,
pass
to
exclude
the
tests
that
were
covering
linux
only
functionality,
and
there
was
that
there's
some
pushback
on
that,
because
they
didn't
really
want
to
change
the
definition
of
the
conformance
or
try
to
make
it
harder
to
understand
what
what
was
conformance
and
what
wasn't.
And
so
the
alternative
proposal
that
that
we
worked
on
with
with
Brendan
was
well
well.
What?
B
If
we
focused
the
testing
on
a
hybrid
cluster
that
has
both
Windows
and
Linux
nodes
in
it
and
then
we're
a
test,
doesn't
make
sense
to
run
on
Windows
because
it
covers
things
like
you
know:
messy
Linux
or
other
Linux
specific
functionality.
Let's
just
run
it
on
a
Linux
node.
So
that
way,
when
you
get
the
list
of
test
results,
all
the
test
cases
that
are
expected
are
there
and
then
all
the
ones
that
that
should
apply
to
Windows
ran
on
Windows
and
the
restaurant
on
Linux,
and
so
they
were
generally
okay
with
that
approach.
B
B
As
you
know,
I'm
just
going
to
be
working
on
Gran,
Dolina
and
Claudio
are
gonna
work
on
updating
that
PR
to
follow
that
approach
instead,
so
sometime
later
this
week,
we
should
know
if
that
approach
is
gonna
work
out
for
a
technical
standpoint,
because
there's
a
few
changes
that
we
need
to
make
in
order
to
be
able
to
switch
the
test
cases
between
Windows
and
Linux
as
needed
anyway.
That's
that's
the
current
direction
that
that
we've
that
we're
going
forward
with.
B
Yeah
and
feel
free
to
feel
free
to
add
comments
into
that
to
the
dock
or
you're
pinging
us
like,
if
you
got
anything
else
so
I
think
that's
all
I
had
on
my
my
list
for
today.
Didn't
he
anybody
want
to
cover
anything
else.
Did
you
want
to
give
any
test
updates,
I,
don't
know
or
anybody
hey.
A
C
B
I
mean:
what's
what's
going
to
be
available
like
right
now
we're
still
focusing
on
1607,
and
that
seems
to
be
okay,
but
it's
not
going
to
work
with
like
the
named
pipe
PR
that
you
submitted,
but
I.
Don't
think
we
need
that
for
conformance
Adelina.
Are
you
aware
of
any
tests
that
would
require
a
version
newer
than
then
1706.
C
What
I
was
getting
at
is
like
ven
113
G
is
like
milder
kubernetes
note
that
says
you
know
these
are
the
Doppler
versions
supported.
Would
that
be
updated
to
say,
1809
cuz
1706
is
not
one
of
the
things
that
you
know.
It
says
in
the
notes
for
every
cube
release
in
the
list
of
dr.
worship,
dr.
immersion,
supported
Rey.
So
it's
curious
about
that
aspect.
Yeah.
B
No
one
says
we
have
to
do
1706,
but
the
problem
is
we
can't
do
1803
actually.
So
let
me
let
me
give
a
quick
overview
of
the
situation
here
so
in
in
docker
version
or
sorry
in
kubernetes
version
1.12,
the
the
docker
api
was
updated
and
Ben
Reeve
and
'red,
where
it
asks
for
a
docker,
API
version
of
1.38.
B
B
The
docker
18:03
release
on
Windows
is
an
older
version
of
the
API.
So
if
you
install
docker
1803
and
try
to
run
kubernetes
1.12
or
newer,
then
what
will
happen
is
the
the
cubelet
will
not
be
able
to
give
a
connection
to
the
docker
engine
because
of
the
API
mismatch,
and
it
just
fails
and
I
still
don't
fully
understand
why
this
works
on
docker,
1706
I
think
it
may
be
that
docker
1706
allowed
people
to
use
an
API
within
version
that
was
newer
as
long
as
they
didn't
make.
B
So
for
whatever
reasons,
1706
works
but
1803
rejects
the
connection
and
so
the
options
we
have
to
fix
this
or
we
could
either
move
to
a
newer
version
of
docker
that
supports
the
API
version
that
matches
qu.
Bernays
is
asking
for
or
we
could
change
the
version
or
we
could
change
the
code
in
kubernetes
to
request
as
lower
version
for
Cooper
and
for
Windows
nodes.
C
B
C
B
B
B
C
C
B
There's
two
places
that
we
would
need
to
clarify
that
one
would
be
in
the
in
the
windows
Docs
that
we
have
just
for
how
to
set
things
up.
We
would
just
list
the
supported
or
basically
the
stable,
OS
and
docker
versions
that
are
there
right
now.
I,
don't
think
we're
gonna
put
in
any
code
to
block
older
OS
versions,
we're
just
going
to
clarify
that
those
are
not
declared
stable
and
you
have
reasons
being
things
like.
B
You
know:
Windows,
Server,
1709
and
Server
2016,
don't
work
with
map
volumes
or
or
C
or
for
secrets
as
volumes,
and
so
they're
not
going
to
be
part
of
that
stable
declaration.
So
we
would
just
list
what
the
versions
are
there
and
then,
whenever
a
kubernetes
vendor,
you
know
whether
it's
a
cloud
vendor
or
whether
it's
something
like
UDOT
Dockery,
he
needs
to
submit
kubernetes
conformance
results.
B
You
have
to
have
the
the
steps
used
to
set
the
environment
up
in
that
submission
as
well,
and
so
that
would
be
another
place
where
you
would
say
you
know
we
reused
this
version
of
Windows,
this
version
of
Linux
on
the
leader
nodes,
and
you
know
here's
the
version
of
docker
that
we
were
using,
and
you
know
here's
what
the
you
know
command
was
to
launch
the
conformance
test
pass.
He
also
be
you
know
we
would
cover
it
in
both
of
those
places.
D
B
Yeah
yeah,
so
that's
just
jointly
maintained
between
the
windows
team
and
between
docker,
but
using
that
using
the
right
parameters
you
could
pick
which
version
of
docker
ee
you
want
to
install
so
once
18:09
is
available,
you'll
be
able
to
pick
there.
The
reason
1706
is
the
default
is
actually
because
that's
the
from
my
understanding.
That's
still
the
version
that
is
supported
for
docker
swarm
users
and
since
there
are
a
number
of
people
using
that
under
a
commercial
support
contract
that
was
left
as
the
default.