►
From YouTube: KubeVirt Community Meeting 2022-06-08
Description
Meeting Notes: https://docs.google.com/document/d/1kyhpWlEPzZtQJSjJlAqhPcn3t0Mt_o0amhpuNPGs1Ls/
B
C
Everybody
I'll
introduce
myself,
then
rob
manger.
We
joined
last
week
just
to
tune
in
and
listen,
but
we're
working
on,
kubert
stuff
on
a
project
on
our
own
and
just
wanted
to
start
being
engaged
and
involved.
So
hello,
thanks
for
letting
us
show
up
and
join
you
guys.
A
B
Yeah
yeah,
where
okay
yeah
just
sorry
here
we
go.
B
Okay,
here
we
go
so
yeah
one
note
so
or
not
in
the
no
note,
so
something
I
wanted
to
to
start
discussing
is
so
first
we're
still
not
v
one
right,
so
we're
still
releasing
a
pre-release
state
with
zero,
fifty
five
or
zero.
Fifty
six
and
two
topics
that
are,
on
my
mind
are
oh
yeah.
B
I
will
remember
now
why
my
certain
pick
is
actually
moving
to
v1
and
actually
the
two
topics
that
I
want
to
add
is:
let
me
actually
restructure
differently
is
so
it's
v1
and
then
the
release
schedule
and
the
third
item
is
deprecation
policies,
but
I
think
itamar
was
working
on
that
already.
So
what
I
want
to,
what
I
want
to
start
discussing
is
how
we
move
to
v1
right.
B
So
the
great
thing
about
one
great
thing
about
moving
to
the
cncf
incubator
is
that
we
now
get
some
marketing
support
from
the
cncf,
and
I
think
this
is
a
good
opportunity
to
now
look
at
amy4v1
so
that
we
can
leverage
the
marketing
powers
of
cncf
to
then
really
advertise.
B
So
I
would
like
to
make
that
a
topic
and
a
recurring
topic
on
this
call
simply
to
start
bike
sharing,
I'm
not
sure
if
bike
shedding
is
the
right
point
to
reiterate
over
it
to
come
to
a
tangible
plan
and
one
of
the
things
that
I
want
to
touch
base
on
this
release
schedule.
So
one
of
the
things
is,
we
have
a
lot
of
releases
today
so
every
month,
and
there
are
a
few
things
about
it.
B
So
if,
for
example,
we
speak,
one
part
of
the
ccf
incubator
discussion
was
how
do
we
build
a
roadmap
right?
B
Until
you
see
oh,
it's
finally
converging
well.
This
is
not
a
good.
How
does
this
relate
to
the
release
schedule?
So
one
thought
is:
oh
at
the
same
time
and
there's
a
number
of
problems
right.
At
the
same
time,
we
see
that
vendors
use
quite
old
versions
of
keyboard.
B
Like
might
be
a
year
old
or
something
like
this,
because
if
they
have
downstream
patches
right,
then
they
need
to
rebase
their
stuff
and
it
takes
them
a
while
to
move
to
a
newer
version,
and
this
means,
if
you
want
a
backboard,
a
feature
or
backboard
to
fix.
You
need
to
adjust
many
versions,
and
these
are
just
just
two
reasons
why
the
number
of
versions
that
we
have
or
releases
are
are
hurting
us.
B
Oh,
a
third
topic
is
actually
ci
right,
because
if
we
release
something,
then
we
want
to
test
it
test
it
and
we
need
to
test
it
with
which
of
the
kubernetes
version.
So
it's
a
lot
of
quite
some
work
attached
to
a
release,
long
story
short:
if
we
move
to
v1
right
and
maybe
before
or
at
the
same
time,
I'm
not
sure
about
it.
B
Maybe
before
we
can,
I
would
I
would
start
proposing
to
to
see
that
we
adjust
the
release
schedule
to
actually
align
to
kubernetes
right
so
instead
of
having
one
and
it
might
actually
align
with
the
project
overall
right,
because
we
kept
developing
kubernetes
for
many
years
now
and
many
features
went
in
and
there's
for
sure
more
to
come,
but
the
pace
of
features
has
slowed
down.
So
maybe
it's
fair
to
say,
we
can
reduce
the
the
pace
of
our
release,
schedule
and
delight
to
kubernetes
and
kubernetes.
B
Today
is
releasing
every
four
months
and
they
have
a
very
well-defined
schedule.
So
that
would
mean
instead
of
having
12
releases
a
year.
We
would
reduce
this
to
three
releases
a
year
and
maybe
speak
about
one
a
nightly
or
a
mainstream
right,
or
we
simply
ship
whatever
is
in
maine,
and
somebody
can
update
from
from
from
night
to
night,
effectively
or
day
to
day,
depending
on
where
you
are
so
that
would
be
one
proposal
to
to
drastically
clean
up
the
release
schedule.
B
That
would
make
it
easier
to
do
rough
planning
right
because
you
would
say
yeah.
Maybe
a
feature
is
planned
for
the
end
of
the
year
and
then
we
can
simply
use
like
the
kubernetes
versioning
or
timing
to
say
that
it's
when
we
intentionally
landed,
we
can
clean
it
a
lot
a
little
bit
of
ci
right,
because
we
don't
need
that
many
versions
anymore,
and
we
don't
need
that
many
backboards
right,
because
if
you
want
the
back
port
for
you
now
you
need
12
backboards
in
future
wood.
B
So
that's
that's
a
long
story
short
and
I'll
extend
that
actually
so
the
simple
proposal
I
want
to
start
working
on-
and
I
think
at
least
spoke
with
daniel
hill-
about
it
is
to
to
to
change
that
release.
Schedule
a
little
bit
and
clean
it
up.
D
Yes,
how
are
you
doing?
We
hardly
ever
talk
how
the
heck
you're
doing
just
to
clarify
when
you
spoke
at
v1.
You
had
mentioned
that
that
david
had
been
working
on
this
a
year
ago.
Was
he
working
on
the
api
version
or
the
the
version
of
the
software
release
itself?
B
Api
version,
and
but
he
also,
he
also
started
to
to
speak
about,
and
he
had
a
keyboard
summit
session
last
year
about
it
and
a
document.
We
can
dig
it
out
again.
He
also
spoke
about
what
does
it
actually
need
beyond
the
api
to
move
kuber
to
version
one
right,
because
v1
is
used
to
many
places
today
got.
D
It
and
on
the
subject
of
the
release
schedule,
I
I
like
this
idea.
One
question
I
do
have
is
the
intention
to
move
to
v1,
before
or
after
changing
the
release
schedule
to
a
different
pace.
B
Yeah,
I
wonder
about
that
as
well.
I
I,
I
think
it
should
be
a
precondition
to
v1,
simply
because
v1
means
we
are
somewhere
and
we
don't
want
to
race
anymore
right,
that's
being
about.
You
know
better
safe
than
sorry
a
little
bit
right,
at
least
for
the
stable
releases.
D
Sorry
trouble
with
your
mute
button:
hey
I'm
all
on
board.
I'm
curious
should
we
consider
changing
the
way
we
represent
the
version
numbers
as
we
change
the
the
tempo
of
releases
or
we
just
continue
with
54
55
56,
but
only
do
three
lineal
numbers
a
year
as
opposed
to
I
don't
I
I
don't
know
if
it
even
is
a
good
idea,
but
date
format
or
something
not
to
violate
goling
version
numbering
though
yeah.
So
I.
B
B
So
maybe
there's
a
difference
so
124,
let's
assume
we
align
the
version
numbers
right
if
cubit
124
is
how
that
is
supported
on
kubernetes
124
right,
because
I
would
say
this
is
like
neatly
entirely
coupled
that
is
like
a
an
optimized
pair
and
if
you
deviate
from
from
this
coupling,
then
maybe
that
has
an
impact
on
the
support
cycle
status.
Right
that
we
say
yeah.
Sorry.
E
Hey
yeah
yeah,
I'm
just
kind
of
lurking
in
the
background
here
to
place
devil's
advocate
here.
If
we,
if
we
anchored
to
kubernetes
and
they
decided
to
go
to
v2,
that
would
be
a
little
awkward
for
us,
because
what
would
v2
mean
for
cubert?
I
guess
I'm
saying
that.
Maybe
it
doesn't
maybe
it's
a
little
risky
to
anchor
ourselves
to
kubernetes
when
we
may
or
may
not
want
to
what
happens
if
kubernetes
may
or
may
not
reflect
the
state
of
keeper.
B
That's
fair
and
first
we
don't
have
to
put
it
in
writing
to
say
that
we
always
follow
the
community's
release,
but
from
my
point
right
now
right
for
the
foreseeable
future.
To
me,
it
seems
that
we
are
coupled
tightly
enough
to
kubernetes
that
first
it
wouldn't
make
sense
to
do
that
alignment
and
with
respect
to
your
concern,
if
kubernetes
decides
to
move
to
b2
right,
I
I
would
wonder
what
does
that
actually
mean
for
keyboard
right,
regardless
of
the
versioning
I
mean
if
they
do
such
a
big
jump
right.
B
I
would
expect
that
there's
some
fallout
for
kubert
as
well,
in
order
to
be
possibly
supported
on
that
new
version
right.
So
even
could
that
potentially
mean
that
even
for
us
on
the
keyboard
side,
this
could
justify
or
lead
to
also
a
major
version
jump
simply
because
we
need
to
adjust
to
continue
working
on
that
new
kubernetes
platform.
D
So,
as
far
as
aligning
the
version
numbers,
I
all
right-
that's
fine,
there's
an
implication
there.
In
my
mind,
that
would,
if
we're
changing
our
verse
number
to
1.24,
because
that
matches
the
1.24
release,
I
think
there's
a
mental
implication
that
we're
only
going
to
support
124
with
the
124
release.
D
Our
current
policy
is
to
support
the
last
three
releases,
but
that
may
especially
for
jumping
to
a
three-month
cycle
that
may
not
make
as
much
sense
anymore
to
do
so
much
backward
compatibility
testing
except
I
mean
I
don't
know
what
what
are
your
thoughts.
B
On
that
yeah,
it's
fair.
I
think
we
cannot
be
so
in
my
opinion.
In
my
mind,
we
cannot
set
up
this
requirement
to
say
that
we
must
only
support
keyboard
and
the
matching
kubernetes
version
right,
ignoring
the
version
numbers
right.
I
think
we
cannot
require
users
to
only
have
one
version
to
choose
from
when
when
choosing
the
kubernetes
version,
so
I
think
we
need
to
maintain
the
backwards
compatibility
to
some
extent.
So
I
think
this
support
guarantee
that
we
give
today
right.
I
think
that
should
roughly
stick
to
the
future
as
well.
B
B
By
the
way,
it
says
it's
the
same
way,
they
support
the
versions
of
the
I
mean
the
three
most
recent
versions
and
to
me
that
sounds
very
even
for
the
keyboard
like
that,
but
it
makes
it
more
clearer
right,
because
today
we
have
that
mismatch,
that
we
have
so
many
versions
on
the
keyboard
side
and
few
versions
of
kubernetes
side
by
lining
the
version
number
the
releases.
Let's
take
the
version
numbers
aside
for
a
second
focus
on
the
releases.
B
I
think
that
would
at
least
make
it
clearer
what
version
is
supported
where
right,
because
we
would
have
three
versions,
two
three
keyboard
versions
and
they
would
be
supported
on
the
most
recent
one
or
three
combination
version.
The
second
one
are
two
combinations
versions
and
last
one
on
one
kubernetes,
but
actually
yeah.
It's
actually
questionable.
If
we
should
go
forward
as
well,
I
I
guess
not
well,
that
would
be
a
question.
E
What
I
guess
so
a
couple
more
thoughts
here,
one
is
there
any
other
precedent
for
another
another
project
in
the
kubernetes
ecosystem
that
tries
to
align
to
the
version
numbers
of
kubernetes
and
the
second
question
and
more
of
a
thought
would
be
if
there
is
why
why
why,
like?
What
would
you,
what
do
they
benefit
from
doing
that,
and
what
would
we
benefit
from
doing
that?
What
would
that
signal
to
somebody.
B
Yeah
david
you're
right.
We
should
look
for
examples
and
I
hope
that
we
find
somebody
who
was
bold
enough
to
try
that
actually
to
align
to
the
kubernetes
version
numbers,
and
if
there
was
nobody
that
brave,
then
we
should
probably
not
follow
that
path.
No,
it's
fair.
We
can.
We
can
look
at
it
and
to
me
again,
it's
it's
a
different
question.
B
I
think
at
the
heart
of
my
proposal
was
at
least
to
change
the
release
schedule
and
the
line
the
version
of
us
was
more
of
a
thought
and-
and
it's
really
not
that
critical
to
me-
I
think
the
changes
of
the
release
cadence
is
more
important
to
me,
but
we
can
look
at
the
versioning
as
well.
I
I
don't
have
an
answer
to
that.
D
At
some
point,
we
should
definitely
have
in
our
release
history
a
1.0.0
release,
even
if
it's
a
formality,
but
just
to
say
today
is
the
day.
We
are
now
officially
a
1.0
release,
because
if
you
jump
to
1.24,
we
still
are
on
thunder.
In
that
sense,.
D
Sorry,
I
missed
that
stupid
sorry
about
that.
We
should
definitely
have
a
day
where
we
have
a
1.0.0
release
in
cube
vert
just
so
that
we
can
mark
that
moment.
As
okay
we've
officially
moved
to
1.0.
You
know,
with
all
the
implications
of
support
that
that
has
because
we
steal
our
own
fender
if
we
just
jump
somewhere
like
the
one
dot.
Whatever
middle
of
you
know
something
fair
point:
firm.
B
B
Oh
yes,
and
that's
what
I
said
david
prepared
that,
like
you
read,
maybe
david,
you
have
that
link
at
hand.
I
was
referencing
it
earlier
before
you
were
here
that
you
already
started
to
work
on
the
dock,
with
your
thoughts
on
what
should
be,
because
what
I
touched
on
earlier
was
what
I
would
like
to
revive
the
topic
of.
Let's
get
to
v1
and
yeah.
You
start
to
think
about
that
in
the
past.
E
Sure
exactly
we
finished
it.
The
only
thing
that's
left
is
this
release
cadence
issue
and
that's
kind
of
where
we
dropped
off.
I
don't
even
know
if
we
officially
documented
the
release
cadence
issue
but
as
far
as
features
goes,
there's
nothing
left
in
the
list
that
I'm
aware
of
and.
G
E
If
there
is
something
that's
left
on
that
document,
which
I
can
find
as
I'm
talking
here,
it
was
just
something
that's
already
been
ruled
out
and
the
essentially
the
dock
lags
behind
reality.
F
E
No,
so
there
was
the
api
version
that
was
clearly
something
specific
just
to
the
api
that
was
decoupled
from
our
actual
release
of
version,
one
meaning
cubert
version,
one,
not
the
api
series.
We
have
many
api
series
so
moving
to
v1
for
the
api.
We
were
talking
about
our
core
api,
offering
which
is
the
vm
bmi
and
maybe
like
migration
and
a
few
others,
but
we
have
lots
of
apis
that
are
in
beta
and
alpha.
E
So
here
here's
the
document,
I'll
post
it
to
the
chat
here.
E
F
C
F
B
Yeah
thanks
for
the
two
cents
and
yeah
the
duplication
policy.
That's
why
this
here
is
the
last
bullet.
I
I
know
that
we
made
some
progress
and
I
think
the
dino
war
opened
the
pr
in
the
past
to
speak
about
the
duplication
policy
and
that
there
were,
I
think
them
some
additional
talks.
I
just
think
that
we
need
to
formalize
that
a
little
bit
more,
but
maybe
we
can
piggyback
really
here
in
kubernetes,
just
as
we
can
do
for
the
form
of
release
cycle
and
possibly
even
for
the
tooling
yeah.
B
So
it's
a
minor
point
and
I'll
see
I'll
I'll.
Take
a
look
at
your
doc
david
and
see
if
I
can
contribute
there
and
help
to
see
yeah
what
you
said.
What
is
really
missing
there,
that's
it!
So
I
just
wanted
to
open
the
topic
that
we
yeah
I
would
like.
Maybe
we
can
get
there
this
year
right,
I
mean
cubecons
are
always
a
good
time
to
announce
these
kind
of
things,
but,
to
be
honest,
cubicle
north
america
is
taking
place
in
november.
B
A
B
G
So,
to
be
honest,
I'm
not
I'm
not
exactly
understanding
the
outcome
of
this.
So
are
we
actually
having
a
document
where
we
want
to
jot
down
what
we
want
to
do,
or
are
we
just
starting
the
discussion
and
shining
out?
Maybe
maybe
do
we
take
this
to
the
name
of
this.
A
A
A
H
I'm
sorry
to
cut
you
off.
I
just
added
links
to
the
upstream
issue
and
initial
prs
for
the
education
policies.
If
somebody
wants
to
take
a
look
and
share
his
thoughts.
A
Great,
thank
you
all
right,
then.
Moving
on
it
looks
like
edward.
You
have
something
that
we've
had
some
conversation
around
regarding
bmi
status,
condition
and
basis.
A
F
D
I'm
missing
this.
I
was
the
one
that
scribbled
all
these
words,
so
maybe
we
should
talk
so
in
my
mind,
a
phase
of
a
vmi
represents
kind
of
the.
You
know
the
the
birth
to
death
of
the
vm.
D
If
you
will
what
what's
part
of
its
life
cycle,
it's
in
whether
it's
booting
up
or
scheduling
or
running,
and
so
those
it's,
it's
a
usually
a
linear
sequence
of
states
that
you
would
go
through
as
a
vmi
and
it
just
kind
of
represents
what
it's
doing,
whereas
a
condition
is
more
representing,
what's
happening
to
it
in
the
sense
that
suppose
you've
got
an.
I
o
error,
which
is
you
know,
causing
it
to
pause,
or
you
can't
attach
to
the
guest
agent.
D
So
we're
missing
some
information
there
or
we're
not
live
migratable
because
of
certain
rules
are
violated
like
we've
got
discs
that
are
just
not
migratable
that
are
now
attached
to
the
vmi.
So
there
are
things
that
can
happen
to
a
vmi
more
than
one
can
happen
at
a
time,
and
it's
I
guess
it
becomes
a
question
of
how
would
you
represent
that
if
we
decide
you
know
we're
going
to
do
away
with
conditions
all
together
and
go
just
to
faces?
D
How
would
you
be
able
to
represent
it
in
a
way
that
would
drive
us
all
crazy
when
four
different
things
were
applying
and
it's
running
so
I
think
that's
kind
of
the
emphasis
is
how
we
ended
up
with
two
different
ones,
but
those
words
are
just
my
own.
If
anybody
else
has
any
interpretation
feel
free
to
jump
in.
B
Yeah,
I
think,
there's
a
lot
of
history
also
to
it
right.
I
think,
by
the
way
phases
were
sometimes
misunderstood
as
being
like
a
state
machine
which
they
aim,
and
then
conditions
came
around
to
actually
be
a
more
flexible
mechanism.
Right
well
fail.
My
observation
and
anybody
please
correct
me
right,
but
phases
are
like
more
static
and
life
cycle
bound,
but
no
real
state
machine
that
you
should
rely
on
conditions
are
a
more
flexible
approach
to
yeah
to
signal
different
states
of
the
of
the
vm,
including
reasons
of
why
it's
in
that
state
right.
B
J
Actually
last
week,
well,
you
can
think
about
this
as
a
subgroup
between
the
phases
and
yeah.
I
don't
know
something
that
you
would
communicate
a
way
to
communicate
between.
J
F
H
F
Like
you,
you've
been
in
a
condition,
and
it
finished
right,
I
think,
or
you
move
to
a
different
condition
or
something
like
that
anyway,
that's
it.
I
can
tell
you
why
I
got
confused
because
in
some,
for
example,
when
we
when
we
have
when
we
look
in
the
test
of
all
the
interventions
that
represents
what's
going
on,
you
wait
for
the
vmi
to
be
ready.
F
J
Is
in
the
phase
I
mean,
because
these
are
two
different
states.
I
mean
the
the
container
is
running,
the
vm
is
running,
but
you
don't
have
an
indication
of
what
is
happening
in
the
application
inside
so
the
the
agent
when
it's
come
up
and
can't
communicate.
It
just
tells
you
that
the
application
inside
is
ready.
K
D
To
add
to
what
vladick
was
saying,
the
faces
are
relatively
static.
I
don't
think
we've
changed
the
phases
of
vmi
in
years
like
the
the
list.
Is
it's
almost
a
sequence
of
a
nums
at
this
point,
whereas
we
can
add
new
conditions
all
the
time
and
we
do
add
them
and
a
vmi
does
not
have
to
even
have
a
guest
agent
installed.
So
if
you
look
at
the
phase
running,
that's
a
pretty
predictable
thing
that
every
vmwa
is
going
to
hit
at
some
point.
D
Hopefully,
if
it's
successful,
whereas
the
guest
agent
conditions
will
only
apply
if
a
guest
agent
is
present,
and
so
they
could
almost
be
looked
at
as
optional
in
in
that
sort
of
sense,.
C
F
G
E
J
But
then
we
would
have
to
treat
pods
differently
than
than
other
objects.
E
Sure
yeah,
that's
so
the
whole
thing
was
we
were
in
the
very
beginning
of
q.
We
were
trying
to
model
the
vmi
after
the
pod
and
the
pod
had
phases
and
that's
what
they
originally
started
with
and
then
they
realized
just
like.
We
realized
that
you
have
lots
of
other
things
you
need
to
represent,
so
then
conditions
were
introduced
and
we're
kind
of
following
it's
the
same
story
for
us.
E
If
we
had
conditions
to
begin
with,
and
that
was
the
way
we
were
representing
everything
and
feasibly,
we
could
have
a
phase
condition
or
I
don't
know
just
a
condition
that
would
maybe
a
series
of
conditions
would
indicate
the
current
state
of
the
bmi.
I
don't
know.
D
Yeah
one
thing
to
to
me:
each
phase
is
mutually
exclusive,
with
all
the
others,
you
don't
have
a
vmi,
that's
both
scheduling
and
running,
and
so
it
makes
sense
to
have
it
a
separate
field.
In
that
sense,
you're
right,
we
could,
as
an
implementation,
detail
conflated
with
conditions
and
get
rid
of
phases
all
together,
but
it
might
actually
make
things
a
little
bit
more
complex.
So
I
I
like
the
way
it
is.
But
sorry
if
it's
confusing.
E
I
think
we
would
have
the
same
discussion.
The
reverse
discussion
like
you're,
saying
stu,
about
how
some
conditions
are
mutually
exclusive
and
some
aren't
and
it
that's
confusing.
Yeah.
L
F
F
I
I
think,
I
think
what
maybe
this
is
relevant
to
is
that
it's
from
not
a
perspective
explaining
what
our
phases,
what
are
the
phrases
or
what
are
the
conditions
but
to
it's,
like
maybe
a
guidance
for
understanding
the
where
you
should
find
what
like,
like
it's
a
guidance
for
troubleshooting
for
for
following
the
life
cycle
of
vmi
stuff,
like
that,
like
that's,
that's
like
a
documentation
that
will
fit,
then
then
everyone
will
may
understand
why
you
should
look
there
and
why
you
should
look
the
other,
the
other
place
or
it's
a
guide
for
a
developer.
B
B
Anybody
who
has
sleeping
problems,
because
then
you
will
really
kept
awake.
They
specifically
dive
into
the
the
relationship
between
phases
and
conditions
right
so,
and
I'm
pointing
that
out
because
after
all,
as
david
said
right,
we
resembled
what
kubernetes
does
and
they
are
explicitly
also.
You
know
describing
this
and
other
words
again,
and
you
find
it
in
the
in
the
condition
section
in
that
document.
I
try
to
link
closely
to
it's
a
little
bit
below
that
bookmark
that
I
shared
here.
M
Yes,
I'm
sorry,
I
was
trying
to
speak
up
when
you
were
explaining,
but
didn't
want
to
stop
the
flow
of
thought.
So
I
I
have
seen
in
red
issues
upstream
kubernetes,
where
the
pattern
of
phases
is
slowly
being
deprecated
and
new
apis
only
have
status
conditions
with,
and
in
most
of
my
experience,
the
phase
is
usually
a
summary
of
what
conditions
represent
at
that
point
in
time
and
the
way
stu
was
explaining
it.
M
It
felt
to
me
that
it
is
true
in
the
case
of
bmi
as
well,
but
I
didn't
want
to
draw
a
conclusion.
So
one
of
the
questions
I
wanted
to
raise
was
how
are
phases
actually
evaluated?
Is
it
just
a
brief
summary
of
what
conditions
are
being
represented
at
that
point
in
time?
If,
yes,
then,
can
we
can
the
users
just
conclude
from
the
list
of
conditions,
rather
than
looking
at
our
face.
B
B
To
have
more
user
friendly,
user-friendly
more
you
still.
Maybe
you
remember
that
or
david
I'm
not
sure
we
reviewed
it,
but
working
on
on
reflecting
the
phases
as
conditions.
Remember,
maybe
that's
close.
D
Yeah,
I
think
the
the
bigger
picture,
if
you
zoom
out-
and
this
comes
back
to
eddie's
original,
but
why
question
the
thing
about
the
phases
is:
it
doesn't
really
truly
represent
every
the
whole
story
about
a
vmi
and
a
great
example
is
paused.
That's
not
actually
the
face
of
the
vmi,
it's
a
condition.
So
when
you
try
to
represent,
what's
it
doing
in
the
ui,
it
gets
fuzzy,
and
so
that
was
v's.
D
M
I
I
would
be
interested
in
diving
deep
into
this.
Why
do
we
need
both
exploratory
topic
and
come
back
with
our
conclusions?
If,
if
that
is
something
the
community
wants,.
E
M
I
think,
from
my
perspective,
the
outcome
would
be
before
we
reach
2v1
api.
We
would
have
correct
understanding
of
why
those
are
needed
and
if
it
is
not
needed,
maybe
we
can
come
up
with
a
plan
to
transition
out
of
it
to
get
a
simpler
status.
Api.
E
Our
api
for
v1,
at
least
for
the
vm
and
vmis,
are
pretty
much
set.
I
think
this
research
might
help
other
apis
like
the
clone
api
or
perhaps
the
snapshot
api,
and
I
don't
remember
if
those
even
have
phases,
but
it
could
be
our
recommendation
on
whether
we
think
phases
are
useful
in
the
future
at
all.
I'm
not
sure
if
they
are.
B
Good
yeah
I
and
I
totally
agree
with
david.
I
think
the
aps
is
set
and
will
not
get
away
from
the
phases,
but
maybe
there's
an
opportunity
to
actually
add
at
the
conditions
as
the
way
forward
right.
So
while
we
can
keep
the
phases
and
mark
when
it's
deprecated,
if
we
have
a
good
answer-
and
I
would
be
really
interested
to
hear
the
good
answer
is
then
maybe
a
condition
could
be
added,
and
I
just
shared
sve's
pr
from
back
then
who
went
into
that
direction.
E
I
don't
know
what
you
call
it
status
field
or
whatever
it's
not
meant
to
be
like
programmatically
used
or
anything
like
that,
and
it's
its
meaning
is
not
perfect,
like
it's
the
best
effort
to
give
the
user
an
understanding
with
one
word
what
the
vm
is
doing
and
we
had
to
make
compromises
like
of
certain
like,
for
example,
two
things
are
happening
at
once.
E
We
have
to
pick
one
sometimes
as
being
the
priority
like
this
one's
more
important
for
the
user.
This
other
thing
that's
happening.
E
So
it's
kind
of
lossy
just
point
that
out
that
that's
not
meant
to
be
an
all-inclusive
representation
of
what
the
vm
is
doing
is
a
human-readable
form
of
the
best.
We
can
estimate
what
the
end
is
doing.
F
So,
just
just
to
represent
present
my
idea
from
a
programmatic
point
of
view.
From
a
programming
point
of
view,
it
would
have
been
much
simpler,
at
least
for
me
to
just
query
the
state
of
condition
and
that's
it
like
like.
If
all
the
phases
are
somehow
represented
in
the
condition,
and
I
can
learn
the
state
from
there,
it
will
have
been
easier
programmatic.
F
C
F
A
Okay,
so
with
that
it
sounds
like
we
at
least
have
more
idea
of
the
content
and
related
conversations
around
phases
and
conditions
edward
thanks
for
bringing
that
up.
It
was
informational,
at
least.
A
Let's
see
and
andrew
burton
wants
to
remind
everyone.
We
are
deprecating.
The
duplicate
calendar
invites
so
make
sure
you're
on
you
have
the
cooper
that
cncfio
calendar
invite
on
your
calendar,
so
you
don't
lose
track
of
future
meetings
to
attend
when
we
deprecate
that
at
the
end
of
the
month,
all
right
we
have
about
15
minutes
left,
so
we
can
go
ahead
and
jump
in
oh
go
ahead.
B
Yeah,
what
that
actually
open
floor
item-
and
that
is,
let
me
find
a
good
description
of
the
problem,
how
to
avoid
that
files
increase
in
size.
The
linting
thread
on
kubernetes
is
that
something
we
want
to
get
back
to
here
in
this
form:
it's
because
it
costs
so
much
money
and
emails
right
and
distributed
to
all
recipients.
B
C
F
Like
there
was
a
request
to
make
it
statically
and
not
dynamic,
but-
and
I
think
dan
was
on
it,
but
and
and
then
there
is
a
other
suggestion
to
put
an
actual
letter
that
does
this,
so
it
is
talked
about.
I
think.
D
F
Now
it
is
now
it's
it's
based
on
the
that
it
didn't
increase
in
the
last
and
the
last
change
in
the
last
pr.
But
then
I
think
roman
commented
that
this
is
problematic,
because
this
may
change
like
you
do
how
tight
is
working.
So
there
was
a
request
to
make
it
static,
like
just
put
a
number
and
then
don't
increase
over
this
number.
F
D
I
think
the
point
is
that
if
we
just
let
it
grow
without
bound,
it
becomes
unmanageable,
because
it's
just
a
big
long
line
of
pros
in
terms
of
functions,
but
it
would
make
more
sense
to
instead
of
adding
a
utils.go
to
group
things
to
have
similar
functionality
in
a
way,
that's
more
sensible,
so
that
we
would
know,
for
instance,
to
go
to
the
vmi
creation
section,
which
I
believe
is
now
lib
vmi,
as
opposed
to
just
utils.go,
which
had
you
know
it's
just
this
general
purpose,
you
know
dump
anything
you
want
in
there
sort
of
module.
D
B
Yeah,
just
my
two
cents
and
yeah,
maybe
bloody
yeah-
would
be
here
interesting
to
you
as
well.
I
think
it's
fair
to
say
I
mean
utils
go
is
helpful,
but
I
think
it's
also
fair
to
say
that
we
saw
a
couple
of
people
right
trying
to
set
up
other
examples
of
how
tooling
functionality
can
be
provided
to
tests.
F
Yes,
I
I
think
that
that
there
was
a
a
lot
of
thing
got
extracted
from
it
in
the
sense
that
they
were
grouped
like
in
several
places
when
there
is
more
work
to
do
there,
and
if
someone
wants
to
add
now
something
there,
it's
like
we
are,
I
will
say
forcing
him
to
think
what,
where
is
a
better
place
to
put
and
not
just
put
it
in
the
default
place
right.
That's
maybe
like
the
default.
Junkyard
is
no
longer
an
option.
F
A
So
on
this
topic-
and
I'm
not
familiar
with
the
linters
for
line
count,
but
I'm
presuming
they
are
like
other
linters,
where
you
can
add
exceptions,
and
if
someone
submits
a
pr
and
it
violates
that
line
count
then
at
that
point
they
would
know
to
also
submit
an
exception
if
there
is
a
valid
reason
to
exceed
it,
but
otherwise
would
help
reduce
abuse
of
a
file.
I
don't
know
I'm
just
spitballing
how
I
understand
it
so.
J
What's
the
reasonable
yeah,
so
sorry
for
cutting
it
off
you're,
fine,
I'm
just
curious.
What's
the
reasonable
amount
of
lines-
and
I
mean
where
do
you
draw
the
line.
D
B
That's
why
I
think
the
current
discussion
has
to
do
with
per
file
right
independently,
like
I
think
you
choose
go.
That
is
why
they
propose
to
have
the
limit
as
the
property
of
the
file
yeah,
and
I
think
4200
is
always
a
good
limit.
A
F
F
There
are
letters
that
check
that
you
are
not
copying
two
big
structs
as
by
value.
There
are
like
tons
of
stuff
like
that.
So
let's
go.
J
Ahead
and
sure
sure
my
question
is
like
I
mean
how
useful
is
this,
I
mean
yeah
sure
definitely
people
who
are
like
to
write
linters
they
will,
they
will
add
more
functionality
to
it.
But
I
think
if
you
see
anything
like
this
being
added
as
part
of
a
code
review
that
you're
doing,
then
you
can
suggest
something
else,
but
I
mean.
D
Sorry,
I'm
sorry
to
talk
over
you,
you
had
broken
there.
It's
always
the
reviewers
option
to
put
a
hold
on
request,
changes
and
suggest
something
else
to
be
done.
So
I
mean
it's.
D
I
think
it's
a
meaningful
discussion
to
have
and,
of
course
it's
always
fraught
with
opinion,
but
this
is
just
one
area
of
many
where
we
can
improve.
A
I
think
it's
valid
to
go
ahead
and
carry
this
one
to
mailing
list
for
further
conversation.
It
does
make
sense
to
keep
in
mind
any
linter
enhancements
we
want
to
make
in
our
walk
towards
a
v1
release,
so
I'm
not
trying
to
cut
off
at
the
conversation
here.
I
just
don't
want
to
run
in
circles
when
that
should
be
a
wider
conversation
beyond
just
the
attendees
anyway.