►
From YouTube: 2020-05-19 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
Okay,
the
recording
is
started,
and
this
is
the
may
19th
2020
rook
community
meeting
and
we'll
start
with
our
milestone
checkups.
As
always
so
1.2.
We
don't
have
any
plans
still
or
currently
for
a
1.2,
another
1.2
patch
for
the
lease.
So
it's
probably
nothing
really
worth
talking
about
on
this
board.
Is
there
yeah?
I.
B
Didn't
look
at
the
board
there's
there
was
the
one
issue
about
vulnerabilities
in
the
base
image
the
base
step
image,
but
that's
yeah,
even
beyond
ceph's
control,
it's
just
in
the
base
centos.
I
think
we'll
wait
for
that
before
we
worry
about
a
patch
release
there.
That
sounds.
B
Yeah
I
made
it
past
that
board
just
before
this
meeting
so
relatively
up
to
date.
There
are
a
couple
more
things
I
want
to
review
and
get
in
potentially
that
that
first
of
in
the
in
review
column,
53
42,
it's
just
been
open
for
a
while.
So
I
need
to
get
final
review
for
that
one
and
blaine.
I
think
you
were
on
that
one
as
pending
approval.
B
And
otherwise,
I
think
yeah,
it's
just
kind
of
we're
ready
to
do
the
next
batch
release
again,
nothing,
I
think
super
urgent,
but
we've
got
a
bunch
of
fixes
in
so
it's
about
time.
B
A
Hey
do
we
have
to
do
do
we
have
a
process,
if
you
can
remind
me
around
updating
like
what
we
have
an
operator
hub
by
the
way?
Do
we
have?
Is
that
a
manual
thing,
or
is
that
all
auto
automatic.
C
Yeah,
so
it
is
like
half
manual
have
well,
I
we
have
a
script
to
generate
the
new
csv
based
on
the
branch
we're
in
and
there
is
small
adjustments
to
do,
and
I
just
keep
forgetting
and
lacking
the
time
to
reflect
the
new
version.
C
B
C
I
think
I've
seen
someone
wondering
when
this
will
be
merged.
Apparently
at
least
one
person
needed
it,
but
I
I
believe
they
they
found
their
ways
around
it.
So
it
doesn't
look
that
urgent.
A
Cool
yeah,
that
was,
I
don't,
think,
it's
critical
to
have
a
fully
automated
process
for
it,
but
that
was
something
that
was
just
on
my
mind
of
you
know,
do
when
we
do
releases,
if
that
was
something
that
was
getting
updated
or
not,
because
it
had
slipped
my
mind
until
just
now.
B
B
A
You're
supposed
to
do
one
operator
per
only
update
one
operator
at
hpr
right
right.
I
think
that's
part
of
the
guidelines
that
I
saw
yep,
okay,
cool
cool
anything
else
on
1.3,
not
four
patch
release.
B
Not
so
much
yeah,
I
think
today
just
plan
on
that,
unless
I
need
a
little
longer.
B
Move
up
there
one
more
comment.
Sorry
if,
but
if
there
are
issues
that
we
need
to
get
into
patch
releases,
just
a
note
to
everyone,
please
make
sure
they're
on
the
1.3
project
board,
so
we
can
track
them
there.
This
board
here,
yes,
that
one
you
had
there
so
by
and
by
default,
when
you
assign
the
github
issue
to
1.3
to
the
project,
it
will
show
up
in
a
blocking
release
column
by
default
until
it's
moved
out
of
that
column.
B
C
A
Good
okay,
so
we
can
move
down
to
the
community
topics
section.
So
the
cncf
graduation.
We
did
finish
the
due
diligence
documents
and
I
think
the
last
thing
we
did
there
was
sit.
You
know
notify
aaron
inside
that
we
had
done
a
full
update
of
all
the
sections
and
I
don't
think
we
got
any
feedback
from
that.
I
think
we're
looking
for
a
green
light
to
say:
hey.
A
Yes,
this
is
what
the
sig
is
looking
for
and
then
we
can
officially
add
it
to
the
pr
that
links
out
to
it
and
then
start
the
public
comment
period.
I
didn't
see
anything
back
from
soldering.
Did
you
travis?
I
didn't.
B
A
Okay,
okay,
so
then
to
the
next
so
yeah.
We
need
to
get
an
understand,
a
collective
understanding
with
us
and
the
sig
that
the
due
diligence
document
is
sufficient
and
the
sig
can,
you
know,
approve
that
and
then
then
we
will
put
it
on
the
pr
and
we'll
start
the
public
comment
period,
because
at
that
point
we
will
have
all
of
the
graduation
items,
including
the
surprise
ones
tackled.
So
then
we
can
move
through
the
public
comment
period.
A
Yeah,
that's
fair!
That's
fair!
Okay!
So
we'll
follow
up
on
that.
Excuse
me!
So
the
google
summer
of
code
ahmad
has
started
in
the
community
bonding
period
with
ashish
and
rohan
are,
and
we
are
mentored
mentoring
him.
So
he
started
doing
some
bug,
fixes
and
looking
into
some
stuff,
and
we
have
our
first
sync
up
meeting
with
ahmad
and
the
mentors
tomorrow
on
wednesday,
ahmad
you're.
I
see
that
you're
on
the
call
here.
Do
you
want
to
mention
any
of
the
specific
things
you've
been
working
on
recently.
A
And
I
saw
that
the
original
author
or
the
person
who
opened
the
issue
for
a
fully
qualified
domain
name
in
nfs.
They
they
read
your
your
analysis
of
it
and
then
they
close
the
issue
too
so
that
one's
closed
out
now,
so
that's
cool,
yeah
cool
and
then
yes,
we'll
have
our
sync
up
meeting
tomorrow
on
wednesday
and
that'll
be
fun
a
conversation.
B
Little
jenkins
poor
little
jenkins,
yeah,
and
so
this
week
yeah
this
week
we
had
some
updates
to
jenkins,
which
was
good.
Let's
see,
did
you
do
those
updates,
so
adam
adam
he's
from
our
red
hat
team
yeah.
He
made
some
updates
this
week.
He
updated
some
plugins
and
actually
for
the
first
time
in
a
long
time,
the
jenkins
ui
actually
looks
a
little
different.
B
B
I'm
assuming
so
actually
I
didn't
talk
much
about
it,
but
the
yeah.
I
think
we're
already
pruning
old
prs,
since
we
don't
need
the
builds
after
they
merge
pretty
much
so,
but
the
master
I
mean
we've
got
all
master
builds
which
there's
about
2
000
of
them
and
then
release
branches
have
like
150
builds
each
and
so
is
there
any
reason
not
to
prune,
I
guess
the
master
builds.
B
You
know
we're
not
going
to
delete
them
from
the
artifacts
from
docker
hub
and
whatever
it's
just
about
pruning.
What's
on
jenkins
right,
and
so
from
my
perspective
it
doesn't
seem
like
there's
anything
we
really
need
from
the
master
builds.
If
we
keep
like
the
last
hundred
just
to
troubleshoot
logs,
but
we
don't.
I
never
go
past.
You
know
the
last
10
builds
personally
to
look
at
the
logs.
A
Yeah
I
mean
the
dog
tried
to
bite
a
cat
around
here.
That's
not
good,
you
know,
there's
so
the
you
know
we
have
an
s3
bucket
that
the
artifacts
get
uploaded
to
you
know.
So.
We've
got
a
helm
s3
bucket
for
the
home
chart.
We've
got
a
like
a
binary
artifacts
like
a
you,
know,
tar
tarball,
sort
of
thing,
that's
in
another
bucket
and
we've
got
docker
hub
as
well.
A
So
we
have,
you
know
a
number
of
distributed
places
full
of
our
artifacts,
but
then
on
jenkins
itself
is
the
is
the
main
value
for
that.
You
think
like
retrospective,
going
back
and
looking
at
the
build
logs
to
see
like
what
the
build
process
did
or
you
know
if
a
step
that
was
succeeding
then
and
now
failing,
we
can
go
and
look
them
back
and
see
what
it
looked
like
when
it
was
succeeding.
Is
that
the
main
value.
A
B
Yeah
artifacts
that
are
already
preserved,
like
you
said,
so
it's
really
just
the
build
logs
and
seeing
that
history
that
we
have
by
turning
those
off
which
yeah
I
just
don't
think
anybody
really
has
a
need
to
go
past.
The
last
100
master
builds
the
release,
build,
I
figure,
let's
try
and
keep
those
for
now,
but
if
we
can
trim
the
master
builds
to
start
with
them.
A
Yeah,
I
think
the
idea
how
that
does
that's
totally
reasonable
if
it's
like
2k
right
now,
trimming
down
to
100
seems
entirely
reasonable.
So
I'm
fine
with
that
does
is
the
chicken's
ui
have
good
configuration
for
this,
like
it,
the
you
know,
auto,
like
configurable
pruning
that
it
keeps
up
with
and
stuff
or
the
batteries.
B
I'm
not
sure
what
the
configuration
allows
for,
but
it
sounded
like
you
could
keep
the
last
n
number
of
builds
for
a
branch
that
was
my
understanding
so
I'll
follow
up
with
adam.
A
Yeah,
if
adam
can
handle
that,
that
sounds
great.
I
I
just
so.
I
just
went
to
releases.rook.io.
You
know,
which
is
supposed
to
be
a
dns.
A
You
know
front
for
the
underlying
releases
bucket
it
that
didn't
load.
I
wonder
if
the
dns
record
is
still
pointing
at
the
right
bucket
and
such
have.
You
been
there
in
a
while.
B
A
Yeah
I
would
like
to
yeah.
Let
me
let
me
take
a
okay,
so
you
have
access
to
the
bucket
yeah.
Let's
see.
Okay,
so
adam
will
configure
jenkins
j
coins
jenkins
to
purse,
to
keep
less
master,
builds
100
and
jared
look
into
releases
dot,
rook,
dot,
io
not
connecting
okay,
sounds
good
and
yeah
and
if
there's
any
manual
cleanup
that
adam
needs
to
do
because,
like
if
you
go
and
say
okay
jenkins
now
from
now
on,
I
only
want
you
to
keep
the
last
hundred.
A
If
jenkins
doesn't
in
response,
go-
and
you
know
prune
ones
beyond
that,
then
you
know
adam.
I
believe
he
should
have
access
to
like
connect
and
like
if
ssh
or
whatever
in
in
you
know,
rm
fr
whatever
if
he
needs
to
so
he's
more
than
welcome
to
clean
up
appropriately.
B
A
B
A
B
Of
a
just
a
general
community
manager,
not
oh
okay,
I'm
not
sure
if
he's
assigned
to
a
specific
project
but
kind
of
oversees
it.
I
think-
and
I
shared
the
report
I
think
in
the
maintainers
slack
channel-
or
if
I
didn't
I
meant
to
do.
I
don't
remember
seeing
that
as
a
couple
weeks
ago.
Those
and
my
memory
is
bad.
So,
let's
see,
did
I
yeah
it's
a
pdf
shared
may
6th,
okay,
okay,
it's
yeah!
It's
an
interesting
report
to
and-
and
the
conclusion
doesn't
surprise
me
at
all.
B
Basically
the
recommendation
is
hey
yeah.
We
should
vlog
more
often,
and
we
should
do
more
with
the
twitter
and
kind
of
do
more
public
relations
type
of
activity
right
now
we're
really
engineering
driven
and
that's
great.
We
update
the
documentation
when
the
code
changes
and
he
said
that's
good.
The
yeah,
just
as
far
as
what
we
can
do
to
really
build
up
more
community
or
visibility
into
what's
happening
is
just
is
really
the
conclusion,
and
so
he
said
that
as
a
follow-up.
B
They
have
an
intern
joining
next
month
or
something
where
he
thinks
they
could
have
them
work
with
us
and
to
give
us
ideas
or
almost
kind
of
do
some
training
for
us
or
anyway,
help
us
in
this
regard.
So
that's
fine
will
be
a
positive
thing.
B
B
A
Cool
that
sounds
good,
I
mean,
and
then
you
know,
I
think
the
graduation
like
there's
a
big
marketing
push
and
a
bunch
of
noise
that
is
going
to
be
made
around
that.
You
know
that
up
on
spending
on
doing
you
know
pushing
on
on
that
as
well,
for
in
on
behalf
of
rook,
so
like
mocha
is,
is
gonna,
be
you
know,
driving
a
lot
of
things
around
that
and
she'll
rope
in
the
appropriate
people
as
well
for
sure.
B
Yeah
and
hopefully
that's
soon-
and
I
guess
to
keep
the
momentum
going,
you
know,
I
think,
is
something
to
keep
on
the
agenda
as
a
regular
item
for
this
meeting
would
be
hey.
Let's
talk
about
what
blog
entries
or
blog
posts
would
be
good
to
write
and
who's
going
to
drive
them
and
anyways
it'll
be
a
good,
recurring
topic
for
this
meeting
too.
I
think
yep.
A
Cool
okay
and
then
I
had
a
topic
here
for
mailing
lists
just
to
confirm
with
folks.
So
you
know
we
moved
our
mailing
lists
over
to
the
the
ones
hosted
by
the
cncf.
It
looks
like
we
get
more
a
little
bit
more
spam
there
than
we
were
when
they're
hosted
in
google
groups.
I
think
google
groups
does
like
more
automatic
spam
detection
and
filtering
and
stuff
the
cncf
lists.
A
Yes,
I
mean
every
link
that
comes
in
there.
I
am
very
interested
in
their
you
know
their
syrian
grandfather
and
their
seo.
You
know
website
improvements
and
you
know
cheap
hardware,
all
sorts
of
stuff,
I'm
very
interested
in
the
products
they're
selling,
but
that's
about
jared,
not
about
rook
the
project,
okay,
so
yeah.
So
my
my
like
just
I
don't
know
if
there's
more
automation
that
can
be
put
in
there.
A
Maybe
it
is
a
manual
thing,
but
I
just
wanted
to
confirm
with
everybody
that
the
way
I'm
treating
it
is
is
pretty
ban
heavy
that
I
don't
I
don't
that
you
the
options
you
get
for
moderating
the
list
is
you
know
to
reject
it?
You
know,
reject
it
with
a
notification,
or
you
know,
reject
and
ban
that
sender
that
they
send
some
some
junk
spam
to
our
lists.
They
are
not
allowed
to
send
anything
again,
they're
banned.
Does
anybody
have
any
problems
with
that
ban
heavy
policy
for
spamming
our
lists.
A
Take
I
take
pleasure
in
doing
that
when,
when
I
get
like
an
email
saying,
there's
a
you
know
a
pending
message
to
to
moderator
to
verify,
and
I
see
that
at
some
you
know
nonsense
spam.
I
very
much
enjoyed
that
band
button.
B
At
the
same
time,
alex
brought
up
a
good
question
in
slack
where
you
know,
if
someone
has
a
support
question
you
know,
should
we
redirect
them
to
to
slack
or
whatnot,
because
it's
not
really
for
support
purposes
it's,
but
I
think
on
our
the
link
we
have
on
our
home
page
for
rook
we're
not
really
clear
about
what
the
email
is
supposed
to
be
used
for.
So
maybe
a
clarification
on.
A
That
yeah
yeah
I
mean
and
possibly
possibly
clarification,
but
it's
really
just
kind
of
a
you
know.
First
point
of
you
know:
first
touch
point
first,
point
of
contact.
You
know
somebody
wants
to
send
an
email
for
just
you
know,
get
in
touch
with
us
and
we
can
kind
of
redirect
them
to
the
right
place.
You
know
or
if
that's
probably
going
to
be
slack,
but
you
know
give
them
like
a
little
bit
of
a
response
or
an
answer
to
kind
of
get
them
going
and
then
nudge
them
along
to
the
communities.
E
It's
more
it's
more
in
the
end
about
if
we
do
well,
if
we
basically
do
support
of
it
or
if,
as
trivia
mentioned
up
basically
just
say,
have
you
checked
out
disney's,
please
use
slack
or
something
for
support.
Basically,
it's
more
about.
C
A
I
think
that
I
think
we
put
the
all
maintainers
on
the
mailing
lists
and
every
every
single
one
of
them
has
gotten
a
response
or
okay
or
or
moderated
in
the
appropriate
way.
So
it's
like
alex
and
travis
have
responded
with
some
actual
content
and
I've
been
moderated
moderating
heavily
okay,
so
they're
getting
the
attention
that
they
need
I'll
say
that
yeah.
C
C
A
Yeah
we've
had
the
info
mailing
list
for,
like
you
know,
since
the
beginning
of
the
project,
like
three
years
now
so
I'd
be
hesitant
to
drop
that
you
know,
I
think
we
can
like.
If
people
need
support,
then
we'll
you
know
the
policy
we're
discussing
here.
Is
that
we'll
direct
them
towards
slack
for
that,
but
the
security
list?
We
have
to
keep
it
at
the
security
list,
no
matter
what
that's.
C
I
think
I
think
it's
fine
yeah,
but
I
think
info
should
we
should
should
really
be
restricted
to
info.
Let's
say
someone
from
a
blog
or
a
website
is
trying
to
reach
out
for
like
interviewing
maintainers.
Then
I
think
it's.
The
info
is
the
good
endpoint
for
this,
and
that's
why
we
should
really
limit
that,
like
making
clear
you
won't
be
getting
any
assistance
via
this
channel,
please
either
open
an
issue
or
go
on
slack
so
that
we
can
help
you.
E
Yeah,
it
was
basically
a
request
which
you
basically
just
described
with
someone
asking
for
well
a
bit
of
conceptual
information
on
rook,
for
example,
which
would
perfectly
fit
into
the
hey
as
the
email
implies.
I
want
some
info
basically
or
have
some
requests
to
the
maintainers,
but.