►
From YouTube: KubeVirt Community Meeting 2021-08-18
Description
Meeting Notes: https://docs.google.com/document/d/1kyhpWlEPzZtQJSjJlAqhPcn3t0Mt_o0amhpuNPGs1Ls/edit#heading=h.myv2pg5x3tya
A
B
C
A
C
Nope
going
once
twice
guess
not
all
right
so
for
our
agenda.
We
have
one
item
so
far
and
I'll.
Let
ed
take
the
floor.
E
This
is
a
small
one.
I
hope
during
one
of
the
reviews
there
was
question
there
were
some
questions
if
we
need
to
add
a
header
license
for
each
file
which
source
file
that
we
create
so,
but
what
I
saw
in
other
in
kubernetes
and
in
the
rest
of
the
project.
It
is
done
like
that,
but
it
seems
like
it
is
not
thrust,
it
is
not
enforced
and,
secondly,
not
sometime,
it
is
not
done
either
missed
or
it's
not
a
must,
which
is
odd.
A
little
bit
yeah.
F
It
is
not
a
must,
we
can
decide
to
do
it
because
many
do
it,
but
it's
from
a
legal
point
not
a
must.
We
clarified
that
at
some
point.
A
E
C
I
kind
of
like
having
the
header
there,
but
it's
not
a
my.
I
don't
know
I
don't
know
we
just
need
to
spend
a
whole
lot
of
time
on
it.
The
reason
I
like
that
header
is
when,
for
example,
when
we
pull
in
something
from
kubernetes,
sometimes
we
pull
in
the
actual
source
files.
F
C
F
E
G
I
think
that
we
can
probably
steal
some
some
or
copy
some.
Some
things
from
I
seen
that
kubert
test
infra,
for
example,
does
that
so
that
it
checks
for
files
or
for
for
such
commands
being
being
around,
and
if
they
are
not
there,
it
adds
it
somehow
so
yeah.
E
F
Yes,
it
should
then
be
the
copyright
should
then
be
for
the
cupid
project
and
not
for
the
individual
contributor
and
the
individual
contributor
is
with
signing
the
commit
approving
that
he
has
right
the
right
to
give
that
copyright
to
the
keeper
project.
F
E
So
so
maybe
that's
what
david
said
like
if
you
take,
if
you
take
something
from
covet
for
kubernetes,
for
example,
from
some
other
project,
then
you
are
supposed
to
keep
the
copyright
right.
Yeah
you
need
to
edit.
So
that's
the
only
place
where
it's
a
must.
I
guess.
E
C
D
Can
you
hear
me
yep
yeah,
so,
on
the
all
things
open
conference,
that'll
be
the
16th
through
the
18th
of
october,
and
the
possibility
was
raised
that
it
might
be
possible
for
for
us
to
have
a
virtual
booth,
and
I
was
just
hoping
to
try
and
bring
that
to
this
forum
and
see
if
there's
any
interest
in
that,
because
of
course
that
will
require
volunteers
and
coverage
to
staff.
You
know,
as
a
virtual
booth,
of
course,
there's
no
travel
requirement
in
this.
D
It's
just
that
we
do
need
to
probably
have
coverage
throughout,
at
least
the
european
and
american
work
days.
I'd
say
probably
late
afternoon.
Europe,
because
I
think
all
things
open
is
in
raleigh,
so
it'd
be
late
in
the
day
in
europe
and
within
the
work
day
in
the
us.
D
Okay,
I
will
bring
that
to
the
mailing
list
and
see
if
anybody
would
be
willing
to
volunteer
that
way
or
if
this
is
just
something
that
we
don't
have
the
the
staffing
for.
At
this
point.
D
I'm
interested
sorry,
I
missed
it.
Thank
you.
C
Okay
and
how's
that
conference
going-
I
guess,
you're
presenting
by
yourself
now.
D
Yes,
well,
you
know,
and
that's
that's
actually
an
interesting
question
that
we're
negotiating
right
now
is
whether
or
not
the
delta
variant
is
really
making
it
a
good
idea
to
travel
at
this
point
you
know
in
in
the
absence
of
any
other
guidance,
so
I
you
know
honestly,
I
would
say
it
may
be
up
in
the
air
whether
or
not
this
is
going
to
be
an
in-person
or
a
virtual
event
at
this
point
anyway,
so
you
know-
and
so
I
yeah
I,
I
unfortunately
have
to
give
you
an
uncommittal
answer
about
that.
D
C
C
Okay,
so
moving
on,
we
have
some
pull
requests
that
need
attention,
so
the
first
one
daniel
it
looks
like
you
have
one
did
you
want
to
talk
about
that.
G
Yeah
sure
this
is
just
a
change
in
the
pre-submit
pre-submit
checks
for
the
cupid
project
for
the
provider
of
121..
G
G
C
G
At
the
moment
not,
I
think
I
think
we
only
have
at
the
moment
we
have
just
support
for
119
throughout
121.
We
are
still
working
on
on
the
122
kubernetes
support.
But
when
that's
done,
when
the
provider
is
present
and
jobs
are
there,
then
we
could
drop
119
but
yeah
we're
not
there.
Yet,
okay.
G
C
C
Yeah,
I
think
that's
what
we
agreed
a
long
time
ago,
and
I
think
the
reason
for
that
was
that
was
the
number
of
versions
that
kubernetes
actually
supports.
So
they
have
like
a
rolling
three
previous
three
versions,
as
we
at
least
know
that
we're
staying
compatible
with
what
the
kubernetes
upstream
is
supporting
yeah.
G
Yeah,
at
least
we
have
automation
in
place
to
automatically
create
new
providers
and
and
create
the
check
pre-check
provisioning
for
those
new
providers.
We
are
still
in
the
process
of
creating
the
new
automation
for
the
for
the
new
jobs
that
need
to
get
created
on
that
which
I'm
currently
looking
into
and
yeah.
When
we
did
when
we
are
there,
we
could
also
automate
dropping
all
those
old
providers
that
are
not
needed
anymore.
A
E
E
Is
it
like
intentional,
and
there
are
other
changes
to
the
which
I
don't
understand
what
they
are,
but
so
how
did
how
this
automation
change
all
of
this
stuff.
G
Regarding
the
changes,
this
is
a
formatting
change
like
we
are
consuming
the
yaml
from
go
code
and
updating
the
required
fields
on
the
jobs
and
yeah.
If
you
have
seen
something
that
was
not
previously
required
and
is
not
required,
that
might
be
a
bug,
but
I
think
I
personally
checked
and
it
it
only
removed
obsolete
default
values.
G
If
I,
if
I
am
correct
but
yeah,
please
team
leads
on
the
other
teams.
Please
check
again
whether
that
is
somehow
the
case
that
there
are
boxes,
something
that
is
what
pull
request.
Reviews
are
for,
I
guess
yeah,
but
but
I'm
going
back
to
check
that,
but
yeah
the
formatting
changes
come
through
consuming
this
yummle
and
then
changing
that
you
know
I'm.
I
was
not
wanting
to
just
doing
something
like
an
sd
or
something
on
on
those
all
those
files.
G
I
was
rather
hoping
I
could
just
reuse
the
kubernetes
available
definitions
for
those
jammels
and
just
change
the
fields
and
then
write
them
back,
and
I
think
this
is
also
better
because
in
general,
I
think
that
all
those
jamal
definitions
of
jobs
are
all
in
general
should
should
be,
for
example,
should
be
alpha,
sorted,
alphabetically
and
so
on,
and
that
is
also
what
the
re
serializing
of
the
new
of
the
new
definition
does.
C
All
right
anything
else
in
that
topic
before
we
move
on
to
a
pull
request,
that
kevin
has.
H
Okay,
my
yeah
still
didn't
like
my
microphone.
I
just
wanted
to
bring
the
shadow
here
really
quick,
because
it's
been
around
for
a
bit
for
the
go
routine
leak
we
had
merged.
I
think,
last
week
we
I
had
to
do
a
different
fix
for
everything
below
release
0.41,
because
we
are
on
all
the
go
language
and
that
doesn't
expose
an
error
and
that
back
port
would
need
review
or
approval.
If
anybody
is
interested
last
time
and
then
we
can
finish,
the
jar
picks
for
all
the
other
releases.
Behind
that.
H
The
difference
is
starting
with
go
1
14.
I
think
the
net
package
exposes
the
error
error
closed
that
gets
returned
when
you
are
reading
or
writing
on
a
closed
network
connection
before
that
it
didn't
for
some
reason
and
I'm
using
that
in
the
up
to
date
fix,
but
the
only
way
to
find
out
if
the
network
connection
was
closed
is
to
check
now
with
the
previous
op
error.
H
C
That's
interesting,
so
should
we
be
checking
for
both
of
these
I'm
uncertain?
What's
the
side
effects,
for
example,
if
somebody
tries
to
build
our
current
cuvert
main
branch
with
a
old
version
of
golang,
well
things
just
unexpectedly
known
it.
C
B
C
That's
better!
That's.
C
H
C
Just
to
use.
H
H
I
thought
about
that.
I
wouldn't
know
how
I
mean
we
could
add
another,
listen
on
the
listener
and
see
if
that
gets
closed
in
a
unit
test,
but
it
wouldn't
guarantee
that
you
go
routine
goes
away,
just
guarantees
that
close
is
called
at
some
point,
but
that
doesn't
fix
the
goal.
Routine
problem
itself.
C
C
H
C
C
I'm
curious
if
we
had
a
functional
test
and
we
got
a
go
routine
dump
using
that
new
pprof
tool
that
I've
been
working
on
is
there
any
way
we
could
introspect
that
to
discover?
If
would
they
even
be
practical
to
discover
if
any
of
these
are
left?
If
we
know
no
more
vm
eyes
exist
in
the
system,
we
would
expect
to
see
no
go
routines
in
a
certain
package
or
something
like
that.
H
That
would
yes,
I
think
we
could
check
for
the
promised
word
handler
this.
This
stuff
is
in
the
word
handler
package.
H
It's
right,
very
generic.
The
exact
path
could
be
tracked.
I
think
something
we
would
want
to
look
at
more
in
general.
Is
adding
leftover
go
routines
somehow
to
our
general
control
plane
tests
to
see
if
apr
introduces
leftover
routines
after
a
density
test?
Somehow.
C
Yeah,
we
can
talk
about
that
in
sixth
scale,
interesting
yeah.
This
is
something
else
for
us
to
begin
thinking
about
when
we
look
at
code
reviews
and
think
about
scaling
and
this
issue,
if
it
manifested
itself
as
an
actual
problem
over
time,
would
it
be
that
memory
keeps
on
increasing
because
our
go
routines,
even
though
these
are
kind
of
these
card
chains?
Don't
do
anything
really
except.
H
The
the
general
low
cpu
load
off
the
vert
handler
increasing
and
at
some
point
when
there
was
too
many
leftover
guru,
jeans
virginia
didn't
I
I
can't
prove
that
it
was
the
case
because
of
that
could
also
have
been
just
overloaded
cluster.
But
since
some
cases
first
handler
goes
completely
crazy
and
until
all
vms
are
deleted,
and
it's
kind
of
like
it's
cp
very
handle,
cpu
load
stays
up
and
doesn't
go
down
at
some
point
and
some
of
our
q
people
have
seen
the
same,
but
I
still
can't
prove
it's
because
of
this.
Okay.
C
H
C
H
Mean
the
best
way
I
I've
only
done
it
for
red
handle,
I
think
about.
I
thought
about
doing
it
for
more
places,
but
actually
how
to
find
those
before
we
have
p
profits
easier
now,
but
it
was
just
search
all
files
in
our
code
base
for
ghost
go
space.
H
No,
I
I
wouldn't
know
where
to
put
it,
but
I
think
it's
some
places
we
can
be
more
aware
of
when
we
when
and
how
we
start
their
routines
to
make
sure
we
clean
up
and
if
we
really
need
them.
C
Yeah
some
of
the
there
are
some
patterns
that
we
can
begin
to
look
for
more
closely
like
one
of
the
ones,
the
simplest
one
that
I
think
you
identified
when
you
were
doing
this
investigation.
The.
C
Channels
get
us
in
trouble
a
lot
because
we
attempt
to
write
to
an
unbuffered
channel
and
a
go
routine
and
then,
if
something
happens,
where
it's
not
red
or
whatever
it
just
hangs
in
forever
and
that's
a
problem.
Okay,
so
I
guess
we
can
go
on
to
the
mailing
list
now
and
I
don't
think
we
had
a
whole
lot
of
new
items
here
from
last
week,
the
only
one
that
I
see.
C
So
we
have
two
that
I
see
it's
sr
iov
network
issue
which
it
looks
like
we
already
have
people
responding
to.
Is
there
any?
Does
anybody
have
an
update
on
that,
or
is
that
worth
discussing
in
this
form.
C
Cuber
srov
network
issues,
I'll
post,
a
link.
Sorry,
I
can't
share
my
screen
easily.
I
was
not
prepared
for
this,
but
this
is
the
keeper
dev
mailing
list
post
that
I'm
talking
about,
and
we
don't
have
to
talk
about
here.
If
it's
not
pertinent,
I
was
just
given
the
opportunity
to
discuss
it
further
if
it
made
sense.
C
Okay,
it
sounds
like
it's
just
debug
trying
to
figure
out
where
packets
go.
E
C
C
Well,
maybe
this
is
mainly
focused
on
the
amd
suv
extension,
which
I
think
that
encrypts
memory
yeah,
where
did
we
get
here?
Is
there
anything
new
worth
talking
about.
H
All
right,
do
you
want
to
talk
about
it,
or
should
we
do
we
have
another
one?
We
want
to
look
at.
C
C
Are
you
concerned
about
the
way
the
api
is
being
constructed
right
now
or
it
sounds
like
you're
uncertain
about
how
it's
going
to
change
in
the
future,
so
we
might
box.
C
I
Yeah,
I
mean
mainly
I
I
don't
know
I
mean
if
we
were
going
to
do
the
station
in
a
certain
way,
I'm
just
not
sure
just
learned
securely.
Also,
it's
it's
a
term
that
I
think
was
taken
from
liberty,
but
I
think
the
general
discussion
right
now.
It's
for
confidential
confidential
computing
and
I
think
the
the
overall
api
may
change.
I
So
I
don't
know
if
we
are,
what's
the
current
benefit
of
just
introducing
this
device
right
now
without
the
attestation,
so
I
just
not
sure
I
mean
I
would
like
vasily
to
to
answer
or
somebody
to
clarify.
I
C
Okay,
I
guess
we
will
leave
this
on
the
mailing
list.
Then
let's
look,
do
we
have
anything
else?