►
From YouTube: KubeVirt Community Meeting 2020-12-23
Description
Recording of the KubeVirt Community meeting on 2020-12-23
A
Okay
welcome
everyone.
This
is
thecube
community
meeting
on
december
23rd
2020.
on
the
agenda.
For
today
we
have
a
topic
from
edward
around
arm64
support.
It
was.
B
All
yours,
okay,
so
thanks
for
having
me
here,
I'm
coming
to
this
from
an
observation
from
the
harvester
project
from
rancher
which,
as
you
may
know,
includes
cubeverd
as
one
of
its
components.
B
It
does
a
hyper
converged
infrastructure
on
top
of
kubernetes,
with
cube
vert,
providing
vms
and
min
io
and
another
block
storage
thing.
What's
the
I
don't
remember
all
the
components,
but
anyway
there
is
a.
There
are
a
set
of
components
that
includes
kubert
it's
working
on
x86.
B
I
have
a
desire
to
make
it
work
on
arm
64.,
and
the
outstanding
issue
is
3558
in
the
cube
vert
repository
where
it
looks
like
howard
zhang
is
working
on
getting
this
to
work.
There
was
a
update
three
days
ago
that
one
of
the
prs
for
building
the
multi-arch
test
image
of
cube
vert
is
blocked
with
a
lack
of
response
from
one
reviewer.
B
So
that's
that's
what
I
know
I
didn't
have
the
I
didn't
have
the
summary
when
I
put
this
on
the
agenda,
but
it
looks
like
there's
progress
and
once
once
that
additional
review
is
in,
it
looks
like
we're
in
good
shape,
to
release
cube
vert
for
arm
64.
B
C
B
I
believe
the
sticky
point
is
indeed
ci.
In
particular,
there
is
a
the
cube
vert
ci
repository
at
issue,
406.
D
Yeah
yeah
and
this
for
this
pr,
the
the
only
missing
thing
is
that
it's
that
we
well
there's
another
pr
reference
to
it
in
the
project.
Infra
repo
and
it
is
modifying
the
jobs
that
publish
these
images
so
that
they
can
they
can
be
pushed
to
to
play,
because
this
is
in
parallel
with
our
our
migration
from
docker
hub
to
to
quay.
So
this
this
is
the
the
only
thing
that
that
could
be
would
be
required.
D
There's
there's
another
another
change
that
we
would
need.
It
is
in
in
go
cli
that
this
is
the
the
tool
that
spin
ups,
the
keyboard,
ci
clusters,
and
now
by
default
we
are.
We
are
pulling
the
images
from
from
docker
hub
and
this.
This
is
a
small
change.
D
There's
also
one
another
pr
with
a
small
change
that
changed
the
the
flag,
the
default
value
of
the
of
one
flag,
so
that
it
wouldn't
require
too
many
changes
but
yeah.
At
the
end,
all
this
is
more
related
to
to
kuwait,
to
the
immigration
migration
to
quay,
because
it
doesn't
imply
that
we
start
using
this
arm.
64
images.
It
is
more
about
the
migration,
so
it
is,
it
is
not
blocking
the
start
using
the
the
the
multi-arc
images
at
the
end.
B
Okay,
well,
it
sounds
from
the
discussion
here
that
things
are
well
in
progress
and
I'll
look
forward
to
the
pr's
resulting.
C
Sure
is
there
anything,
I
guess
what
are
your
expectations
with
this
just
trying
to
understand
what
you
would
like
to
see
come
out
of
this?
Are
you?
Are
you
hoping
that
we
publish,
I
guess,
arm
64
artifacts
with
our
releases
and
things
like
that,
or
is
it
yeah
for
testing
for
us
to
just
make
it
enable
people
to
build
it?
So
you
all
can
begin
evaluating
it
like
what
what.
B
Yeah,
so
the
hope
is-
and
this
is
a
this-
is
a
process
with
a
couple
of
steps
along
the
way
right,
because
once
artifacts
are
published,
it'll
be
easier
to
consume
them
by
upstream
by
dancing
projects.
B
So
the
goal
is
for
the
artifacts
to
be
built
and
published
and
released
such
that
harvester
can
now
start
testing
with
its
infrastructure,
consuming
those
binaries
and
then
producing
this
infrastructure
for
for
testing
harvester,
just
to
be
clear,
is
in
version
0.1,
so
there's
a
whole
bunch
of
testing
that's
going
to
have
to
go
on
before
it
gets
really
released,
and
here
at
equinix
metal
we're
going
to
be
working
with
them.
I
think
on
integrating
our
tinkerbell
provisioning
tool
with
harvester.
C
B
Yeah,
that's
I
mean
not
not
a
hundred
percent.
B
It
would
still
be
possible
for
someone
who
is
extraordinarily
diligent
to
build
the
whole
thing,
but
from
a
ci
and
test
perspective,
it'd
be
much
better
to
consume
artifacts
than
to
consume
source.
C
Okay,
all
right,
that's
helpful,
some
of
the
things
that
I've
been
thinking
about
with
this
arm
and
I'm
just
catching
up
to
speed
with
it
is
trying
to
figure
out
incrementally
how
we
can
begin
enabling
this
before
we
just
flip
the
switch
entirely
and
say
that
we
fully
support
arm
or
whatever
and
there's
the
step
of
when
we
start
publishing,
artifacts
that
unless
we
have
ci
to
completely
exercise
our
entire
functional
test
suite,
we
don't
have
any
guarantees
with
that.
E
C
Yeah
so
yeah,
I
want
to
enable
people
like
you
to
begin
testing
and
consuming
it,
but
at
the
same
time
figure
out
a
way
of
doing
that
that
doesn't
make
it
look
and
appear
like
it's
being
fully
a
first
class.
Listen
to
our
other
release.
Artifacts.
B
B
B
You
can
well
so
the
test
cube
ver
you,
how
do
you?
How
are
you
currently
testing
kubert.
C
Where
it's
not
complicated,
but
it's
kind
of
unique
we're
running
virtual
machines
within
containers
and
we're
simulating
a
cluster
within
a
container,
so
that
allows
us
to
run
multiple
kind
of
simulated
environments
all
in
one
like
hardware,
like
we
have
a
large
vertical
hardware,
we
can
run
multiple
clusters
on
it
right.
C
So
we
like
that
pattern.
For
us
it
involves.
B
Yeah,
so
we
don't
have
that
infrastructure,
as
as
you
describe
right
now,
we
we
do
have
some
partners
who
are
providing
vm
based
infrastructure,
particularly
foss
host.
B
B
I
I
think
that
the
answer
is
you
know.
Raw
access
to
hardware
may
not
be
the
challenge.
The
challenge
may
be
the
software
infrastructure
to.
E
B
There,
although
the
the
the
the
folks
at
arm,
have
been
very
generous
with
their
support
for
the
management
of
things.
It's
just
a
matter
of
aligning
everyone's
interests
and
and
providing
the
right
people
with
the
right
cooperation.
C
Okay,
it
sounds
like
there's
resources
that
are
potentially
available.
We
just
kind
of
have
to
track
all
this
down.
I,
I
think,
there's
a
path
for
us
to
get
armed
support,
preliminarily
or
just
kind
of
the
initial
support,
merged
and
kind
of
give
us
a
path
to
eventually,
hopefully,
building
artifacts
and
publishing
them
in
the
future.
F
B
I
think
that
might
be
possible
if
the
downstream
harvester
stuff
has
that
same
goal
there
there
may
be
ways
of
of
leveraging
other
projects
to
do
some
of
that
heterogeneous
testing.
But,
as
david
says,
it
seems
unlikely
that
the
first
round
is
going
to
be
heterogeneous.
It
would
make
sense
right,
I
think,
that'd
be
a
desired
goal.
F
C
Technically,
there's
nothing
prohibiting
it
from
working.
It
doesn't
fit
the
pattern
that
we're
doing
with
the
setup
of
clusters
right
now,
so
we're
setting
up
clusters
and
simulating
them
on
the
same
hard
like
one
node
like
we
have
one
node
that
we're
simulating
multiple,
no
like
it's
a
nested
cluster.
So
when
we
talk
about
doing
something
like
a
heterogeneous
cluster,
that
would
be
a
cluster.
C
That's
set
up
in
a
different
way,
maybe
already
exists
that
we
just
execute
our
tests
on,
so
that
setup
phase
would
look
different
than
what
we
have
today,
which
that
that's
a
discussion.
So
there's
some
nice
things
about
the
way
we
do
it
today,
and
that
means
that
every
time
we
we
start
when
these
simulated
clusters,
we
we
start
from
scratch
and
we
tear
it
down
and
we
kind
of
get
a
lot
of
predictability
and
stability
out
of
doing
it.
C
E
C
Would
be
great,
and
also
so
we
have
some
options
here
with
our
ci.
If
it's
just
beneficial
to
begin
introducing
these
heterogeneous
clusters
and
different
ways
of
setting
up
and
tearing
down,
we
can,
we
can
add
these
lanes
and
not
make
them
required.
So
it
would
be
something
where
we
begin
getting:
data
and
understanding
how
our
like
how
stable
it
is,
and
everything
before
we
actually
make
it
where
it's
a
gating
mechanism
for
code
to
get
merged.
So
we
have
some
options
here,
just
pointing
that
out.
A
Okay,
so
to
summarize
initial
arm,
support
seems
to
be
relatively
close,
not
as
a
initially
probably
not
as
a
first-class
citizen,
as
david
mentioned,
and
a
longer
term
goal
would
be
to
work
on
additional
features
like
multi
multi-arc,
that
are
genius
clusters.
Okay,
anything
else
around
that
topic.
B
A
Thank
you.
Yes,
thanks
thanks
and
cool,
so
there
is
no
other
agenda
item
in
the
regular
section.
Anyone
has
one
last
minute
topic.
If
not,
we
will
move
to
the
the
open
floor.
A
couple
of
topics
there.
A
Okay,
so
I
wanted
to
mention
david
actually
sent
an
email
a
few
days
ago
about
the
start
of
the
preparation
of
the
keyboard
summit,
an
online
event,
there's
a
link
to
the
the
archive
of
the
mail
that
david
sent.
Basically,
we
kind
of
secured
dates
for
this.
A
This
first
ever
keep
birth,
focused
online
event,
two
half
days,
nine
and
ten
of
february,
and
the
plan
is
to
have
two
different
tracks:
two
different
audiences,
one,
more
contributor
oriented
and
another
one
more
user
oriented,
but
preparations
are
just
starting,
and
this
is
a
call
for
participation
to
the
you
know,
early
preparation
as
well.
As
you
know,
content
can
already
be
accepted.
A
Some
details
are
there
on
the
proposal.
The
proposal
is,
you
know
for
sorry.
The
suggestion
for
proposals
is
to
accept
prs
in
the
community
of
repo
which
can
be
reviewed
in
the
open
and
and
then
we
take
it
from
there.
Anyone
who
wants
to
contribute
to
the
preparation
or
content,
please
feel
free.
A
That's
what
I
wanted
to
say.
I
don't
know
if
anyone
wants
to
add
something
about
this.
C
I'll
just
add
that
I'm
probably
going
to
start
pinging
individuals,
because
I
think
we
have
a
lot
of
really
cool
things
that
have
gotten
added
this
year
and
I
want
to
make
sure
that
people
understand
that
it's
valuable
to
to
talk
about
the
things
like
so,
for
example,
like
features
like
hot
plug,
and
we
have
the
tecton
pipeline
work,
that's
come
through,
and
even
this
arm
work.
A
Yeah
yeah
yeah
this
this
topic,
you
know
multi-arc
and
arm
support-
can
be
a
very
interesting
topic
to
discuss.
C
It's
very
dense
how
much
has
changed
this
year
and
I
think
we
have
the
opportunity
to
share
a
lot
of
really
interesting
things
so
I'll
be
sending
out
reminders.
I
know
this
end
of
the
year.
I
didn't
really
necessarily
expect
to
get
any
content
before
you
know
january
1st.
Just
given
you
know
everyone's
kind
of
slowing
down,
but
I
kind
of
wanted
to
get
the.
I
think
the
goal
here
was
just
get
everyone's
minds.
Thinking
about.
A
Sure
yeah
personally
I
one
thing
that
I
I
have
on
my
to
the
list
of
things
to
check,
but
from
the
recent
release
that
the
removal
of
capnet
admin
knee
requirements
and
well
I
don't
know
this
is
probably
I'm
not
sure
if
this
is
worth
a
session.
But
it's
something
that
I
haven't
checked
yet
and
I
wanted
to
check.
But
anyway,
that
sounds
good.
Yeah.
C
That's
that's
a
really
good
topic.
I
think
the
whole
topic
of
reducing
privileges
from
the
launcher,
pod
and
kind
of
the
vision
moving
forward.
So
the
things
you
just
mentioned
about
reducing
some
of
the
capabilities
are
kind
of
part
of
a
larger
vision
that
absolutely
belongs.
It's
a
topic
as
well,
there's
just
so
many
things.
It's
gonna
be
great
cool.
A
Okay,
well,
the
only
other
thing
I
wanted
to
mention
is
that,
unless
anyone
objects,
the
plan
is
to
cancel
next
week's
meeting.
Today
we
had
limited
attendance
next
week.
We
expect
to
have
even
less
attendance
so
well.
The
suggestion
is
to
meet
again
next
year,
starting.