►
From YouTube: 2020-09-22 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
september
22nd
2020
rook
community
meeting.
Let's
go
ahead
and
start
with
our
upcoming
milestones
1.3.
We
do
not
have
any
planned
patch
releases
back
for
that,
but
we
are
anticipating
a
1.4
patch
release
coming
up
targeting
next
week
chuck.
Do
you
want
to
talk
about
some
of
the
important
issues
that
would
be
included
in
that
patch
release
or
some
of
the
status
there.
B
Was
it
a
week
ago
now,
last
tuesday
time
flies,
and
that
was
just
the
weekend
after
the
one
for
143,
where
we
had
a
there
was
a
blocking
issue
for
some
clusters
to
upgrade
that
were
based
on
pvcs.
B
Osds
were
not
or
sorry
mons
we're
getting
stock
upgrading,
so
we
got
that
fixed
out,
so
the
I
don't
know
of
any
urgent
fixes
to
get
out.
So
I
I
put
that
data
on
there
potentially
for
next
thursday
to
get
the
5
release
out,
I'm
blanking
right
now
and
what
all's
already
in
the
release
branch
that
would
be
included
with
that.
But
I
could
do
it
this
week
if
necessary,
but
I
think
next
week
should
be
fine.
From
my
perspective,.
A
B
So
I
moved
that
one
over
that
was
the
blocking
issue
from
1.444
that
we
got
out
otherwise
yep
just
standard
fixes
going
on.
A
All
right
cool,
so
no
other
particular
issues
to
dive
into
here
on
the
board
for
1.104.pat
or
1.4
patch
release
it
for
anybody
else.
A
Is
that
this
one's
closed
here
travis
is
this:
what
is
the
resolution
of
this.
A
Nice,
okay,
all
right
so
back
to
the
agenda.
Excuse
me
the
document
then.
So
we
are,
you
know
working
towards
the
next
major
release
of
1.5
for
kubecon
north
america,
which
is
mid-november
november.
17Th
is
when
that
starts
here.
We'd
want
to
do
the
release,
probably
the
week
before
that,
so
that
it's
out
there
we
can
have
blog
posts,
etc,
and
things
like
that,
the
I
had
another
point
on
1.5.
What
was
it?
A
Oh,
yeah
travis
you
merged
the
road
map
updates
for
1.5,
so
kind
of
the
upcoming
features
or
things
that
kind
of
the
high
level
themes,
etc.
That
we
plan
to
include
in
1.5
are
now
reflected
in
the
roadmap.
That's
in
master
branch!
A
That's
right,
yep,
any
any
any
like
issues
to
talk
to
for,
like
a
board
view
there
or.
B
Yeah,
not
nothing,
I
can
think
of
right
now.
I
think
I'll
just
put
a
date
here
targeting
november
10th,
for
the
release
right.
B
A
B
There
are
some
features
there,
but
we
need
they're
still
we're
about
to
transition.
I
feel
like
from
focusing
on
1.4
patches
to
kind
of
1.5
features,
so
we'll
have
more
coming
on
the
1.5
project
cool.
I.
B
B
A
Yeah,
all
of
them
are
done
in
master,
except
for
the
disc
quota.
Oh
there's
that
one
right
there
yeah.
A
Okay,
all
right,
then,
if
that's
everything
for
our
milestones,
then
we
can
proceed
on
to
the
community
section.
A
So
graduation
is
still
still
ongoing.
We're
still
one
vote
shorts.
We
have
no
negative
votes,
which
is
a
good
thing,
but
we
are
one
vote
short
still,
so
we
still
need
one
more
person
to
come
through
and
render
their
judgments
so
to
speak.
The
the
atmosphere
from
the
cncf,
including
their
marketing
department
as
well,
is
that
it's
very,
very
positive
outlook.
People
we've,
you
know
proceeded
with
like
press
release
stuff
and
you
know,
write
ups
and
everything.
A
So
it
seems,
like
the
expectation,
is
there,
but
the
votes
are
not
so
we
will,
if
they've
been
instructed
to
continue
sitting
sitting
on
a
holding
battery.
I
think,
like
obviously
before
we
if,
as
we
get
closer
to
kubecon
like
there's,
there's
gonna,
be
a
definite
push
here.
That
either
is
expected
for
the
toc
to
go
ahead
and
move
things
through
the
pipeline,
but
we
should
make
more
noise
as
well
to
ourselves
that
you
know
hey.
A
We
were
targeting
kubecon
march
for
this,
so
q
con
in
november
is
something
that
we
would
really
appreciate.
So
I
think
that's
not
unreasonable
to
make
more
noise
about
that.
A
Yeah,
absolutely
okay,
alex
you
have
a
topic
here
for
new
ticket
labels.
C
Yes,
I
would
like
to
more
or
less
ask
if
anyone
finds,
if
that
would
be
useful,
to
have
two
new
labels
regarding
well,
especially
bugs,
if
basically
well
they're,
confirmed
to
be
an
actual
bug
or
well
being
unconfirmed
that
they're
not
yet
confirmed
to
be
a
bug
or
something.
At
least
it
was
my
idea
behind
it.
So
are
you
saying
it's.
C
Of
it's
basically
what
the
words
say
like
if
it's
a
like,
if
you
know,
if
I
create
a
bug,
an
issue
as
a
back
on
github
and
in
the
end,
it's
oh,
it's
not
a
bug.
It's
you
know
something
else,
but
it's
kind
of
like
a
bit
of
triaging
to
have
the
bugs,
which
have
been
confirmed
to
be
an
actual
bug
or
you
know
not.
C
Maybe
I
don't
know
wrong
like
some
something
wrong
in
the
south,
classic
yaml
or
something
of
the
person,
but
we
have
kind
of
a
like
a
way
to
tell
those
apart.
Certainly.
A
And
alex
what
is
that
help
me
understand
kind
of
the
flow
here
or
what
the
the
decisions
would
be
made
or
actions
that
would
be
taken
based
on
this
information
would
is
that
to
help
identify
like
issues
that
we
like,
we
know
our
bugs
and
that
we
could
put
engineering
resources
on
fixing
them
or
prioritizing
them
or
is
it
about?
Is
it
more
about
identifying
issues
that
we
aren't
sure
of
yet
so
we
need
to
you,
know,
take
more
looks
and
then
into
them
to
understand.
C
You
it's
a
mix,
it's
a
mix
of
both
worlds.
For
the
first
part,
it's
a
let's
with
that,
you
know
being
able
to
just
select
after
the
label
confirmed
to
see.
C
Oh,
those
bugs
have
been
confirmed
like
with
you
know,
there's
reproducible
commands
and
all
that
that
we
can
easily
you
know,
hopefully
get
them
fixed,
so
we
can
focus
resources
efficiently
there
on
the
tasks
which
have
been
confirmed
well,
especially
also
even
on
the
ones
that
have
not
confirmed,
have
not
yet
been
confirmed
to
look
into
if
they're
really
a
bug
or
if
you
know,
if
it's
something
else,
maybe
but
also
on
the
hand
of
planning
that
we're
able
to
more
or
less
plan
there
for
the
releases
as
well.
B
Another
idea
is
that
if
we
use
the
project
board
to
really
track
what
we
want
to
prioritize
for
the
next
release
right,
you
know
sometimes,
when
I'm
looking
at
a
bug-
and
I
say
oh
yeah-
I
really
want
that
fixed
to
the
next
release.
Well,
then,
I'll
just
immediately
put
it
in
the
project
board
and
say:
well,
let's
get
this
in
the
1.4
project,
make
sure
it's
back
ported
for
the
next
patch
release,
or
so
that's
kind
of
how
I've
been
prioritizing
at
least
and
saying.
C
B
C
At
least
well,
my
idea,
it's
good
to
get
feedback
on
that,
it's
more
or
less,
not
necessarily
on
the
on
the
prioritizing
part
there,
but
more
on
the
like.
It
may
seem
weird,
but
there's
probably
a
few
issues
which
well,
you
know,
are
not
like
it's
like
it's
not
a
rich
priority
there.
It's
more
about.
C
You
know
new
bug,
tickets,
someone
investigates
and
says
oh
yeah.
This
is
this
is
an
actual
bug
and
basically
puts
like
a
confirmed,
labor
or
something
which
probably
for
most
parks
yeah,
would
result
in
them
just
being
added
to
the
project
board.
So
yeah,
we
kind
of
have
that
with
that
with,
when
we
would,
when
we
were
using
the
project
board
with
that.
A
Is
it
would
it
is
one
possibility
here
alex
to
have
some
automation
that,
like
for
any
new
bug
that
is
opened
or
a
new
issue,
that's
open
that
it
automatically
gets
an
unconfirmed
label
on
it
and
then,
if
you,
yes,
that
would
be
possible.
I
see
and
then,
if
you
somebody
looks
at
it,
they
can
remove
the
unconfirmed
label
and
like
it's
implicit,
that
if
it,
if
an
issue
doesn't
have
that
unconfirmed
label,
then
it's.
C
We
could
have
it
like
this
as
well.
Yeah,
I
said
like
the
idea
is
that
we
have
a
good
amount
of
tickets
open
and
looking
back
at
a
bunch
of
them.
Well
the
bullet
it
either.
Some
just
don't
really
get
any
attention
because
of
resources,
but
also
you
know
if
there's
like
an
issue
looking
at
the
garbage
collection
issue
with
csi
driver,
and
so
on
that
you
know
walking
through
the
steps
the
person
has
provided
to
see
if
it's
reproducible
and
all
that
it
would
be
a
way.
C
You
know,
then,
as
I'd
like
to
focus
the
resources
there,
and
if
I
create
an
issue,
we
as
a
team
can
walk
through
it
and
see
like
oh
yeah,
the
steps
to
reproduce
now
when
and
we
can
look
into
well,
if
it's
even
really
reproducible
and
based
on
that
see.
Oh
yeah,
it's
actually
a
bug
and
then
we'll
fix
it
or
you
know,
try
to
get
the
person
to
add
more
information
and
so
on.
If
we
would
be
able
to
see
if
it's
basically
a
confirmed
bug
or
if
it's
an
unconfirmed
box
so
to
say.
B
C
Yes,
it's
more
or
less
like
a
concept
in
the
end
that
came
to
my
mind
there
that
there's
like
especially
like
with
tickets
being
closed
after
about
time
by
the
well
inactivity,
bots
or
whatever
it's
called
some
tickets
yeah
the
sailboat
yeah
exactly
like
some
tickets,
then,
like
oh
yeah,
there
was
something
you
know
like
now:
it's
like
oh
yeah.
C
We,
like
I
totally
missed
this
ticket
or
something
and
having
like
a
confirmed
level,
maybe
more
or
less
like,
makes
it
well
a
bit
more
easy
to
spot
the
tasks
which
are
really
like
yep.
We
confirm
this
is
an
issue
and
we
need
to
work
on
this
quick
or
more
or
less
like
then,
with
the
prioritizing
in
the
project
board
per
release,
if
like,
if
there's
even
a
fix
possible
for
like
1.3,
1.4
and
so
on,
and
so
on,.
A
C
The
same
way
for
the
project
part
like
I
would
say
like
we,
you
know
we
should
we.
We
should
do
that
all
the
time.
Well,
we
should
always
add
the
issue
if
we
know
that
it's
something
confirmed
in
the
end
to
the
project
board
as
well,
but
yeah.
B
A
C
Got
a
bunch
of
emails
over
the
weekend
as
well
and
saw
some
issues
with
like
oh
yeah,
well,
yeah,
something
confirmed
so
to
say
that
we
should
act
on
as
a
bug
or
something
or
at
least
like
a
documentation
change,
but
it
you
know
just
got
flooded
by
the
mass
of
well
things
going
on.
So
it's
it's
kind
of
a
good
thing.
At
least
from
this
perspective,.
A
Yeah
yeah
cool,
okay,
so
next
topic
that
so
we
got
a
inbound
message
about
from
a
security
researcher,
about
our
jenkins
instance
being
publicly
accessible
which,
to
my
understanding,
is,
is
by
design
right.
We
want
the
jenkins
instance
to
be
available
for
people
to
go,
see
the
status
of
builds
for
people
to
be
able
to.
You
know
like
see
reasons.
Why
builds
failed
et
cetera?
We
have.
C
Are
you
sure
that
it
was
about
jenkins
being
publicly
available?
As
far
as
I
understood
the
mail?
It
is
about
the
jenkins?
Well,
the
jenga
is
being
publicly
available,
but
there
is
a
security
like
a
plugin
having
a
security
issue
or
something
isn't
that
what.
B
A
Well,
did
you
see
that
that
was
my
response,
saying
that
that
that
we
did
like
so
this
is
to
bring
this
up
so
to
get
confirmation
from
everybody
that
you
agree
with
my
assessment
that,
yes,
it's
intentionally
publicly
accessible,
but
we
use
the
you
know:
get
out
of
authentication
plugins
to
lock
it
down,
for
people
being
able
to
do
have
any
right
access
or
be
able
to.
You
know,
change
configuration
or
get
access
to
security
settings
or
anything
like
that.
So
it's
my
understanding
and
then
any
sensitive
information
is
obfuscated
in
build
output.
A
So
my
understanding
is,
as
we've
had
this
configuration
going
for
a
long
time
that
this
is
perfectly
by
design
that
this
is.
You
know
something
that
we've
actually
desired
for
the
community
to
be
able
to
accept
access
jenkins,
and
so
that's
what
I
responded
to
the
security
researcher
with
and
then
I
think
he
replied
only
to
me
maybe
saying
that,
oh
okay
I'll
let
you
know
if
I
find
any
vulnerabilities
after
that,
so
it
seemed
like
that
was
okay,
oh.
B
C
There
I
thought
it
was
about
like
a
plug-in
or
something
as
jenkins,
previously
wasn't
in
such
a
maintained
state
as
it
is
right
now
so
well,
there's
also
again
a
thanks
to
adam
for
taking
care
of
the
premier.
The
permissions
for
the
jenkins.
B
C
B
C
A
Okay,
cool.
That
sounds
good
thanks
for
confirming
everybody
and
then
also,
I
noticed
too,
when,
through
that
interaction
with
the
inbound
security
message
that
our
not
all
of
our
mailing
lists,
since
we
migrated
to
the
cncf
mailing
lists,
not
all
of
them
excuse
me
will
include
the
sender
to
the
list
in
the
replies
like
it's.
I
think
it's
a
really
odd
design
choice
about
the
lists.
A
Email
lists
at
state.cncf.io
is
that
by
default,
like
you'll
hit
reply
at
all,
and
you
can't
include
the
person
who
emailed
the
list
in
the
first
place,
so
they
don't
see
replies
by
default,
which
doesn't
make
much
sense
to
me,
but
so
I
opened
up
a
service
desk
ticket
to
get
that
fixed
because
we
don't
have
access
to
fix
that.
So
that's
I
think
you
are
said
that
he's
going
to
be
fixing
that
he
might
may
have
already
done
that,
but
that
service
desk
ticket
is
open
for
that.
A
C
A
Okay,
cool,
okay,
then
roadmap,
any
any
other
updates
to
add
to
the
roadmap
that.
B
B
B
A
What
organization,
where
does
that?
Where
does
that
come
from?
Because
I
know
of
google
summer
of
code,
and
I
know
of
a
community
bridge
that
the
cncf
runs?
What
is
what
is
outreachy.
B
A
Why
would
we
use
that
instead
of
the
cncf's
community
bridge
program.
B
Community
bridge
yeah,
I
don't
know.
A
B
So
where
this
came
from
is
so
mike
perez
saying,
hey,
we've
got
funding
basically,
for
I
guess,
with
the
seth
with
seth
project
upstream
they've
used
outreachy
before
and
they
got
out
funding
for
two
interns
and
they
said
oh
we'll
get
one
for
staff
and
one
for
rook
and
yeah.
So
it
came
from
the
seph
side
and
just
getting
funding
for
one
extra
for
rook.
B
C
A
So
that's
that's
a
third
source,
then
a
funding.
That's
you
know,
because
google
summer
code
google
pays
for
that.
Cncf
community
bridge
cncf
pays
for
that
and
then
outreachy
it
sounds
like.
Is
that
a
big?
So
red
hat
is
doing
the
funding?
For
that
then
right.
B
A
Pretty
much
cool
so
so
it's
that's
three
independent
sources
of
funding
and
availability
for
more
new
members
of
the
community,
which
is
which
is.
C
A
Okay,
all
right
then
in
we
don't
have
any
listed
prs
listed
here.
So
you
know,
if
anybody
had
any
issues
or
pr's,
they
wanted
to
bring
up
and
now's
the
time.
A
And
otherwise,
then
I
guess
we
can
go
ahead
and
wrap
up
the
meeting
then
from
other
agenda
items.