►
From YouTube: KubeVirt Community Weekly Meeting - 2018-08-08
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).
A
B
A
C
D
D
B
There
isn't
really
an
advantage
for
something
like
passing
def
KVM
into
the
pot
with
all
the
overhead
which
comes
with
it,
and
it
has
a
lot
of
it,
makes
it
harder
for
developers
and
for
operators
right
now
from
my
perspective,
and
there
is,
of
course,
a
demand
in
the
future
to
use
device
plug-ins
for
different
stuff,
especially
if
the,
if
some
changes
are
getting
in
there
regarding
to
the
API.
So
I
want
to
also
make
sure
that
the
architecture
like,
for
instance,
that
privileged
operations
should
can
help
them
in
in
their
handling
of
their
launcher.
C
B
B
And
if
we
do
this
in
vert
launcher,
we,
we
can't
really
remove
privileges
from
the
wet
laundry
container
and
can't
centralize
them.
Also,
with
launcher
then
contains
logic
which
they
especially
right
now
would
be
synchronized
with
the
device
plugins
various
for
the
other
thing
we
have,
we
can
provide
an
interface
in
there,
Tendler
or
which,
which
is
much
easy
to
maintain
for
us.
E
So
one
of
the
difficulties
that
we
had
in
the
original
device
plug-in
was
to
figure
out
what
is
the
namespace
of
the
pod
right,
because
this
is
the
namespace
to
which
we
need
to
move
to
create
the
patron
and
that's
not
right.
So
the
kind
of
couple
of
workarounds
that
we
had
to
add
in
our
device
planning
to
figure
out
what
is
the
right
namespace,
and
this
is
very
easy
between
the
bit
launcher
and
the
handler
because
they
have
any
continent
which
doesn't
exist
between
the
the
device
plugin
and
the
rig
launcher.
E
B
Ya
truth,
let
me
just
add
here
in
the
future:
if
there
I
think
you're
at
now,
you
can't
even
pass
in
environment
variables
or
so
from
the
device
plug-in.
So
we
still
device
plugins
in
the
future
could
offer
something
like
that
to
hurt
launcher
and
then
still
there
tend
like
an
extracted
information.
If
there
is
a
well
known
interface
or
something
that's
completely.
Fine
from
my
perspective,
important
part
is
really
that
we
have
one
of
the
important
parts.
B
F
I
wasn't
there
for
the
discussion
last
week,
but
I
was
able
to
catch
up
a
little
bit
with
the
discussion.
So
from
my
perspective,
what
I
see
is
that
we
talked
a
lot
about
what
the
device
plug
in
some
part,
some
people
were
speaking
about,
including
me,
should
deliver
so
the
layer,
two
functionality
and
I
think
that
that
is
still
valid,
what
it
provides,
but
what
we
missed
is
to
really
deepen
the
discussion
about
how
the
integration
with
cupid
is
is
looking
because
I
think
to
the
people
work
we're
working
on
the
networking
side.
F
You
look
pretty
straightforward.
So
now
we
see
that
there
are
concerns
on
the
integration
side.
So
what
I'm
proposing
is
actually,
let's
have
a
document
to
focus
only
on
the
integration
and
interactions
between
the
device,
plug-in
and
kubert's
are
how
we
can
integrate
them,
because
it
looks
like
it.
The
existing
PRS
are
not
enough
or
not
the
right
platform
to
discuss
this
so
I
would.
F
What
I
would
prefer
is
to
exchange
thoughts
is
travel,
design
document
or
something
like
that,
where
we
can
outline
the
specific
flows,
we
have
how
the
integration
loops
in
detail,
how
the
information
is
passed
from,
what
component
to
what
component?
What
component
is
responsible
for?
What
and
what
implications
that
that
has
to
to
the
DM
API,
but
also
to
to
other
api's
I.
C
Think
I
mean
that
what
we
are
miss
I
mean
what
I'm
a
missing
is
an
understanding.
What
exactly
is
is
the
device
plug-in
API
is
missing,
be
properly
used
by
cube
field,
so
we
could
I
mean
I
would
like
to
that.
The
device
plug-in
knows
due
to
which
container
it
needs
to
attach
it
to
which
airport
it
needs
to
attach
the
device,
and
this.
A
A
So
one
of
the
problems
is
that
well,
when
you
do
a
device
advertisement
at
the
host
level,
that's
fine,
but
if
Bert
handler
doesn't
boot
up
for
any
reason
at
all,
every
error
that
could
possibly
manifest
shows
up
as
a
device
plugins
error.
So
it
kind
of
masks
real
issues
and
they
just
show
up
as
can't
schedule
the
pod
sorry
we're
unable
to
assign
file
ownership
to
device
nodes,
because
the
the
framework
provided
by
kubernetes
only
makes
the
path
exist.
It's
owned
by
root
and
if
that's,
not
appropriate,
there's
no
way
to
change
that.
A
You're
gonna
need
privileges
to
longer
to
correct,
then
you're
going
when
the
device
is
created
at
the
handler
level.
That's
done
at
the
very
end
of
the
questions.
There's
no
context
inside
that
the
Pyke's
plugin
about
which
pod
the
device
is
assigned
to.
When
you
have
a
direct
connection
between
handler
invert
launch
or
if
there's
a
special
understanding,
that's
needed.
That's
already
present
is
you
have
that
socket
that
connect.
F
Yeah-
and
that
goes
a
lot
into
the
device
plug-in
discussion,
because
one
can
say
it's
a
question:
if
device
begins
should
know
the
the
pod.
The
namespace
is
what
it
should
operate
on
or
if
you
look
at
the
today
still
device
plug-in
API,
then
the
device
program
does
not
know
anything
about
the
pods
or
what
they
live.
Yes,.
E
Maybe
maybe
a
comment
about
that?
Maybe
Sebastian
can
chime
in
so,
for
example,
there
is
an
example
of
using
device
phone
in
conjunction
with
the
maltose
scene,
I
wear
the
device
bargain
is
used
only
for
the
resource
friendly.
So
the
only
thing
with
device
parking
does.
Is
that
the
discovery
of
the
resource
and
tell
how
many
instances
in
which
this
is
a
boundary
region,
because
it's
in
4s
or
RV,
so
it's
not
unbounded,
so
it's
bounded
resource
and
the
only
thing
that
device
parking
does
is.
E
Does
the
discovery
check
how
many
instances
or
virtual
functions
there
is
on
the
note
and
publish
that
and
the
actual
work
and
API
and
communication
is
not
done
by
the
device
buggy.
So
you
know
all
the
information
that
we
think
that
they
respond
in
such
a
case
should
transfer
to
whomever
needs.
The
resource
is
not
on
valuable
time
with
that
by
the
democracy
in
our
that
supports
SLE,
and
the
the
only
use
of
the
my
funding
here
is
that
communities
knows
how
to
schedule
paying
smartly,
where
the
resources
exist
and
that's
it.
E
C
C
You'd,
like
you,
could
use
device
plug-in
to
allocate
smartly
yeah
exactly
but
okay,
but
but
but
what
you're
saying
that
a
device
plugin
should
to
be
used
to
I
mean
when
we
are
using,
for
example,
vgpu
to
which
the
device
plug-in
was
invented.
It
was
not
just
reporting
what's
out
there.
It's
also
passing
the
the
specific
device.
B
Instance,
right
now,
network
devices
don't
have
a
path
with
list;
some
don't
have
one
right,
and
so
you
then
creating
a
fake
device
which
you
pass
the
cubanÃa
so
that
it
has
to
create
something
and
I
think
all
those
things
we
now
said.
We
lead
to
the
situation
for
us
right
now
that
we
have
to
bring
in
a
lot
of
X.
C
C
F
Well,
yes,
I
know,
there
are
I
mean
there
are
several
iterations
of
that.
The
thing
is
the
thing
is,
and
that
is
why
I'm
a
fan
of
really
getting
it
pre-major
into
Cubert
is
to
gain
hands-on
experience.
The
problem
is
that
a
lot
of
the
mandates
are
not
defined
like
that
number.
It
is,
it
is
not
I
mean
it
could
be
a
simple
integer.
You
know,
which
is
you
know
where
you
move
some
quantity
and
and
dedicated
to
a
pod.
F
What
I
try
to
say
is
it's
very
hard
to
define
a
shopping
cart
if
we
have
for
ourselves
not
clear
how
we
imagine
the
right
solution
to
look
and
to
get
to
the
right
solution,
I'm
a
fan
of
getting
hands
on
and
having
real-world
experience.
What
is
helping
us,
and
that
is
why
I'm
so
hard
for
pushing
to
get
device
begins
in
so
that
we
know
how
we
want
it
to
be
and
how
it
is
right
to
get
it
more.
Firsthand
x-rays
did
not
write
it
or
invented
from
scratch,
and
we.
F
F
C
F
E
F
I
think
that
is
that's
our
goal.
I
mean
we
know
the
device
breaking
API
is
not
suited
for
network
devices
currently,
for
several
reasons,
I
mean
I.
Think
that
yeah,
for
several
reasons
and
in
the
discussion
in
upstream.
If
you
look
at
the
mailing
list
and
the
meeting
nodes
and
some
of
the
resource
management
working
group
and
make
that
work,
plumbing
working
group
we
see
over
the
last
year,
there
was
always
a
discussion.
C
F
B
F
And
that's
why
I
proposed
a
design
document
to
sort
out
how
an
expected
integration
can
work,
because
we
saw
that
the
current
suggestion
was
maybe
too
too
harsh.
It
didn't
take
the
consents
into
account
and
there
are
other
objections
on
your
PR,
but
that's
okay,
I
just
want
I.
Think
design
document
is
good
because
then
we
can
have
that.
Then
we
have
the
ground
to
discuss
what
an
acceptable
solution
can
be
and
then
I
think.
As
part
of
that
document,
we
can
start
to
outline
that
shopping.
F
Cart,
like
you
know,
device
the
gr,
PC
awareness
for
netlink
devices,
for
example,
or
file
ownership.
Like
you
mentioned,
these
are
the
things
that
we
should
point
out
and
what
it
would
be
good
to
have
in
order
to
make
our
solution
or
integration
optimally
integrated
on
the
long
run
with
device
pregnant.
So
in
other
words,
what
we
would
require
from
the
device
plug
an
API
in
order
to
have
to
stand.
C
F
F
And
be
complete
with
the
problem,
because
the
problem
or
the
complexity
increases
with
the
resource
classes,
for
example,
which
are
also
being
developed,
because
then
we
can
model
stuff.
Like
this
logical
network,
read,
for
example,
it
is
backed
by
these
resources
where
resource
can
be
in
a
classical
net
link
device.
It
can
be
a
file,
a
file
pointer
because
that
can
be
used
for
I,
don't
know
for
better
efficiency.
It
can
be
shared
memory
because
DVD
K
is
using
that
so
I'm
saying
the
topic
is
complex
and
I
know
my
gist.
F
H
Also
have
latent
configuration
on
network
devices
that
are
only
discovered
at
runtime,
so
like
after
Qbert
brings
up
a
vm.
If
you
had
the
domain
XML
hooks
that
that
you
guys
developed,
we
discovered
some
some
latent
network
device,
modifications
like
multi,
cue,
stuff,
I'm,
not
sure
exactly.
It
would
be
easily
expressed
with
just
the
device
plug-in
approach.
H
D
H
Saying
after
on
the
web,
hooks
sorry
not
web
hooks
on
the
hooks
API
that
Qbert
has
basically
on
the
domain
XML,
we
can
tell
the
network
interface
extra
properties
before
we
start
up.
You
know
basically
through
libvirt.
What
I'm
saying
is
that
some
of
those
properties
are
not
necessarily
available
to
the
device
plugin
and
are
only
available
at
runtime.
Why.
F
I
think
I
think
I
think
what
Alexander
tried
or
let
me
try
to
put
in
my
words
and
to
make
sure
I
understand
correctly.
Alexander
is
the
order
of
availability
of
resources
provided
by
device
plugins
in
in
relationship
to
the
to
the
hooks.
We
introduced
right
so
that
at
the
point
where
hooks
are
run,
not
necessarily
all
devices
are
available.
Yes,.
H
F
C
I
would
like
to
understand
it
that
they
caveat
here,
because,
as
I
see
it
I
mean
we
had.
One
option
was
for
whomever
that
defines
the
the
VM
a
writing
down
which
resources
it
requires.
Oh,
the
other
idea
that
better
have
had
for
admission
controller,
that
translates
a
network
name
to
the
resource
that
implements
it
and,
as
I
said,
the
admission
controller
can
hop
in
after
the
dome.
Xml
is
already
defined,
so
it
can
take
the
dome
XML
into
consideration
and
require,
if
it
resources
only
if
they
are
like
based
on
the
hooks,
know.
B
F
So
yeah
I
mean
concerns
like
what
you
have
Alexander
and
how
that
effects.
Also
the
device
rings.
That's
also
which
we
need
to
capture
somewhere
and
maybe
such
a
designer
come,
which
is
specifically
speaking
about
the
integration,
might
race
or
or
make
those
might
be
good
place
for
somewhere
site,
because
we
don't.
H
A
All
right
I
mean
at
this
point.
This
is
an
important
discussion,
which
is
why
we
spent
half
the
time
slot
here
on
it,
but
I
think
we
might
want
to
move
on
to
the
next
topic
here,
which
may
be
a
couple
of
weeks
ago.
You
had
put
down
a
note
for
opinionated
cube
vert,
but
we
have
had
a
chance
to
discuss
that.
Yet
so
I
just
wanted
to
give
you
that
chance,
yeah.
F
D
F
Qbert
isn't
out
under
kubernetes,
but
communities
can
be
set
up
in
many
many
ways,
so
we
actually,
we
just
saw
in
the
slack
channel
that
somebody
tried
to
run
Cuba
with
calico
as
a
back-end,
Network
back-end,
and
he
had
some
issues
with
connectivity
so
right,
but
that
is
about.
It
is
I'm,
more
speaking
about
Qbert,
so
for
Qbert,
for
example,
and
we
also
have
some
variation.
F
So
currently
we
have
what
do
I
try
to
say
for
Cupid,
for
example,
we
have
CDI
which
can
help
us
to
provision
PVCs,
and
we
might
have
an
Alaia
to
plug-in
device
plug-in
which
provides
us
now
more
functionality,
and
all
of
that
could
be
meshed
together
to
provide
a
specific
distribution
of
keyword
with
opinionated
set
of
components,
because
after
all,
you
don't
need
CDI
and
you
don't
need
the
Lane
to
plug
in.
But
on
the
other
hand,
we
could.
F
We
could
form
a
set
of
valuable
tools
together
in
one
and
one
entity
in
order
to
make
the
deployment
for
users
more
easy.
Also-
and
that
already
affects
us
today,
independent
of
these
additional
tools
like
CDI
and
the
ultra
plugin
stuff,
like
updating
or
removing
comfort,
is
already
not
easy
and
I
wanted.
The
does
an
operator
which
it
can
be
opinionated
to
some
degree
could
help
us
to
to
resolve
the
installation,
the
installation,
installation
of
removal
of
Qbert
and
delivering
additional
components
to
three
users.
F
Because,
clearly,
we
have
cubed
ansible,
which
is
doing
this
job
to
some
degree
for
open
shift
and
an
operator
would
be
more
I,
think
a
more
native
way
or
more
or
traceable
way
to
do
to
do
this
stuff,
it
would
also
fit
in
with
the
operation
framework.
Like
know
they
operate
a
lifecycle
manager
and
so
on.
We
actually
started
on
that
I.
F
J
D
D
It
seems
to
me
that's
really
about
installing.
You
know
application
in
basically
multiple
instances
of
applications
and
multiples,
namespaces
and
since
Qbert
is
kind
of
a
cluster
single
thing.
It
didn't
have
been
super
nicely.
It
has
a
lot
of
like
clusters
to
go
resources
that
you're
not
supposed
to
create
in
operators
and.
D
D
It
may
be
something
else
it
seems
like
it's
like
they
have
a
philosophy
document
and
it
seems
like
their
whole
philosophy.
Is
everything
so
everything
the
operator
does
should
be
scoped
to
a
single
namespace
and
there
shouldn't
be
any
kind
of
shouldn't
other
than
the
CRD,
which
is
a
global
things
which,
by
the
way,
the
operators
aren't
supposed
to
install
the
CR
DS,
that's
handled
by
some
other
something
in
the
OLM.
It
has
actually
quite
them
figure
it
out,
yet
it
it's.
D
It
seems
to
me
at
the
philosophy
of
the
operations
about
installing
these
applications
and
isolating
namespaces
of
it.
You
know
they
can
do
charge
back
and
kind
of
things
like
that
when
they're
installing,
when,
when
your
operators
potentially
installing
like
no
cluster
roles
or
things
that
are
span,
multiple
namespaces
it,
it
makes
it
harder
to
manage
them
like
one
of
the
hard
things
manage
with
other
applications
like
the
sub
resources.
J
D
H
So
david
quota
management,
we
would
use
that
too
I
think
so,
for
example,
like
the
the
web
team
arakawa
would
one
like
some
VMs
for
them
to
use
that
are
separate
in
terms
of
accounting,
from
like
the
platform
or
whatever
other
departments.
So
I,
you
know,
and
then
it
gives
us
different
failure.
Domains
like
if
a
set
of
things
fail
in
a
particular
name
space,
the
label
selectors
in
kubernetes,
they
might
not
necessarily
affect
other
namespaces
at
the
hardware
level.
F
F
What
we
need
yeah,
because
a
general
statement,
I
I,
think
there's
so
much
hotter
air,
no
not
for
the
area,
but
there's
so
much
fuss
around
communities.
That
a
lot
of
stuff
is
work
in
progress
and
I.
Think
let's
speak
to
the
people
to
understand
their
intention
and
see
where
they
go,
because
after
all,
we
know
they're,
they
have
limited
resources,
just
like
we
have
so
they
might
just
not
have
gotten
to
it.
But
to
me
it's
important
understand.
D
I
mean
one
thing:
I
think
we
could.
You
know
I,
think
my
understanding
of
their
vision.
We
could
change
the
way
Cubert
is
installed.
You
know
basically
have
API
servers
that
listen
on
on
her
own.
The
operations
on
certain
namespaces
have
basically
all
these
components
like,
rather
than
listening
for
new
C
RDS
on
every
namespace,
with
specific
namespaces,
you
could
have
the
operator.
The
OLM
basically
have.
D
J
F
A
B
Yeah
we've
said
before
I
think
we're
at
in
a
meeting
way
where
we
had
to
migrate
off
from
our
own
infrastructure.
We
had
a
new
infrastructure,
which
is
also
used
by
overt
and
most
of
the
chops
are
now
running
there.
There's
just
one
Windows
test
Lane
running
there.
We
will
make
sure
that
Windows
is
really
working
with
Cubert,
which
was
hopefully
migrated
off
to
this
week,
and
the
most
important,
visible
part
is
that
the
logs
look
different
and
that
you
have
to
run
CI
test.
Please,
instead
of
retest
this,
please
that's
it.
A
K
Sorry
so
I
hi
everyone
I
posted
in
indeed
er
a
couple
of
P
arts
and
Philippine
issue
to
an
issue
to
track
the
what's
going
on
and
we
we
me
and
Martin.
We
are
experimenting
still
at
the
virgin
dear
of
veered
profiles
diamond,
so
we
are
deep
in
design
face,
but
one
of
the
concerns
I
have
is
the
overlap
between
Viet
profiles
and
current
presets,
which
we
will
totally
have
some
overlap
in
my
opinion,
so
those
patches
are
an
attempt
to
see
how
we
can
solve
this
overlap
and
see.
K
How
can
the
two
feature
can
coexist
and
I'm
not
looking
for
a
merge?
What
I'm
trying
to
do
is
to
demonstrate
with
code
and
not
just
with
words
in
English
how
it
could
lie,
how
it
could
look.
So
people,
please
comment.
Even
if
you
can
say
no,
this
is
not
going
to
flood,
because
that's
okay,
I
just
need
death
because
and
that's
it.
G
Can
you
hear
me?
Yes?
Yes,
so,
okay,
now
we
have
a
problem
using
the
provider
dot-111
that
zero
desire.
There
is
a
problem
that
was
in
Cooper
natives.
We
need
to
rebuild
this
provider.
The
problem
was
when
I
try
to
run
again,
they
make
clusters
sing.
It
can
delete
the
veldt
handler
and
can
delete
the
API
a
api
aggregation
of
the
ver
type
VI,
a
resource
where
the
problem
was
fixed
by
kubernetes
there.
G
They
have
a
problem
with
the
finalizar
in
in
the
pod
and
the
configuration,
so
we
just
need
to
rebuild
it,
and
I
will
push
a
bit
hard
because
we
need
to
do
one
more
thing.
We
need
to
change
the
way
we
are
cleaning
the
environment.
We
first
need
to
delete
the
PVC
we
create
and
after
that,
delete
the
PV
and
because,
if
we
try
to
delete
the
PV
first,
it
just
stuck
in
a
in
deleting
mode
until
this
until
you
remove
the
PVC,
it's
something
new
in
Maricopa,
ettusais,
1.11,.
A
B
B
There
are
many
different
layers
possibilities,
and
then
we
have
a
device
or
an
interface
or
even
multiple
devices,
whatever
brought
in
there
and
the
pot,
but
we
don't
have
it
on
the
VM
and
there
is
a
captain
how
to
connect
it
to
QE
move
with
levert
run
and
I
am
just
interested
in
standardizing
that
gap
for
us
and
before
that,
whatever
community
likes,
whatever
makes
sense,
whatever
flies
in
Cubert
or
cuban
illustrate
the
cuban.
Is
it's
fine
for
me,
but.
B
G
Exactly
what
water
barometer
does
is
is
to
move
the
binding
mechanism
that
we
does
in
the
vert
launcher
to
the
vert
handler
to
do
everything
and
just
give
the
virtual
machine
just
given
the
interface
on
there.
So
the
relaunch
I'm
just
going
to
put
everything
in
the
a
vertex
ml
and
that
that's
it
that's
on
the
logic
it's
going
to
do
and
the
logic
its
move
to
the
handler.
It's
Andy
yeah,
so
I'm.
C
C
F
Great
yeah
and,
and
just
a
note,
I
think
that
is
what
we
now
see
in
the
original
Network
API
document.
The
the
bending
binding
making
us
more
connections
back
then
really
were
not
clear
enough
and
I
think
that
is
yeah.
What
we
need
to
be
clear
for
I,
didn't
add
in
say
something
in
any
I
did
not
say
anything
but
you're.
Sorry,
okay,.
A
L
A
I
A
F
C
F
A
There
there
is
one
issue
that
I
would
prefer
to
see
in
and
that
is
pull
requests.
1372.
Let
me
grab
the
go
over
the
chat.
Put
that
in
there
this
one
is
basically
just
a
small
knit
with
respect
to.
If
you're.
Under
current
framework,
we
automatically
find
a
ton
device
to
every
virtual
machine.
It's
part
of
the
pod
networking,
if
you
are
opting
to
not
use
pod
networking
using
the
auto,
attach
pod
interface
false.
A
We
still
require
a
ton
device
using
device
plugins
in
cases
where
we're
trying
to
avoid
device
plugins
altogether
that
can
break
things.
Aka,
open,
stack
or
open
shift.
Origin.
Excuse
me
where
we
don't
have
operable
device
plugins.
This
might
be
helpful
other
than
that.
It's
not
a
huge
deal,
but
in
some
cases
might
be
I.
F
A
A
And
we
have
a
couple
action
items
that
we
captured:
creating
the
document
to
the
design
document
for
device
plugin
integrations
and
how
we
want
that
to
work
and
look
and
the
follow
up,
keep
for
an
operator
operator
framework
tape
just
to
get
their
perspective
other
than
out
of
there
any
other
items
for
the
open
for
and
or
agenda
items.
We've
missed.
F
Just
a
quick
one,
I
wondered
if
we
want
to
do
if
we
want
to
try
to
get
no
I'll,
be
sending
out
an
email
to
the
mailing
list
to
ask
whether
we
want
to
have
a
small
meetup
at
one
before
cube
con
I
mean
the
day
before
cube
kernels,
usually
the
sick
day.
Well,
dicks
are
meeting
up
to
speak,
but
we
are
known,
and
maybe
we
even
get
a
space
there
and
then
would
have
an
opportunity
to
get
together
have
some
time
to
speak
and
discuss
stuff.