►
From YouTube: 2021-11-30 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
I
think
that's
what
you're
in
I'll
go
ahead
and
share
my
screen
and
then
we'll
get
going
on
the
agenda.
A
Alrighty
here
we
go
so
1.6
we
had
the
1.6
that
11
released.
Okay,
has
it
been
a
couple
weeks
ago
already,
or
was
that
just
last
week
anyway?
A
At
this
moment,
I
don't
know
of
any
other
fixes
that
we
need
to
get
in
there.
So
there's
no
more
planned
releases
for
the
1.6
branch,
but
that
is
still
a
possibility
if
something
urgent
comes
up
there
on
1.7,
I
didn't
check
the
board
today,
but
I
think
the
board
should
be
fairly
clear.
A
A
I
think
we're
just
going
to
keep
that
one
for
1.8.
It's
turned
into
a
bigger
change
than
initially
anticipated
I'll
update
that
after
the
meeting
and
then
the
unnecessary
first
name
argument
from
demon's
data's
command,
yeah.
B
B
A
Okay
and
the
migration
procedure
from
flex
volume
that's
later
in
the
agenda,
so
I'll
prefer
that
topic
and
then
these
last
couple
issues
they're
not
blocking
in
any
way.
I
think
we'll
move
these
out
just
to
get
the
board
cleaned
up
and
then
focus
on
1.8.
A
Let
the
let's
see
the
tentative
release
date,
thinking
this
thursday
december
2nd
for
the
1.7.9
release
and
again
coming
back
to
the
flex
migration.
In
this
release,
we
want
to
include
the
flex
migration
tool
and
hopefully
we'll
be
ready
by
thursday.
If
not,
we
may
delay
that
until
the
initial
version
of
the
migration
tool
is
ready
and
documented
and
and
ready
to
go,
so
people
can
start
converting
their
flex
volumes
to
csi.
A
All
right,
if
not
so,
go
on
to
1.8,
so
1.8
we're
coming
up
on
the
release
date
for
next
week.
I
think
we're
on
schedule
for
that.
I
don't
know
of
any
delays
yet
needed,
so
we're
planning
on
a
beta
release
potentially
tomorrow
for
for
to
basically
create
their
lease
branch
and
get
the
first
build
out
in
place
to
start
testing
for
the
release
and
then
the
following
wednesday,
the
eighth
to
get
that
release
out
in
time
for
kubecon
china,
which
is
around
that
time.
A
The
rook
talk
was
recorded
with
1.8
features
discussed,
so
that
will
be
good
timing
to
get
it
out.
Let
me
just
check
the
1.8
board.
A
B
A
With
that,
then
we'll
continue
on
that
path
and
yep
the
upgrade
test
we
just
updated
so
upgraded
from
1.1.7
to
the
latest
master
and
that
test
worked
perfectly
fine,
no
upgraded
issues
anticipated
we'll
do
some
manual
testing
on
upgrades
as
well
and
write
the
blog
and
all
that.
A
A
It
does
currently
only
convert
rbd
volumes
and
there's
not
yet
a
design
for
even
converting
fms
volumes
and
yeah.
I
don't
have
an
update
there
on
I.
Well,
I
don't
anticipate
the
demand
to
be
as
much
for
those
ffs
flex
volumes,
so
definitely
looking
for
feedback
on
how
big
of
a
blocking
issue
that
is.
B
Merged
yeah,
we
we
have
made
a
few
changes
in
the
repository
layout.
This
is
something
we
we
have
been
wanted
to
do
for
a
very
long
time
to
hopefully
ease
the
like
experience
once
you
hop
onto
the
repo,
so
we
just
renamed
one
main
directory.
That
is
the
root
of
the
repository.
B
Previously
it
was
called
cluster
and
then
a
bunch
of
few
subdirectories
and
now
hopefully,
it's
much
clearer
because
we
have
a
deploy
directory
and
it
contains
all
the
manifests
to
either
use
helm
to
deploy
or
yamls
so
yeah.
That's
that's
essentially
yeah.
That's
essentially
the
the
change.
Obviously,
it's
a
small
breaking
change
for
whoever
has
automation
to
touch
the
repo
and
then
create
the
ammos
for
example.
B
A
Yeah
yeah
thanks
for
the
summary
I
just
put
the
the
conversion
in
the
notes
there
for
people
who
take
a
look
at
that
and
yeah
honestly,
I
was
hesitant
to
say
well,
should
we
do
this
because
it
could
be
breaking
for
people
with
automation,
but
it
will
be
really
nice
in
the
long
term.
So
that's
yep.
We
did
it
and
hopefully
it's
not
too
much
pain,
so
we'll
make
sure
it's
clear
in
the
release,
notes
and
yeah.
It
should
be
fine
after
that.
B
A
A
A
D
So
sorry,
if
this
is
the
wrong
venue,
I've
found
documentation
from
red
hat
that
says:
hey
you
don't
want
to
run
these
on
the
same
note,
but
then
under
that
it's
like,
but
if
it's
containers
looks
a
little
bit
different,
so
I
just
wanted
to
know
if
rook
like
managed
this
for
me
or
if
this
is
something
I
have
to
worry
about,
or
I
am
worrying
about
it,
but
like.
A
What
what's
the
best
practice,
I
guess
is
what
I'm
trying
to
ask.
A
B
B
What
group
does
for
you
is
that
it
will
make
sure
that
it
will
make
sure
that
at
least
the
months
are
running
on
separate
hosts
and
not
on
the
same
node.
Unless
you
ask
it,
unless
you
ask
to
do
it,
but
because
we
don't
recommend
it
it's
not
on
by
default
and
then
for
the
osds
that
there
is
no,
you
can
have
placement
policies,
but
I
think
they
just
come.
Naturally,
with
whatever
architecture
you
have
whatever
infrastructure
you
have
in
terms
of
those,
so
yeah,
no,
no
issue
there.
I
guess
thank
you
so
much.
C
Yeah
hi
there,
hello,
hello,
hello,
yeah,
so
sorry,
I'm
walking
out
outside
so
my
a
bit
sad
noise.
So
I
added
two
two
two
topics
to
discuss.
C
C
By
fact,
they
do
have
some
something
for
docker
support
and
I
even
saw
some
recent
updates
for
the
linux
kennel
version
5.x,
which
supports
linux
containers
as
well.
So
some
despite
some
lack
of
tribal
virtualization
solutions
by
fact,
as
for
now
they
do
have
some
some
some
something
for
a
docker
and
containers.
Something
is
possible.
C
It
is
possible
to
launch
operate
containers
as
well.
So
container
support
is
possible,
but
not
sure
not
sure
about
the
performance
aspects,
but
it's
possible
probably
possible
to
perform
some
porting
and
I
guess
there
is
no
dependency
libraries
which
rook
could
depend
on
which
wouldn't
be
either
already
ported
or
might
be
ported
with
some
little
effort,
so
it
it
could
be
possible
to
perform
some
something.
C
Like
hardware
assisted
has
hardware
assisted
acceleration,
which
is
a
big
advantage
and
the
reason
to
stand
for
risk
five
so
and
that's
the
first
topic
and
the
second
topic
general
general
general
question
about
alexey
and
rook,
and
maybe
some
history
for
on
that
direction.
I'm
not
not
not
didn't.
C
I
didn't
dig
that
much
what's
what's
possible,
but
since
this,
that
is
some
something
like
an
alternative
container
container
technology
I
was
curious,
is
there
is
any
active
support
on
maybe
on
a
trivial
architecture
like
x86
and
arm.
So
what's
about
supporting
alexei?
If
any,
and
maybe
some
comments
on
this.
C
D
A
D
Yeah,
I
mean,
I
guess
the
other
alternatives
are
like
one
could
presumably
figure
out
how
to
build
ceph
for
risk
five
build
a
cef
container
for
risk
five
and
then
do
the
same
with
like
rook.
If
there
are,
you
know
if
you
have
a
data
center,
where
risk
five
exists,
but
given
that
the
the
like
compiler
tooling,
doesn't
seem
like
it's
quite
there
yet
for
go
like
I,
I
don't.
A
C
Probably
I
was
lost
a
bit
a
few
minutes
so
lost
my
connectivity.
C
So
I
wanted
to
add
some
comments
so
as
the
reason
why
I'm
asking
about
the
risk
life
server
is
also
related
to
the
fact
there
are
some
at
least
two
so
hardware,
vendors
which
deal
with
storage
and
I
sus
suppose
it's
western
digital
and
the
second
is
not
sure-
maybe
that's
cg8,
maybe
not,
but
the
first.
The
first
one
to
mention
is
western
digital.
They
do
have
risk
5
already
inside
some
of
the
hardware
solutions
themselves.
C
So
it's
probably
an
option
to
integrate
integration
in
in
data
centers
as
well,
and
probably
if
we
would
consider
some
middleware,
it
might
be,
might
be
a
considerable
option.
So
there
is
already
an
hardware
optimizations
within
their
hardware
for
the
for
those
embedded
boats
and
as
for
the
risk
fire
servers,
they
do.
The
only
commercial
experiments
is
not
known
within
alibaba's
data
centers.
C
I
think
that's
quite
a
way
is
subsidiary,
so
but
this
unclear
whether
whether
it's
commercially
reasonable,
due
to
some
limitations
related
to
to
alibaba
and
their
restrictions
on
commercial
activities
in
some
countries.
So
it's
also
a
commercial
question.
Whether
their
data
centers,
but
they
they
do-
have
some
some
experience
on
you
on
using
those,
but
they
also
sell
this
hardware
as
service
themselves.
So
probably
if
there
would
be
demands
so
multi
multi-clock
servers
with
with
pretty
high
cpu
frequency
is
already
up
is
already
possible.
C
So
this
might
might
be
some
so
so
for
some
edge
computing
options.
It's
it's
already
possible,
but
for
the
data
centers,
it's
not
that
massive
massively
used
yet
so,
but
it
might
because
massively
you
use
within
their
storage
hardware
itself.
C
So
it's
not
necessarily
a
full
full
stack
server
server,
but
might
be
a
hardware
connected
to
the
server
for
the
storage
for
from
the
side
of
the
storage,
but
also
might
be
connectable
to
a
triple
x,
86
or
arms
server,
but
might
be
also
a
full
stack
hardware
with
the
same
architecture
on
the
main
board
and
something
on
the
storage
card.
We're
also
featuring
risk
fires.
So
it
might
be
a
okay
but
do
like,
like
dual
options:
dual
option
so.
A
C
Well,
as
far
as
I
know,
I
know
about
carlos-
I
don't
don't
remember
his
second
name,
but
there
is
carlos
from
red
hat.
He
did
experiment
with
some
discontinuing
boards
with
docker
and
kubernetes
support
itself.
C
So
the
general
answer
is
yes,
but
I'm
not
sure
if
all
maybe
some
all
capabilities
who
are
are
possible
today
with
that,
that's
definitely
requires
some
additional
work
and
plus
there
is
a
big
demands
and
and
engineering
activities
about
virtualization
extensions,
since
risk
5
offers
more
isolation.
Levels
like
like,
I
would
say
it's
called.
I
think
it's
called
mode,
so
there's
machine
mode,
user
mode
and
so
something
else.
C
So
they,
instead
of
having
a
kernel
mode
and
user
mode
levels
of
execution,
they
have
three
different
modes
and
I'm
not
pretty
sure
how
it's
differ
correlates
with
the
virtualization
strategy
on
say,
for
instance,
virtual
machines
and
containers.
So
if
we
are
talking
about
containers,
probably
there
is
some
support
say
this
docker
and
kubernetes
is
supported,
but
what's
what's
kind
of
architecture
is
are
coming
coming
through
there
and
how
does
the
employment?
C
C
So,
but
there
will
be
changes
since
different.
More
improved
hardware
would
offer
a
different
virtualization
capabilities,
which
means
there
is
more
options
for
continuity,
and
I
think
I
guess
this
would
be
something
would
be,
would
be
rewrite
so
offerings
using.
There
is
a
replacement
for
docker
called
putman.
So
I'm
not
sure
what
is
what
is
what
about
podman
on
risk
fire
that
at
this?
That's
what
I
don't
do
not
know-
and
I
don't
have
any
information
about
this
in
something
that
something
is
working
successfully.
A
Yeah
I
mean
we'd
be
happy
to
add
support
for
it.
We
don't
have
any
risk
five,
real
expertise
or
experience.
So
you
know,
let's
follow
up
on
issues,
feel
free
to
open
issues,
and
if
you
have,
if
you
can
provide
contributions,
you
know,
let's
do
what
we
need
to
to
to
get
it
working
there.
D
D
For
like
a
risk,
five
kubernetes
environment,
where
rook
can
run,
I
mean,
certainly
we
have
no
way
of
testing
it
right
now.
We
have
no
risk
five
machines,
not
that
you
know
that
stopped
us
from
building
for
arm
before
we
had
arm
machines,
but.
D
A
A
As
far
as
lxc
support
yeah,
I'm
not
sure
we
we
have
any
real
update
there,
but
so
is
that
more
about
the
container
runtime
or
I
mean
because
obviously
our
containers
are
supported
on
linux,
because
I'm
not
sure
exactly
what
lxd
support
is
looking
for.