►
From YouTube: 2022-01-25 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
A
I
think
I
got
it
all
right.
You
can
see
my
window.
I
assume
yes
all
right.
So,
first
of
all,
1.7
we
did
have
a
1.7.11
released
last
thursday.
That's
all
done.
There
were
a
couple
of
fixes
in
there
that
were
useful
for
the
community
and
the
next
1.7
release
may
or
may
not
need
to
happen.
We're
really
focusing
on
1.8
now
and
I
don't
know
of
any
anything
critical.
A
A
So
if
I
look
at
the
1.8
board
here,
I
spent
a
few
minutes
updating
it,
removing
things
that
obviously
wouldn't
probably
make
it
into
1.8
just
because
nobody's
assigned
to
them,
but
there's
still
a
bunch
of
other
things
in
here
that
I'm
sure
will
move
out
there.
Just
just
left
them
here
optimistically
for
those
who
are
working
on
them
to
get
get
in
the
back
ports.
A
B
I
don't
think
so.
I
yeah,
I
think,
cleaning
that
up
is
was
good.
A
Yeah
sounds
good
for
1.9,
then
the
there's
nothing
much
of
interest
in
the
project
board.
Yet
I'm
I
started
making
a
pass
on
what
we
might
do
for
the
road
map
for
1.9
I
mean
ultimately
it'll
be
targeted
for
end
of
march
or
start
of
april
after
set
quincy
is
available
and
we'll
see
when
that
date
comes
out,
but
other
than
the
support
for
seth
quincy.
A
Well,
that's
just
the
main
target.
That's
that
has
it
on
the
calendar.
For
that
around
that
time,
I
think.
That's
all
I've
got
for
releases
any
other
questions
about
releases.
A
A
So
we
just
reviewed
that
and
talked
over
it
and
they
we
talked
about
their
operator
because
they
they
have
created
their
own
independent
operator,
and
so
the
question
really
that
we
talked
about
was:
does
it
make
sense
for
the
rook
cassandra
operated
to
continue
because
there's
no
one
currently
maintaining
it
and
kind
of
the
current
position
is
or
my
assumption
is
that
they
would
stick
with
their
operator
that
they're
already
working
on,
and
we
would
can
rook
just
point
people
to
that
opera
operator
that
they've
got.
I
linked
it
there
in
the
agenda
for
cassandra.
A
Yeah
so
we'll
see
if
they
get
back
to
us
on
anything
different,
but
just
like
we
sunsetted
the
a
couple.
Other
operators
like
cockroachdb
and
mineo,
we'll
probably
sunset
the
cassandra
operator
as
well.
B
Yeah,
I
guess
the
the
only
thing
I
would
add
to
that
is.
It
is
nice,
at
least
in
this
case,
if
we
sense
that
the
cassandra
operator
to
have
something
to
point
users
toward
at
least
like
something
they
can
optionally
use
instead,
if
they
do
come
to
rook,
looking
for
cassandra
still.
A
Yeah
exactly
and
since
we
separated
to
its
own
repo.
Now
we
can
we'll
just
keep
the
repo
and
we'll
just,
I
think,
make
it
obvious
on
the
main.
Readme
just
hey
go
use
this
one.
Instead,
this
one's
deprecated
and
unsupported,
so
I
opened
an
issue
which
I
linked
from
the
agenda
there
just
basically,
so
the
community
can
be
more
aware
of
that
plan.
A
B
Yeah,
so
I
mean
regarding
cozy,
which
is
the
you
know,
aims
to
be
kind
of
csi
for
for
object,
storage,
the
the
design
seems
like
it's
getting
pretty
finalized.
I've
been
following
those
meetings
again.
B
This
hopefully
means
that
they're
on
track
for
releasing
alpha
in
kubernetes
1.24.
Once
that
happens,
I
know
we
would
like
to
to
integrate
with
that.
It's
going
to
be
like.
Ideally,
it's
going
to
be
a
replacement
for
lead
bucket
provisioner,
which
is
yeah.
I
mean
it's
in
sustaining
now
like
there
are
no
no
new
feature
development.
It
is
all
focused
on
so
happy
to
see
that
moving
forward.
B
I
think
so
I
thought
I
just
looked
at
the
kubernetes
releases.
I
thought
1.23
was
released
in
january.
B
Well,
so
like
earlier
this
month.
I
think
that
probably
means
it's
going
to
be
what
four
months
june
february
march
april.
May
I
guess,
but
there's
also
like
the
you
know.
The
proposal
needs
time
to
be
like
accepted
as
well
in
kubernetes,
because
it
is
part
of
account.
A
B
I
think
so
it
was
just
kind
of
a
very
basic
proof
of
concept,
and
I
I
think
it
used
a
lot
of
the
like
primitives
that
we
had
used
to
implement
a
driver
for
a
bucket
provisioner.
So
I
mean
hopefully
it
should
be
pretty
easy.
They
yeah,
I
mean
I
I
do
have.
B
I
guess
one
major
thought
around
like
what
we
should
try
to
do
differently
with
cozy,
which
is
to
keep
track
of
which
buckets
are
created
as
a
result
of
cozy
and
like
assume
that
buckets
that
aren't
like
marked
as
such
are
created
by
users
so
that
we
don't
like,
even
if,
like
a
cozy
buckets
like
cleanup
policy,
is
set
to
delete
if
it
wasn't
originally
created
by
cosi.
We
shouldn't
delete
that,
but
I
think
that's
also
an
optimization
that.
B
A
A
C
Thank
you
yeah,
it's
the
first
time
I'm
joining
here,
I
probably
got
in
touch
with
some
of
you
a
couple
of
times
already.
C
So
just
wonder,
there
is
already
a
ticket
in
github
for
that.
It's
already
mentioned
there
that
there
is
some
work
ongoing,
just
checking.
Where
do
we
stand
if
we
can
help
getting
this
moving?
We
tested
it
with
a
manual
installation
on
okd
and
it
worked
fine
for
us,
but
yeah.
The
the
experience
having
an
operator
in
the
catalog
would
really
be
much
better.
A
Right
right,
I
guess
the
well
it's
good
to
know
that
at
least
that
the
manual
install
of
rook
worked.
So
the
and
honestly,
I
think
here
among
brook
containers
we're
just
not
real
familiar
with
the
okay
catalog
or
the
scenarios
or
the
we
just
don't
see
those
users.
So
it's
not
that
we
haven't
wanted
to
do
it.
It's
just.
A
Maybe
the
other
things
keep
pulling,
is
in
priority
weight
so
and
maybe
one
question
with
the
okiti
catalog,
so
the
because
there's
also
a
downstream
product
like
odf,
that's
kind
of
built
on
road.
So
if,
if
the
downstream
is
installed,
it
can
be
installed
with
otd
right.
Would
that
look
like
a
duplicate
entry
in
the
catalog
or
how
does
I
don't
even
know
how.
C
A
Okay,
so
there's
no
worry
about
that-
I
guess
duplication
in
the
catalog
okay,
but
I
heard
something
about
that
possibility,
but
that's
good
to
know:
okay
yeah,
I
think
the
main
action
item
or
work
item
there,
then
is
just
we
need
to
go,
do
the
work
that
puts
it
into
the
catalog
and
publishes
to
the
catalog.
Each
time
we
have
a
release
from
rook
which
yeah
I
know,
there's
examples
provided
for
how
we
can
do
that.
C
I
can
tell
you
that,
within
the
okay
d
virtualization
effort,
we
have
an
operator
which
is
the
hyper-converged
operator
which
is
currently
published,
also
in
the
common
catalog
between
openshift
and
okd,
and
we
plan
to
move
it
to
the
okay
d1
once
it
will
be
available.
So
if
you
need
help
with
the
pipeline
deploying
the
operator
and
sending
it
to
the
catalog,
we
can
probably
give
an
end
there.
A
Okay,
yeah
plain:
do
you
have
any
thoughts
around
that,
but
I
haven't
been
as
involved
with
the
packaging
for
openshift.
B
But
yeah
I
I
guess
I
have
some
questions
around.
How
like
testing
would
work
like
if
we're
releasing
on
a
different
platform,
it's
good
to
test
that,
like
we
have
helm,
we
test
helm
charts.
I
know
also,
if,
if
we're
producing,
you
know
an
okde
catalog
entry
like
that
should
be.
At
least
you
know,
smoke
tested
at
some
point,
but
I
I
think
that
concern
can
be
largely
left
like
to
a
detailed
follow-up
conversation.
C
A
I
think
I
remember,
as
I
recall,
in
the
the
sample
scripts
or
actions
that
were
provided
or
been
been
done,
other
places.
So
when
we
automate
this
a
pr
will
be
opened
against
the
okd
catalog
and
some
ci
validation
is
done
at
some
level
right
and
then
it's
merged
automatically
or
how
does
the
merge
get?
Does
somebody
have
to
click
merge?
C
Yeah,
the
guy
that
is
working
on
the
test
part
there
simone
is
not
in
the
meeting
today,
but
he's
open
to
provide
feedback
and
contributing
so.
C
A
All
right
so
thanks
for
bringing
that
up
today
then
and
then
on
the
action
items.
We
have
a
couple
of
things
to
follow
up
on
from
our
last
meeting
to
sunset,
the
rook
dev
google
group,
and
then
I
was
going
to
open
a
pr
to
update
the
roadmap
dock
for
for
1.9
yeah
I'll
do
that
in
the
next
few
days,
so
we
can
get
that
done,
but
that's
all
we've
got
on
the
agenda
for
today.
Is
there
anything
else
anybody
wants
to
bring
up.