►
From YouTube: KubeVirt community meeting 2020-11-04
Description
Recording of the KubeVirt community meeting held on 2020-11-04
A
A
B
C
Of
course,
thank
you,
daniel
and
hello,
everyone
yeah,
I'm
I'm
federico
and
yeah.
I've
just
joined
the
the
team
this
this
week
and
yeah
I'll
be
focusing
on
the
on
the
ci
part
of
things
and
testing,
and
all
this
kind
of
stuff
and
yeah.
I'm
looking
forward
to
learn
from
you
guys
as
much
as
I
can
trying
to
be
to
properly
contribute
to
the
to
the
project
and
to
the
team
as
soon
as
possible.
C
C
A
B
D
B
Yeah,
it
looks
like
at
the
moment
at
least
it's
not
more
flaky
than
the
other
lanes,
I
would
say
yeah
yeah.
We
have
flaky
tests
on
everyone
on
every
lane.
Still
but
yeah
there's
work
on
work
in
progress
going
on
on
that,
but
on
the
other
hand,
it's
it's
not
failing
more
often
and
one
thing
that
was
kubernetes
1.19
related
got
fixed
by
kika.
I
think-
and
I
think
we
have-
we
don't
have
anything
else
open
on
that.
So,
in
my
opinion,
it's
good.
B
B
D
B
B
E
All
right,
so
I
think
there
was
an
email
from
ezra
and
he
sent
an
email
to
the
mailing
list.
He
and
he
sent
a
pr
about
it.
I
linked
here
the
pr
it's
something
strange
I
didn't
saw
this
anywhere
else
raised
if
I
just
wanted
to
bring
it
to
your
attention.
So
if
anyone
has
time
to
think
about
it,
it
will
be
interesting
here
is
that
when,
when
you,
when
we
defer
a
close
of
a
file,
maybe
it's
not
only
for
files,
but
let's
assume
it's
for
files.
E
F
I
think
it's
quite
clear
to
everyone
that
if
you
have
a
read,
write
file,
if
you
write
stuff
to
a
file,
currently
most
systems
are
caching
stuff
to
memory.
So
basically
the
file
is
can
be
written
while
you
are
closing
it
and
on
some
cases,
even
after
you
close
it.
But
let's
not
talk
about
that.
So
the
file
is
flashed
while
you
are
closing
it.
So
if
you,
if
there
is
an
arrow
during
that
clause,
it's
similar
to
an
error
on
right.
F
It
might
be
that
you
fail
to
write
or
you
partially
write
and
so
on.
If
we
defer
it
normally,
we
do
not
test
not
normally
because
of
the
different.
We
do
not
check
those
errors
on
gulang
and
kubernetes
and
so
on.
If
there
is
such
a
cr
on
the
gulang
libraries,
what
they
do,
they
do
not
defend
the
clause,
they
do
explicit
clause
on
every
condition,
and
but
this
is
very
tedious.
F
It
means
that
you
need
to
make
sure
that
on
every
return
you
first
try
to
close
the
file,
which
is
tedious.
So
so
I
I
pushed
the
pr
and
to
me
at
least
the
interesting
part
is
what
are
we
doing
with
errol
durie?
So,
first
of
all
we
need.
I
want
to
get
the
new
reaction
of
whether
we
should
at
all
check
those
arrows,
because
up
to
now
we
ignored
those
all
over
the
code.
F
D
F
F
F
F
You,
what
you
are
saying
is
instead
of
defending
this
clause,
what
we
can
do
we
can
do
flash
and
explicit
flash
after
the
right
and
so
on,
that's
a
possibility,
but
then
you
lose
the
whole
asynchronic
issue
of
writing
and
so
on.
So
once
again
the
problem
is
not
the
flesh.
The
problem
is,
what
are
you
doing
with
the
errors
you
got
during
the
clause
so
on
right?
I
can
handle
them.
I
I
already
handled
this
on
the
pr.
F
E
So
so
I
think
that,
in
my
opinion,
the
if,
if
the
close
has
an
error,
it
means
that
that
we
have
a
problem.
So
in
any
case
you
are
you
are
you
talked
about
the
the
problems
of
writing
or
problem
of
reading,
and
but
in
any
case,
if
you
get
an
error,
the
the
what
is
common
to
all
is
that
you
will
have
a
find
the
script
or
not
closed.
E
So
if
this
is
something
that
requires
a
lot,
then
we
will,
in
the
end,
we'll
have
find
the
scripts
of
leaking
and
then
we'll
end
up
in
a
very
bad
shape.
Probably-
and
no
one
will
know
why.
So
in
my
opinion,
if
we
need
to
find
the
common
common
ground
for
all
of
them
and
that's
it,
it
doesn't
matter
if
it
you
write
and
he
didn't
write,
he
did
write
and
it
doesn't
matter
if
you
read
and
it
it
read
it
or
or
and
then
you
fail
to
close
it.
E
In
any
case,
it's
an
error
and,
in
my
opinion,
my
the
easiest
part
is
to
be
it's
interesting
to
me.
If
it
even
happens
in
our
project,
so
I
will
just
do
a
panic
and
that's
it,
and
if
you
do,
if
we
don't
do
the
panic,
then
it
means
we
will
always
leak
file
descriptors.
If
this
is
happening,
I
don't
see
any
other
way
for
us
not
to
lick
them.
D
F
F
I
personally,
I
think
that
at
this
point,
because
this
will
what
personally,
what
I
would
have
done-
and
this
is
what
I've
implemented
is-
I
think
we
should
treat
arrows
during
right,
because
this
can
impact
your
flow.
However,
at
this
point,
because
of
exactly
what
you
ask,
I
don't
think
we
have
like
severe
issues
on
the
reed.
F
I
would
recommend
to
catch
those
arrows
on
closing
grid
and
just
print
out
a
log
message,
so
in
case
you
encounter
an
issue
when
you
exhausted
your
file
descriptors
on
at
least
you
can
look
and
see
whether
the
case
is
there,
because
I
want
to
remind
you
for
the
read
they
are
very
very.
They
are
very
kind
of
unique
cases
in
which
it
doesn't
makes
any
sense
to
panic
or
to
do
an
error.
I
can
give
you
even
one
example.
F
On
many
cases
we
just
open
the
file
and
try
to
test
it
check
the
flags,
for
example,
if
it
has
all
direct
in
order
to
set
the
cache
mode
and
so
on,
and
then
we
try
to
close
it
now.
If
we
fail
to
close
it,
what
does
it
mean
that
the
file
doesn't
support
it?
It
does
support
it.
It
doesn't
mean
anything
for
us.
We
don't
care
if
we
fail
the
clause
here,
so
I
would
recommend
to
just
print
a
log
message,
but
that's
my
opinion.
F
Once
again,
we
wanted
to
open
it
to
and
to
your
question
it's
a
concrete
issue.
We
have
it
in
the
code
so
once
again
for
right,
I
would
recommend
to
actually
catch
there
and
return
it
to
the
caller,
because
this
is
a
real
arrow.
You
didn't
succeed
to
write
the
file
and
for
it
I
recommend
justin
logaro
but
feel
free
to
answer
in
the
email
or
here
or
whatever
you
choose.
D
Okay,
yeah,
I
think
that
makes
sense
so
we'll
get
visibility
on
read,
closed
errors,
which
I'd
be
really
surprised
that
this
occurs.
But
I'm
sure
it's
it's
great.
If
we
hit
some
sort
of
file,
descriptor
limit
and
we'd
know
at
least
have
evidence
why
that's
occurring
and
for
right,
yeah,
you're
right!
It
does
indicate
that
we
didn't
get
the
result.
We
wanted
there
right.
F
And
I
I
just
want
to
warn
you
in
advance,
because
gosek
produced
a
lot
of
very,
very
interesting
issues.
I'm
looking
on
several
of
them
so
expect
more
similar
discussions
on
other
topics,
because
it
seems
that
go
have
very
peculiar
way
on
handling
stuff.
That
can
cause
very
strange
errors
that
are
very
hard
to
debug
if
we
don't
catch
them
in
advance.
A
F
Second
and
it,
the
overall
topic
is
interesting
because
I
went
and
do
some
exploration
and
it
seems
that
kubernetes
itself
and
golem
is
and
so
on
are
not
using
ghost
second
static
analysis,
so
it's
either.
We
will
be
better
than
everyone
else
or
that
we
are
doing
redundant
stuff.
You
can
choose
the.
F
A
Okay,
moving
on,
I
just
noticed
in
the
chat
that
there
were
new
people.
I
I'm
just
pasting
again
a
link
to
the
meeting
notes
in
case
you
didn't
have
them
because
you
mentioned
you
are
new.
So
this
is
the
link
to
the
meeting
notes
and
a
reminder
that
to
get
edit
access,
you
just
have
to
be
a
member
of
the
hebrew
dev
group
and
I'll
take
the
opportunity,
I'm
sorry
to
put
you
folks
in
the
spot,
but
we
started
the
meeting
welcoming
a
new
member
federico
and
I
see
alice.
G
A
G
A
Yes,
thanks,
and
I
also
saw
and
sorry
again
for
putting
you
on
the
spot,
but
I
see
jordy
in
the
list
as
well.
He
joined
last
week,
but
last
week
we
kind
of
cancelled
the
meeting.
So
I
I
know
it's
not
your
technically,
not
the
first
meeting
you
joined,
but
it's
the
first
actual
meeting
you
joined.
So
I
wanted
to
say,
welcome
as
well.
If
you
want
to
say
hi
as
well.
A
H
A
A
You
cool,
there's
no
other
item
in
the
regular
agenda
list,
so
unless
anyone
has
anything
else,
I'll
move
to
the
open
floor,
where
I
added
an
item
just
to
mention
that
a
reminder
that
kubecon
is
coming
soon
in
a
couple
of
weeks
and
there
will
be
martin
sent
at
least
a
mailed
to
the
list.
A
couple
of
days
ago,
talking
about
his
session
on
cubert,
together
with
huamin.