►
From YouTube: 2021-06-01 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
B
A
So
said
this
is
the
june
1st
2021
rook
community
meeting,
and
so
we
can
go
ahead
and.
A
We
can
take
a
look
at
the
1.5
board
since
it
looks
like
we'll
be
doing
a
12
patch
later
on
this
week.
I
think
yeah,
that's
this
thursday.
Okay,
a
couple
improvements
for
osds
and
modern
reliability.
C
A
Were
there
particularly
specific
issues
in
the
done
column
here
that
we
wanted
to
call
out
there
then
travis,
because
this
general,
a
few
fixes
contributed
to
the
reliability,
fixes.
C
Yeah,
I
can
add
the
links
later
at.
I
don't
know
that
they
ended
up
in
the
1.5
board.
A
All
right,
but
the
either
way
thursday
we
were,
we
were
planning
on
going
in
and
releasing
that
1.5.12
patch.
A
C
A
Is
there
a
1.7
board
already
started.
A
Yeah
we
should
get
that
linked
in
the
in
the
agenda
doc
as
well
too.
A
Okay,
let's,
let's
take
a
look
at
the
at
the
107
board,
as
the
milestone
is
upcoming,
you
know
it
is,
is
more
than
a
month
away,
but
let's
see
sort
of
what
are
the
highlights,
for
you
know
big
ticket
items
you
know,
features,
etc
that
we
can
either
expect
that
have
already
been
merged
in
or
that
are
along
the
way
coming
along
the
way.
I
think
we're
going
to
talk
about
the
south
cluster
home
chart
later
on
today,
but
but
what
other
big
you
know,
big
improvements?
C
C
What
else
I
I
feel
like
or
maybe
but
then
we've
been
focusing
more
on
1.6
and
not
so
much.
I
wanted
to
send
it
yet.
So
I
feel
like
we're
about
to
turn.
D
B
Oh,
I
haven't,
I
haven't
started
anything
for
1
7.,
just
focus.
You
know
one
one,
one,
six.
A
A
A
B
D
A
That's
funny:
okay,
let's
add
the.
We
had
updated
the
roadmap
here
at
least
somewhere
recently.
So
let's
make
sure
we
have
that
length
here.
A
Okay,
all
right
so
folks,
we'll
start
rolling
off
more
dev
resources
to
1.7,
as
we
are
you
know,
have
been
focusing
some
some
of
the
resources
on
1.6
patches
and
stability
and
improvements
there,
but
we
can
see
things
in
the
roadmap
coming
down
the
pipeline
linked
in
the
agenda
doc,
and
you
know
next
next
meeting
here
we
can
focus
more
on
some
of
the
planning
or
items
and
status
and
updates
for
1.7
next
community
meeting.
A
Okay,
so
this
has
been
a
long
time
coming
the
home
chart
for
some
cluster.
That's
pretty
that's
exciting.
Who
travis
did
you
add
that
to
the
list
or.
C
Yeah,
oh,
I
added
it
to
the
list.
So
a
member
remember
the
community
submitted
this
pr,
for
I
forget.
The
pr
number
is
linked
in
the
proposal
that
proposal
link
there,
but
basically
it
is
merged
to
master.
C
Well,
people
can
test
can
test
the
master
chart
as
of
the
last
few
days
to
see
it
working,
but
my
I
guess
my
thought
I
haven't
thought
deeply
through
this,
but
to
get
more
feedback.
I
wonder
if
it
would
make
sense
to
backport
it
to
1.6
and
get
it
in
a
1.6
release
and
just
kind
of
label
it
as
experimental.
C
C
Having
an
experimental
channel
is
an
interesting
idea,
but
maybe
we
should
just
leave
it
in
the
master
channel
and
say:
hey
go
try
this
out
because
it
is
still
early
and
then
we
need
to
stabilize
it
to
make
sure
it's
in
good
shape.
Before
we
put
in
the
release.
D
Yeah,
I
I
think
we
do
a
lot
to
make
sure
things
are
backwards
compatible
in
rook
and
I
think
that's
a
really
good
effort.
D
D
So
I
I
kind
of
wonder
if
maybe
it
would
be
good
for
us
to
say
that
it's
experimental
in
1.7,
also
just
as
far
as
the
chart
goes
to
get
more
feedback
and
then
come
back
in
in
like
1.8
and
like.
Hopefully,
everything
is
good,
but
come
back
with
changes
that
we
don't
have
to
worry
about
so
much
being
like
backwards
compatible,
although
I
think
helm
does
handle
quite
a
bit
of
that
for
us.
So
I
I
guess
that's
like
kind
of
my
idea
around.
D
Maybe
we
should
consider
it
experimental
in
one
seven
also
and
why
it
might
be
useful
to
have
an
experimental
channel,
although
we
could
also
just
always
have
it
on
the
master
channel
and
then
just
mention
in
the
documents
like
this
exists,
we're
collecting
feedback.
You
can
use
it.
We
we
do
reserve
the
right
to
make
some
changes
to
it
before
it.
Like
is
probably
released.
A
What
would
that
look
like
exactly
like?
Would
the
for,
in
terms
of
like
the
helm,
repo?
Would
you
would
have
an
experimental
one
or
you
know
something?
That's
not
master
or
release,
and
then
this
chart
would
only
be
available
from
that
experimental
repo
would
not
be
in
you
know,
included
like
in
as
in
the
stable
1.6,
or
anything
like
that
when
you
couldn't
even
do
a
helm
install
from
from
there.
D
I
I
guess
that
was
kind
of
my
thought.
I
I
will
admit
it's
not
it's
not
a
fully
baked
thought,
like
I
hadn't
like
thought
to
like
the
final
ends
of
it.
I
was
just
kind
of
thinking
around
just
making
sure
there's
some
way
we
can
market
as
experimental
or.
B
D
Note
for
users
that
is
experimental
so
that
they
don't
have
unrealistic
expectations
of
its
perfection.
I
guess,
but
we
do
want
to
get
feedback,
and
I
think
if
we
make
a
separate
experimental
channel
that
that
might
go
against
our
desire
to
get
feedback,
I
think
it
probably.
We
might
get
better
feedback
if
we
just
leave
it
in
the
master
channel.
You
got
us
kind
of
mentioned
that
I
think.
D
Or
if
there's
just
a
way,
we
can
like
denote
that
particular
thing,
as
this
is
experimental
it's
here,
but
just
like
be
aware
that
it
is
not.
D
We're
not
considering
this
a
like
final
form,
I
guess
of
of
what
this
looks
like,
not
that
anything
is
ever
final
form,
but
like
our
our
attempts
to
make
sure
things
are
backwards,
compatible
between
like
one,
seven
and
1
8
will
be
minimal.
I
guess
I
would
say
just
to
make
sure
that
it
doesn't
overly
complicate
that
development
cycle
as
we're
kind
of
trying
to
figure
out
what
our
strategy
should
be.
I
think
I
think
that's
part
of
what
this
what
this
is
for
me
is.
I
I
realize
we
don't.
D
I
don't
know
if
we
have
someone
with
a
clear
idea
of
like
what
our
helm
strategy
should
look
like
or
how,
like
someone
with
like
a
deep
understanding
of
helm
and
health
charts
and
releases,
and
things
like.
D
C
Right
and-
and
I
think
that
I
feel
like
I
agree-
that
the
risk
of
not
being
able
to
be
backward
compatible
or
is
pretty
low
with
with
this
chart,
particularly
because
we're
just
taking
the
theft
cluster
and
updating
it.
We
wouldn't,
unless
there's
a
major
structure,
change
to
the
whole
health
chart,
then
yeah.
That's
why
we
want
to
be
experimental,
because
if
we,
if
we
decide,
we
need
a
totally
different
approach,
then
it's
like.
We
have
to
throw
it
away
and
not
support
upgrades,
but.
C
For
at
least
for
now,
I
feel
like,
if
we
just
leave
it
in
master
instead
of
trying
to
do
something
with
some
new
experimental
channel
the
I
mean
the
channels
we've
got
today
really
match
the
branches.
So
an
experimental
thing
would
diverge
from
that
and
then
we'd
have
to
come
up
with
be
more
ci
work
at
least
yeah.
C
So
if
we
leave
it
in
master
for
now
and
let's
see
if
we
can
push
the
community
for
feedback,
say:
hey,
try
the
master
branch,
let
us
know,
but
then
they
would
just
be
trying
it
on
master
and
not
a
1.6
release.
So
it
really
would
have
to
be
experimental,
obviously
for
people
trying
it
instead
of
trying
it
in
some
sort
of
production
based
on
one
that
sits.
D
Yeah,
I
I
think
we
could.
We
could
update
the
like
documentation,
416
to
say
there
is
an
experimental,
a
chart
for
the
ceph
cluster,
which
you
can
use
to
use
this
with
one
that,
like
with
one
use
this
with
a
current
rook
1.6
helm,
chart
just
make
these
changes
to
it.
Maybe
that
way
it's
like
we
are
officially
telling
you
about
it
and
telling
you
it's
experimental,
there's
just
a
little
bit
of
a
like
a
couple
more
manual
steps
to
get
there
than
just
grabbing
it.
C
Right
right,
that's
true,
because
the
the
rook
version
won't
actually
be
as
dependent
for
this
helm
chart
because
it's
just
the
cr,
but
the
actual
version
of
it
comes
from
the
operator
which
would
be
on
the
other
helm
chart.
So
we
could
right.
That's
a
good
point.
We
could
just
tell
people
to
test
on
master
even
with
work
1.06.
A
And
the
intensity,
for
that
is
like
more
visibility
as
well
too.
If
you
know
people
go
like
the
default
docs
or
for
1.6,
you
go
to
the
1.6
documentation
and
then
seeing
an
entry
like.
Basically,
I
have
to
go
to
the
master
documentation
just
to
even
see
this
right
now
right
so
going
to
1.6
docs
having
a
page
here.
That
then
has
basically
the
same
instructions
that
would
have
to
instead
of
using.
A
C
A
Do
that
in
the
docs,
but
when
we
go
to
1.7
since
we
don't
have
granularity
over
her
chart
in
our
build
system,
you
know
it
would
be
all
charts
or
just
rook
release
right,
that's
that's
this.
They
all
go
to
the
release
channel.
At
that
point,
you
can't
say
this
one's
going
to
release,
but
this
one
stays
in
this
channel.
It's
you
know
you
cut
through
this
branch.
You
run
the
ci,
they
all
go
to
the
release
channel.
A
A
And
and
there
there
aren't
any
abstractions
here
right
like
these-
are
just
complete
pass-throughs
of
data
down
to
the
cr
itself,
right
yeah,
pretty
much
okay,
and
that's
what
you're
saying
so.
The
interface
here
isn't
like.
There's
there
shouldn't,
we
wouldn't
expect
there
to
be
much
iteration
over
the
interface
here
since
it's
you
know,
it's
just
a
complete
pass-through
of
values.
D
I
like
that,
I
think
something
we
we
always
could
do
once
we
get
to
one
seven,
if
we're
still
not
sure
about
the
feedback
we
have
is,
to
just
add
some,
some,
like
some
lines
to
our
like
make
files
that
just
kind
of
like
strip
off
this
chart
from
like
tagged
releases.
D
D
C
A
Makes
sense:
okay,
cool
yeah.
This
is
a
great
addition,
though
I
know
people
have
been
wanting
that
for
a
while,
and
it
makes
it
makes
a
lot
of
sense
to
be
able
to.
You
know,
template
the
cluster
as
well,
in
addition
to
the
operator,
so
great
ci
improvements,
making
more
steps
to
finally
killing
jenkins.
C
Oh
yeah,
I
guess
I
added
this
too,
so
we're
we're
getting
really
close
thanks
to
shivam
and
seb's
work
around
all
of
these
github
actions.
There's
a
question
really,
I
think,
for
the
master
branch.
The
we've
got
everything
running
with
the
actions,
and
the
only
thing
I
think
that's
not
pointing
to
it.
That
needs
to
is
the
the
badge
that
we've
got
on
our
github.
C
That
says,
if
it's,
if
the
build
latest
build,
passed
or
failed
and
but
then
the
question
is
about
a
good
question
like
do,
we
even
need
this
badge
like
it
just
the
only
reason
it's
ever
read
is
because
of
intermittent
test
failures.
Really,
can
we
just
should
we
just
put
a
green
badge
there
for
the
build,
or
you
know,
what's
the
right
thing
to
do
said
about
your
thoughts
on
it.
B
Yeah,
I
don't
think
this
is
really
providing
any
useful
insights.
Any
useful
details,
what's
I
mean,
what's
red
now,
can
be
green
in
10
seconds
from
now
or
the
other
way
around,
so
it
doesn't
really
tell
much
from
the
user.
If
I
land
on
that
page,
I
see
build
is
failing
I.
B
What
does
this
mean
like?
Can
I
still
use
rook?
Should
I
wait?
Where
do
I
look
for
if
this
is
going
to
be
resolved?
Eventually,
you
see,
I
think
it's
just.
I
think
it's
good
to
show
like
badges,
maybe
for
security
scans,
and
things
like
this,
like
the
ones
we
have
are
good
but
the
build.
I
feel
like
it's
not
really
providing
any
useful
insights,
so
I
would
just
look
to
to
drop
it
but
yeah
if
yeah.
My
only
hesitation
is
thoughts
like
this
is
super
reliable,
like
yeah.
C
A
Oh
yeah,
well,
what
I
was
going
to
say
is
that
I
mean
it's
it.
It
is
definitely
a
transient
type
of
data
right
where
you
know
it's
going
to
change
as
as
the
latest
builds
come
out,
and
it's
less
of
a
upward
progress,
sort
of
measurements
like
you
have
with
other
things.
You
know
like
the
cia,
best
practices
and
stuff
that'll
you
know
are
supposed
to
over
time
consistently
just
get
better
and
improve
it's,
but
it
is.
A
I
mean
it
is
a
nice
status
indicator
of
hey
cool
like
if
you
know
all
things
are
green
I've.
Another
thought
on
that
real,
quick
that
I'll
get
to,
but
it's
a
nice
status
indicator
of
you
know
coming
in
and
seeing
like
everything
about
the
project
being
passing
right.
So
my
question
is:
that
is
it
you
know.
I
think
that
jenkins
maybe
provides
this
fairly
easily
and
with
github
actions.
Is
it
a
simple?
B
So
they
provide
badges
already.
If
you
go
on
to
one
of
the
actions,
then
you
can
create
badges
out
of
it
pretty
easily.
I
guess
it's
more
like
it's
not
a
lot.
That's
not
so
much
the
engineering
efforts
required
it's
more
about
we're,
just
questioning
whether
it
makes
sense
to
have
it
like.
Is
it
useful
for
users
to
have
that
status?
B
A
I
think
I
think
yeah,
and
that
makes
sense
that
I
understand
that
I
think
my
biggest
questions
would
be
that
if,
if
we
had
reliable
tests-
and
we
were
like
almost
always
green
and
it
going
red,
it
was
like-
oh
shoot,
it's
red,
oh
my
gosh,
we
got
it.
Somebody's
got
to
do
something
about
this.
Would
the
badge
have
more
meaning,
then
would
we
we
would
want
this
badge?
I
would
assume
if
that
was
the
case.
B
I
mean
if
something
is
red,
then
we
we
know
it
because
on
every
pr's,
then
something's.
C
D
C
B
A
Think
well,
yeah
in
general,
I
think
the
more
green
you
can
show
like
the
better
is
for
people
to
first
come
to
a
readme,
like
you
know,
like
okay
cool.
What's
this
brook
project
here,
okay,
cool,
it's
graduated,
nice!
You
know
like
build
this
fast
and
cool
cool
like
these
other
ones.
I'm
actually
more
concerned
about
these
other
ones.
Like
a
go
report
card
of
f,
it's
like
yeah.
B
It
has
been
failing,
since
I
think,
since
we
I
don't
know
like
it's
only
failing
always
failing
on
previous
branches,.
A
Yeah
fosters
yeah
fastest
little
a
little
odd.
You
have
to
do
some
manual
stuff
with
fafsa
to
get
it
to
understand
like
your
license
tree.
Sometimes
I've
messed
with
that
nonsense
before,
but
yeah
so
anyway.
So
like
I
I'm
not
against
removing
the
build
badge
but
yeah,
but
this
I
would
definitely
oh
that's
pretty
the
only
the
only
green
thing
and
go
on
the
go
report
card
is
licensed.
A
C
B
D
I
I
think
that
that
could
be
a
a
good
solution
is
to
show
the
like
the
building
unit
unit
test
progress
I
mean,
after
all,
it
is
a
build.
A
It
that
makes
me
think
that
it
like
makes
me
kind
of
you
know
re-ask
seb's
question
of
like
what
what
is
the
value
to
it?
If
we're,
it
sounds
like
we're
more
concerned
about
whether
it's
green
or
red,
but
as
opposed
to
useful
information
being
shown
that,
like
people,
would
act
on
or
make
decisions
on
or
anything
so
I'd
be
hesitant
to
change
it
to
something
just
to
get
it
green.
A
C
C
A
A
B
B
D
If
yeah,
this
is
something
that
I
I
think
I
saw
with
some
like
ibm
machines,
also,
if,
if
the
machines
are
running
very
slowly,
that
means
that
the
pods
can
initialize
very
slowly
and
the
liveness
probes
can
fail
so
like
if,
if
the
tests
are
just
going
to
run
slow,
we
might
have
to
change
the
the
startup
delay
for
the
liveness
probes,
but
it
also
means
that
our
integration
tests
might
like
might
not
be
waiting
long
enough
for
resources
to
become
available
even
outside
of
the
liveness
probe
probe
issues
I
don't
yeah.
D
B
B
I
think
honestly,
the
goal
for
me
with
this
one
was
just
to
see
if
we
could
deploy
on
arm
64.
like
if,
for
some
reason
we
have
an
issue,
an
underlying
issue
of
the
environment
and
then
we
would
know,
but
the
goal
is
really
to
kick
off
the
simple
deployment
and
then
have,
and
then
we
run
the
script
for
validating
that.
The
step
cluster
is
healthy
and
that's
it.
B
B
B
A
A
All
right
that
sounds
good
thanks,
so
that
works
out
all
right
anything
else
on
ci
or
we
move
on
to
the
remaining
topics.
A
Okay,
so
a
quick,
it
was
this
quick
question
I
had
for
the
kubecon
north
america
call
for
proposals
that
was
last
weekend
the
weekend
before
that
one
did.
We
did
anyone
end
up
hearing
about
or
submitting
any
talks
outside
of,
like
the
maintainer
track
for
for
rook
that
we
know
of.
B
I
don't
think
they
will,
but
well
not
that.
B
I
know,
but
I'm
always
super
pessimistic
with
like
if
you're
not
super
known
or
anything
like
this,
then
you're
not
going
to
get
to
talk,
accepted
and
somehow.
D
B
Already
started
getting
too
much
traction
anyways
first
time
did.
Did
you.
A
Say
it
was
with
rohan
like
roman
gupta,
yeah
yeah
yeah,
okay
yeah
put
that
on
there
yeah,
that's
cool
I'll,
be
hoping
for
them
and
rooting
for
them.
Even
if
you're
not
sebastian.
A
Yeah,
all
right
and
so
blaine
you
wanted
to
talk
about
some
of
the
design
doc
stuff
here,
get
some
feedback.
D
D
If
there
is
a
ceph
object,
store,
it's
possible
to
delete
the
seth
cluster
itself
and
leave
the
ceph
object,
store
sort
of
orphaned
without
underlying
storage,
and
so
we've
been
talking
about
kind
of
codifying
the
dependencies
that
exist
between
rooksef's
custom
resources
to
to
make
it
so
that,
if
a,
if
a
resource
that
is
like
dependent
on
another
resource
exists,
then
we
would
block
deletion
of
the
other
resource
so
kind
of
at
the
most
simple.
We
should
not
be
deleting
the
subcluster.
D
If
there
are
any
sort
of
you
know,
resources
that
are
referencing
it
in
the
same
name.
Space
is
kind
of
like
the
easy
metric,
for,
I
just
say,
does
this
exist,
but
this
document
outlines
the
other
dependency
relationships
that
can
exist
and
proposes
to
to
implement
a
like
kind
of
safety
check
for
them.
D
D
D
C
A
Maybe
that's
yeah,
maybe
that's
not
true,
sorry
yeah,
because
you
can
update
it
to
remove
the
finalizer
when
you're
done
with
the
deletion.
So
that's
true
yeah,
maybe
status
updates
or
maybe
not,
but
I
think
you
could
do
an
update
on
that
object.
Hopefully-
and
I
think
a
general
blame
that
that
that
part
definitely
makes
a
lot
of
sense.
You
know
for
surfacing
in
a
easily
user
discoverable
way,
what's
blocking
the
deletion
of
the
object,
so
we
can
go
and
make
any
create
updates
there.
A
I
would
consider
it
events
as
well
for
that,
in
addition
to
the
status
conditions,
events
all
the
objects
you
know,
control
describe
shows
what
it's
doing
or
why
it's
blocked.
This
can
be
helpful
as
well
too.
B
Could
we
somehow
integrate
with
admission
controllers
so
that
we
could
effectively
deny
requests
and
also
output
a
reason
why,
even
though
the
admission
control
won't
always
be
there,
but
still,
I
think
it's
also
the
good
interface
to
catch
things
like
this
and
yeah.
I
don't
know
we
might
have
to.
I
guess,
look
deeper
into
it,
but
that's
an
option.
Yeah,
maybe
look
also
into
it.
D
I
yeah-
I
guess,
just
to
to
to
phrase
that
in
my
own
understanding,
it
should
be
possible
to,
in
the
admission
controller,
look
at
like
what
is
like,
if
you're
requesting
to
delete
something.
We
should
be
able
to
see
okay,
the
user
requested
to
delete
this.
We
can
look
at
if
any
dependencies
exist
and
reject
that
deletion.
D
D
I
think
the
the
things
that
I
have
outlined
in
the
document
there's
nothing
that
really
specifically
requires
like
the
operator
to
be
doing
the
checking
it's
just
looking
at
resources,
I'm
I'm
not
sure
if
an
admission
controller
can
block
if
the
user
wants
to
delete
something,
but
I
think
that's
definitely
something
we
can
like
add
to
this
design
as
like
further
research
and
something
that
can
be
added
on
later
as
well,
and
I
can
certainly
try
to
like
implement
the
code
in
such
a
way
that
the
the
like
dependency
checking
can
be
called
from
another
application
in
a
in
another
place.
A
It
does
that's
definitely
interesting,
because
you
know
you,
I
commonly
you
come
in
here
about
emission
controllers,
like
the
validating
emission
controller
being
used
to
you
know,
reject
an
operation
like
create.
I
didn't
I
hadn't
thought
about
it,
using
it
from
delete,
so
it's
actually
a
pretty
interesting
idea
sub
and
that's
that's
normally.
The
best
user
experience
you
can
get
as
well,
too
is
immediate
feedback
as
opposed
to
asynchronous
feedback,
so
that
if
that
works,
that's
pretty
cool.
I
like
that.
C
C
Yeah,
I
mean
that's
right,
so
I'm
curious
if
it
works
too.
I
just
haven't
seen
that
pattern
for
deletion
for
other
resources.
D
D
This
yeah-
I
guess
that
is
also
a
good
point,
one
of
the
things
that
I've
been
kind
of
thinking
that
is
nice
about
this
is
it
does
also,
if
you
so,
if
you
just
have
like
one
huge
file
or
I
guess
it
doesn't
matter
if
it's
one
huge
file,
but
in
in
my
imagination
it's
one
huge
file.
That
is
just
all
of
your
manifests
for
your
cluster
and
you
just
delete
it.
Then
it
kind
of
forces
things
to
delete
in
the
order
they
need
to
delete
based
on
like
who
is
using
what.
D
B
D
Yeah
I
yeah,
I
think
my
my
inclination
is
to
add
that,
as
a
like,
like
further
discussion
topic
on
the
design
and
then
kind
of
handle
that
in
another.
B
Yeah,
I
don't
know
just
something
to
keep
somewhere
like
back
of
our
minds.
I.