►
From YouTube: Kubernetes SIG Windows 20190806
Description
Kubernetes SIG Windows 20190806
A
A
A
B
A
B
A
A
You
do
it
asked
a
question
on
that
recently,
and
the
thing
I
wanted
to
mention
was
that
Windows,
Server,
2000,
19
and
1809
are
the
same
code.
They're
interchangeable,
it's
just
a
branding,
difference
and
18:03
were
not
currently
testing
anymore.
We
stopped
testing
that
when
we
released
kubernetes
1.14
and
then
1903
is
something
that's
still
up
for
discussion.
If
we
do
want
to
build
and
test
that
as
a
sig,
the
images
are
available
on
Azure,
and
so
we
could
spin
up
a
test
environment
if
needed,
I'm,
just
not
sure.
A
D
A
A
D
A
A
So
do
you
know
anybody?
That's
got
more
context
and
how
the
builds
work,
because
I
know
that
one
of
things
Claudia
had
brought
up
was
that
even
if
we
select
yeah
we
we
can
create
VMs
to
do.
These
builds
on
Azure
no
problem,
but
we
still
have
an
issue
where
we
don't
have
a
credential
that
can
allow
us
to
push
to
these
GCR
repos
and
that
currently
requires
a
Googler
for
some
authentication
reasons.
I.
D
A
Yeah
I'm,
okay,
with
either
build
flow.
We
just
need
to
either
have
a
decision
to.
If
we
build
on
GCE
and
then
we
can
use
some
sort
of
built-in
authentication.
It's
not
a
problem.
That's
one
solution.
The
other
alternative
is
that
we'll
need
to
come
up
with
a
way
to
either
pull
images
from
a
registry
that
that
is
running
on
Azure
or
get
sufficient
credentials
that
we
can
push
directly
to
GCR
from
the
azure
VM,
and
so
both
both
are
possible.
A
E
Okay,
I
will
do
natively.
We
could
just
have
the
windows
build
machine
in
nature.
Like
we
already
do,
we
can
just
pass
to
the
Googlers
the
certificates
required
to
use
that
node
and
then
the
basically
they
can
be
build
on
their
nodes
and
push
from
their
notes.
I
think,
oh
actually,
that
never
mind
about
that.
Those
will
actually
require
notification
on
the
windows.
Node.
Sorry,
because
image
still
has
to
be
pushed
from
the
windows.
No,
this
world
yeah.
A
A
E
F
A
A
I
think
we
just
root
caused
was
relating
to
a
hain
deleting
Network
endpoints
with
container
D,
and
so
that's
there's
a
team
that
basically
the
developer
that
was
working
on
container
D
for
Windows
past
some
details
off
and
they
think
they've
route
caused
that
one
now,
but
I
don't
have
an
ETA
on
a
fix
yet,
but
yeah
2019
is
is
kind
of
like
that.
The
minimum
version
that
we
want
to
use
for
container
D.
D
B
B
A
A
B
B
C
So
main
updates
are:
yes,
sir:
the
cap
got
merged
in
implementable
state
last
Tuesday,
thanks
Patrick
for
reviewing,
as
well
as
others,
from
its
void,
and
you
too
and
others.
So
that's
n.
We
got
a
repo
created
under
kubernetes
CSI
to
host
the
CSI
proxy
and
right
now,
I'm,
looking
at
the
plugin
watcher
changes
that
need
to
be
done
in
or
support
the
domain
suck
at
FS
notify
stuff
for
Windows.
So
this
is
where
I
found
an
interesting
difference
in
1809
and
1903.
It
seems
the
domain
socket
files
in
case
of
1809.
C
You
still
have
a
reverse
point,
widget,
with
a
specific
tag
that
was
tagged
as
if
something
between
sockets
and
it
seems
in
1903.
That
reports
point
went
away.
It's
just
like
a
regular
and
the
FS.
You
don't
need
longer
reports
that
reverse
file,
so
for
now
I'm,
just
like
you
basically
need
to
filter
down
on
the
final
notifications
that
we
get
based
on
whether
they're
socket
files
or
not,
and
so
for
now
my
plan
is
to
just
like
try
to
connect
to
them.
If
the
connection
fails,
then
I
say
it's
not
a
soccer
file.
C
If
it
passes
then,
but
we
can
no
longer
depend
on
the
three
powers
point,
it
seems
so
that's
like
an
acoustic
thing,
but
yeah
overall,
my
goal
is
to
get
the
increasing
engine
first,
when
work
with
six
storage,
maybe
next
week
to
get
everything
up
for
the
node
registrar
and
when
John
is
planning
to
start
working
on
them.
In
the
same.