►
From YouTube: KubeVirt Community Meeting 2021-10-13
Description
Meeting Notes: https://docs.google.com/document/d/1kyhpWlEPzZtQJSjJlAqhPcn3t0Mt_o0amhpuNPGs1Ls/edit#heading=h.4m5rv0vnpx2a
A
Hello,
everyone:
it
is
wednesday
october
13th
2021..
I
am
here,
I'm
chris
caligari,
I'm
the
host
of
audio
issues.
A
Oh
hello,
I
can
hear
you
just
fine
still
well
anyway,
welcome
to
the
weekly
community
meeting
for
project
kubvert,
and
this
is
your
chance
to
talk
to
the
project
core
developers
and
and
other
users
about
user
issues
and
and
bugs
or
new
features
anything
you
want.
A
I'm
gonna
post
our
meeting
notes
into
chat.
If
you
could
please
fill
in
your
attendance
that
is
tracked,
and
we
appreciate
that.
A
Okay:
okay,
david:
were
you
filling
in
that
first
agenda
item.
B
So
many
windows
open
okay,
so
I
am
trying
to
improve
the
debug
of
virtual
machines
and
the
relationship
between
virtual
machines
and
all
the
underlying
objects.
So
when
a
virtual
machine
is
created,
it's
often
associated
well,
it's
always
associated
once
we
started
a
virtual
machine
with
a
vmi
and
then
an
underlying
pod,
but
then
there's
also
other
things
that
are
associated
with
the
virtual
machine,
like
data
volumes
which
handle
the
import
of
disks
on
the
pvcs
or
cloning
of
disk
on
pvcs,
and
we
might
even
have
more
objects
in
the
future.
B
So
when
we
are
looking
at
what's
going
wrong
with
the
virtual
machine,
we
kind
of
have
this
one-to-one
relationship
with
lots
of
objects
underneath
it
sometimes
one-to-many,
depending
on
what
it
is,
and
it
can't
always
be
obvious
like
what
has
occurred
and
if
it's
bad
or
why
we're
in
a
certain
state.
It's
been
improved
quite
a
bit
with
the
introduction
of
this
new
printable
status,
feature
that
gives
like
a
high
level,
aggregated
understanding
of
the
current
status
of
a
virtual
machine.
B
B
I
just
want
to
verify
so,
for
instance,
if
we
create
a
virtual
machine
today
and
try
to
start
it
and
there's
not
enough
resources
for
it
or
something
like
that,
we
have
to
drill
in
several
layers
to
understand
why
the
scheduling
problem
has
occurred.
B
What
I'd
like
to
do
is
begin
aggregating
conditions
from
the
vmi
onto
the
vm
and
we've
kind
of
hand
picked
a
few
so
far
that
actually
exists
today.
So,
for
example,
if
you
pause
your
virtual
machine,
we're
actually
getting
a
condition
on
the
vmi
that
live
instances
pause
and
we're
syncing
that
back
to
the
virtual
machine,
I'm
proposing
that
we
just
do
that
with
all
aggregate
like
all
conditions.
So
we
have
that
debug
information
on
the
top
level
object,
which
is
the
virtual
machine
so
first
off.
How
do
people
feel
about
that?
B
E
It
before
I
think
yeah,
we
were
thinking
about
things
like
this
for
pretty
long
time
on
how
to
make
it
better
fuel
on
the
vehm,
and
I
think
we
really
need
to
do
something
there,
and
this
is
probably
one
thing
we
can
do
pretty
easily
and
with
a
good
impact
on
the
usability.
F
Between
will
it
happen
automatically,
I'm
trying
to
understand
what,
if
the
the
condition
and
the
vmi
will
will
change
rapidly?
How
fast
will
we
update
it
on
the
vm.
B
As
fast
as
the
informer
tells
us
of
those
changes
and
the
vm
is
reconciled,
so
it's
just
in
the
normal
vm
update
status.
Let
me
just
sync.
B
Okay,
here's
here's
my
hard
question.
We
have
a
condition
on
the
virtual
machine
today.
I
think
it's
just
called
failure
or
something
like
that
and
I
think
that's
inaccurate,
because
we
don't
really
have
failures.
We
have
conditions
that
represents
a
an
error
state.
That's
evidently
consistent,
so
failure
seems
permanent
and
that's
not
necessarily
the
case,
so
that
probably
needs
to
be
renamed.
But
what
that
condition
is
doing.
Is
it's
detecting
if
there
is
any
sort
of
error
that
occurred
during
our
reconcile
of
a
virtual
machine?
It's
setting
this
failure
condition.
B
What
am
I
representing
with
that
specific
condition?
Because
it's
trying
to
represent
the
state
of
two
controllers
at
the
same
time
yeah?
I.
E
The
the
zoom
condition
also
doesn't
seem
to
be
such
as
a
good
name
for
the
vm
for
condition
on
the
vm,
because
the
sync
condition
is
very
specific
to
synchronization
between
vertendla
and
qemol,
divert
with
launcher.
So,
if
synchronized
on
the
vm
would
then
also
maybe
compete
with
other
things
like,
I
can't
reach
it
in
order.
So
I'm
not
sure
if
this
is.
B
Derived
that's
interesting.
It
was
synchronized
yeah.
I
didn't
realize
that
we
were
considering
the
relationship
to
the
node.
I
was
thinking
that
synchronized
was
the
relationship
of
how
is
this
virtual
machine
instance
being
reconciled
successfully.
E
E
E
G
B
So
we
do
set
the
synchronized
condition
at
the
cluster
level
on
the
bmi.
B
I
think
that
there
should
be
a
precedent
that
precedence
a
priority
given
to
the
synchronized
condition
on
the
vm,
where,
if
a
synchronization
error
occurs
at
the
vm
layer
that
it
is
set
as
the
vm's
condition
and
if
there
happens
to
be
both
a
vm
and
a
vmi
synchronized
error,
the
vm
takes
precedence
over
the
vmi
and,
if
there's
no
vm,
synchronized
condition
or
whatever
or
it's
not
set
to
false
that
we'll
take
one
that's
set
to
true
or
the
other
way
around.
B
Basically,
if
an
error
occurs,
we'll
take
the
vmi
one
and
display
that
in
the
vm
does
that
make
sense
the
priority
I
know
now.
I,
like
my
suggestion
to
have
them
split
more
well.
The
problem
with
this
split
is
that
it's
really
common,
my
understanding
is
it's
really
common
to
have
a
status,
dot
conditions
structure
that
represents
all
the
conditions,
so
we
already
have.
Presumably,
for
example,
somebody
who's
building,
ui
components
on
top
of
keyverts
or
other
components
would
be
looking
at.
That.
E
Yeah,
it's
just
not
so
easy
to
see
them
from
where
something
is
coming.
Not
that
it's
easy
now,
it's
not
at
all
transparent
right
now,
but
it's
then
still
not
easy
to
exactly
see
where
something
is
coming
from,
especially
if
we
have
maybe
similar
names
conditions
which
have
which,
where
one
would
have
prefer
a
precedence.
B
Over
the
other,
this
is
the
only
one.
The
synchronized
and
failure
condition
are
the
only
ones
that
overlap.
B
I
don't
foresee
there
being
more,
because
I
mean
I
could
always
be
wrong
here,
but
there's
a
certain
level
of
responsibility
that
the
virtual
machine
controller
has
a
certain
level
of
responsibility
that
the
vmi
controller
has,
and
the
only
thing
that's
similar
today
is
that
both
of
them
are
trying
to
reconcile
style.
These
objects
and
report
errors
when
reconciliation
fails
yeah.
So.
B
So
the
question
is:
do
we
try
to
synchronize
these
two
conditions,
I'm
using
the
word
synchronized
too
often
here.
Do
we
try
to
unify
here
we
go
those
two
conditions
or
to
try
to
keep
them
distinctly
different.
What
do
we
feel
comfortable
with?
I
think
that
I
feel
comfortable
with
the
precedence
of
setting
a
priority
on
the
vm
controller,
without
causing
any
problems.
I
So
one
usage
model
that
I've
seen
I've
recently
been
doing
some
of
the
work
on
getting
argo
cd
to
understand
these
particular
resources
and
their
conditions.
B
E
E
E
I
have
to
look
it
up,
can't
find
it
now,
but
I
think
more
than
just
indicating
that
you
lost
note
yeah,
the
only
I
mean
we
have
to
think
the
sink
error
is
basically
always
a
good.
The
same
condition
or
the
failure
condition
on
the
vm
is
a
good
sign
of
that.
We
do
not
really
know
what's
going
on,
something
which
may
resolve
itself
is
happening,
but
we
have
no
clear
idea
what
it
is,
and
the
other
thing
is
when
notes
time
out
and.
I
Yeah,
I
think
that
is
actually
because
it
does
point
out
that
the
unknown
condition
could
go
either
way
right.
You,
you
see,
you
know
sometimes
you'll
see
a
pod
in
like
a
back
off
and
you're.
You
know
you
have
to
go
and
fix
something
with
a
registry
or
with
an
image
tag
or
something
like
that
or
maybe
you
just
had
a
network
problem
and
it
will
resolve
itself.
So
those
are
kind
of
hard
to
judge.
E
Yeah,
I
think
david's
proposal
is
also
good
for
your
rcd
case,
where
I
think
we
had
the
issue
that
one
thing
you
would
want
to
just
would
have
wanted
to
display
for
vms
was
only
visible
on
the
vmi,
but
you
didn't
have
the
positivity
at
the
car
at
the
position
where
the
state
is
calculated
to
do
to
get
that
information
from
other
objects
right.
I
E
B
What
do
you
mean
by
that?
Are
you
talking
about
merging
them
as
in
taking
the
reasons
and
messages
and
like
appending
them
so.
B
No,
the
failure
condition
is
the
equivalent
of
the
virtual
machine's
synchronized
condition
and
the
vmi.
E
I
agree
with
you
that
the
naming
is
very
unfortunate.
Yes
for
the
reasons
you
mentioned,
but
still,
I
think
we
would
at
least
need
a
backward
compatible
transition
path
if
we
decide
to
remove
one
of
it
really.
B
E
E
B
I
see
some
conditions
being
an
interface
to
the
larger
ecosystem
like
readiness
and
stuff,
like
that,
being
a
consistent.
B
Some
of
these
workload,
specific
conditions
like
they're,
specific
to
virtual
machines
like,
for
example,
pos
or
something
like
that.
B
I
guess
we
have
built
a
an
interface
for
that,
because
people
are
looking
at
that
to
determine
yeah.
This
only
way
to
determine
if
your
virtual
machine
has
been
paused
or
not.
B
So
I
guess
I'm
stuck
with
the
virtual
machine
failure
condition
today,
and
maybe
this
is
a
non-issue
because
I
will.
E
B
Okay,
I
think
I'm
going
to
take
everything
as
it
is
today
and
merge
it
onto
the
vm
and
leave
the
failure
condition
as
it
is
because
it's
a
it's
a
programmable
interface
that
we
need
to
maintain
support
for,
and
the
discussion
of,
changing
that
name
in
the
future
would
be
a
different
discussion
entirely.
So
we'll
have
failure
to
represent
the
virtual
machine
state
kind
of
like
whether
it's
being
recognized
or
not.
The
synchronization
will
represent
the
runtime,
so
the
virtual
machine
instance
ability
to
reconcile,
and
then
everything
else
is
pretty
self-explanatory.
B
All
right
that
works
for
me,
I
will
clean
up
this
failure,
condition
a
little
bit
because
it
has
some
inconsistencies
in
it,
but
I'll
do
that
in
the
pr
anything
else
in
this
topic
before
I
move
on
thanks
for
sorry,
I
think
I
took
way
too
much
time
on.
Oh.
A
That's
that's.
Okay.
I've
been
taking
a
look
over
at
the
agenda
to
see
if
anybody
filled
anything
else,
and
so
no
one
has,
and
I
just
let
you
run
okay.
A
Thanks
david
okay,
since
there's
no
other
agenda
items,
let's
move
on
to
open
floor,
which
I
have
the
first
bullet
point
to
talk
about
events,
just
as
a
reminder,
david
and
I
will
be
doing
an
office
hours
session
at
kubecon
n.a
tomorrow,
thursday
october
14th
at
1,
30
pm,
pacific
time
zone,
kubecon,
n
a
is
in
seattle.
A
So
time
zones
are
in
pacific
time
zone
and
I
am
bummed
because
the
con
is
the
conference
is
a
half
an
hour
drive
north
of
me
and
it's
too
risky
for
me
to
attend
in
person.
A
So
I
get
to
do
it
virtu
we
get
to
do
a
virtual
another
event
coming
up
all
things
open,
2021
in
raleigh
north
carolina.
This
is
a
a
major
red
hat,
sponsored
event
that
they've
been
doing
for
quite
a
while.
Now
we
are
due
to
present
kubernetes
and
cooper
on
raspberry
pi
and
it's
going
horribly.
A
So
I
don't
know
what
to
do
here.
If
anybody
here
is
interested
in
in
helping
us
debug,
I'm
I'm
gonna
leave
the
zoom
session
open
after
this
meeting,
so
we
can.
We
can
all
hack
on
it.
A
I
was
hacking
on
it
all
afternoon
yesterday
and
actually
was
able
to
get
a
hold
of
howard
from
arm,
and
he
he
gave
me
some
tips.
A
He
did
confirm
that
cooper
is
working
fully
on
on
arm
and
raspberry
pi,
and
then
he
gave
me
some
tips
to
debug,
but
it
was
late
in
the
evening
yesterday
and
it
was
family
time,
so
I
haven't
had
a
chance
to
go
through
it.
Yet.
A
A
Yeah,
we
have
also
got
a
really
good
feedback
from
the
cncf
that
they
felt
that
we
really
represented
the
community.
Well
we're
moving
on
to
the
next
step,
which
is
interviewing
of
of
three
major
users
of
the
project,
and
I
I
just
automatically
volunteered
ryan
because
he's
my
favorite
guy
to
pick
on
with
ryan
with
nvidia,
and
that
process
is
either
started
or
completed.
A
Not
sure
you
did
ping
me
in
slack
asking
me
what
the
the
format
of
that
session
was
gonna
be,
but
if
anybody
has
a
partner
in
mind
or
or
another
major
user
in
mind
that
could
that
would
be
interested
in
being
interviewed
on
their
use
of
the
project.
Please
let
me
know
so
I
can
pass
it
on
to
the
doc.
K
A
A
Okay,
we
see
a
myriad
of
of
applications
under
operating
under
kubernetes
and
and
many
of
these
projects
compete
with
each
other
and
and
so
what
this.
What
this
entails
is
a
like:
a
meritocracy
of
projects
that
float
up
to
the
top
of
of
the
ecosystem
and
and
get
advertised
heavily
for
production
use,
and
that's,
and
so
there
they're,
really
encouraging
competition
and
the
best
the
best
project
to
to
fill
a
space
in
the
in
the
ecosystem.
A
Cooper
is
currently
at
sandbox
project,
so
we're
we're
down
here
in
the
in
the
bleeding
edge
and
we're
trying
to
get
into
the
middle,
and
once
we
get
become
a
graduated
project,
things
move
much
slower.
Changes
are
scrutinized
heavier
and
so
that
that's
when
we
start
seeing
us
become
productized
in
vendors
products,
which
we
we
kind
of
already
are
in.
In
several
vendors.
We
we
advertise
on
our
website
who's
who's,
distributing
us.
A
So
red
hat
does
sponsor
the
project,
so
this
is
in
alphabetical
order,
but
red
hat
does
sponsor
us
and
we,
but
we
don't
favor
one
project
versus
the
other,
suzay
and
and
and
equinix
and
h3c
platform,
9
kubermatic
and
there's
several
others
that
we
haven't
got
authorized
to
advertise.
A
Yeah,
there's
a
there's
many
benefits
to
to
progressing
in
the
in
the
process.
The
cncf
will
step
in
and
give
us
money
for
for
hardware
for
marketing
give
us
hands-on
assistance
with
with
various
aspects
of
the
project,
a
sandbox
project
they
just
pretty
much.
Let
us
run
them
up
and
we
manage
ourselves.
E
A
Yeah
yeah.
Definitely
that
too
we
it
would
be
great
to
see
cooper
become,
have
a
keynote.
E
J
A
Okay,
that
takes
us
to
itamar
has
a
pull
request.
You
would
like
to
talk
about
lab
migration
policies
like
any
of
those.
L
L
A
L
Got
you
covered?
Okay,
thank
you.
So
this
is
again
the
live
migrations
pr.
So
basically
we
we
agreed
that
we
will
have
a
an
initial
implementation
and
this
point
like
a
poc
in
order
to
have
something
working,
something
basic.
So
the
question
is
what
is
basic?
Exactly
and,
and
specifically,
the
question
is
how
to
specify
the
group
of
vms
on
which
you
want
to
apply
the
the
migration
policy
so
right
now
the
the
implementation
is
doing
that
by
namespace.
L
So
you
have
can
have
a
one
migration
per
namespace
and
it
works
on
all
of
the
vms
that
runs
on
this
namespace.
So
yeah
we
are
having
a
discussion
mainly
me
and
vladik
over
there.
If
it's
the
right
approach
or
if
we
should
switch
it
to
something
else,
we
can
use
labels,
we
can
use
bmi
names.
There
are
many
different
approaches
that
come
into
mind,
so
yeah
you're
welcome
to
jump
in
the
discussion
and
help
us
with
your
ideas.
A
A
A
Okay,
thank
you
for
that
and
if
we
have
nothing
else,
we're
at
7
37,
let's
go.
Do
10
15
minutes
of
bug
scrubbing,
since
I
don't
believe
we've
done
that.
A
In
the
past
few
weeks,
it's
been
two
weeks
since
we
last
bug
scrubbed,
so
let's
do
let's
get
mailing
list
review
and
get
into
bug
scrub.
K
A
K
K
Yeah,
okay,
so
I
just
wanted
to
make
sure
that
we
have
like
two
gouge
metrics
that
will
operate
already
in
the
vert
control
already.
I
just
wanted
to
make
sure
that
this
gouge
matrix
of
prometheus
they
need
to
be
aligned
to
the
readiness
problem,
because
currently
they
are,
they
are
decoupled
from
the
from
the
you
know,
from
the
handler
of
the
health
endpoint.
So
when,
for
example,
the
view
operator
or
build
controller
is
considered
unhealthy,
we
still
have
this
gauge
metric
set
to
one.
K
So
what
you
will
see
is
that
from
from
kubernetes
point
of
view,
the
board
is
unhealthy
and
you
know
the
leader
election
will
occur,
but
on
the
other
side,
in
the
prometheus
method,
you
will
see
this
same
pod
in
a
ready
state,
so
just
wanted
to
make
sure
that
this
issue
is
correct
and
if
it
is
correct,
I
would
like
to
fix
it,
because
I
was
thinking
on
the
way
to
do
that
and
yeah,
so
roman
david
or
anyone
else
who
worked
before
with
the
metrics.
Please
keep
me
honest.
This
is
a
real
issue.
E
K
Well,
okay,
cool,
so
I
have
assigned
it
to
myself
and
I
was
thinking
about
say,
pass
forward
about.
It
perhaps
will
require
some
a
little
bit
of
refactoring
because
because
the
handler
of
health,
it's
pretty
related
to
some
cube
factory,
which
is
not
that
scalable,
perhaps
changed
it
and
roman.
I
will
as
soon
as
I
will
have
a
proposed
pr
I
will
assign
I
will.
I
will
cco.
D
A
A
A
All
right,
ctl
image,
upload
failed.
J
E
E
Yeah,
let's
yeah
that
yeah,
you
already
think
alexander
was
I'm
not
sure.
If
we
need
more
information,
maybe
he
knows
it
but
yeah.
Let's
just
apply
it
right
now,.
E
A
Don't
I
really
don't
the
only
reason
I
have
a
macbook
pro
anyways
is
because
I
have
bad
eyes
and
and
it's
a
very
expensive,
x86
laptop
to
get
something
even
close
to
the
retina
display.
E
I
asked
there
now
for
giving
us
output
with
more
ribosity.
Just
this
invalid
correct.
I
have
no
clue
where
this
is
coming
from.
Maybe
we
see
more
with
more
verbosity,
otherwise
we
would
need
someone
with
a
mech.
A
K
A
K
K
The
next
one
is
yeah,
it's
easy.
L
E
B
A
Yeah
so
it
looks
like
they
they've
already
done
some
proof
of
concept
work
here.
B
We've
said
that
we
are
a
kvm
project
from
the
beginning.
This
is
kind
of
tough.
E
H
A
I
can
tell
you
from
my
my
work
history
at
credit
suisse
bank.
They
were
a
100
percent
zen
shop
in
2010.
A
A
So
they
made
us
hot.
They
made
us
use
zen
products
and
there's
a
lot
of
them
aside.
Just
a
virtualization.
A
Yeah,
let
me
just
put
a
note
here
to
have
them
submit
a
design
proposal
and
at
least
they're
making.
H
B
A
Okay,
that
takes
us
to
7
56
a.m,
and
we've
got
a
handful
of
bugs
on
discussed
here
and
how
about
we
call
it
quits
for
the
for
the
week.
A
And-
and
we
pick
up
the
rest
of
the
bugs
and
next
week.
A
Thank
you,
chris.
Okay,
thank
you.
Everyone
have
a
good
week
and
please
help
me
with
these
demos.
If
you
have
time
in
the
next
few
days,
I'm
begging
you.
A
Okay,
anyway,
see
you.