►
From YouTube: 2021-07-27 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
All
right
the
recording
has
started-
and
this
is
the
july
27th
2021
rook
community
meeting.
We
don't
have
any
1.5
activity
planned.
I
know
we
just
did
a
1.6.8
just
last
week
link
that
the
release
notes
here
in
the
agenda
document.
A
number
of
bug
fixes
were
included
in
that
one.
So
a
lot
of
activity
there.
Anything
like
the
worth,
like
big
items,
fixes
to
worth
mentioning
there
travis
said
blaine.
B
A
B
A
Talk
later
yeah,
we
can
talk
about
it,
then
I
think
yeah
and
blaine
might
have
stepped
away
for
a
second
too.
So
we'll
do.
A
Okay
and
then
so
we
got
1.6.8
out
just
last
week
and
we'll
have
a
1.6.9
on
the
somewhat
typical
cadence
triple
few
weeks.
I
guess
later
so
thursday
august
12th
is
when
the
1.6.9
is
planned.
Let's
take
a
look
at
the
project
board
and
see
what
are
the
high
priority
or
issues
of
interest
to
talk
about
for
1.6.9.
B
B
A
A
What
about
now,
do
you
see
the
agenda
document
nope,
it's
still
just
black.
No,
that's!
Never!
That's
never
happened
to
me
before
I've
seen
other
people
have
this
issue
with
zoom
before,
but
I
have
never.
It's
never
happened
to
me.
A
A
Happened
with
me
when
you
have
dual
monitors,
interesting.
B
B
A
B
A
Yep,
I
see
your
board
there,
no
problems
1.6.
B
Okay,
so
yeah
here
we
are
as
far
as
the
issues
in
here,
so
we've
got
one
that's
in
progress
that
shabam
has
a
pr
for
merging
and
appending
osd
placements
and
then
otherwise.
B
B
C
B
B
For
1.7,
then
we
did
get
the
1.7.0
beta0
release
out
yesterday
I
did.
I
did
not
do
a
very
good
job,
communicating
that
out,
just
because,
with
all
of
the
new
changes
to
the
github
actions
and
the
fact
that
it's
all
based
on
the
github
actions.
Now
there
was
no
jenkins
involved
in
this,
which
is
awesome.
B
B
If
I
look
at
the
board
for
1.7,
then
I
think
so,
there's
a
black
column
blocking
release
column
that
let's
make
sure
that
any
issues
that
need
to
be
in
for
before
1.7.0
is
released.
We
can
make
sure
they're
there
that'll
be
great.
B
I
think
the
we
have
the
standard
update
to
the
upgrade
guide
that
we'll
need
so
blaine
you're
working
on
that
I
think,
and
then
I
don't
know
of
any
other
issues
right
now,
honestly,
but
we'll
get
an
issue
open
to
track
there
and
otherwise
yeah
there's
a
bunch
of
to-do
items
for
1.7.
B
Yeah
and
then
for
the
timeline
of
1.7.0,
so
just
given,
I
want
to
make
double
sure
that
the
new
github
actions
are
stable.
I'm
thinking
if
we
move
out
to
move
it
out
to
early
next
week,
monday
or
tuesday
did
I
put
monday
on
there.
I
was
thinking
I
put
tuesday,
but
just
to
give
a
little
extra
time
for
the
blog
and
upgrade
testing
and
everything.
A
Yeah,
I
think
I
think
you
had
tuesday
travis,
but
it
was
tuesday
eight
two
and
I
think
that
the
second
is
monday.
So
if
you
make
tuesday,
then
eight
three
would
be
okay.
B
I'm
gonna
change
it
to
that
then,
as
my
proposal
whoops,
does
anybody
have
any
concerns
about
waiting
until
that
tuesday
or
comments
on
that
date?.
B
B
B
So
basically
the
workflow
is,
we
merge
things
into
the
release,
branch
and
the
release
branch,
build
is,
is
kicked
off
and
the
tests
run
and
the
build
is
published
but
not
promoted,
and
then
once
the
person
doing
there
at
least
sees
that
oh
yeah.
The
tests
are
all
good,
it's
ready
to
be
released.
Then
we
push
the
tag
and
and
it'll.
You
know
in
the
next
half
hour,
we'll
have
the
release
out
there.
B
A
What's
the
what's
the
big
delta
there
or
the
root
the
cause
for
the
big
delta
in
a
much
shorter
time
frame,
did
you
not
run
all
the
same
integration
tests
again
or
for
the
final
build?
A
B
The
so
what
I'm
saying
is
so
the
the
last
commit
we
always
do
for
the
release
is
where
we
update
the
manifest
with
the
release
version
right,
so
we'll
push
that
command
and
well
honestly,
if
we
add
that
step
in
it's
not
quite
as
much
of
a
time
savings,
but
so
when
we
push
that
commit
we'll
wait
for
the
ci
to
complete
and
we'll
see
that
if
it,
if
things
passed
or
failed-
and
if
we
see
that
oh
it
all
passed
except
for
a
couple
of
intermittent
issues,
then
we'll
decide
to
tag
it
and
it'll
be
released
within
a
half
hour.
B
I
mean
so.
The
real
improvement
here
is
that
all
of
those
tests,
all
the
integration
tests,
run
in
different
github
actions,
so
they're,
basically
in
parallel,
instead
of
all
being
sincerely
run
on
jenkins
right,
so
that
all
the
integration
tests
take
like
a
half
hour
or
less
total
instead
of
an
hour
and
a
half.
So
I
think
we
should
save
a
good
hour
there
anyway.
A
Have
to
wait
for
a
runner
to
be
to
be
available,
so
we
don't
have
to
cue
the
job
and
then
jenkins
was
running
unit
tests
first
and
then
running
integration
tests,
which
was
obviously
adding
more
time
or
just
like
charlie,
said
everything
runs
in
in
parallel
here.
The
builds
as
well
as
the
unit
test
are
different
operations,
but
yeah.
That's
that's
where
we're
saving
so
much
time.
I
guess,
and
we
don't
have
to
wait
for
resources
to
be
available
to.
B
Yeah,
oh
one
comment
I
want
to
add
on
that,
so
the
event
of
pushing
a
tag
that
in
in
this
beta
release,
was
still
a
manual
process.
So
basically
I
went
into
my
local
enlistment
made
sure
it
was
all
clean
and
then
added
a
tag
and
then
pushed
the
tag.
Really.
We
need
a
place
to
do
that,
like
from
the
github
ui,
where
it's
like
go
tag,
this
branch,
and
so
we
don't
risk
any
local
changes
that
are
on
happen
to
be
on
the
machine
of
the
person
we're
using
it.
A
Chat,
yeah
and
travis
we
spend
so
in
the
cross
playing
project.
We
have
a
github
action
to
to
tag
a
particular
branch
or
you
know
a
particular
semantic
version
and
that's
part
of
our
release
workflow
there,
so
that
that
could
be
something
that
helps
we
can
be
used
for
rook
too.
B
C
A
We
could
also-
I
was
thinking
about
something
similar
where
we
would
use
this
tagging
action,
but
it
will
react
based
on
the
merge
of
a
particular
pr
with
maybe
a
particular
label
which,
which
would
mean
okay.
This
is
this
is
this
is
the
pr
that
we
merged
before
releasing,
and
then
we
know
this
will
trigger
a
tag
and
then
the
tag
will
trigger
the
build
something
like
this.
B
All
right,
I
think,
well
at
least
I'm
not
ready
to
go
with
that
much
automation,
because
I
want
to
wait
until
a
build
is
completed
and
just
verify.
The
tests
are
good
before
we
go
ahead
with
release
because
we
wouldn't
want
to
release
the
build
before
the
tests
have
completed
and
passed,
and
all
that
no
no.
A
But
you
don't
but
yeah
we
can
discuss
this,
but
yeah
still
introducing
this
action
and
run
it
manually
will
be
your
first
good
step
for
sure.
B
Sounds
good,
if
that's
all
the
thoughts,
I'm
tagging,
then
the
other
item
I
want
to
follow
up
on
is
with
our
beta
releases.
So
so
far
we
have
not
had
the
pattern
of
promoting
that
build,
which
basically
means
the
helm
chart
is
published.
B
B
B
All
right
we've
mentioned
this
in
the
last
couple
of
meetings,
but
I
just
wanted
to
make
sure
everyone's
clear
on
what
would
be
coming
with
rook
1.8.
B
B
B
B
B
B
A
Yeah
travis,
you
might
have
just
said
it
sorry,
I
didn't
hear
it,
but
that's
kind
of
a
big,
bigger
jump
than
the
normal.
For
you
know,
minimum
kubernetes
version
from
11
to
16.
it
was.
There
was
a
specific
functionality
in
16
that
we
were
going
to
be
requiring
or
taking
a
penalty
on
going
forward.
B
A
That's
that
sounds
good
yeah,
so
some
of
the
the
cloud
provider
like
mid
services
manage
kubernetes
offerings
like
gke
that
already
passed
all
the
1.62.
I
think
their
minimum
now
is
like
1.18,
maybe
they're,
moving
to
one
at
19
soon
so
they're
they're
beyond
this
as
well
too.
So
I
don't
think
we're
you
know
going
too
far
ahead
of
anybody
or
being
too
aggressive.
B
Cool
all
right,
if
there's
no
other
comments
about
that
blaine,
do
you
want
a
quick
summary
on
atari,
partitions
and
lvm
mode
and
raw
mode,
and
all
that.
C
And
yeah,
I
ended
up
just
going
through
the
atari,
like
partition,
table
specification
and
through,
like
the
linux
kernel
code
and
realized
that
whoever
wrote
this
atari
partition
table
support
was
really
lazy
and
it
it
creates
a
lot
of
issues
when
os
is
enabled
that
support
for
the
data
that
does
not
meet
the
atari
specification
to
appear
to
the
linux
kernel
as
one
of
these
phantom
atari
partitions,
it
doesn't
happen
with
lvm
mode,
or
at
least
it
doesn't
like
negatively
affect
ceph
in
lpm
mode.
C
I
have
seen
some
evidence
of
it
still
appearing
in
lvm
mode.
It
just
doesn't
like
the
lvm
containers
kind
of
hide
the
issue
from
becoming
a
problem.
C
The
recommended
workaround
is
for
users
to
create
large
partitions
on
their
devices
if
they
still
want
to
use
raw
mode,
if
they
don't
want
to
like
have
a
vm
on
their
hosts
or
for
whatever
reason
they
don't
want
to
use
lpm
and
yeah.
I
have
a
pr
and
set
volume
that
will
like
effectively
work
around
the
issue
and
set
volume.
C
The
other
kind
of
reasonable
course
of
action
might
have
been
to
change
the
like
first,
like
512,
byte
sector,
that
the
osd's
put
down,
but
that
would
require
osd
format
updates,
whereas
working
on
the
issuance
of
volume
like
that
is
like
the
tool
for
provisioning
stuff
with
disks
for
stuff,
and
the
only
other
like
alternative
is
to
fix
the
atari
code
in
the
linux
kernel.
C
A
B
And
if
there
are
no
more
comments
on
that,
I
still
have
an
action
item
from
the
last
meeting
or
two
about
updating
or
replacing
the
fossa
license
scanning.
So
we
can
get
a
clean
run
there
and
continue
having
it
run.
There's
no
known
license
issues
it's
just
this.
The
tool
is
not
cooperating
to
give
us
a
good
positive
pass
message.
So.