►
From YouTube: 2021-09-07 Rook Community Meeting
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
Hello,
everyone
welcome
to
the
work
community
meeting
for
september,
7th
2021.
we'll
go
ahead
and
get
started
after.
I
share
my
screen
here.
Where
did
that
option
go
share
screen
and
there
we
go.
A
A
A
A
I
think
in
a
couple
more
weeks,
it'd
be
good
to
have
at
least
one
more
release
for
1.610
and
maybe
even
a
11
after
that,
but
unless
somebody
knows
a
reason
to
or
a
request
to
have
a
sooner
release.
We'll
probably
just
make
this
a
monthly
cadence
at
this
point,
which
would
make
it
about
the
23rd
and
let
me
look
at
the
board
real,
quick
to
see
if
anything's
happening
there
and
I
think
it's
pretty
empty
as
well
all
right.
A
A
C
A
B
B
A
My
deprecation
policy
for
work
releases,
you're,
saying
all
right.
Yes,
yes,
right,
yeah,
we've
we've
intentionally
not
really
documented
our
deprecation
policy,
but
the
reality
is
that
we
have
our
latest
two
minor
releases
where
we
do
patch
releases
for
them.
So
right
now
that
would
be
1.7
and
1.6
still
doing
patch
releases,
and
I
can't
remember
the
last
time
we
did
a
patch
release
for
n
minus
two,
so
it
yeah.
The
reality
is
that
n
minus
two
is
not
something
we're
generally
supporting
for
upstream
businesses.
A
B
A
A
D
E
Yeah,
I
I
should
probably
check
on
it
to
make
sure,
but
the
last
time
I
checked
on
it,
which
was
I
think,
last
week
or
maybe
the
week
before
the
the
cap
itself
had
not
been
approved,
which
I
think
means
that
it's
not
yet
in
a
like
in
a
kubernetes
version.
D
A
Sounds
good
then,
so,
oh
I
was
going
to
ask
also
the
stale,
but
it
looks
like
it
was
catching
up
with
some
of
those
those
issues
you
opened
blaine,
but
we
might
need
to
add
a
flag
to
them,
so
they
don't
get
closed
by
the
the
stale
block.
A
So
it's
good
so
all
right!
Moving
on
to
1.8
discussion,
then
so
yeah.
The
previous
proposal
was
the
first
week
of
december
for
that
release,
just
to
make
sure
we
get
it
out
before
the
end
of
the
year
with
holidays
and
things.
I
think
that
would
still
be
a
good
thing
to
work
with
blaine.
Your
comment
on
kubecon
china,
december
9th
and
10th
so.
E
Yeah
I
there's
a
little
bit
of
the
note
continues
like
in
the
in
the
next
page,
yeah
cube
content.
China
is
december,
9th
and
10th
we
could
target
trying
to
release,
buy
that
kubecon.
I
know
we
have.
We
have
often
tried
to
release
just
before
kubecon.
However,
it
is
a
virtual
only
conference,
which
also
means
the
talks
have
to
be
recorded
like
a
month
and
change
beforehand.
E
So
I
don't
after
writing
that
note
I
was
like
well,
maybe
that's
actually
not
like
the
best
thing
to
set
as
a
a
thing
that
controls
our
our
target
release,
because
we,
you
know,
the
talk-
will
be
recorded
like
a
good
month
beforehand
anyway,
before
we
know
exactly
what's
going
into
1.8
and
what
we've
been
able
to
to
make
in.
A
At
the
same
time,
I
think
so,
if
we're
already
shooting
for
the
first
week
of
december
and
if
it
bleeds
into
the
second
week
of
december,
like
on
the
day
of
kubecon
or
something
it
would
still
be,
hopefully
out
by
the
time
it
releases
and
as
far
as
what
to
talk
about
in
1.8.
I
think
we'd
have
to
look
at
it
when
it's
time
to
record
yeah
and
just
see,
but
talking
about
the
1.8
release.
That's
close
enough!
That
that'd
be
good
to
shoot
for
okay,.
A
D
A
A
Thanks
all
again
for
all
those
efforts-
and
I
don't
think,
there's
any
reason
to
keep
jenkins
around
for
builds
because
1.6
and
1.7
builds
are
on.
We
can
have
actions
now,
we'll
just
maybe
give
it
till
after
until
the
end
of
the
month,
just
to
make
sure
we're
not
forgetting
anything
else
and
then
just
turn
it
off
for
good.
D
All
right,
no,
but
maybe
yet
another
greatness
coming
from
github,
have
you
seen
what
they
are
doing
with
issues
right
now.
D
I
have
subscribed
to
like
like
early
like
bad
at
easters,
and
things
like
this.
So
what's
the
link
again
yeah,
I
don't
remember
like,
but
if,
if
you
look
up
like
get
up
issues,
they're
really
like
revamping
the
way
you
subscribe
to
issues
and
the
way
you
manage
issues
with
projects
and
sprints
and
things
like
this,
so
it's
going
to
become
much
more
like
a
task
management
like
even
like
jira
almost,
and
I
think
it
looks
super
promising,
because
obviously
everything
is
really
integrated
into
into
github.
D
D
A
E
Yeah,
I
we
we
forked
rook
into
cassandra
and
rook
nfs
and
in
each
of
the
forks
disabled,
well
completely
stripped
out
the
other
back
ends.
So
cassandra
is
only
cassandra
and
nfs
is
only
nfs.
There's
no
trace
of
ceph
or
the
other
back
end
and
yeah.
E
Travis
really
helped
with
the
with
the
documents
and
now
the
documentation
landing
page
is
the
for
rook
rook
is
now
the
core
and
has
seth,
and
then
the
back
end
can
be
selected
from
a
drop
down,
which
looks,
looks
really
nice
and
and
works
really
nicely
yeah.
So
I
think,
with
the
upcoming
1.7.3
release,
our
our
goal
is
to
make
sure
that
cassandra
and
nfs
can
release
from
those
repos.
E
A
Yeah,
I
think
you
covered
it
and
and
just
to
emphasize
so
this
thursday,
we'll
plan
on
the
173
from
the
three
separate
repos,
because
they'll
all
be
separate
at
this
point,
and
so
we
still
need
to
do
a
little
work
to
like
back
port
the
github
actions
and
make
sure
every
oh
they're,
all
working
in
the
release
branches
for
the
individual
storage
providers,
but
they're
all
working
currently
in
masters.
So
I'm
optimistic
it'll
be
pretty
straightforward
to
just
backboard
them
and
get
them
running
there.
A
Yeah,
I
think,
in
my
mind,
there's
kind
of
a
question
going
forward.
What
will
make
sense
for
the
versioning
story
because
it
could
be
confusing
if
they
sort
of
follow
the
same
versioning,
but
not
really
so,
but
it'll
really
be
up
to
each
storage
provider,
which
is
how
I
think
it
always
should
have
been,
and
this
is
the
right
thing,
the
right
approach.
Really
each
storage
provider
gets
its
own
release,
scheduled
depending
on
timelines
that
people
decide
and
whatever
those
requirements
are.
A
A
A
D
Yeah,
but
this
can
wait
when
you
when
you're
done,
I
guess.
A
D
D
Yeah
so-
and
I
think
the
initial
comment
I
had
is
that,
would
it
be
more
like
helpful
if
we
changed
master
and
called
this
latest.
D
D
E
For
latest
I
don't,
I
don't
think
I
think
we
have
like
the
the
master
releases
that
have
the
like
hash
stuff
on
them,
and
then
we
have
just
the
master
tag
that
gets
you
whatever
the
latest.
One
of
those
is.
E
Yeah,
I
think
so
we
could
just
yeah
we
can
just
have
both.
We
can
have
as
many
tags
as
we
want
for,
like
docker
images.
D
Yeah,
but
I
mean
it's
just
for
clarity-
you
don't
have
to.
E
Yeah,
I
I
think,
that's
a
good
point.
I
think
it's
just.
We
would
also
want
to
take
the
step
of
making
sure
that
the
like
documentation
matches
the
images
that
are
available
to
users
also.
D
A
E
As
an
unrelated
note,
I
did,
while
you
were
doing
the
the
website
demo
I
out
of
curiosity,
I
took
a
look
on
my
phone
and
the
the
like
mobile
web
or
like
yeah.
The
mobile
experience
of
the
documentation
also
works
pretty
well
like.
There
were
no
weird
issues
with
not
being
able
to
like
find
the
right
documentation
link.
So
that's
also
a
plus.
A
A
All
right
that
sounds
good
for
that
topic
then,
and
the
last
item
on
the
agenda
you
can
siobhan,
so
you
have
a
demo
on
migration
of
flex
and
entry
volumes.
Looking
forward
to
prototype
is
ready.
C
Sure
so,
sometimes
back
we
had
a
meeting
where
we
discussed
that
why
we
need
the
migration
steps
for
flex
and
entry
volume
to
csi,
and
we
also
looked
at
the
manual
process
that
we
could
do
for
achieving
the
same.
And
now
we
have
a
prototype
ready,
like
which
I
can
show
a
short
demo
on
on
how
it
works.
Let
me
share
the
screen.
C
Okay,
so,
basically
just
a
quick
overview.
So
this
are
is
a
golang
project
that
has
a
we
have
created
a
binary
and
copied
inside
the
toolbox
part.
So
where
we
are
running
it,
we
are
providing
two
parameters
that
are
basically
the
source,
storage
class
and
the
destination
storage
class
source
source
class.
C
Being
here
an
example
of
a
flex
volume,
storage,
class
and
destination
will
be
a
csi
in
this
example
and
below
we
can
see
that
we
have
the
roof
set
agent,
which,
with
the
help
of
which
we
have
deployed
flex
pvc
bound
to
the
storage
class,
and
we
also
pre-requisite,
we
have
to
create
the
csi
storage
class
beforehand
so
that
the
tool
can
use
it.
C
C
We
are
just
writing
some
things
that
wrote
a
file
migration
there
and
we
then
proceed
to
delete
the
part,
because
in
the
migration
process
it
involves
a
downtime,
so
the
pvc
will
be
deleted
for
some
time,
and
now
we
can
see
that
select
class
is
currently
for
rbd
pvc,
it's
throughout
block,
which
is
a
flex
storage
class.
C
And
now
what
we'll
do
is
we'll
start
the
tool
it
will
run
the
steps
required,
like
exchange
the
backend
images,
set
very
closely
retained.
Do
all
the
steps
apologize
for
the
ugly
logging
here
this
so
just
now
success
migration
is
successful,
and
now
we
can
see
the
pvc,
the
same
name
is
in
bound
state.
C
We
have
to
use
the
same
name
suppose
if
some
application
is
using
it
in
the
front,
it
will
not
change
anything
and,
as
you
can
see,
in
the
storage
class,
it's
now
using
the
csi
storage
class
and
it's
now
bound
using
the
soyuz
class
now
we'll
verify
if
the
data
also
got
migrated
along
with
the
pvc.
C
C
So
that's
pretty
much
the
demo
for
our
small
prototype
that
we
had
for
the
migration
tool.
This
is
a
very
quite
initial
prototype
and
we
are
get
to
have
some
many
stability
improvements
here
and
there
so
that,
because,
since
it
is
a
very
critical
process
and
people
might
lose
data,
if
we
do
it
indirectly,
so
we
we
are
planning
to
add
various
steps.
C
Like
module,
suggested
a
step
of
adding
a
rollback
operation
that
if
something
goes
wrong,
you
just
make
them
roll
back
to
the
stage
where
they
were
earlier
and
many
other
small
subtle
things.
So
this
initial
prototype
wanted
to
share
with
you
all
and
get
your
thoughts.
E
Yeah,
I
guess
first
of
all
that
was
really
quick.
I
think
that's
that's
gonna
be
really
good
for
users.
I
think
yeah
we've
been
yeah
like
in
in
your
explanations
of
this,
throughout,
like
all
of
the
planning
and
and
demos,
before
we've
known
that,
there's
going
to
be
some
amount
of
like
downtime
for
applications,
which
is,
is
good
and
as
a
good
thing
to
to
also
tell
users
I
I
can
imagine
a.
E
E
Like
for
for
their
users,
an
administrator
wants
to
keep
the
same
storage
class
name
that
their
users,
you
know-
maybe
they
have
a
large
user
base
and
their
users
are
like
used
to
always
specifying
the
same.
Like
storage
classes,.
E
I
want
to
make
sure
that
we
we
at
least
have
a
documented
process
for
how
administrators
can
keep
the
same
storage
class
name
using
this
tool.
Even
if
it
involves
running
the
tool
twice
like
once,
to
go
to
an
intermediate
like
csi
dash,
the
storage
class
name
and
then
migrating
like
from
that
storage
class.
Name
to
what
the
original
one
was.
F
Yeah
and
also
we
wanted
to
like,
since
we
have
the
tool
ready.
So
in
our
last
discussion
we
in
the
end
we
decided
that
once
we
have
the
tool
ready
and
we
see
how
how
the
tool
works,
then
we
can
decide
the
home
for
the
two,
and
so
I
think
we
can
discuss
that
now,
so
that
we
can
progress
on
that
more
quickly.
And
since
I
think
we
have
people
from
csi
and
group
two
like
from
csi,
we
have
madhu
and
you
can
yeah
from
look.
F
We
have
all
the
people
required,
so
I
think
we
can
discuss
about
the
home
for
the
migrations.
A
Before
we
talk
about
that
for
it,
I
want
to
go
back
to
the
question.
Maybe
the
blaine
head
or
the
the
comments
yeah.
I
think
that
the
one
other
scenario
similar
to
what
blaine
said
of
having
the
same
csi
or
storage
class
name,
I
think
you
know
what
if
the
previous
storage
class
doesn't
exist,
do
we
require
the
storage
class
to
exist
or
could
you
just
have
a
pv
and
say
I
want
to
convert
this
pv
from
flex
to
csi?
A
B
B
A
B
Yeah
some
someone
has
to
write
a
script
to
get
the
pbs
and
then
call
this
the
tool
with
that
as
an
input
parameter
or
like
they
can
patch
their
all
the
pvcs
with
some
labels,
so
that
the
label
can
be
a
parameter
to
this
tool.
So
then,
like
the
tool
will
list
the
pvcs
with
the
particular
labels
and
then
migrate
it
to
the
csi
storage
class.
C
We
can
do
multiple
things
like
migrating
all
pcs
in
a
namespace
or,
as
you
mentioned,
adding
labels
and
we
can
migrate
either
one
pvc
or
multiple
pvc
at
the
same
time
recording
an
application
and
about
that
solid
class
name.
Yes,
lane
we
can
do
that.
That
is
definitely
a
good
station
and
we
can
keep
an
intermediate
csi
spirit,
class
name
and
then
quickly
getting
to
the
same
storage
class
so
that
that
also,
I
think,
can
be
done.
E
I
guess
I
think,
that's
a
really
good
point
travis.
I
I
think
there
are
it's
like
rook,
I
think,
supports
running
both
csi
and
flex
volume,
so
there
may
be
administrators
who
already
have
like
taken
a
storage
class,
for
example,
that
used
to
be
flex
volume
and
modified
it
so
that
it
now
is
a
storage
class
that
is
csi,
and
so
they
may
have
a
lot
of
older
legacy,
pvs
that
were
created
from
the
same
storage
class.
So
we'll
just
call
it
storage
class
like
a.
E
E
C
Yes,
basically,
since
we
are
doing
what
we
are
doing
is
we
are
retaining
the
pv
of
the
say,
flex
volume
and
we
are
deleting
the
pv.
So
the
backend
image
also
gets
retained
and
we
are
deleting
the
pvc
of
flex
so
later
on.
What
we
do
is,
in
the
back
end
the
image
that
we
have
of
flex.
C
We,
instead
of
that,
we
use,
we
rename
it
to
the
the
we
create
a
same
name,
a
pvc
with
csi,
so
that
the
metadata
is
generated
with
the
help
of
csi
and
then
what
we
do.
Is
we
rename
the
image
created
by
flex
to
csi?
So
it
it
kind
of
manipulates
csi
to
look
like
it's.
So
it's
his
own
image
and
it
picks
up
the
image
created
by
a
flex
volume
because
it
has
the
name
which
it
generated.
B
B
A
C
Right,
yes,
not
even
a
variable
change,
yeah.
B
B
It's
completely
a
different
problem,
because
we
need
to
still
figure
out
how
to
mount
and
move
the
data,
because
previous
ffs
was
without
sub
volumes
and
also
volume
is
a
newly
introduced
concept.
We
need
to
see
and
how
to
do
that.
One
also.
B
A
A
D
A
D
A
dry
run
would
be
nice
just
to
see
hey.
What
is
this
tool
is
going
to
do,
because
it's
not
really
the
type
of
thing
you
want
to
test
on.
I
mean
you
could
always
test
on
a
dummy
volume,
but
it's
just
good
to
have
some
sort
of
a
driving
mode.
Where
you
see
what
the
tool
is
going
to
do
before
you
run
it.
F
And
nothing
much
like
that.
I
was
saying
that
that's
why
we
need
proper
testing
and
the
ci
and
yeah.
We
need
to
test
that
properly
yeah.
I.
C
F
C
Yes,
and
we
are
also
planning
to
now
from
now
onward,
since
we
are
working
prototype,
we
are
planning
to
have
a
proper
ci
first
and
then
continue
our
contributions
on
the
same
later
and
we'll
in
future,
we
will
have
multiple
jobs
for
the
same
for
migration
and
testing,
so
that
that
does
not
happen.
Then.
B
D
A
D
Yeah
I've
even
to
the
point
where
I
don't
see
why
we
would
need
one
bag,
because
I
mean
you
can
always
run
it
reverse
if
you
want
to
do
some
kind
of
a
roll
back,
but
honestly
implementing
the
road
bike
might
be
just
too
much
of
a
headache
where
resume
seems
really
sufficient.
If
you're
really
planning
on
migrating
anyways,
like
you
have
volumes
that
have
been
migrated
already.
So
just
just
continue.
This
resume.
B
Yeah
but
but
in
the
case
like,
if
you
have
deleted
the
pvc
and
you
you
somehow
like
tool,
got
crashed,
but
you
don't
know
which
piece
you
have
to
roll
back.
Also,
I
mean
to
resume
one
for
it,
because
the
whole
object
is
gone.
C
And
the
issue
also
will
be
that
suppose,
as
travis
mentioned
earlier,
that
they
don't
have
the
storage
class
for
flex,
so
provisioning
volume
with
flex
again
for
them.
A
Maybe
we
just
need
some
additional
arguments,
that's
to
take
specific
pv
names
or
image
names
to
so
we
can
resume
instead
of
trying
to
maintain
some
state
in
the
tool,
if
we're
just
logging
sufficiently
in
case
of
there's
a
problem.
Well,
maybe
they
need
to
dig
through
the
logs
and
give
parameters
back
to
the
tool,
and
that
might
just
be
sufficient,
not
perfect,
but
if
there's
a
any,
if
there's
some
way
to
recover
from
it,
I
think
we
just
don't
need
to
automate
all
of
it.
D
A
A
A
A
A
C
The
reason
being
that
I
suppose,
if
some
some
users
are
facing
some
issue
in
migrating
entry
volumes
to
step
csi,
so
they'll
unnecessarily
create
issues
in
rook
which
we
might
not
want,
because
we
just
concerned
about
migrating
flex
volumes
to
csi,
and
we
don't
care
here
about
how
we
migrate
entry,
because
we
don't
support
them
and
many
other
like
points
like
lifetime
of
the
tool
will
be
more
outside,
as
it
supports
both
entry
as
well
as
flex
volume.
C
So
users
from
both
can
come
directly
and
get
the
migration
done
since
csi.
Also
standalone
can
use
the
tool
for
its
migration.
D
B
A
B
For
csi,
so
I
think
best
would
be
to
keep
it
in
safe,
so
anyone
can
migrate
it
to
save
csi
or
even
in
rook,
because
the
project
will
have
more
visibility
if
we
keep
it
inside.
So
I
want
documentation
on
ci,
because
if
you
keep
it
in
sepsis,
it
would
be
very
really
hard.
A
A
A
F
And
I
see
like
there's
a
similar
requirement
in
communities
upstream
also
like
they
also
are
looking
for
some
tools
for
our
intuit
list.
So
if
we
keep
outside
of
any
repo,
it
will
be
more
visible,
so
yeah.
A
D
E
It
it
may
also
be
good
to
have
an
integration
test
in
the
csi
repository,
also,
especially,
to
make
sure
that
incoming
changes
to
stuff
csi
aren't
going
to
break
the
tool.
E
That's
like
something
I've
seen
with
with
other
c
ci
work
when,
when
dealing
with
multiple
repositories
that
all
have
to
work
together,
it's
it's
good
to
make
sure
that
each
repository
is
at
least
testing
a
like
small
amount
of
the
integration.
A
E
E
Oh,
I
I
just
had
a
kind
of
continuation
from
when
we
were
talking
about
kind
of
selecting,
different
inputs
for
the
tool,
like
realizing
that
we
probably
like
we
don't
necessarily
want
just
the
storage
class
name
from
a
like
administrator
perspective.
E
I
think
it's,
it's
really
easy
for
administrators
in
most
cases
to
produce
a
list
of
names
of
pvs,
given
various
selectors
like
if
I'm
like.
I
want
all
pvs
in
this
name
space.
It's
very
easy
for
me
to
do
that
on
my
own
right
now,
so
I
think
the
kind
of
like
base
input
that
we
want
for
this
tool
is
a
list
of
pv
names.
E
We
also
want
a
default
case.
That
is
something
like
all
pvs
in
the
cluster,
but
the
real
value
add
for,
like
administrators,
is
going
to
be
any
more
complex
selectors
that
they
would
need
in
sort
of
inside
information
about
how
the
pvs
are
labeled.
If
they
want
to
select
something
like.
I
want
to
only
do
flex
volume
pvs
like
something
like
that
they
aren't
going
to
know
off
the
top
of
their
head
and
they
might
not
be
able
to
figure
out
even
like
from
inspection.
E
How
do
I
determine
what
is
a
flex
volume
tv
versus
a
csi
pv
or
an
entry
pv?
So
I
think
we
should
consider
like
there
are
a
lot
of
things.
Administrators
can
do
and
can
query
and
can
select
that
are
very
easy
for
them
to
do
already
that
we
we
actually
don't
need
to
focus
on
doing
those
things.
E
C
Sure,
thanks
and
just
one
more
thing
that
I
wanted
to
add
was
in
rook:
we
want
to
deprecate
the
support
for
flex
volumes
and
and
after
some
time
we
might
not
want
the
tool,
and
we
might
not
require
it
after
say.
A
couple
couple
of
releases,
so
keeping
it
outside
will
also
be
helpful
for
multiple
users
when
even
root
does
not
need
it
anymore.
E
I
see
okay
yeah,
I
would
say
yeah.
I
would
suggest,
having
the
tool
be
a
job
that
we
can
run
with
its
own
rbac
definition.