►
From YouTube: KubeVirt Community Meeting 2022-05-25
Description
Meeting Notes: https://docs.google.com/document/d/1kyhpWlEPzZtQJSjJlAqhPcn3t0Mt_o0amhpuNPGs1Ls/
A
Of
course,
if
you
have
anything,
you'd
like
to
cover,
feel
free
to
add
that
to
open
floor
agenda
notes
or,
of
course,
pull
requests,
mailing
list,
reviews
and
bug
scrubs
that
we
need
to
pay
a
special
attention
to
you're,
welcome
to
drop
in
the
notes
and
go
ahead
and
introduce
yourself
if
you're
new
on
the
call
today
I'd
love
to
hear
what
brought
you
in.
B
All
right:
well,
I'm
new
on
the
call.
My
name
is
connor,
I'm
a
science
student
at
umass
lowell
and
this
year.
B
I'm
sorry,
I
will
I'll
see
what
I
can
do
I'll
get
back
to
you
in
a
minute.
A
A
All
right
so
we'll
come
back
around
to
connor,
and
if
we
want
to
jump
ahead
into
agenda
notes,
it
looks
like
we
want
to
discuss,
release
branches
and
things
of
that
nature.
Who
wants
to
go
ahead
and
pick
that
one
up.
C
I
try
okay,
so
we
were
discussing
about
what
we
want
to
support
regarding
release
branches,
because
at
the
moment
we
have
a
release
branch
every
month
and
the
back
porting
starts
to
get
a
little
bit
of
a
hassle,
and
so
we
were
thinking
about
probably
how
we
could
probably
some
formalize
something
like
what
we
exactly
want
to
support
for
how
long
at
the
moment,
I
don't
think
we
have
any
policy
on
that
and
yeah.
C
I
would
just
wanted
to
pitch
the
idea,
probably
that
we
would
probably
try
to
go
with
something
like
aligning
to
the
kubernetes
support
policy,
so
something
like
using
the
release
versions
from
kubernetes
that
were
were
not
out
of
date,
so
something
like
if
we
just
a
quick
example
of
a
release
branch
that
was
cut
a
year
ago
and
that
would
support,
for
example,
120,
119
and
118.
C
It
would
be
out
of
out
of
support
for
now
right
because
the
the
newest
version
of
that
would
be
120,
and
then
we
could
at
least
think
about
stopping
support
for
this.
That
would
be
one
idea
that
we
would
have
also.
We
might
probably
another
idea
that
we
had
would
probably
be
something
like
defining
special
long-term
support
branches,
but
we
actually
didn't
really
have
a
good
idea
on
how
to
formulate
this.
So
I
was
just
wanting
to
ask
the
community
on
their
point
of
view
over
this.
D
No
thank
you
for
bringing
it
up.
I
think
that's
great.
We
have
so
many
releases
and
we
see
it
sometimes
right
if
people
want
to
backboard
they
pay
for
like
12
releases
of
something
like
this.
D
I
would
split
it
though
right
I
mean
one
is
the
the
release
cadence
in
which
we
release
and
the
other
is
like
the
support
time
where
we
want
to
support,
and
I
think
we
should
at
least
reduce
the
number
of
artifacts
that
we
have
to
support.
So
I'm
at
these
with
you
with
that.
Do
you
think
that's
something
we
should
take
to
the
mailing
list
to
just
give
a
few
more
people
to
weigh
in
on
that
topic.
C
Yeah,
I
think
that
would
make
sense,
although
I
maybe
maybe
I
would
need
to
think
a
little
bit
about
how
the
suggestions
would
look
like
that
we
have
but
yeah.
Maybe
we
can
just
push
it
to
the
mailing
list
and
see
what
people
think
about
this
yeah.
I
think
that's
a
good
idea.
D
B
A
F
B
A
A
All
right,
okay,
so
back
to
agenda
item
two:
how
do
we
want
to
support
creational
patterns
when
adding
new
construction
methods?
Who
wants
to
pick
that
one
up.
C
We
were
discussing
about
some
progress
that
we
looked
at
and
we
had
an
internal
talk
about
patterns
that
make
the
software
of
the
the
code
look
better
and
better
understandable
and
more
readable,
and
we
wanted
to
think
about
how
we
could
support
this
knowledge
somehow
to
get
consumed
by
the
community
themselves.
C
But
we
didn't
really
have
a
good
idea
on
how
we
could
pitch
this.
Somehow,
I'm
not
so
one
special
example
would
be
something
like
a
creational
function.
That
would
create
a
structure
and
you
would
have
a
variatic
argument
on
the
on
the
function
which
way,
which
you
could
use
to
put
any
number
of
functions
that
would
manipulate
this
initial
or
created
structure
so
that
it
would
then
be
of
the
desired
state.
C
I
think
this
is
a
very
I
hope.
I
hope
that
this
is
understandable.
What
I'm
saying
without
any
any
pictures.
I
guess
that
said,
but
my
point
is:
we
want
to
improve
the
code
quality
for
everyone,
so
that
people,
so
that
people
don't
stumble
on
the
things
of
code
that
they
might
have
trouble
understanding
somehow,
and
we
wanted
in
general
to
get
the
opinion
on
how
we
would
go
about
pitching
this
idea
of
code
quality
and
how
to
improve
the
code
quality
to
the
community.
C
And
yes,
this
is
the
question
also
for
the
people
here
in
the
forum
and
yeah
I
I
can
understand
that.
Maybe
this
might
be
something
we
should
also
probably
take
to
the
name
of
this.
A
C
Yeah,
actually,
I
was
thinking
about
probably
something
like
a
simple
like
a
simple
tool
that
would
probably
scan
something
and
create
some
numbers
which
we
could
use
to
work
on
this,
so
that
we
would
at
first
see
the
worst
places
where
one
could
up
could
look
word
count:
minus
l,
yes,
yeah,
for
example,
something
like
that,
but
I
was
also
thinking
about
yeah
a
general
tool
like
I
saw
something
that
was
called
lizard,
which,
for
example,
also
supports
golang,
which
produces
numbers
for
lines
of
code
and
method,
links
and
cyclomatic
complexity,
for
example,
which
is
a
great
indicator
of
understandability
of
function.
G
H
C
Yeah
I
mean
the
ultimate
thing.
Is
that
something
that
you
can
automate,
of
course,
but
I
think
what
we
are
talking
about
is
something
what
sometimes
like.
Maybe
would
not
be
that
easy
to
automate.
So
I
think,
for
example,
also
readability
or
the
code.
Quality
itself
is
sometimes
a
topic.
That,
of
course
depends
on
the
taste
of
the
reader
right,
so
I'm
not
exactly
sure
how
to
automate
such
things.
I
So
basically
the
idea
is
to
have
some
basic
rules
that
we
all
can
agree
upon,
which
are
obvious
and
broadly
agreed,
and
then
we
can
test
it
either
by
a
lane
or
and
a
local
make
file
target.
So
people
would
be
able
to
do
something
like
make
lint
or
something
like
that,
and
they
see
that
they
don't
have
problems
in
their
code
or
at
least
the
more
obvious
ones.
C
Yeah,
to
give
just
one
example
what
we
were
talking
about,
so
I
can
add
a
little
bit
more
context
to
what
we
do.
What
I'm
trying
to
say,
we
were
looking
at
the
utils
go
in
the
tests.
Folder,
and
I
guess
everyone
that
who
contributes
to
the
tests
knows
that
it's
more
than
5000
lines.
C
Long
and
I
guess
we
have
separate
files
and
packages
for
a
reason,
and
I
guess
that
further
my
guess
would
be
that
we
could
probably
extract
stuff
that
would
create
or
modify
stuff
there
into
a
separate
file,
so
that
the
concerns
would
be
better
reflected
from
what
the
code
is
doing.
But
yeah.
I
just
I.
I
have
a
little
bit
an
idea
of
of
higher,
not
not
sure
how
to
say
that.
C
I
think
that
we
want
to
convey
the
the
the
importance
of
code
quality,
probably
to
the
community,
somehow
and
and
not
enforced,
but
encourage
the
this
behavior
of
trying
to
think
about
how
this
would
be
best
readable
and
not
just
getting
the
job
done,
but
also
don't
leave
any
chaos
behind
and
after
you're
done
just
go
away
and
leave
it
like
that.
Right.
I
All
right,
so
my
thoughts
on
this,
at
least,
is
that
you
can
split
the
problem
to
two
parts.
One
part
is,
can
be
automated,
it's
something
that
we
can
discuss
and
agree
upon.
For
example,
you
don't
make
a
certain
file
larger
than
it
is.
I
You
only
can
shrink
it
or
basic
rule
that
rules
that
we
cannot
agree
upon
and
the
other
part
is
stuff
that
I
I'm
not
sure
we
you
know
we
can
automate
because,
as
you
said,
it's
also,
you
know
there
are
a
lot
of
stuff
that
fit
certain
places
and
don't
feed
others
and
basically
for
code
qual
for
a
real
cult
quality.
I
think
that
we
need
a
human
to
to
make
a
real
review,
but
the
the
the
linter
is
is
a
great
start.
In
my
opinion,.
C
Yeah,
I
think
so
too.
I
think
we
we
might
just
settle
at
first
try
to
establish
the
linter
and
and
to
then
pick
up
again
on
this
discussion
on
how
to
create
the
awareness
of
what
probably
good
code
is
and
and
how
we
could
probably
improve
on
this.
I
think.
D
That's
just
for
note,
I
think
we
had
a
linter
a
while
ago,
sonar
cloud
or
sony
cube
one
of
the
two,
and
that
was
quite
picky
right
even
about
details.
So
I
think
in
the
end,
we
should
take
care
that
it's
reasonable
right,
because
if
we,
if
we
block
on
something
it's
like
you
know,
false
positives,
that's
worrying
us
out
as
well.
So
just
just
my
two
cents
added.
C
Chime
on
you
know
this.
What
fabian
just
said-
and
I
agree
with
you
avicii.
C
We
have
the
separate
initiative
trying
to
bring
gosek
into
this,
and
this
just
suddenly
died,
because
I
think
there
were
so
many
problems
with
integrating
it
because
we
were
not
starting
on
the
green
field,
but
we
were
just
trying
to
bring
it
in
and
we
discovered
so
many
problems
that
we
had
to
incrementally
try
to
fix
it
and,
in
the
end,
the
the
the
work
that
was
that
had
to
be
done.
C
C
I
So
so
I
think
that
it's
it's
a
problem
to
enforce
many
many
rules
with
the
linter
like
take
a
some
linter
off
the
shelves
and
and
expect
the
code
to
be
perfect
by
its
standards.
I
think
this
might
be
too
much.
I
think
that
what
we
need,
or
or
at
least
as
a
start,
is
something
that
is
to
just
point
out
the
obvious
to
just
point
out
what
is
agreeable
upon
everybody,
and
I
really
relate
to
what
alicia
said.
J
I
just
wanted
to
say
that
there
is
actually
a
standard,
even
in
in
the
project
that
are
under
conflict
at
the
moment,
and
the
standard
is
not
solar
that
that
tool,
it's
which
is
not
open,
source
and
and
has
like
it's
the
cloud-based
and
not
that
cannot
use
it
locally,
and
so
there
is
a
standard
and
many
projects
are
using
a
standard
linter.
It's
like
a
collection
of
many
linters
and
I
think
we
should
start
with
it,
and
I
I
suggest.
C
A
All
right,
then,
that
sounds
like
a
good
plan
on
the
next
item.
It
looks
like
we
have
an
incomplete
spot.
Does
anyone
want
to
fill
in
the
blanks
there.
C
We
had
a
couple
of
discussions,
so
the
thing
was
that
we
wanted
to
probably
have
some
areas
of
concern
inside
cuba
tuber
when
we
are
going
to
assign
prs-
and
I
just
wanted
to
reiterate
on
this
discussion-
I
think
we
had
this
already,
I'm
not
exactly
sure
if
that
was
by
the
mailing
list
or
and
what
else,
what
other
forum
it
was,
but
maybe
that
we
wanted
to
have
some
special
groups
for
special
areas
of
code
that
would
be
touched,
and
we
would
then
automatically
try
to
assign
those
groups
to
that.
C
K
F
Yeah
exactly
that
we
were
discussing
previously
in
another
meeting,
so
the
aim
is
to
at
least
see
if
we
can
divide
the
project
into
some
subjects
and
if,
if
it's
required,
maybe
to
consolidate
the
areas
of
code,
whether
it's,
for
example,
storage
network,
I'm
just
giving
you
know,
brainstorming
examples.
Migration
build
handler
with
launcher
into
such
scopes
and
assign
the
owners
for
these
scopes,
and
I
believe
this
may
do
some
optimization
in
the
way
we
do.
F
Currently,
we
are
reviewing
pr's,
because
today
pr
could
be
like
end
and
then
the
reviewer
on
who
will
need
to
know
like
it's
better.
For
instance,
we
have
to
know
all
the
cross
project
details
which
makes
it
more
complex
to
react
effectively
and
immediately,
to
be
honest,
especially
to
prs
that
introduce
some
some
new
features
to
the
project
that
touch
almost
every
corner
in
the
project
itself
yeah.
So
that
was
my
idea,
and
I
think
this
was
also
discussed
before
about
separate
simulation
of
concerns.
L
J
No,
but
it's
I
think
the
problem
is
that
that
is
not
enough.
The
problem
is
that,
for
example,
at
this
moment,
because
the
structure
of
the
project
is
not
it's
not
following
the
the
content
I
will
say
or
the
responsibility,
then
then
it's
hard
for
for
the
bottom
to
assign
the
right
person
to
do
the
review,
for
is
if,
for
example,
there
is
a
network
folder
and
under
the
metaphor,
you
can
put
a
specific
owner
with
with
maintenance.
J
F
Yeah
I
mean
I
meant
to
do
some
more
deep
separation
yeah.
They
may
come
with
the
cost
of
breaking
the
code.
Any
person.
F
A
Pieces,
do
we
have?
Is
there
something
I
can
mute.
F
L
L
Yeah,
I
think
it's
just
a
matter
of
of
of
people
tagging
the
the
correct
interest
group
same
way.
It
does
work
for
for
kubernetes
itself.
There's
a
oh.
B
L
Sig,
network,
signaled,
and
so
on
I
mean
just
to
me
just
a
matter
of
more
reviews,
people
reviewing
more
and
they
are,
on
the
second
hand,
it's
on
the
other
hand,
it's
just
adding
more
more
labels
that
would
focus
the
interest
of
people.
F
J
Okay,
I
can
just
tell
you
that,
at
least
in
networking
we
did
we
did.
We
did
something
like
that
and
I
think
it
covers
90
of
the
code.
So
what
we
did
is
we
extracted
most
of
the
networking
logic
to
a
package
like
you
can
consider
it
like
a
library
so
and
that
library
is
accessed
by
the
all
the
other
components
like
the
wheel
handler
and
the
build
launcher
and
whoever
needs
it.
Whoever
needs
services
from
that
library.
J
C
But
that
would
produce
a
lot
of
work,
because
I
think
this
would
mean
that
a
lot
of
refraction
would
have
to
be
done
for
that
to
work
somehow,
and
so
I
think
an
immediate
solution
would
rather
be
than
better
or
better
to
go
with
some
adding
adding
a
sig
network
or
something
like
that
on
the
pr.
C
So
I
think
what
what
matters
here
is
that
the
area
of
concern
is
is
somehow
expressed
in
the
pr,
and
maybe
my
idea
with
with
some
special
owners
assignments
is
not
that
ideal.
I
think
like
like
vladik
just
said.
I
think
there
are.
There
might
be
a
lot
of
touch
points
for
several
things
in
the
pr
and
maybe
the
concern
or
what
what
is
touch
should
be
expressed
by
a
label
on
the
pr
so
that
those
people
know
what
to
look.
For.
Probably
I
don't
know
if
that
makes
sense,
but
yeah.
L
A
I
I
So
currently
we
don't
really
have
a
deprecation
policy
which
is
problematic
because
we
do
support
many
stuff
because
of
backward
compatibility
and
these
stuff
are
being
accumulated
and
nobody
really
wants
to
deprecate
anything
because
we
don't
have
a
process
for
it
and
therefore
I've
opened
this
issue
and
it
would
be
great
if
many
people
from
the
community
can
participate
and
look
and
take
part
of
it.
I
Because
I
mean
it's
only
good
if,
if
it
had
has
a
broad
acceptance
and
yeah,
that's
basically
it
we're
just
in
the
beginning
of
the
discussion
so
yeah.
I
welcome
everyone
to
take
part
of
it.
I
I
So,
just
as
an
example,
what
david
suggested
for
future
cases
basically
to
first
make
sure
every
feature
under
the
feature
gate
is
on
by
default
and
then
raising
some
kind
of
a
warning.
If
somebody
enables
this
feature
gate
and
after
some
some
releases,
we
can
remove
it
all
together
after
asking
in
the
mailing
list
and
verifying
that
nobody
uses
it.
So
this
is
an
example
for
the
application
policy
for
future
gates.
I
I
I
mean
for
some
of
them
yeah
I
mean
if,
for
example,
okay,
so,
let's
take,
for
example,
the
live
migration
feature
gate.
Let's
say
we
want
to
deprecate
it.
So,
first
of
all,
we
should
allow
live
migrations
to
occur
by
default,
and
then,
basically,
if
this
feature
gate
is
enabled
or
disabled,
it
doesn't
really
matter.
So
we
just
have
to
warn
the
user
about
our
intention
to
deprecate
it
in
the
future
and
make
sure
that
nobody
is
using
it
and
after
a
while,
we
can
remove
it
all
together.
M
So
this
is
not
more
about
deleting
the
whole
feature,
but
this
is
about
moving
them
into
production
state.
Yes,
exactly.
D
Yeah
by
the
way,
itamar
first
great
great
to
see
that
we
started
that
discussion,
but
I
think
the
other
way
is
probably
also
worth
documenting
right.
What
how
do
we?
How
do
we
remove
a
feature
eventually
again
like,
for
example,
I
think,
for
example,
the
oh
well
host
path?
We
probably
want
to
keep
it
right.
D
I
don't
have
a
good
example
yeah.
I
wonder
if
it's
worth
to
I
looked
at
the
pr
and
I
think
what
I'll
comment
is.
Maybe
look
at
the
broader
life
cycle
right.
How
do
we
introduce
a
feature
gate?
What
does
that
mean
for
the
api
you
know?
Do
we
accept
it
to
be
an
alphabet
or
a
ga
right
away
and
then
to
see
how
do
we
get
get
it
to
ga?
So
maybe
if
we
can
extend
that
in
dpr
a
little
bit,
I
think
that
would
be
helpful.
I
Yeah
sure,
so
I
completely
agree
with
everything
you
said.
These
are
important
topics
that
we
should
discuss
and
I
don't
have
all
the
answers
and,
to
be
honest,
this
pr
was.
The
intention
was
just
to
kick
off
the
process
and
have
you
know
some
kind
of
a
of
an
initial
document
so
that
people
would
be
comfortable
working
on
and
improving
over
time.
A
O
O
What
the
other
one
is,
and
it's
kind
of
container
con,
which
is
no
longer
part
of
the
cube
gun,
kvm
forum
and
double
and
open
source
summit,
are
both
in
dublin
and
they're
offset
by
about
a
day
or
two,
and
so
it
kind
of
makes
sense
that
if
we
can
be
at
one,
we
can
be
at
the
other.
O
Kubecon
us,
which
is
in
detroit
this
year
is
also
has
its
calls
for
proposals
closing
on
june
3..
So
it's
been
extended
by
a
week.
That's
in
detroit
in
october.
All
these
details
are
in
the
email
that
I
sent
out.
Yeah
it'd
be
really
great.
If
we
could
have
representation
at
all
of
these,
if
possible,
they
all
definitely
suit
the
project
and
do
you
ever
saw
some
in
the
kvm
forum?
O
I
think,
because
they're
less
towards
kubernetes
audience,
maybe
an
interesting
place
for
us
to
present
to
people
that
don't
perhaps
know
that
running
virtual
machines
alongside
containers
is
necessarily
a
thing.
Obviously,.
O
A
Actually,
yeah
on
that
topic
stitch,
how
did
your
talk
go
in
valencia.
O
It
went
sorry
you're,
good.
O
It
was
really
great
I'll,
just
throw
some
enthusiasm
out
there.
It
went.
I
thought
it
went
really
well,
but
I'll
I'll.
Let
lha
kind
of
talk
about
the
more
technical
aspects.
G
Yeah
right
nice,
I
I
will
send
some
notes
in
the
mailing
list.
Yeah
I
was
nice.
We
did
virtual
office
hours
in
the
morning
wednesday
morning.
I
think
there
were
around
30
attendees.
We
had
values.
Demo
was
very
nice
yeah
in
the
in
the
afternoon
we
had
the
maintainer
track.
G
The
recording
will
be
available
by
june
6.,
so
yeah
people
were
very
interested
in
running
windows
vms.
That
was
something
with
gpus.
That
was
one
of
the
questions
I
got
and
then
so
are
you
prepared
vm
disk
to
be
run
with
cubert
live
migration
was
also
interesting.
A
Great
thanks
for
representing
there
there's
definitely
interest.
So
if
people
feel
inspired
to
carry
the
torch
to
other
conferences
and
such.
O
Definitely
and
the
kubecon.
This
is
in
my
most
recent
email
that
I
sent
out
today.
It
wasn't
my
previous
one.
The
cncf
offers
specifically
for
kubecon
us
a
review
process
for
first
time
or
unsure
proposals,
so
I've
included
the
form
in
there
for
that.
O
I
don't
yet
know
if
the
linux
foundation
offers
the
same
for
kvm
forum
and
open
source
summit,
but
if
I
can't
wrestle
up
a
a
link
for
like
a
review
squad,
then
I
highly
recommend
people
bring
any
topics
to
the
mailing
list
or
to
we
can.
If
we've
got,
if
there's
someone
here
now,
maybe
that
we've
got
time
to
to
bring
it
up
quickly.
Just
so
we
have
more
heads
are
better
than
one
but
yeah.
O
A
All
right,
I
don't
hear
anyone
just
rushing
to
the
mic
to
volunteer
for
speaking,
but
definitely
consider
it.
A
A
A
C
C
At
the
moment,
I,
what
I
think
is
that
that
he
could
just
pull
the
container
images
from
the
from
the
from
from
the
operator.
Probably
I
think
that.
C
There
so
or
from
the
one
of
those
from
the
cuba
manifest,
I
think
they
should
be
inside
there.
A
Yeah,
I
mirrored
like
dozens
of
operators
regularly
when
I
was
at
red
hat
into
air
gaps,
and
the
standard
tooling
seems
to
be
pretty
functional
for
that
and
I
didn't
see
edge
cases
for
any
of
the
red
hat
operators.
Some
of
the
community
operators
were
usually
frequently
had
other
obstacles
that
they
would
throw
in,
but
the
red
hat
operators,
the
manif
the
digest
manifests,
are
pretty
complete.
A
C
So
I
think
this
is
an
issue
that
we're
facing
for
a
longer
time
now
and
I
think
it's
it's
legit
to
just
cut
down
on
or
just
remove,
the
failure
to
execute
commands
on
a
part
that
is
not
running
anymore.
If
I
understand
correctly,
yeah.
A
A
Okay,
actually,
I
still
have
not
submitted
a
request
to
join
the
organization,
so
I
can't
triage
you,
okay.
I
need
to
do
that
this
week.
A
K
B
A
K
C
I
think
this
should
be
more
more
precise
than
it
is
now.
C
C
M
A
Really
ch
responded
to
that
one.
Thank
you.
H
O
E
A
A
C
K
C
Yeah,
to
be
honest,
I
I'm
a
little
bit
I
I
was
just
mumbling
to
myself,
so
I
keep
quiet
for
another.
Sorry.
A
You
know
you're
fine.
I
actually
have
to
drop
right
now.