►
From YouTube: KubeVirt Community Meeting 2019-06-19
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
Me,
okay,
so
there's
two
changes
coming
down
the
pipe
and
Romans
Romans
doing
both
of
them
right
now,
but
the
biggest
one
is
with
the
guitar
discs
in
the
past.
We've
always
done
this
copy
of
the
image
from
the
container
image
to
the
local
pot
and
shared
that
between
the
virtual
machine
and
the
host.
B
So
what
that
means
is
that
we
always
have
to
copy
make
a
copy
of
the
container
locally
to
be
used
by
the
virtual
machine,
which
is
duplication
and
also
the
image
could
be
huge,
so
it
could
be
a
large
copy
this
involved.
So
one
of
the
changes
working
on
right
now
is
the
ability
to
have
zero
copy
for
container
images
for
container
disc
images.
D
C
Second,
change,
mostly,
is
that
you
can
base
your
image
that,
where
your
container
the
skin
on
the
scratch
doc
image
so
right
now
we
have
some
basic
logic
included
in
the
image,
and
you
have
to
face
your
container
disk
image
and
our
base
image,
but
that's
not
removed.
Then
you
just
take
a
scratch
image
and
copy
over
your
copy
of
this
context.
It
right.
B
For,
what's
actually
in
the
container
this
image,
you
can
just
put
your
image
and
that's
it.
I
can
be
just
a
totally
blank
container
image
other
than
that.
So
those
are
the
two
changes
come
down
the
pipeline,
and
this
should
make
the
container
disk
feature
actually
be
something
that
it's
usable
and
production,
rather
than
kind
of
it
start
out
as
kind
of
this
development
thing
where
we
need
a
way
to
easily
distribute
disks
for
virtual
machines,
and
now
it's
actually
something
that
we
perceive
as
being
useful,
useful
in
production.
E
I'm
just
just
a
comment
if
I
could
or
a
bit
of
a
question.
So
if
you're
not
aware,
CDI
supports
the
container
disk
format
as
well,
and
what
we
do
is
we
import
the
the
container
using
scope,
EO
and
copy
the
disk
image
into
a
persistent
volume
claim
so
that
it
can
be
persisted
across
vm
starts
just
checking
here
to
make
sure
that
we
haven't
changed
any
of
the
rules
about
where
the
image
should
be
located,
the
name
of
the
image
or
any
other
of
those
things.
E
C
E
B
C
B
And
feeding
out
that
it's
also
we're
increasing
the
security
of
container
discs
as
well.
People
can't
execute
arbitrary
code
within
their
container
discs
anymore,
which
was
one
of
the
concerns
that
we
had
now.
They
we
ignore
whatever's.
In
there
no
code
is
actually
being
run,
that's
being
shipped
with
B
container
disk
image
anymore,
we're
injecting
our
own
binary
in
there
to
execute,
so
people
can't
run
whatever
they
want
anymore.
It's
the
entry
point
I.
A
F
F
Yesterday
I
was
able
to
get
first
full
coverage
report,
so
it
seems
we
have
20%
coverage
around
that
value
and
I'm
talking
about
all
endpoints
and
when
we
are
talking
about
only
view
to
our
machine
instances.
It's
it's
about
76%.
Subject
like
this.
What
I
reserve
this
issue
I
will
share
this
report
to
to
you
guys
and
next
steps
are
one.
F
Yeah
I
mean
for
each
line.
We
have
separate
rest
API
coverage
right
now,
but
it's
just
after
after
test
cleanup
I
run
this
test
from
the
test.
Sorry,
after
test
clean
up
I
run
coverage
from
test
level,
so
next
steps
is
to
integrate
it
with
pro.
So
when,
when
there
is
this
phase
after
test,
cleanup
I
run
my
tool.
F
C
G
H
I
H
F
H
Sorry,
just
just
highlighting
Adam
John
I
think
that's
also
interesting
for
other
projects
for
choosing
custom
resources,
because
it's
agnostic
to
to
be
underlying
resource.
As
long
as
the
open
API
is
used
to
find
fields,
and
you
can
effectively
understand
how
many
of
my
fields
are
covered
by
my
function.
H
F
A
J
You
know
we
had
the
binding
mechanism
for
the
default.
Well,
interface
was
bridge
and
don't
know,
but
we
have.
We
had
some
issues
with
that.
Specifically
one
bug
were,
after
a
sort
of
cue
blood.
We
lost
connection
to
the
RPM,
so
we
decided
to
change
the
default
binding
mechanism
for
interface
to
masquerade
which
solve
this
problem.
We
switched
see
our
functional
test
to
use
the
masquerade
by
default
and
there
was
a
PR
that
fixed
the
masquerade
on
binding
mechanism
to
align
with.
A
J
A
C
J
J
Take
your
number
I'm,
not
sure
I
will
plan
to
change
default
in
the
UI
to
use
the
bridge.
Sorry
I
must
great
as
well
as
a
default.
Not
only
a
so
default
is
the
only
option
but
to
be
safe.
We
should
fix,
fix
it
and
then
we
are,
and
for
the
name
I
mean
we
should
look
back
at
the
original
PR
if
they're
also
in
discussion
about
it,
I'm
not
verily.
Okay,.
C
B
That's
a
pretty
big
issue
yeah,
especially
for
clustering
use
cases,
so
people
need
to
be
able
to
register
potentially
their
IP
address
with
the
service
and
that
to
be
reachable,
so
they
don't
know
what
their
IP
addresses
or
they
all
look.
The
exact
same.
It's
gonna
kind
of
unexpected
behavior
for
some
applications.
Well,.
J
G
J
C
Was
discussing
some
ways
with
traffic
control
or
so
on,
to
kind
of
keep
the
IP
inside
the
VM
to
so
that
it
looks
for
the
VM
like
it
has
to
say
map,
but
she
drew
some
magic
in
the
container.
Maybe
you
can
also
have
look
into
that
one
or
from
that
it
looks
like
we
will
need
both,
and
what
I
just
want
to
highlight
is
I
want
that
back,
if
possible,
also
fixed
on
the
yeah
fun
on
the
qubit.
That's
on
the
on
the
normal
network
interface.
That's
my
main
point.
Yeah.
J
J
When
you,
when
you
risk,
when
you
set
up
the
interface
in
the
pot
or
Qibla
table,
set
up,
sets
up
the
interface
in
the
boat,
it
checks
whether
or
the
IP
address
and
the
interface
is
there,
and
it
is
there
when
the
boat
is
starting.
But
then
we
take
over
the
IP
address
and
move
it
into
the
VM.
So
it's
not
there
anymore.
Then
you
restart
cue
blood
and
it
has
this
health
check
where,
after
restart
it
iterates
all
containers
robots
and
rejects
the
IP
address,
which
is
not
there
anymore.
J
I
B
J
J
B
H
J
H
Oh
yeah,
actually,
what
math
great
do
we
still
look
at
moving
the
IP
address,
or
does
it
get
a
different
IP
of
us?
It
gets
a
different
one
type
addressed
stays
on
to
the
port
interface
great
yeah
for
the
pot
interface
I
would
actually
make
that
the
general
norm
that
for
the
pot
interface
we
never
ever
with
any
implementation,
move
the
IP
to
the
VM.
Well,.
H
E
And
sorry,
sorry
to
drag
this
on
further,
but
part
of
my
part
of
this
is
my
own
ignorance
but
I'm
wondering
as
part
of
these
changes
are
we
going
to?
Will
it
be
possible
for
qmu
to
use
the
control
paint
plane,
like
the
pods
IP
address,
for
example,
to
communicate
with
a
remote
block
device,
yeah
sure,
I
think
so.
J
H
And
that
is
actually
why
I
would
go
with
saying
that
we
eliminate
or
other
methods
on
the
point
interface
because
currently
Adam
the
problem
is.
We
cannot
expect
it
because
somebody
can
still
use
the
bridge
networks.
So
that
is
what
I
was
thinking
about
down
the
road.
But
really
you
know
cuber
2
or
something
like
that
to
just
commit
something
like
snorkel
mask
right
on
the
pond
network,
because
then
we
can
assume
that
the
pot
will
always
have
no
connectivity,
yep.
J
J
J
All
right,
then,
I
go
to
another
networking,
but
point
merchants
at
the
focus.
So
what
okay
Dee?
We
decided
that
we
we
want
to
switch
to
Linux
bridge
cni
as
the
default
l2
CNI
Pugin,
the
reason
being
that
it's
easier
to
set
up
a
Linux
bridge
on
okd
host,
since
it
has
no
dependencies,
unlike
the
obvious,
which
requires
to
you
to
have
a
demon,
loaded,
Carol
modules
and
so
on
so
yeah.
A
B
Not
hold
on
here,
but
I
just
wanted
to.
Let
everyone
know
that
right
now,
our
API
for,
like
virtual
machines,
virtual
machine
instances
is
v1
alpha
3
and
we've
been
progressing
it
through
the
past
couple
of
years
and
every
time
we
progress
it.
It
means
that
it's
not
backwards
compatible
with
the
previous
one.
We
think
we're
at
the
point
where
we
like
our
API
in
the
stable,
and
we
would
have
already
moved
it
to
something
like
a
B
1
beta
1,
but
we
haven't
had
the
feature
set
in
kubernetes
until
recently
to
progress
our
API.
B
So
we
feel
like
we're
at
the
point
where
we
want
to
make
our
API
generally
available
and
markedness
v1,
so
we're
gonna
be
skipping
beta
and
the
idea
is
we're
gonna
jump
directly
from
v1
alpha
3
to
v1,
and
this
change
is
going
to
be
putted
backwards,
compatible
with
previous
with
the
previous
b1
alpha
3
API,
so
that
API
isn't
going
anywhere.
It's
still
available.
Virtual
machines
started
with
that
and
then
say
you
update
to
version
2
version
and
convert
that
it
supports
the
new
b1
alpha.
B
Everything's
still
gonna
work
fine.
So
this
change
is
coming
once
we
hit
V
1.
That
means
we're
committed
to
supporting
this
API
without
backwards,
incompatible
changes,
backwards,
incompatible
changes,
modifying
a
field
or
removing
a
field.
A
compatible
change
is
additions
to
the
API,
so
we're
still
gonna
allow
additions
to
the
API,
we're
just
saying
we're
not
going
to
mutate
any
fields,
rename
them
or
delete
them
without
going
to
like
a
v2
someday,
but
v1
I
think
we're
gonna
say
this
forever.
B
Just
like
kubernetes
is
doing,
and
we
have
no
plans
to
not
support
anything
that
exists
today,
so
I'm
working
on
that
change.
Now
it
should
land
at
the
poll
question
land
this
week
sometime
along
with
a
proposal
for
for
what's
happening
for
discussion.
So
anyone
has
any
problems
with
the
API,
bring
it
up
now
because
we're
pretty
much
committing
to
it.
At
this
point,
one
limitation
this
has
and
I'll
bring
it
up
in
the
proposal
is
that
we
have
to
use
Cabernets
one
guy,
11
or
greater.
B
B
K
Hey,
hey
Francesco,
yeah
I
have
a
question
about
the
AP
stability
I'm,
not
sure
this
is
the
right
place,
but
still
so
are
we
happy
about
the
state
of
the
hyper-v
API,
because
the
last
time
we
touch
the
subject
we
pretty
much
well,
it
is
pretty
low
level
and
it
exposed
quite
a
lot
of
flags.
So
since
this
is
pretty
much
done,
the
last
chance
to
review
it
I'm
bringing
this
up.
K
No
I
don't
have
any
strong
opinion
that
I
see
why
it
is
like
that,
but
it
feels
somehow
well
my
own
very
gut
feeling
is,
that
is
pretty
low
level,
and
it
is
somehow
at
odds
so
two
other
component
of
the
API,
but
I
don't
have
a
list
of
complaints
or
any
suggestion.
I
will
just
like
to
bring
this
up
because
I
don't
want
these
to
be,
are
not
to
go
on
noticed
but
maybe
started.
I
will
start
animal
trade.
Is
it
a
better
place
to
discuss.
B
Yeah
maybe
bring
it
up
and
in
the
discussion
I'll
try
to
here's
what
I'll
do
opposed
to
Kieffer
davell
once
I
post
the
pull
requests,
and
we
can
have
the
discussion
there
so
we're
not
locked
into
never
making
a
change
to
our
API.
If
that
changes
in
the
future
will
require,
if
they're
not
backwards
compatible,
it
will
require
a
conversion
between
our
API
s
and
that's
something
that
we'll
probably
need
to
push
out
for
a
year
or
so
because
that's
something
that
just
recently
got
released
with
kubernetes.
C
C
L
L
We
have
a
couple
of
documentation
updates,
most
of
them
are
merged,
but
the
one
is
still
in
progress
because
there
is
an
extreme
test,
failing
I
think
yeah.
What's
the
pettiness
that
we
still
don't
respect
the
base
name
with
what
cuddle
binary
is
that's
the
to
do,
and
we
had
a
discussion
about
whether
the
repo
where
the
binaries
are
created
should
either
be
moved
into
the
queue
per
door
or
probably
completely
integrated,
as
Cubert
I
think.
L
C
L
L
C
L
Because
just
cube
the
new
plugin
mechanism
just
takes
the
binary
and
uses
it,
so
you
don't
have
to
do
anything
it
just
forwards
it
to
the
binary
so
like
just
do,
keep
coming
vert
and
then
whatever
command
you
do,
and
you
don't
have
to
describe
anything
you
can
use
a
shell
script.
You
can
use
another
binary.
It
doesn't
matter.
Okay,
that.
C
Sounds
really
good
also
doesn't
sound
like
too
much
needs
to
be
done
to
F
that
automate
it.
She
already
said
I'm,
not
sure.
If
it's
so
the
past,
we
always
decided
to
have
something
like
this
in
Hubert
dev
main
repo
I
would
still
keep
it
there
put
it
there
for
simplicity,
but
I,
don't
know
what
other
things.
L
Yeah
well,
actually,
I
didn't
get
that
much
response.
I
wrote
a
mail
to
the
keyboard.
Def
mailing
this,
but
I
didn't
get
much
response
except
from
Snider's.
We
group
the
discussion
whether
Rico
should
we
move
to
our
integrated,
so
I
don't
know
what
to
do.
Should
I
should
I
send
some
reminder
emails
so
that
probably
a
couple
of
other
guys.
L
E
So
you
have
a
couple
of
different
options
here.
The
real
problem
we
run
into
is
with
something
like
a
UI.
That's
trying
to
walk
a
user
through
an
easy
process
to
create
a
virtual
machine
which
access
mode
it's
a
required
parameter
on
the
PVC.
What's
which
access
access
mode
should
be
chosen
by
the
UI?
It's
not
something
I
think
we
should
bother
users
with
and
that
access
mode
has
implications
on
what
features
we
can
support.
For
example,
whether
live
migration
will
be
available
for
that
virtual
machine.
E
So
it's
pretty
important
and
again
with
the
volume
mode,
so
we're
trying
to
figure
out
how
to
solve
this
problem,
make
it
easier
for
users.
One
of
the
ideas
that
we've
had
is
to
create
a
new
Ciardi
called
cube,
root,
storage
capabilities
which
would
be
ACR
that
basically
connects
the
capabilities
that
we
know
a
storage
class
can
support
with
that
storage
class.
E
So
this
would
be
an
object
that
the
UI
could
reference
when
deciding
which
options
to
display
to
users-
and
you
know
things
like
that-
it
could
be
extended
in
the
future
to
say
that,
oh
by
the
way,
this
storage
class
would
give
you
snapshot
support,
so
we
could
integrate
with
that.
It
would
be
a
single
stop,
maybe
for
the
UI
to
understand
what
storage
is
capable
of
doing
so.
We're
looking
at
this
we're
trying
to
figure
out
which
project
within
cube
root
should
own.
E
It
I
think
at
this
point
we're
leaning
towards
CDI,
just
because
it
kind
of
seems
obvious,
being
storage
related,
but
I'm,
not
exactly
sure.
That's
the
right
decision
so
more
to
come
on
this
one.
I
just
wanted
to
give
a
heads
up
because
it
really
is
I
think
starting
to
bite
us,
especially
as
we
try
to
work
with
local
storage
and
also
kind
of
shared
storage
such
as
SEF,
and
so
we're
starting
to
hit
this
for
real.
Now
any
questions
for
me
on
this
one
yeah
question
for.
A
E
It's
a
good
question,
so,
basically
the
having
CDI
own.
This
would
be
cementing
the
idea
that
cd-I
really
should
come
along
with
Qbert
and
further
bolstering
the
argument
that
they're
one
in
the
same.
What
we
would
do,
one
of
the
benefits
to
pairing
it
with
CDI
would
be
that
you
could
have
some
nice
data
volume
integrations.
For
example,
we
could
make
the
UI
not
care
about
this
at
all
by
making
access
mode
and
and
volume
mode
completely
optional
fields.
E
E
So
that
would
be
one
one
reason
to
integrate
it
there
right
now
the
UI
should
be
creating
data
volumes
in
the
Wizards,
so
it
implies
that
CDI
already
exists
there.
If
you're
gonna
create
your
own
PVCs,
then
you
might
have
to
know
what
those
should
be
I
guess.
A
contrarian
argument
would
be
in
the
template
for
templates
like
that
are
being
provided
for
as
part
of
Qbert
those
if
they're,
specifying
any
data
volume
templates,
for
example.
E
Those
would
need
to
have
the
appropriate
values
filled
in
based
on
the
storage
class
would
be
like
a
bit
of
dynamic
processing
there.
That
would
needs
to
be
thought
about.
So
I,
don't
know
if
that
answered
it
for
you,
so
the
UI
would
be
the
main
benefactor
of
this,
because,
if
you're
creating
objects
by
yourself
in
the
cluster,
you
would
of
course
have
your
own
workload
for
figuring
that
out,
potentially
in
terms
of
which,
which
values
to
specify
so
the
UI
would
would
be
the
main
main
benefit.
But
beneficiary
of
this.
D
I,
know
Pablo,
which
is
part
of
our
community
team,
is
working
on
trying
to
have
a
katakana
repository
enabled
and
the
questioning
that
we
are
having
is
where
we
want
to
actually
post
it.
So,
basically
we
can
ever
try
to
do
it
at
learn,
open
ChiCom,
which
is
kind
of
a
product
thing.
So
we
don't
know
all
we
can
otherwise
of
people
who
get
hurt,
not
credential
just
authorize
the
application
and
do
it
this
way.
So
I
believe
the
question
was
which
approach
we
should
have
and
personally
I
think
that
we
should
go
with
it.
D
A
D
M
K
Migration
policies
are
some
feature
we,
it
is
added
to
overt
and
I
was
wondering
if
and
how
it
should
be
introduced
in
Qbert
I
had
a
quick
look
at
the
issues,
and
that
appears
it
seems
no
one
is
working,
so
here
I
am
proposing
for
the
edition,
because
I
think
this
is
a
cool
feature
to
add
and
before
to
let
the
others
speak.
I
would
like
to
point
out
that
this
is
not
a
way
to
sneak
in
a
scripting
language
or
any
fancy
stuff
inside
the
cube
earth
core.
K
K
Basically,
they
a
configuration
of
configurable
way
to
monitor
the
immigration
progress,
because,
unfortunately,
immigration
is
not
something
that
one
can
fire
and
forget.
Having
emigration
successfully
complete
is
something
that
varies
wildly
with
respect
to
the
work
of
VM
workload.
So,
in
order
to
back
in
time,
we
figured
out
that
having
a
different
way
to
manage
and
help
an
immigration
improve,
depending
on
the
workload
and
making
it
configurable.
It
is
something
that
people
may
benefit
benefit
from.
K
So
this
level
of
configuration
is,
we
believe
well
speaking,
about
Oviatt
is
we
believe,
the
right
spot
between
the
confer
ability
and
the
easy-to-use.
You
set
the
immigration
policy
of
VM
to
a
choice
you
are
provided
for
and
you
you
can
add
your
own,
but
again
it
is
simple
enough
to
be
used
without
many
many
things
to
do,
but
yet
powerful
enough
is.
K
You
opt-in,
you
can
have
the
default
behavior
or
you
can
have
a
policy,
a
policy
which
is
a
policy.
Well,
the
simplest
policy
would
be
something
like
if
you
do
many
steps
for
some
definition
of
too
many
like
memory
tration.
You
know
if
you,
for
example,
reach
the
fifth
iteration
okay,
enable
post
copy
and
make
it
converge.
K
K
C
Find
out
is
what
exactly
on
which
spots
not
what
you
can
use,
but
what
you
are
doing
fully
understand
it.
To
be
honest,
it
I
kind
of
okay
I
can
specify
a
policy
for
the
whole
cluster.
But
now
you
say
that
you
can
specify
per
VM,
and
this
just
gives
me
require
opens
the
questions
for
me.
Then
what
can
you
configure
there
because,
for
instance,
I
could
select
one
policy
for
VM
a
whereas
a
it
should
migrate
with
30
M
bit
and
the
other
one
should
have
went
with
of
60
M
bit?
C
K
This
is
actually
was
the
reason
why
we
know
I'm
not
completely
sure,
but
the
bandwidth
the
bandwidth
management
bird
say
was
was
was
was
put
outside
of
the
policy
and
we
didn't
made
it
inside
in
the
first
implementation.
It
was
enforced
by
videos
and
innovate
and
what
we
made
possible
to
say
to
be
set
in
the
policy
was
flags
like
when
to
kick
in
the
podium
in
the
post
process.
They,
the
postcode
immigration
and
the
auto
convergence
flag
and
all
the
other
fancy
flag.
Depression
had.
N
K
That
could
be
well.
Another
good
effect
of
this
effort
could
be
that
we
can
have
we
need,
since
we
need
the
way
to
report
at
immigration
on
the
immigration
progress
for
implementing
the
policies.
We
can
just
start
doing
this
reporting
having
metrics
about
the
immigration
state
like,
for
example,
memory
iteration,
the
drawback
I,
see,
is
and-
and
we
can
expose
them
to,
for
example,
to
you
I.
The
drawback
is:
is
that
basically,
all
the
immigration
indicators,
we
could
think
of
we're
pretty
low
level
and
somehow
hard
to
understand
for
for
for
users.
C
Okay,
so
here
is
one
last
question
garden
to
that.
Is
that
something
which
they
mean
to
us
on
migrations,
or
is
this
something
but
I
use
it
and
says?
Okay?
This
is
a
database
which
I
don't
know
it's
hard
to
migrate
because
of
a
lot
of
Rights
and
I
can
live
with
some
performance
degradation
through
my
creation
for
as
long
as
it
migrates,
and
they
give
it
a
specific
special
policy
or
is
this
something
which
the
admin
kind
of
does.
O
C
Something
like
this
sounds
reasonable
in
general.
I
would
be
very
interested
in
seeing
why
you're
offering
with
the
users
and
what
these
policies
and
what
you
offer
them
in
the
policies
to
understand
how
it's
used
and
in
practice
but
in
general,
could
be
useful.
I
guess
it's
just
that
we
still
have
not
much
data
from
people
which
are
using
migrations
and
what
they
need,
but
they
needn't
but
I'm.
K
N
O
O
So
the
idea
of
doing
an
official
release-
and
we
agreed
that
as
a
first
step,
I
would
need
to
implement
some
integration
tests
and
integrate
them
with
CI
pipeline
and
I
just
wanted
to
give
them
head
up
that
I
managed
to
look
in
this
topic
now
this
week
and
I
will
probably
reach
out
next
week
for
some
assistance.
Assistance
on
how
this
could
be
integrated
in
CI
even
make
sense.
A
I
Yes,
you
almost
set
everything
the
pr
merged,
and
that
means
that
within
the
next
few
hours,
I
don't
know
exactly
how
much
this
is
synchronized
Cupid
version,
0,
18
1,
will
be
available
on
operator.
Hop
IO,
who
is
not
familiar
with
that
operator.
Hop
ioad
provides
an
easy
way
to
instant
operators
on
upstream
kubernetes.
If
I
just
installing
one
manifest
for
for
OLM
and
everything's
operator
lifecycle
manager,
and
then
you
have
another
manifest
for
creating
subscription.
For
example,
given
the
cube
foot
operator,
that's.
H
It's
actually
mark
on
question
here
and
I'm
I
don't
think
we
don't
need
to
tackle
it
right
now,
but
one
question
that
actually
emerges
is
now
now
that
we
support
upgrades
in
queue
bird.
How
can
we
get
the
operator
to
do
it
that
way,
right
I
mean.
Did
you
have
a
test
that
you
know
how
it
behaves
if
you
update
Cubert
through
all
m,
if
the
that
will
actually
trigger
an
upgrade
of
q
bird.
I
H
H
B
Can
so
oh,
but
he
thought
it
will.
Actually,
if
you
don't
explicitly
define
the
version
tag
and
the
version
registry
that
you
want
to
install
Cubert
with
in
the
q
bert
custom
resource,
then
it's
going
to
tie
it
directly
to
the
operator,
and
so,
if
OLM
updates
the
operator,
then
that
means
that
keeper
gets
updated.
Yeah.
B
A
H
Hates
me
I
just
want
down
movement,
so
just
heads
up
there
would
be
a
few
of
us
like
Sebastian,
not
from
from
roots,
will
be
at
the
container
days,
IO
workshop
in
Hamburg
it
sold
out,
but
we'll
still
be
around.
So
in
case
you
want
to
catch
us
catch
us
there
and
on
the
same
page
I
see
that
the
Qbert
tutorial,
which
will
be
used
there,
is
now
also
available
on
the
Qbert
org,
which
might
be
a
good
thing.
H
So
please
consider
it's
in
somewhere
in
France.
So
if
you
want
to
have
a
nice
trip
to
France-
and
you
want
to
speak
about
Qbert
and
consider
submitting
something
something
there
about
Qbert
I-
think
Hubert
has
a
chance,
because
in
the
end
we
are
we're
a
strong
user
of
KDM
right
and
form
sauce
summit.
They
also
still
focused
on
virtualization
and
kubernetes,
and
so
in
what
sweeter
spot
could
we
be
to
be
accepted?
There
cool
that
was.