►
From YouTube: 2021-08-24 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).
B
B
A
A
That
topic
a
little
later
in
the
intervention.
A
1.5,
there's
1.5
already
like
six
months
old
or
more
or
was
it
last
december.
Time
is
flying
here
anyway,
1.6
we
did
get
the
1.6.9
release
out
yesterday
and
that
that
was
all
good
to
go
and
it
was
fully
based
on
the
new
github
actions
which
we
shivan
helped
us
get
done
and
port
to
the
1.6
branch.
A
A
As
far
as
the
next
version
of
1.6
so
1.6.10,
probably
in
three
or
four
weeks,
we
could
do
another
one.
I
don't
know
of
any
urgent
issues
right
now
and
just
to
double
check
the
project
board.
I
think
it
should
be
pretty
clean.
A
A
A
A
We've
got
bucket
notifications
in
progress
and
part
through
change
on
utility
string
or
retail
sets.
All
right,
I
don't
know,
there's
anything
specific.
We
need
to
talk
about
for
1.7
releases.
Anyone
else
have
something
specific
that
we,
I
guess
the
main
thing
is.
If
there's
anything,
we
want
in
the
dot
2
patch
release,
let's
make
sure
it's
in
the
block
and
release
column
before
thursday.
A
Let's
see
thinking
ahead
for
the
1.8
release
the
let's
say
september
october
november,
I
think
we'd
be
looking
around
early,
probably
the
first
first
week
of
december
realistically,
for
that,
so
we've
got
a
while.
A
A
So
for
the
topics-
I
guess
we
already
mentioned
this
1.69
on
github
actions.
A
Now
with
that,
I
did
find
one
small
issue
during
that
release,
which
was
this
was
the
first
1.7
or
1.6
release
based
that
were
where
I
tried
to
use
the
new
tag
action.
So
the
tag
action
created
the
tag
but
for
some
reason,
the
github
actions
that
rely
on
that
tag
were
not
triggered
to
kick
off
the
build.
So
I
opened
an
issue
for
that,
so
I
had
to
basically
delete
the
tag
and
then
go
back
and
create
the
tag
manually
instead
of
using
that
action
to
trigger
the
other.
A
B
A
A
B
A
A
B
C
Yeah
there
there's
a
lot
here.
This
is
based
a
lot
on
what
I
posted
in
the
slack
channels.
We've
talked
loosely
several
times
and
for
a
while
about
separating
different
back-ends
from
work
core.
C
So,
notably
for
us
like
we
got
rid
of,
I
think
mine
I
o
and
cockroach
tv
back
in
so
now
there
is
still
the
nfs
back
and
cassandra
back
end.
C
When
we
have
like
a
ci
issue
and
nfs
is,
I
think,
maybe
just
small
enough
and
just
hasn't
given
us
a
lot
of
problem,
but
for
for
new
projects
coming
in,
our
idea
is
for
them
to
have
their
own
repo,
and
I
think
we.
C
C
Remove
the
like
make
build
targets
that
are
related
to
ceph
and
the
like
back
end.
But
it's
not
part
of
that
that
repo
and
then
in
our
rook
repo,
we
can
do
the
same.
Remove
the
cassandra
and
nfs
stuff.
C
One
of
the
I
think,
long-term
gains
that
we
get
from
this
in
the
rook
and
the
primary
rook
repo
is
that
we
can
simplify
some
of
the
like
make
targets
and
build
tooling,
which
a
lot
of
the
complexity
derives
from
supporting
the
multiple
back
ends.
From
a
time
when
rip.
I
think
that
was
rick's
goal
from
from
cncf's
kind
of
feedback
was
to
to
support
more
back-ends.
C
A
Yeah-
and
I
agree
with
everything
you
said
just
to
reiterate,
maybe
so
with
with
the
github
actions
in
place,
so
this
makes
it
a
lot
easier
to
have
the
actions
just
running
on
separate
repos
and
just
target
the
operators
that
are
in
that
repo
that'll
be
really
nice
operator
only
gets
released
when
there's
actually
updates
to
it,
because
yeah,
like
you,
said
we're
just
implicitly
supporting
it,
but
not
really
supporting
it,
which
isn't
really
healthy
for
the
operator.
If
we
give
the
impression
of
supporting
something,
that's
not
really
supported.
A
A
Well,
we
still
haven't
seen
that,
and
so
long-term
support
is
just
a
struggle.
Even
right
now,
with
the
cassandra
tests.
There's
they've
been
failing
for
the
last
couple
of
weeks
and
jen
is,
is
meaning
to
look
into
them,
but
he's
busy
even
moving
moving
to
a
new
place
moving
across
countries
and
everything
so
he's
a
little
bit.
He
is
a
little
busy
right
now,
it's
hard
for
him
to
just
maintain
it
himself
too,
since
he
doesn't
work
on
it
for
his
full-time
job,
either.
A
One
question
I
had
about
the
github
actions:
I
wonder
if
we
have
the
actions
mainly
enabled
just
for
just
the
rook
rook
repo.
I
wonder
if,
when
we
go
to
rook,
slash
cassandra
and
nfs,
if
we'll
have
to
get
our
limits
increased
well,
we
probably
won't
need
limits,
increase
so
much
for
the
other
ones
anyway.
Maybe
just
the
default
limits
will
work.
Fine
for
the
nfs
and
cassandra
repos.
C
A
Yeah,
so
getting
it
set
up
may
take
a
a
bit
of
work,
but
it
seems
like
it's
a
worthwhile
investment
for
sure
for
the
it's
also
the
pattern
we
want
in
the
long
term
like
if
another
storage
provider
actually
came
to
rook
and
said
we
want
to
do
it,
but
we've
already
said
you
have
to
create
a
repo,
and
if
we
already
have
the
pattern
in
place,
it
will
just
be
easier
going
forward.
C
Yeah
yeah
there
there's
definitely
an
amount
of
like
things
that
we
can
do
that.
I
have
not
necessarily
planned
to
do.
C
We
we
could
for
cassandra
or
nfs
not
like
treat
it
as
a
like
full
full
fork
like
I
have
sort
of
implied
and
used
the
rook
rook
repo
as
a
library
that
is
used
by
rook
cassandra
or
rook
nfs,
and
any
new
operator
might
choose
to
do
that
or
might
not,
depending
on
what
their
I
guess
desires
are,
and
we
could
show
what
that
looks
like
I,
I
don't
think
that's
quite
as
simple
of
a
set
of
changes
that
I
think
I
could
accomplish
that
in
a
day.
C
C
A
A
C
Yeah,
the
since
it
yeah
it's
also
interesting,
since
those
operators
are
both
in
alpha.
I
think
it
is
better
if
we
would
release
them.
It's
like
zero
dot,
something,
but
because
they
already
have
been
released,
possibly
under
zero,
not
something
or
they
already
have
releases
under
one.
That's
something
that
it
becomes
confusing.
C
I'm
not
sure
how
to
indicate
like
an
alpha
state
other
than
maybe
just
you
know,
specifying
with
all
versions
that
you
know
just
happened.
A
A
Yeah,
I
think
all
this
makes
sense.
I'd
like
to
sync
up
with
jared
on
it,
just
as
an
official
steering
committee
thing,
since
it
is
such
a
big
impact
to
the
overall
project,
but
I
think
we
should
be
fine
with
it.
B
Yeah
and
I
think
it's
a
really
natural
move
as
well,
and
it's
really
about
this
like
in
tree
versus
out
of
three
thing
and
yeah.
I
guess
out
of
three
makes
a
lot
of
sense
in
that
case,.
C
B
Oh
yeah
yeah,
I
wouldn't
vote
for
that.
I
think
we
would
be
losing
also
too
much
history
as
well
like
migrating
aw
shoes
and
things
like
this
project
boards.
I
think
we
will
be
losing
so
much
history
that
it's
going
to
be
really
troublesome.
A
B
A
B
B
C
I
don't,
I
don't
think
so.
I
think
there
will
certainly
thing
have
I'm
sorry.
There
will
certainly
be
things
that
come
up
like
I
just
remembered
documentation
will
come
up,
so
we'll
have
to
figure
out
whether
we
should
still
produce
documentation
and
like
your
documentation,
should
we
at
a
particular
version
or
how
that
will
work.
A
Yeah,
actually,
that's
a
good
point.
We,
the
documentation,
may
need
a
bit
of
work,
because
I
what
I've
really
wanted
for
a
long
time,
is
that
a
job
each
storage
provider
would
have
its
own
set
of
documentation
pages.
So
we
don't
have
to
have
them
overlapped,
which
would
which
would
follow
along
well
with
this
repo
rework,
where
each
provider
would
publish
its
own
docs
according
to
its
own
version
scheme,
and
it
would
just
maybe
put
it
under
a
different
subfolder
on
the
website,
so
that
each
is
published
on
its
own
schedule
and
everything.
C
Yeah,
maybe
maybe
something
to
talk
to
jared
about,
would
be
whether
someone
outbound
has.
C
Like
an
idea
for
an
ability
to
to
spend-
maybe
I
don't
know
I'm
hoping
if
it's
someone
who
works
in
that
domain,
a
lot
they
could
spend
like
a
day
on
it
and
actually
like
get
it
done.
Similarly,
to.
A
B
A
And
so
far
we
don't
have
a
github
issue
to
track
this
proposal
right.
It's
just
been
a
slack
discussion
with
maintainers
and
now
a
year.
So
maybe
it's
time
to
go
ahead
and
if
you
want
to
open
a
github
issue
so
that
the
community
is
more
aware
of
what
would
be
coming
with
this
change-
and
I
think
we're
saying
so-
the
the
docker
repos
wouldn't
change.
They
would
still
be
each
store's
writer
would
still
have
its
own
repo
just
like
today
for
publishing
yeah.
C
B
A
B
C
Yeah
yeah,
I
guess
like
there
aren't
really
any
new
features,
but
it
is
like
a
substantial
is
a
substantial
change
and
I
think
worth
doing
like
release
notes.
For
so
we
could
like
cut
1.8
versions
of
cassandra
and
nfs
earlier
yeah.
A
C
And
then
just
say
that,
like
this
is
the
like
officially
like
these,
these
releases,
like
anything
after
this,
is
not
really
planned,
but
will
be
from
like
a
community
that
comes
up
around
them.