►
From YouTube: KubeVirt Community Meeting 2023-02-22
Description
Meeting Notes: https://docs.google.com/document/d/1nE09vQWcCTW-9Ohe9oCldWrE0he-T_YFJ5D1xNzMtg4/
A
All
right
in
case
anyone
is
missing
or
doesn't
have
the
elite
candy
for
the
agenda.
Notes
just
dropped
that
link
in
Zoom
chat.
A
Looks
like
we
have
this
week's
template
started.
Thank
you
for
getting
that
started.
A
A
All
right,
of
course,
this
is
a
great
time
to
add
anything
to
the
agenda
that
is
important
to
any
of
you.
A
This
is
an
open
public
meeting,
so
anyone
is
welcome
to
make
sure
that
they're
part
of
the
community
Google
group,
and
that
should
give
you
access
to
right
on
the
notes.
So
you
can
add
agenda
items
or
PRS
bugs
or
anything
else.
That's
supposed
special
interest
to
you
that
we
go
ahead
and
cover
today.
A
By
chance,
do
you
have
anyone
on
the
call
who
would
like
to
introduce
themselves,
maybe
they're
new
to
the
call
or
have
just
been
lurking
in
previous
calls?
We'd
love
a
chance
to
welcome
you
and
say
hello.
D
C
Joined
some
calls
previously
as
well
so
yeah
I'm,
upgrading
your
to
the
community,
I
would
say:
I'm
I'm,
just
a
software
developer,
I
would
say
that
work
around
kubernetes
and
other
related
Technologies.
Recently
we
have
done
some
work
that
involves
cupert,
and
that
is
the
reason
I'm
just
trying
to
join
these
these
meetings
to
know
more
about
about
the
things
so
yeah.
If
you
have,
if
you
have
something
to
talk
about,
if
you
want
to
reach
out
to
me,
feel
free
to
reach
out
to
me.
C
I
have
I
have
added
my
GitHub
handle
in
my
name
as
well.
Awesome
yeah,.
A
I
think
that's
pretty
much
it
yeah
yeah,
it's
good
to
have
you
in
fact,
thanks
for
the
introduction
yeah,
let
me
see
actually
there's
something.
I
want
to
add.
A
All
right
just
wanted
to
call
out
real,
quick,
of
course,
that
the
all
of
the
submitters
for
the
covert
Summit
should
have
received.
A
Or
otherwise
notice
that
their
talks
weren't
accepted
this.
E
A
Of
course,
thank
you
to
everyone
who
submitted.
It
was
my
first
time
on
the
review
panel.
I
was
extremely
pleasantly
surprised
that
we
were.
A
We
were
really
pushed
to
try
and
include
it
so
many
more
than
we
could,
but
the
the
submissions
were
excellent
and
it
was.
It
was
definitely
difficult
to
try
and
eliminate
any
of
them.
So
thank
you
all
to
everyone
who
submitted
and,
of
course
the
dates
are
March
29th
to
30th,
be
sure
and
add
that
to
your
calendars,
there
are
some
really
fantastic
sessions
coming
up
and
I.
Don't
know
when
we're
going
to
publish
the
public
schedule
or
if
that's
already
done,
Andrew
burden
is
out.
A
I
believe
right
now,
so
we'll
be
sure
and
get
that
all
shared
out
as
soon
as
that
is
available,
so
you
can
mark
the
ones
that
are
of
interest
to
you
on
your
calendar.
F
Yes,
hey
sorry,
I
was
just
populating
the
text
for
it,
so
we
were
upgrading
Cube
word
from
a
relatively
older
version.
That
is
zero
point
three
five
to
zero
point:
five:
zero
and
one
of
the
things
that
happened
was
that
the
metadata
fields
in
cloud
in
it
so
there
are.
There
are
two
ways
in
which
you
can
use
cloud
in
it:
no
metadata
and
config
Drive
metadata,
so
the
config
Drive
metadata
Fields
changed
from
using
hyphenated
delimiters
to
snake
case.
That
is
underscore
delimiters.
D
D
F
Sorry
give
me
one
second
Cloud
unit
dot
go
line,
83.
F
Yeah,
so
if
you
look
at
the
Json
tag,
those
changed
and
the
older
tags
were
are
on
the
left
line.
70.
F
It
expected
the
the
hyphenated
Fields,
but
it
was,
the
keyword
code
base
was
looking
for
the
underscore
delimited
fields
and
it
turned
out
to
be
blank.
So
this
is
the
core
issue.
What
I
I
mean
I
wanted
to
know?
If
anyone
would
have
opinions
about
whether
or
not
we
should
consider
this
issue
and
solve
for
it,
one
of
the
ways
we
could
solve.
It
is
add
an
optional
Legacy
instance
type
field
which
would
have
the
older
older,
API
hyphenated
API,
and
that
really
does
not
break
anything.
F
It
would
not
be
a
huge
burden
to
carry
forward
that
that
fix,
but
I
wanted
to.
You
know,
get
communities,
thoughts
on
whether
we
should
go
for
this
or
not.
F
E
So
I'm
not
sure
that
anyone
even
considered
it
I
can
tell
you
from
a
downstreams
that
are
using
Google.
Don't
have
such
a
thing
like
it's,
usually
they
are
very
close
and
it's
well
tested,
and
but
we
will
probably
never
have
a
matrix
that
test
such
such
objects.
The
question
is:
if
you're
upgrade
in
a
in
small
steps,
do
you
have
the
same
problem
or
not.
F
We
got
unlucky
and
just
got
hit
by
it.
I,
don't
believe.
If
anyone
upgrades
from
let's
say
0.45
to
0.46,
they
will
hit
this
issue
because
if
they
are
using
0
for
0.45
version,
it's
already
the
new
fields
in
the
API.
E
And
maybe
even
then
we
didn't
have
any
upgrade
passes,
I
mean
we
have
an
upgrade
test
at
the
moment.
At
that
time
we
didn't
have
that.
So
is
this
even
relevant
to
the
current
version.
F
F
And
really
like
this
is
one
instance
of
the
upgrade
path
that
I
I
understand
our
versions.
Q
was
large,
but
this
brings
up.
Our
second
larger
conversation
is
that
what
would
be
an
acceptable
upgrade
paths
that
that
we
would
ideally
like
to
support
and
that
that
is
a
larger
discussion
and
I
I
wanted
to
kind
of
root
out
that
discussion
with
this
example.
B
F
Okay,
make
sense,
yeah,
I,
I,
think
n
minus.
Is
that
a
number
that
have
that
has
come
out
of
discussion
or
it's
that
number
we
have
already
implicitly
assumed
in
in
discussions
in
the
community.
B
F
Got
it
and
do
you
think
I
should
open
another
issue
that
at
least
documents
it
somewhere
for
users.
D
B
E
I
I'm
not
but
I'm,
just
not
sure
I
mean
I,
think
that
you
can
raise
it,
but
but
I'm
actually
not
really
sure
that
we
can
even
do
this
in
in
in
practical
sense,
we
are
not
supporting
this
version
for
sure.
It's
like
it's
like
so
long
ago
that
no
one
is
looking
that
foreign.
F
Safe
right,
we
are
just
adding
an
extra
optional
field.
If
those
fields
don't
exist,
nobody
will
be
hurt
by
by
that
chain
right.
So
I'm
I'm,
not
sure.
If
the
concerns
are
valid
or
or
maybe
we
can
come
up
with
something
where
we
don't
have
to
back
Port
it
all
the
way
up
to
version
35.
F
F
So
so
at
least
we
have
an
upgrade
path
from
35
to
some
later
version
which
which
is
acceptable
and
then
from
there
on
users,
can
take
the
upgrades
for.
F
F
Let
me
raise
the
pr
and
you
can
comment
on
the
burden
because
so
first
thing
this
is
an
API
change
right,
so
API
change.
We
have
been
supporting
backward
compatibility
since
since
long
time
like
we
don't
try
to
break
API.
F
And,
and
so
fixing
this
is,
is
not
going
to
be
as
harder
burdensome
is,
as
it
can
appear
to
be
in
in
the
first
like
first
pass,
it's
just
some
extra
additional
like
two
three
lines
of
fields
that
you
have
to
add
here.
E
Yeah
but
that's
the
the
problem
is
that
these
fields
are
not
used
as
well.
It's
only
there
for
like,
like
Style
Style
fields,
in
order
to
allow
upgrades
from.
D
E
That
we
don't
even
remember
they
existed
so,
but
let
me
give
you
a
another
option:
I
don't
know
if,
anyway,.
D
E
Could
suggest
it
anyway,
just
just
the
personal
opinion.
My
my
suggestion
is
that,
because
this
is
so
so
old,
what
what
can
be
done
is
to
create
a
special
version,
maybe
to
Branch
it
to
a
special
branch,
and
only
that
version
will
support
this.
So
you
could.
So
if
someone
wants
to
upgrade
for
from
something
before
so
old,
they
must
go
through
this
special
version.
E
If
they
encounter
this
problem
and
then
only
then
they
can
continue
on
with
the
object,
but
so
that
one
will
not
not
cause
problem.
I
mean
we
don't
need
to
add
anything
to
the
to
the
Future
and
no
need
to
touch
the
existing
code.
But
for
for
this
exceptions
for
very
old
version
that
are
still
running
today,
we
could
give
this
workload.
I,
don't
know
if
it's
like.
For
me,
it
sounds
much
easier
to
so.
Have
it,
but
but
still
it's
another
option.
F
I
think
that
option
will
cause
more
problems
in
the
future
right,
because
how
long
will
you
keep
maintaining
that
Branch?
Would
we
have
CI
testing
things
across
that
Branch.
F
E
I'm
sorry,
what
types
of
Judges
that
we
don't
maintain
anything
that
we
just
create.
For
example,
you
take
the
branch
that
was
0
36
you
you,
we
released
another
build
there
like
it's,
a
very
special
build
like
a
hot
fix
and
there
that
version
that
specific
version
will
solve
this
specific
problem
for
very,
very
old
user.
So
they
will
have
to
upgrade
to
that
one
and
from
there
they
will
have
to
go
or
continue
on,
but
we
will
not.
We
will
not
maintain
it.
F
F
Although
what
I'm
suggesting
what
I
am
the
discussion
we
are
having
is
not
just
specific
to
me,
anyone
who
upgrades
from
35
will
hit
this
issue
and
and
the
the
question
I
have
in
that
workflow
is
for
how
long
will
we
keep
telling
users
that,
if
you
want
to
upgrade
to
older
version,
then
35
go
to
this
hotfix
friends
branch?
Do
we
have
a
way
to
test
it
or
do
we
have
the
Cycles
to
to
look
at
that
branch
I.
D
F
Rather,
prefer
to
you
know:
if
the
code
changes
are
not
huge
and
it
is
not
buttered
burdensome,
which
I
think
it
will
not
be
I.
I
would
think
this
would
be
a
good
example
we
set
for
for
the
things
API
changing
API
breaking
things
that
have
been
recognized
and
we
as
a
community,
keep
keep
up
having
in
the
code
base,
so
that
upgrades
don't
break
for
users.
In
my
opinion,
it
will
be
a
good
good
example.
Yeah.
G
So
you
have
to
be
careful
which
direction
you
go
with
that
because,
if
you
add
more
fields
and
people
start
using
those
fields,
instead
of
you
know
using
the
correct
field
now
you
have
other
people
who
could
potentially
be
broken
in
the
future.
If
we
decide
to
remove
the
Legacy
field,
so
you
just
break
it
further.
You
just
push
the
problem
forward.
E
This
is,
this
is
not
true
by
the
way
we
are
we
don't
at
the
moment
we
don't
have.
Such
I
mean
we
are
breaking
apis
from
time
to
time.
This
is
something
that
we
do.
We
are
trying
not
to
do
it,
but
at
this
current
state
we
do
have
this.
We
do
sometimes
do
it.
G
It
depends
on
on
how
the
you
know
the
version
releases
her
or
are
managed.
You
know
if
it's
semantic,
versioning
versus
you
know
some
other
versioning.
It's
up
to
the
you
know
the
overall
maintainers
of
the
project
to
make
that
decision
and
to
to
enforce
how
they
see
fit.
But
if
you,
if
we
never
broke
apis
at
a
an
acceptable
stage
and
we'd,
never
make
progress
so.
F
I
I
think
we,
then
we
have
reached
V1
like
the
V1
apis.
We
try
to
not
break
them
at
least,
ideally
as
a
principal
and
then,
if
things
like
this
happen,
where
it
it
is
unintentional,
you
know
nobody
can
go
around
that,
but
at
least
in
practice
my
understanding
was
that
API
fields
that
have
hit
V1,
don't
they
should
not
be
broken.
D
G
A
So
one
one
thing
to
notice
in
all
of
this
is
while
it
is
friendly
to,
of
course,
try
and
support
larger
jumps
in
the
at
the
upgrade
cycle.
A
Technically,
the
kubefort
update
policy
is
to
only
support
updating,
One
release
at
a
time
and
that's
the
way
that
the
the
testing,
of
course,
will
be
done,
which
means
jumping
from
a
3-0
release
to
a
5x
release
is
going
to
be
well
beyond
the
the
tested
update
path
of
of
the
supported.
You
know
Journey,
so.
A
At
this
point,
I
can
understand
how
it
might
be
nice
to
prevent
something
like
this
if
it's
reasonable
and
possible
and
if
it
affects
a
very
large
number
of
people
within,
especially
within
the
the
approved,
the
supported
upgrade
path.
But
this
since
this
is
so
far
outside
of
the
updated
support
path.
A
F
I
I
agree
with
that.
I
just
just
wanted
to
bring
this
up
for
discussion,
because
if,
in
the
future
we
will
come
up
with
like
if
there
are
API
breaking
changes,
can
we
have
some
kind
of
written
down
or
agreed
upon
rules
where
the
community
or
the
users
are
aware
that
this
is
how
it
should
work,
so
I
I
think
the
while
this
is
a
really
like.
F
This
is
a
large
version
skew
in
terms
of
breakage,
okay,
I'm,
trying
to
just
have
a
more
forward-looking
conversation
where
we
set
down
some
kind
of
examples
for
this.
A
Ahead
and
also
drop
the
release
notes
hyperlink
here:
I
haven't
quickly
identified.
Where
which
version
has
this
change?
It
should
be
relatively
easy
to
go
back
to
GitHub
to
see
when
that
was
merged,
and
then
what
release
came
after
that
and
then
identify?
If
we
have
it
correctly
noted
in
the
Cooper
thesis,
it
might
be
an
obscure
release
note,
so
it
may
be
that
we
could
improve
the
release.
Note
message,
I
do
not
know.
I
would
have
to
identify
that
and
if
that's
the
case,
it's
completely
fair
to
to
point
that
out.
A
I
I
would
not
disagree.
That
way
you
can
at
least
hone
in
on
which
release
addresses
this
issue,
so
that
you
can,
you
know,
make
sure
to
follow
that
entire
Journey,
but
for
the
sake
of
time,
I
am
going
to
go
ahead
and
move
the
meeting
on
to
going
through
PR's
any
mailing
list
and
Bug
scrub
items
here.
I
didn't
know
no.
A
A
A
A
A
A
A
A
D
G
A
Thank
you,
okay,
so
apologies
for
the
dead
air
there,
hot
plug
volume
killpod
more
time
lead
is
a
re
login.
That
is
a
little
bit
of
a
mouthful,
but
basically
it
looks
like
the
hot
plug
volume
or
a
nice
fuzzy.