►
From YouTube: Kubernetes SIG Windows 20190723
Description
Kubernetes SIG Windows 20190723
A
A
A
A
B
A
C
A
C
Yeah,
so,
basically
is
they
should
ug
opened
on
kubernetes
regarding
the
Redis
image
and
I've
opened
it
in
I
mean
linked
it's
another
issue
in
Windows
testing,
so
basically
what's
happening.
There
is
that
they
updated
the
image
used
the
rebus
image
to
an
inverter
5:05,
an
image
we're
using
so
we're
using
a
Windows
port,
but
that's
only
for
version
3.2,
that's
as
far
as
the
port
goes
now.
C
The
problem
with
that
particular
test
is
that
basically,
what
this
does
is
just
get
the
logs
from
a
pod
and
tries
to
find
the
particular
string
in
there
which,
happily
enough
changed
between
versions
now
we're
running
into
a
bit
of
a
problem
here,
specifically
because
Redis
the
windows
port
for
Redis
is
not
is
no
longer
supported.
On
the
one
hand,
and
on
the
other
hand
we
don't
have
a
version
5:05.
That
would
basically
have
that
that
new
string
inside
there
now
the
idea
is
that
a
quick
fix
for
this
will
obviously
be
just
change.
C
The
regex
them
they're
trying
to
match
their
to
a
subset
that
works
for
both
versions.
But
obviously
this
is
just
the
quick
fix
for
the
test,
not
for
the
the
overall
problem
we
have
with
with
the
Redis
image
and
the
fact
that
we
don't
support
it.
The
grated
version
so
I
thought
that
we
might
actually
port
that
whole
test
to
the
the
new
image
on
host.
C
So
it
is
so
it
uses
that
because,
basically,
there's
no
reason
that
this
it
just
looks
through
the
logs
should
use
rebus,
except
that
I
suspect
where
they
use
it
only
because
it
just
outputs
a
lot
of
logs
continuously
so
I'm
guessing
that's
the
reason
they
they
have
it
that
one
and
not
something
else.
So
the
long-term
solution
will,
in
my
opinion,
be
just
YouTube
port
that
thirst
you
use
on
host
and
implement
something
in
there.
C
C
The
other
one
I'm
expecting
a
little
bit
of
more
delay
in
terms
of
reviews,
and
you
know
the
normal
process
so
I
father.
Maybe
we
can
just
have
the
first
fiction
and
while
it
or
until
it
goes
and
just
disable
the
tests
from
so,
for
example,
in
our
case
from
staging
and
master
just
because
there's
no
reason
to
have
read
test
cases
just
because,
just
because
we
have
that
that
no
nation
so
basically
have
the
original
fix
until
that
goes
in
disable.
The
tests
and,
in
the
meantime,
have
that
more
that
more
complete
approach.
C
The
problem
where
we
we
actually
change
the
flow,
the
tests
to
change
the
image
now
I,
don't
expect
this
to
be
too
much
work
or
complicated
anyway,
over
here
thing
to
hit
any
any
problem.
So
all
a
SAP
on
on
this
today
or
tomorrow
early
in
the
morning
for
us
here.
A
C
Know,
generally,
port
the
test
for
both
windows
and
linux
to
use
the
different
image
which
is
on
host
because
again,
the
whole
test
just
gets
the
logs
from
a
container
and
checks
it
for
a
particular
string
is
in
there
if
a
particular
text
is
in
there.
So
there's
no
reason
you
using
red
Redis
for
this
test.
There's
never.
C
As
I
said,
my
only
suspicion,
the
the
thing
I
suspect
is
that
they're
using
red
is
because
it
outputs
a
lot
of
laws.
That's
what
they're
trying
to
test,
because
if
you
I'm
guess
you
can
use
any
image
that
just
outputs
you
know
the
hostname
or
something
like
that.
But
you're,
not
testing
much
in
terms
of
log
function,
I'll
be.
E
A
C
More
parallelism
or
experimenting
to
find
exactly
the
point
where
it's
starting
to
be
unstable
because
of
the
parallel
test
notes,
basically
we're
trying
to
shave
off
as
much
as
possible
from
the
test
time
but
again
in
a
case
and
in
the
ApS
engine
CI
the
testing
itself.
So,
for
example,
how
is
now
in
staging
the
testing
itself
takes
like
50
minutes
on
average,
the
provisioning
and
building
of
the
winery's
is
the
hypercube
and
everything
that's
what
takes
most
of
the
time.
A
A
A
The
other
note
I
had
on
here
I
put
links
to
the
current
work
on
container
D
I'm,
still
trying
to
get
a
better
timeline
on
that
from
the
for
the
people
that
are
working
on
the
windows,
container,
D
Court
right
now.
I
still
don't
have
a
like
we're
at
the
point
where
we've
identified
some
issues,
but
people
are
actively
working
on
the
issues
we've
identified
yet
in
terms
of
fixing
them
and
so
I'm
still
thinking
that
it's
going
to
be
likely.
A
You
know
a
few
weeks
to
possibly
a
few
months
before
we
get
active
engagement
on
that,
so
so
that
only
is
continuing
to
to
work
on
getting
some
of
those
issues
identified.
But
at
this
point
I
think
it
might
be
a
it's
more
likely
something
for
1.17
rather
than
116
in
terms
of
getting
it
actually
stable.
But
but
I
think
it
looks
like
we're
on
track
to
get
the
tests
up
for
16
with
some
with
some
known
failures.
C
Yeah,
so
basically
the
whole
idea,
so
a
couple
of
weeks
ago,
as
you
know,
we
still
had
trouble
actually
running
the
tests
in
continually
because
the
nodes
with
the
flip-flop
between
ready
and
not
ready,
you
identified
an
issue
there,
and
now
we
started
the
tests
with
a
fix,
let's
say
more,
of
a
hack
that
can
evolve
course
into
a
fix
for
for
those
issues.
Now
the
nodes
are
stable
and
I
started
the
tests.
Only
in
this
algebra
scenario,
I've
started
the
test
and
the
hoops
here
are
to
just
have
them
running.
C
So
we
know
which
are
the
failures
and
start.
You
know,
investigating
the
tests
and
at
least
having
them
prepared
for
whenever
continuity
is,
is
actually
landing
and,
of
course,
finding
any
issues
that
might
appear.
So
that's
that's
the
goal
just
investigating
what
we
have
to
see
if
there
are
issues
how
figure
them
out,
maybe
even
if
they're
reasonable
enough
to
fix
in
container
to
be,
and
not
let's
say
it's
a
platform
issue
or
whatever
you
know,
go,
go
as
much
as
possible
in
that
direction,
but
basically
on
what
the
tests
give
give
us.
E
So
if
anyone
wants
to
take
some
time
reading
it,
there
would
be
great
it's
it's
just
about
cleaning
of
the
the
registry
keys
they
recreate
for
for
a
GMS,
a
containers
and
making
sure
we
eventually
lead
them,
even
if
the
container
never
starts
or
never
removed
so
yeah.
If
people
have
time
to
look
at
that,
that
would
be
awesome.
Thank
you.