►
From YouTube: KubeVirt Community Meeting 2021-04-28
Description
Meeting notes: https://groups.google.com/g/kubevirt-dev/c/LBydmsIyGTE
A
Okay,
here
we
go
hello,
everybody
I'm
chris
caligari
and
I'm
your
host
of
the
this
week's
installment
of
the
coopert
community
meeting,
and
I
want
me
to
share
my
screen.
A
All
right,
we
have
quite
a
list
of
attendees,
so
is
there
anybody
new
here
that
would
like
to
say,
hi
and
and
just
give
a
brief
mention
of
how
you're
using
coovert.
A
Nope:
okay:
okay,
let's
begin
first
agenda
item
is
from
ryan
halsey.
Talking
about
a
new
sig,
go
ahead,
ryan.
C
Okay,
they
can
hear
me
okay.
Here
we
go.
Okay,
sorry,
I'm
on
my
phone,
so
I
I
I've
been.
You
probably
saw
the
mailing
list
thread
and
I
I've
been
talking
to
a
few
folks
in
the
the
community
about
the
possibility
of
starting
a
new
sig
focused
on
scale
and
perf,
and
from
a
lot
of
the
conversations
that
I've
had
in
the
community.
C
There's
there's
been
a
lot
of
people
that
I've
found
that
are
have
been
looking
at
this
in
different
facets
and
it's
a
fairly
large
area
and
topic,
and
so
I
wanted
to
look
at.
It
are
some
of
the
specific
topics
more
closely,
so
I
put
together
a
document,
that's
linked
for
some
of
the
areas
that
we
can
explore,
not
exclusive
to
those
areas,
but
some
of
the
some
of
those
areas
that
we
can
look
at
as
well
as
a
mission
statement
for
for
the
group.
C
So
the
whole
goal
is
that
we
want
to
look
in
areas
and
elevate
some
work.
That's
that's
focused
on
perfect
scale
and
meet
at
least
to
start
off
by
monthly
on
thursday,
so
it
would
be
for,
for
this
week
we're
planning
to
have
a
meeting
so
be
tomorrow
at
the
exact
same
time
slot
as
this
meeting.
C
So
it's
1400,
utc,
7,
pacific
time,
10
eastern
we'll
look
to
let's
have
our
first
meeting,
we'll
almost
kind
of
introduce
things
and
kick
things
off
talking
about
perfect
scale.
So,
if
you're
interested
in
it
at
all
you're
doing
any
work
in
that
area
would
love
to
have
you.
We
can
discuss
any
sort
of
topics
that
are
going
on
and
try
and
look
and
solve
some
problems
with
that
area.
A
Hey
ryan,
yes,
my
only
concern
is
your
first
meeting
is
tomorrow
and
that
kind
of
interferes
with
an
all
things
open
event,
plan
that
we've
had
for
a
week.
C
Yeah,
I
understand
some
people
have
have
reached
out,
so
I,
if
you
want
like
I
I
like
I,
can
push
it
back
a
little,
maybe
like
an
hour
or
something.
But
so
that's
fine,
if
you,
if
you
think
if
you
think.
A
A
At
least
for
that
first,
one,
because
I
rescheduled
that
thing
twice
now
and
I
don't
want-
and
we
have
a
friday
deadline
to
get
our
paper
submitted.
A
C
Can
well
yeah
sure.
I
think
I
think
that,
like
some
people
have
mentioned
in
the
mailing
list
as
well
about
the
time-
because
I
I
understand
like
there
are
some
a
lot
of
conflicts
and
and
so
and
and
but
it's
good
to
see
those
interests,
so
there
we'll
I'll,
do
a
poll
for
this
after
kind
of
the
first
one.
C
So
I'll
move
this
one
back
an
hour
to
1500
utc
and
then
we'll
I'll
follow
up
after
our
first
call
we'll
do
a
poll
and
kind
of
get
some
more
insight
into
you
know
what
are
the
time
zones
that
work
for
people
and
and
we'll
find
a
good
spot
for
it,
so
just
kind
of
yeah
finding
the
first
one
is
we'll
just
to
kick
things
off
is
what
what
we
want
to
start
with.
So
I'll
move
it
back
an
hour
so
with
1500
dtc
11
more
now
on
the
mailing
list.
C
C
D
C
D
So
I'm
marcelo,
so
we
we
talked
at
tracelock
before
so
I'm
not
sure
if
I
can
join
because
we'll
be
you
know,
middle
night
in
tokyo.
So
it
is
too
late
for
me,
but
we
can.
We
can
see.
C
E
C
The
first
one
we're
just
going
to
have
to
we'll
just
go
with
you
know,
we'll
see
what
we
can
do
on
the
first
one
and
then,
like
I
said
we'll,
do
a
we'll
do
a
doodle
pull
and
we'll
get
some
more
feedback.
The
reason
I
want
to
get
a
first
one
out
of
the
way
is
just
to
get
a
general
idea
of
what
you
know
what
people
have
or
what
people
are.
C
What
times
when
work
or
what
works
with
this
time
and
and
then
we
can,
we
can
work
to
try
to
incorporate
more
folks.
So
the
the
keep
an
eye.
D
Yeah,
I
think
erza
and
nelson
can
join.
I
don't
know,
I
don't
know
if
you
he
saw
the
context
but
ariza
nelson
and
I
we
are
from
ibm
team
and
we
are
working
directly
with
coopers
in
a
collaboration
and
we
are
taking
also
some
initiatives
to
analyzing
the
convert,
control,
plane,
performance
and
scalability.
D
We
are
proposing
also
some
works
on
that,
but
I
think
nelson
will
join
tomorrow
and
then
he
can
synchronize
and
see
and
and
talk
to
you
guys
so
and.
D
G
Sure
that
michelle
they
all
that
the
hour
later
works,
also
for
me
and
I'll,
be
there
as
well
so
yeah,
oh
great,
yeah,
okay,
it's
right
after
our
perf
sync!
So
I'll
go
there
as
well.
Oh
great
yeah,.
H
H
I
I'm
all
for
nf
tables,
I
really
love
it,
but
not
so
fast.
So
the
reason
that
the
nf
tables
and
ib
tables
are
slow
to
to
be
adopted.
Is
you
don't
take
the
same
approach
in
nf
tables?
Now
each
each
table
needs
a
name
and
there's
no
default
like
before.
It
was
just
like
input
with
capital
input
or
forward
with
capital
forward.
Now
you
don't,
you
can't
predict
what
somebody's
table
names
are
ahead
of
time.
I
I
To
my
knowledge,
I
believe
so
no
no
net
filter
is
nf
tables.
Net
filter
is
the
the
the
kernel
implementation
is.
It's
is
a
net
filter
is
the
new
thing.
Ip
tables
or
ib
chains
is
what
it
used
to
be.
Iptables
is
basically,
oh,
my
god,
like
25
years
ago,
stu
really.
I
Okay,
sorry
right
so
yeah
we
should
not
have
used
that
word,
but
point
b
is
the
current.
Is
the
new
is
what
we're
moving
to
unless
I
completely
missed
reality
in
the
last
year,
or
so
so,
but
yeah
to
edward's
point,
though
this
is
something
that
salient
we
should
discuss,
but
I
think
we
need
a
path
forward
at
a
technical
level
before
we
can
just
jump.
H
So,
just
to
clarify
the
current
state,
the
current
state
is
that,
if,
if
we
detect
and
cover
it
at
the
moment,
if
we
detect
that
there
is
a
there
is
enough
table,
it
exists
and
it
works.
Then
we
use
it.
This
is
the
primary
way
to
configure
it
if
it's
not
found
we
go
to
the
to.
The
second
option
is
to
use
ip
tables,
and
even
in
that
case,
I
think
in
any
any
red
hat
mean
any
fedora
sent
us
this
kind
of
solutions.
H
We
will
also
use
probably
the
nf
tables
behind
the
scenes,
because
the
the
ip
tables
that
you
see
there
is
is
just
a
translation
layer.
It's
not
really
ip
table
behind
in
the
back,
so
I
think
the
only
place
where
this
may
exist
is
in
in
other
other
distributions,
like
maybe
an
older
ubuntu,
for
example,
but
in
so
that's
that's
why
I
raise
it.
I
I
do
recognize
it's
not.
H
We
cannot
just
deprecate
it
without
it
being
deprecated
or
removed
from
all
the
other
distribution,
but
but
I
think
that
the
current
state
is
that
we
do
support
both
in
the
code
and
that's
like
pretty
problematic,
because
we
want
to.
We
are
adding
things
all
the
time
like,
I
think
recently
it
was
about
integration
with
the
istio
and
later
we'll
have
to
add
the
max
proofing
stuff.
So
anytime,
we
add
something
we
will
have
to
support
both
the
both
in
a
stable
format
and
in
ip
device
format.
B
We
don't
have
a
great
deprecation
policy
right
now,
which
I
think
is
something
that
makes
these
discussions
hard.
So
we
kind
of
have
to
declare
what
that
is
like.
How
do
we
remove
things
and
what's
the
predictable
like?
What's
the
what's
the
procedure
that
we
go
through
like
we
announce
it,
and
then
we
wait
how
many
releases
before
we
actually
remove
it?
And
you
know
we
let
people
raise
objections
and
things
like
that.
We
don't
like
I'm
fine
with
deprecating
iep
tables,
but
how
to
go
about
doing
that,
isn't
defined.
H
Yeah,
that's
why
I
rested
here,
and
there
is
also
adding
to
what
you
said.
There
is
also
another
problem
that
we
are
not
declaring
on
what
are
the
or
maybe
we
do,
and
I
don't
know
it
on
which
nodes
operation
system
we
support,
deploying
kuvi,
because
currently
I
I
don't
know
any,
and
that
also
can
affect
this
one
of
the
things.
So,
for
example,
we
are
currently
only
if
I'm
not
mistaken,
we
are
only
testing.
H
B
H
But
this
is
a
problem,
because
this
is
what
we
can
break.
I
mean
we
can
assume
something
now
and
it
may
not
be
there
on
a
different
distribution,
but
we
don't
test
it
and
we
don't
even
declare
what
we
are.
What
we
are
saying,
I
think
this.
F
Is
internally
a
difficult
question
because
I
mean
we
use
now
center
stream
for
testing
mostly,
but
what
we
really
depend
on
to
99
is
the
kernel
version
to
be
compatible
with
it.
If
there
is
there,
then
we
may
have
issues,
but
it's
really
nice
to
get
less
about
the
operating
system.
It's
more
about
the
kernels.
B
With
sc
linux
on
ubuntu,
just
because
that
wasn't
seo,
that's
not
used
or
something
like
that,
but.
F
Yeah,
I
I
know
about
two
things:
one
is
a
c-linux
which
is
kind
of
an
an
optional
thing
which
we
support,
which
we
have
on
our
test.
Infrastructure
which
broke
once,
and
the
other
thing
is
what
edward
mentioned,
with
rp
tables
and
nf
tables.
That
are
basically
our
two
switches
right
now.
The
rest
that
we
know
of
yeah.
B
H
I
guess
it's
all
about.
I
mean
in
the
what
you
said
about
the
camera
is
right,
but
I
think
here
and
in
the
senior's
case
it's
just
the
kernel
module
that
is
either
deployed
or
not
deployed
on
the
node.
So
oh
yes,
it's
like
in
in
the
the
basic
cases
is
indeed
the
kernel
and
the
kernel
modules
that
it
it
loads,
but
the
in
the,
if
we
think
about
it,
the
end
result
is,
is
what
matters.
H
So
if
we
can
deploy
on
a
specific
ubuntu
version,
then
or
we
can
determine
any
other
distribution,
then
then
we
at
least
need
to
say
what
we
what
we
tested
on.
So
it
will
not
be
surprising
or
we
need
to
say.
A
So
yeah
there's
a
there's
orgs
out
there
that
are
sorry
guys
there
there's
there's
orgs
out
there
that
are
running
on
gen,
2
and
arch.
So
let's
not
leave
those
guys
out.
J
I
suppose
this
is
also
related
to
what
ci
do
we
have.
I
mean
if
we
would
have
a
ci
for
that
and
somebody
would
donate
a
node.
Maybe
I.
K
Would
like
to
contribute
something
here
for
you
guys.
We
didn't
reach
an
agreement
with
red
hat
to
deploy
the
solution
and
I
put
on
the
chat
window.
What
we're
gonna
use!
K
This
is,
let's
say,
an
alternative
sento
s
since
on
december,
we're
gonna
have
not
match
anymore
centos,
eight
against
red
hat
enterprise,.
K
K
Fork,
yes,
but
these
guys
have
like
enterprise
support
for.
D
L
Servers
regarding
the
table
support
I
mean
for
david
too,
I
mean
deviant,
even
kind
of
replaced.
Ip
tables
lit
up
tables,
then
kind
of
use,
the
nf
it
was.
They
have
some
variation
of
ib
table,
yeah
and
ib
tables
nft
layer,
which
interprets
all
of
the
existing
ip
tables
rolls
into
the
net
filter.
So
that's,
I
think,
since
debian
10,
if
one
breeds
correctly
and
then
variance
would
follow
with
open
to
2004,
which
is
the
latest
lts,
it
should
be
supported
and
on
by
default.
L
But
if
anything,
it's
all
included
in
packages
for
previous
periods
of
those,
I
can
check
other
operating
systems.
If
you
need
arch
linux
also,
I
just
checked
as
extensive
documentation
right.
It's
just
installed.
E
I
mean
even
now
we
are
not
testing
with
ip
tables
really,
and
so
let's
test
it
only
on
like
customers
clusters,
I
guess
so
I
mean.
Can
we
just
go
forward
with
it
and
document
that
we,
our
dependency,
is
not
a
specific
os,
but
our
dependency
is
enough
tables
on
the
host
and
announce
deprecation
period
of
like
month
for
two
and
then
just
go
all
forward
for
enough
tables
and
maybe
do
the
same
thing
for
like
the
kernel
version.
If
that's
our
dependency,
you
know.
L
Yeah,
I'm
even
wondering
what
do
you
all
use
ip
tables
for
because
I
mean
if
enough
tables
is
default
back
and
when
using
ip
tables?
What's
I
mean?
Is
there
any
real
difference
into
what
would
be
written
differently
or
the
performance
differences?
L
I'm
sorry,
I'm
unfamiliar
with
keyboard
inspected
and
how
it
revolves
at
key
tables
right
now,.
H
Oh
in
I
just
wanted
to
learn
at
once
or
about
this
one.
In
essence,
there
is
a
performance
things,
and
but
it's
I
think
I
I
I
don't
think
this
is
the
main
reason
that
I'm
raising
it.
There
is
a
difference.
There
is
a
performance
thing,
but
it's
not
that
important
at
this
moment
at
least
maybe
in
the
future,
if
we
need
to
support
some
performance
oriented
traffic,
but
this
stage
is
just
about
our
maintenance
inside
the
code
base,
so
we'll
not
have
to
worry
about
it
and
I'm
I'm
raising
it
again.
H
H
We
are,
we
are
using
currently
firewall
rules
inside
the
right
or
ip
tables
or
nf
table
rules
inside
the
wheel
launcher
code,
for
that
runs
the
virtual
machine.
So
we
have
their
rules,
for
example,
to
support.
M
Right,
so
the
problem
is
not
the
os
support.
You
need
to
remember
that
there
are
customers
out
there
that
have
assets
that
depend
on
ib
tables.
They
already
have
automated
scripts
and
some
more
more
automation
that
is
not
related
to
convert
and
deploy
firewalls
and
so
on
related
to
epitables.
So
we
need.
H
Well,
that's
correct,
but
on
the
other
hand,
it's
we
are
not
saying
that
we
are.
We
are
able
to
deploy
covert
on
any
operation
system.
I.
M
H
H
If
you
take
covert
and
say
I
require
this
is
like
a
very
general,
if
you
take
over
it
and
say
I'm
able
to
deploy
it
on
some
node
and
you
can
specify
what
that
node
needs
to
support
like,
for
example,
what
is
the
minimum
kernel?
What
is
the
kernel
module
that
you
expect
them
to
exist?
Then?
Then
you
are
opening
yourself
to
whatever
deployment
anyone
wants
to
do,
but
if
you
want
to.
E
H
M
No,
no,
I
I
fully
agree
with
you
and
you
know
there
is
this.
You
know
a
kind
of
direction
of
okay.
We
say
we
officially
support
only
what's
inside
our
ci,
which
is
not
reasonable
to
do
currently
right.
But
I'm
just
saying
it's
a
general
problem
that
at
some
point
we
will
probably
encounter,
because
you
know
we
can
postpone
that.
But
you
know
there
is
such
a
variance
out
there
that
we
need
to
have
some
kind
of
a
policy.
O
A
Sorry,
sorry,
everybody
looks
like
you
have
a
microphone
problem
and
I
muted
you
instantly.
Can
you
jiggle
your
wires
or
or
see
if
you
can
fix
it.
A
M
I
So
I
guess
yeah
having
kind
of
taken
a
step
back
and
to
let
the
conversation
go
its
course.
I
know
that
debian
stretch
has
nf
table
support,
debian
buster,
it's
it's
the
default
and
by
debian
bullseye.
I
think
that
iptables
is
outright
deprecated,
but
I
don't
I
don't
think
and
that
that's
just
an
example-
and
I
know
that
ubuntu
is
based
on
data
and
testing.
So
I
think
that
they're,
probably
already
to
the
point
that
they're
saying
ip
tables
is
deprecated,
I
don't
know
about
suse
or
any
of
the
other
major
distros.
I
So
I
I
think
that
it's
still
too
soon
for
us
to
be
aggressive
about
saying
we
will
support
iptables.
We
could
certainly
message
and
start
the
messaging
process
that
we
that
we're
going
to
start
the
deprecation
process
and
and
not
rush
into
anything.
Yet,
but
at
least
you
know
make
an
official
statement
that
we're
planning
to
go
that
direction.
F
Yeah
and
if
we
finally
define
some
deprecation
timelines,
I
think
it's
fair
to
just
write
that
ip
table
is
currently
not
tested
in
rci.
So
we
don't
know
if
it's
working
anyway
and
that
we
will
remove
code
traces
after
12
months
or
something,
but
we
need
to
define
the
I
would
suggest
to
define
on
keyword
project.
Finally,
the
duplication,
deadlines.
A
Yeah,
I
think
that's
that's
the
first
step
and
I'm
happy
to
take
on
that
issue
and
I'll
interface
with
the
with
cncf
and
the
main
kubernetes
project
and
see
what
they
have
and
bring
it
to
our
group.
G
B
G
P
P
A
He
was
in
negotiations
with
red
hat,
to
run,
openshift,
dedicated
and
and
probably
rel
as
well,
and
you
mentioned
this
morning
that
the
negotiations
didn't
succeed
and
they
decided
to
pivot
their
platform
to
kubernetes
community,
with
kubert
community
running
on
all
my
linux,
os.
P
All
right
I
mean
that's
great
if
they
speak
with
reddit.
What
I'm
more
interested
in
is,
I
would
like
to
understand.
I
mean
how
how
he's
envisioning
to
also
test
on
armor
linux
and
how
relevant
that
is
so
once
he
has
audio,
then
we
can
pick
up
that
discussion
because
I
would
be
interested
there.
A
It
might
be
worthwhile
to
to
have
a
separate
meeting
with
him
to
see
how
we
can
how
we
can
all
work
together
and
lay
out
some
next
steps.
A
A
Well,
I
I'm
going
to
suggest
that
we
move
on
to
the
next
topic.
We
can.
We
need
up
a
deprecation
policy,
so
let's
kevin
and
I
can
can
work
through
that,
as
well
as
the
future
date
and
get
something
into
the
community
project.
A
Everybody
can
comment
on
it
and
then,
for
the
sake
of
the
meeting
here
and
everybody
else
who
wants
to
talk
about
something.
Let's
move
on
for
right
now
is
everybody?
Okay
with
that.
H
A
All
right,
thank
you,
edward
okay,
shirley
request
for
contribution
or
alert
run
books.
Q
I
would
like
to
ask
for
contributions
for
the
content,
and
so,
if
anyone
that
has
the
knowledge
can
contribute
to
that,
it
would
be
much
appreciated.
Q
B
So
I
I
just
cut
the
tail
into
this
because
I
was
distracted,
but
this
alert
run
books.
I
saw
that
there
was
just
a
presentation
up.
There
was
a
github
repository
for
this
as
well
right.
Maybe
maybe
you
just
said
that.
Do
we
have
a
link
for
that.
Q
D
B
Yeah,
I
think
this
is
really
valuable,
especially
from
an
operations
standpoint.
People
will
find
this
useful
for
sure
definitely
yep.
B
P
P
M
P
P
G
R
P
We
only
do
it
for
fun
to
change
them,
but
just
my
two
cents.
I
think
that
we
wouldn't
call
them
an
api,
although
we
have
like
we
strive
for
keeping
them
stable,
and
I
think
here
we
don't
test
like
the
names,
but
we
would
rather
be
ensuring
that
a
run
book
is
provided
alongside
and
alert.
Otherwise,
it's
like
saying
hey
something's
wrong,
but
we
don't
really
help
you
how
to
get
out
of
this
situation,
and
I
think
that's
something
that
I
would
consider
to
be
important
right
simply
to
to
do
this
hygiene.
H
Yeah,
so
I'm
just
saying
that
so
no
one
will
change
this.
We
think
that
oh
there
is
a
typo.
Now
we
will
change
it
and
it
may
not.
I
will
say
it
may
not
be
easy
to
change
if
there
are
implications.
If
someone
changes
something.
M
I
I
I
actually
think
it
might
be
a
good
idea
to
at
least
look
on
the
options
of
having
it
appear,
because
there
are
other
implications
that
need
to
be
improved.
For
example,
in
the
alert
you
are
putting
the
metrics
name,
but
no
one
actually
validate
that
that
metric
same
is
actually
a
valid
one,
and
if
it's
not
no
error,
okay,
it's
just
you
are
not
going
to
get
the
alert.
M
A
All
right:
well,
let's,
let's
move
on
from
here!
We've
we've
talked
about
this
a
couple
of
times,
we'll
we'll
see
the
the
github
issue
for
updating
post,
submit
job
to
ensure
that
run
book
entries
exist
and
then,
if
well,
we're
already
trying
to
come
up
with
a
deprecation
policy
for
two
other
features
might
as
well
come
up,
might
as
well
apply
to
changing
alerts
around
as
well.
A
Thank
you
shirley.
This
is
really
good
stuff
as
a
old
ops
guy,
nothing
worse
than
not
having
run
books
on
alerts.
So
it's
gonna
make
our
our
software
even
better.
Operationally.
A
S
Yes,
that
would
be
me
hi,
so
situation
is
such
that
for
the
longest
time
live,
virgo
has
been
following
the
same
versioning
policy
as
the
main
c
library,
which
is
not
using
semver,
and
that
has
worked
fine
until
now,
but
now
we're
seeing
that
newer
version
of
go
starting
with
116.
I
believe
the
default
mode
of
operation
is
building
modules
and
you
can
still
opt
out
of
this
behavior,
but,
as
I
understand
it,
that's
going
away
with
google
1.17.
S
The
question
is
whether
we
should
do
that
and
how
to
do
it
in
a
way
that
minimizes
the
long-term
pain
for
consumers,
and
so
I
raised
the
issue
on
on
the
gitlab
repo
for
the
virgo,
and
I
would
really
love
if
people
from
the
cuber
community,
who
are
both
one
of
the
bigger
biggest
consumers
of
the
liver,
go
library
and
also
clearly
very
well
versed
in
the
go
ecosystem
and
in
the
go
modules
and
all
those
topics
could
so
into
the
discussion
and
help
us
out.
F
S
Right
that
is
definitely
what
we
do
with
the
with
the
c
library,
and
that
is
also
what
the
intention
is
with
the
language
bindings.
I,
I
cannot
say
for
sure
that
we've
never
broken
the
language
bindings
in
the
past,
because,
of
course,
the
the
design
decisions
are
different.
The
the
api,
the
end
link
of
api
and
api
is
also
slightly
different,
but
that
is
definitely
the
intention
never
to
break
the
compatibility.
F
I
don't
know
how
strict
go
is
with
december,
but
in
theory
you
could
just
add
something
like
an
epoch
in
front
like
yet
like
you
start
to
see
the
go
bindings
with
1.7.2.0
or
something
and
that
would
just
live
in
v1.
Then
right.
The.
F
S
S
A
T
A
T
A
T
It's
all
right,
so
hi
guys.
So
this
point
is
about
a
pr
that
I
posted
I
think
a
week
ago,
something
like
that
and
basically
this
changes
how
we
protect
the
part,
for
I
mean
the
vmis
while
migrating
so
like
right
now
we
create
a
pdb
that
protects
two
parts:
the
source
pod
and
target
pod.
This
pr
changes
that,
because
some
some
systems
like,
for
example,
openshift,
have
an
alert
mechanism
that
when
you
have
pdbs
that
protects
more
than
one
pod
and
you
just
have
one
part
of
life.
T
Basically
they
I
mean
it's,
it's
not.
They
complain.
So
basically,
this
changes
that
so
that
we
create
one.
I
mean
a
pdb
with
that
protects
one
part
and
when
a
migration
happens
just
for
the
duration
of
the
migration,
we
create
an
additional
pdb
that
protects
two
pots.
T
But
this
is
a
bit
controversial
because
basically
means
that,
while
the
migration
is
in
flight,
you
will
have
two
pdbs
one:
protecting
just
the
source
spot
and
one
protecting
both
and
the
documentation.
T
They
will
just
be
not
evicted
any
time,
so
this
is
kind
of
the
side
effect
which
in
practice
should
be
fine
for
us,
because
we
just
want
no
pods
to
be
evicted
while
doing
the
migration,
but
yeah
I
mean
I
just
wanted
to
discuss
this
like
if
anyone
has
feedback
ideas
and
how
to
proceed
with
this.
T
Yeah
yeah,
but
that
means,
for
example,
which
is
not
our
case,
that
if
you
have
like
min
available
set
to,
for
example,
two
and
you
have
three
parts,
so
that
means
you
can
evict
one
part
since
you
have
two
pdb's,
no
pause
will
ever
be
evicted,
so
that's
kind
of
one
side
effect,
but
in
practice
it's
okay
for
us.
I
I
B
The
behavior
is
what
we
want.
I
think
the
concern
and
the
thing
that
I'd
like
to
investigate
and
hear
other
people's
feedback
in
on
is
we're
using
a
side
effect
of
a
feature.
B
I
don't
know,
there's
unintended
consequences
for
this,
like,
for
example,
when
we
used
the
pod
disruption
budget,
as
we
have
it
today,
where
we
set
that
we
need
a
minimum
of
two
pods
available.
Whenever
live
migration
is
set
for
the
eviction
strategy,
then
we
get
the
alert.
So
is
there
going
to
be
another
side
effect?
If
we
add
overlapping
pod
disruption
budgets
where
something
else
occurs,
that
is
unexpected.
F
T
Yeah,
just
I
mean
just
bear
in
mind
that
like
it,
would
anyway
improve
the
situation
because,
right
now,
when
we
create
a
pdb,
we
have,
for
example,
openshift
complaining
all
the
time
about
this,
because
essentially,
if
you
had
never
do
a
migration,
it's
going
to
be
just
one
part
and
a
pdb
set
for
two.
T
While,
if
you
have
an
alert,
as
you
said,
the
alerts
when
you
have
more
than
one
pdb
for
you
know,
I
mean
one
part
of
the
two
parts,
whatever
you're
just
gonna,
have
the
alert
being
triggered
only
for
the
migration.
So
it's
a
tiny
bit
better
anyway.
I.
T
F
If
we
don't
find
any
obvious
downsides,
as
you
say,
I
think
it's
better
than
what
we
have
today
still.
It
would
also
be
great
if
we
would
finally
look
into
that.
There
is
a
pod
disruption,
budget
feature
which
is
called
a
max
unavailable,
which
allows
basically
says
don't
allow
the
eviction
of
any
port
which
matches
this,
and
this
works
with
deployments,
for
instance,
and
replica
sets
and
so
on,
but
it
does
not
works
for
custom
resource
resource
definitions.
F
As
far
as
I've
seen
in
the
source
code.
When
checking
this,
there
is
no
good
reason
for
not
supporting
it.
It's
just
like
it
was
not
a
priority
feature
to
add
for
custom
resource
definitions,
so
we
should,
I
think,
yeah
I
mean
your
change,
looks
good.
We
should
probably-
or
the
approach
looks
good
in
your
change.
F
We
should
just
probably
also
invest
this
time
to
add
this.
It
shouldn't
be
too
hard.
Yeah
max
max
makes
unavailable
yeah.
Okay,
thank
you.
It
does
not
work
with
trds
but
or
crs,
but
it's
really
just
about
changing
a
few
code
paths
as
far
as
I've
seen,
and
I
don't
think
that
there
was.
D
F
T
I
agree
in
the
pr
I
I
also
said
that
probably
it's
been,
I
mean
the
best
would
be
like
merging
that
approach
now
merging
npr,
so
that
we
kind
of
like
fix
this,
for
I
mean
yeah
for
for
openshift,
for
example,
and
then
use
some
time
to
do
this
in
kubernetes,
because
that's
probably
gonna
take
a
long
time.
F
T
For
I
mean
yeah
sort
of
the
same
goes
for
mean
available
because
being
available.
T
I
think
for
like
default
controllers,
you
can
use
it
that
with
a
percentage,
but
you
can
do
that
for
custom
controllers,
so
I
mean
any
any
of
the
two,
but
what
I
just
wanted
to
say
that
the
only
side
effect
that
seems
to
and
that
you
should
be
aware
of
when
reading
at
least
ordinances
documentation
is
that,
of
course,
if
you
have
a
pdb
which
protects
like,
I
don't
know,
75
75
of
the
pods,
something
like
that,
so
not
100
like
we
do
that
doesn't
work
anymore
if
you
have
more
than
one
pdb
for
for
a
single
pod
for
the
same
set
of
pods.
T
B
One
thing
just
leaves
me
a
little
uneasy
is
that
that
still
is
the
dynamic
nature
of
this,
and
I
just
wanna
throw
this
one
other
caveat
out
there
and
see
what
people
think
when
we're
mutating
or
adding
a
new
object
things
like
that,
the
controller
that
interprets
that
there's
a
lag
time
so
we
can
commit,
for
example,
this
new
pod
disruption
budget,
and
then
we
can
immediately
post
a
new
pod.
B
When
does
the
pod
disruption
budget
actually
take
hold,
so
is
there
any
risk
of
us
posting
a
new
pod,
podcoming
online
and
eviction
getting
called,
and
it
not
like?
What's
the
timing
involved
here?
Is
it
so
narrow?
That
was
something
we'll
never
have
to
worry
about
the
new
pod
disruption?
Actually
stopping
the
eviction
after
the
pod
comes
online,
or
is
there
a
concern
there?
I
I
don't
know,
but
that's
just
another
piece,
that
kind
of.
T
Concerns
me,
I
think,
that's
very
important.
I
think
that's
a
very
good
point,
but
I
mean
I
would
expect
expected
the
two
requests,
so
the
creation
of
the
pdb
and
then
the
eviction
I've
kind
of
serialized
inside
the
api
server
so
that
they
have
been.
T
I
mean
that
you
know
nothing
gets
in
the
way,
but
I
mean
if
that
can
happen.
I
am
not
aware
of
any
method
to
actually
check
with
the
whatever
pdp
controller
that
is
inside
kubernetes.
That
actually
kind
of
like
acknowledge
the
creation
of
the
pdb
and
assures
that
the
plots
are
protected.
G
T
G
T
Second,
one
because
you
have
to
basically
you
can't
modify
it,
so
you
have
to
delete
it
and
recreate
it.
But
this
basic,
like
I
think
in
not
in
my
pr,
but
an
up
yard,
was
done
in
a
previous
solution.
T
The
solution
that
was
proposed
was
to
have
the
pdp
controller,
watching
so
having
a
new
informal
migration.
So
when,
whenever
you
see
a
migration,
it
would
create
a
b2b
with
the
with
two
as
minimum
available,
so
by
default,
creating
one
as
minimum
available
and
then
creating
two
would
see
immigration
but,
as
david
pointed
out
in
that
solution,
basically
it's
risky
because
there
could
be
a
race
condition,
because
immigration
could
have
started
already
and
two
parts
might
already
be
there.
T
G
Yeah,
I
think
my
favorite
would
also
be
to
see
how
quickly
we
can,
if
and
how
quickly
we
can
fix
it
upstream
and
not
be
willing
to
help
with
that,
but
yeah.
For
the
rest,
I'm
not
deep
enough
into
the
matter.
B
Can
we
silence
the
alert,
that's
kind
of
causing
all
of
this?
Did
we
investigate
that.
T
I
did
I
did
not,
but
I
I
guess
that
would
affect
the
more
people.
I
mean
a
lot,
a
lot
more
people
than
what
we
can
think
of.
So
I.
F
B
F
So
I
think
I
would
go
with
with
taking
this
in
and
then
make
it
right.
A
And
it
looks
like
kevin
has
tagged
himself
on
the
working
up
stream
to
make
that
max
available
feature
work
correctly.
G
Yeah,
I'm
not
yet
familiar
with
the
component
itself,
but
so,
if
somebody
wants
to
work
on
it,
then
who
knows
more
about
it,
I'm
happy
to
at
least
help,
but
I'm
I
would
be
willing
to
I'll
put
up
stream.
A
Okay,
well
we're
at
eight
o'clock.
Let
me
give
a
real
quick
one
minute
summary
on
events
and
then
we'll
close
out.
The
meeting
red
hat
summit
isn't
is
in
progress.
We
have
not
had
one
question
in
our
booth
related
to
coobert
come
on
we're
awesome.
Somebody's
got
to
be
interested
in
us,
so
but
that's
the
the
nature
of
these
virtual
summits
that
the
huge
projects
like
fedora
get
all
the
attention
we
stu
and
I
are
going
to
host
all
things
open
planning
meeting
tomorrow
at
well.
A
For
me,
it's
going
to
be
7
a.m,
pacific
time,
so
10
a.m,
eastern
and
whatever,
whatever
your
time
your
time
will
be
in
in
the
european
time
zones.
A
This
thing
is
going
to
be
awesome:
an
internet
distributed
kubernetes
cluster
everybody
providing
their
own
raspberry,
pi
or
or
intel
nook
of
some
sort.
So
if
you
want
to
participate
in
this
thing,
join
us
tomorrow,
there's
an
issue
regarding
the
planning
and
the
and
the
cooper
community
repo.
A
The
meeting
information
is
in
that
issue.
Josh
burkus,
with
the
the
with
the
ospo
reached
me
yesterday,
late
in
the
day
and
wants
somebody
to
do
a
podcast.
A
live.
Podcast
live
on
it
on
youtube.
To
talk
about
cooper.
A
Youtube
interview,
so,
if
you're
interested
in
in
doing
that,
let's
talk
otherwise
I'm
gonna
have
to
do
it.
A
really
bad
public
speaker.
A
Okay,
that's
all
I
have
thank
you,
everybody
and
we'll
see
you
next
week.