►
From YouTube: 2020-02-25 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
has
started-
and
this
is
the
February
25th
2020
Brook
community
meeting
and
as
always,
we
will
start
with
the
latest
milestone
checkups,
so
we're
in
the
currently
running
patch
releases
for
1.2,
and
so
we
will
be
doing
a
1.2.5
patch
release
this
week.
Hopefully,
let's
go
ahead
and
take
a
look
at
the
project
board
and
get
some
more
details
about
that
Travis.
Do
you
want
to
talk
through
some
of
the
big,
the
important
issues
for
1.2.5
and
what
is
remaining
yep.
B
The
like
to
get
this
yes
I
driver,
cleanup
issue
fixed
at
least,
is
working
on
that
it
should
be
done
in
the
next
day
or
two
and
then
I
think
we'll
just
plan
on
the,
at
least
after
that.
Nothing's
really
been
burning,
though,
for
the
dot
5
release,
so
I
think
we're
getting
close
to
the
three
weeks
since
the
last
patch
released,
which
is
fine.
It's
just
sort
of
a
periodic
time
to
get
it
really
sent,
and
then
the
other
one
in
that
to
do
column,
I,
don't
know
that
it
was
urgent.
B
A
B
Yesterday
I
was
thinking,
oh
we're
getting
close
to
that
day.
We
better
start
putting
dates
down
next
to
what
we
want
to
do.
So
we
can
ship
on
time
so
feature.
Freeze,
I
was
thinking.
You
know.
Kind
of
end
of
the
week
has
worked
well
for
the
past
couple
releases,
so
Friday
March,
13th
kind
of
end
of
day.
We
would
potentially
create
the
beta
first
beta,
build,
which
creates
the
new
release
branch
and
allows
master
to
move
on
and
with
the
target
ship
date
of
approximately.
B
We
can
change
after
that
to
give
us
time
to
work
on
the
upgrade
guide
and
testing
and
final
bug
fixes
and
things
I
don't
feel
like.
We
have
a
lot
of
new
features
coming
in
hot
this
release,
so
I
don't
feel
like
it's
a
risky
sort
of
schedule,
but
are
there
any
thoughts
or
concerns
about
those
proposed
dates?.
A
A
A
A
B
A
B
A
B
A
B
A
Right
right
on
okay,
so
that's!
Let's
move
on
into
the
community
topics
section
and
the
first
one
we
have
here
on
the
list
is
for
the
graduation
process
with
the
CNCs.
So
since
the
last
Brook
community
meeting
here
two
weeks
ago,
we
did
our
first
initial
presentation
and
proposal
to
the
CNCs
storage
sig.
That
was
really
to
get
the
conversation
started
and
to
identify
any
of
the
gaps
or
obstacles
in
the
way.
A
So
he
is
going
to
sponsor
us
and
he
will
call
the
vote
with
the
technical
Oversight
Committee
when
the
time
comes
for
that.
So
the
next
step
here,
which
is
a
big
one,
is
tomorrow
morning
we
will
again
at
the
same
CN,
CF
storage,
sig,
Wednesday,
8:00
a.m.
we
at
Pacific
time.
We
will
do
our
formal
presentation
of
our
graduation
proposal
and
do
a
Q&A
session
for
due
diligence
with
the
storage
sig.
A
There
so
Travis
and
I
will
both
be
at
that
we
will
be
presenting
and
answering
the
questions
coming
from
the
sig,
so
that
will
be
fun
times
tomorrow
morning.
If
it's
an
open
meeting,
everyone
is
welcome
to
join
if
they
want
to
see
the
process
or
participate
and
answer
any
questions
too.
If
you
want
to
I,
have
a
link
here
in
the
agenda
documents
to
their
agenda
document
for
the
meeting
tomorrow
morning,.
D
A
A
Don't
don't
miss
it
Travis
sure,
counting
on
you,
but
I've
been
talking
about
it
for
weeks,
mm-hmm,
yes
and
then
the
just
a
quick
look
at
the
graduation
to-do
list.
We've
got
a
whole
bunch
of
things
crossed
out
here
because
we
finished
them.
A
couple
of
big
outstanding
things
is
that
Travis
is
finished.
Updating
the
steering
committee
and
governance,
updating
governance
updates,
Alex
and
I
have
approved
it
and
reviewed
it
pretty
thoroughly.
A
So
we
are
going
to
get
asam's
approval
as
well
today
before
before
we
head
into
the
presentation
tomorrow
morning,
and
so
we
can
merge
that
and
call
that
completed
as
well.
I've
gotten
all
the
production
testimonials
from
all
the
reproduction
users
that
answered
our
survey
so
I
have
those
integrated
into
the
slide
deck.
The
presentation
slide
deck
will
be
giving
buddy
to
add
that
information
to
the
updaters
excuse
me
adopters,
markdown
file
in
the
repo
and
then
I
have
a
draft
PR
for
the
official
proposal
to
the
COC
repo,
and
then
we
we
present
tomorrow.
A
B
A
Yeah,
it
would
be
good
to
get
a
hundred
percent
sign
off
on
that
one.
Since
it
it
is
governance
updates
and
maintainer
membership
update
and
everything
yeah
we
do.
We
do
already
have
the
votes
for
it.
That's
true,
okey,
so
graduation
stuff
super
exciting.
They
Travis
I
changed
in
the
graduation
proposal.
Here
I
changed
the
link
to
to
comment
only
it's
no
longer
an
editable
link.
So
if
you
need
to
edit
slides
I
can
add
you
as
a
you
know
a
specific
editor
to
it.
Would
you
need
to
need
editing,
stuff
stuff.
A
B
So
the
well
became
apparent
that
some
people
are
looking
at
old
blogs
to
install
work
instead
of
our
latest
documentation
and
they're.
Getting
hung
up
on
using
our
old
channels
that
we
used
for
helm
shards.
So
just
a
note
that
we
need
to
remove
those
channels
and
I
haven't
looked
yet
into
where
that
would
need
to
happen.
They
backed
off
and
what
it
would
take
to
delete
those
channels.
Or
were
these
like
buckets
an
s3
or
something
we
need
to
clean
up.
I!
Think
that's
what
it
is,
but
I.
B
Anyway,
so
well,
I
can
take
that
action.
They
clean
that
up
unless
somebody
else
feels
so
inclined
or
knows
where
those
already
that's
all
I,
don't
think,
there's
any
negative
effects
of
just
deleting
those
channels,
because
hopefully
people
will
see
they're
missing
and
then
go
look
for
a
new
documentation
and.
A
D
B
A
The
last
last
time,
I
talked
to
Keith.
That
was
I,
think
that
was
here
in
San
Diego
at
the
last
coop
con
got
that
we
had
a
conversation
there
too
I
think
I.
Think
the
biggest
thing
for
them
is
that
they
wanted
to
be
able
to
easily
use
some
of
the
more
advanced
operator
frameworks
like
operator
SDK
stuff,
which
we
do
have
examples
for
first
subset
of
some
of
the
stuff
operator
functionality.
A
D
B
I
guess
where
there's
no
engagement,
there's
this
kind
of
recruiting
thing:
do
we
remove
it
until
they're,
an
added
back
when
there
is
engagement,
the
and
that's
the
same
question
really
of
our
release
cycle?
Well,
if
there's
nothing
changed
for
a
storage
provider
in
a
release,
doesn't
really
make
sense
to
release
a
new
version
of
it.
One.
A
I
think
this
interesting
Travis
is
that,
from
our
you
know,
our
rookies
user
survey
that
we
were
doing
this
part
of
graduation
there.
There
are
folks
that
are
using
the
cockroach
support
already
don't
have
that
deployed
in
their
environments.
So
how
interesting
yeah
that's
good
to
know.
So
that's
definitely
something
that
for
me
that
you
know
at
least
makes
a
statement
of
it
doesn't
cost
us
anything
to
continue
supporting
it,
and
we
would
like
to
you
know,
potentially
keep
driving
that
conversation
around
increasing
the
engagement
or
the
ownership
from
the
cockroach
books.
B
A
C
Yes
can
I
hello
robbery
and
what
it's
just
that?
Well,
we
have
a
Python
client
for
Luke,
okay.
Basically,
this
is
automatically
generated
classes
and
what
I'm
wondering
if
this
repository
that
currently
is
in
in
the
self
organization
can
be
moved
to
the
to
the
rook
organization.
I
think
this
is
the
URL
and
basically
it's
just
a
generator
for
Python
classes,
using
the
to
want
to
use
the
local
CRT
say
in
Python.
B
Yeah,
thanks
for
bringing
that
up,
I
think
it's
yeah
on
that
PR
or
we've
had
a
period
where
was
discussed,
but
we
haven't
I,
don't
think
he
brought
it
up
here
in
the
meeting
before
so
the
Python
client
yeah.
We
need
it
for
the
Ceph
code
for
staff
manager,
but
Sebastian
Wagner
also
did
work
to
really
make
this
work
for
this
Python
client
generation
for
other
providers
to
I.
Think
you
got
a
working
graduate
fast
and
I.
B
C
B
C
Think
basically,
it
could
be
very
useful,
for
example,
for
the
v
money
in
models.
It
is
useful,
okay
and
I
think
that
it
it
could
be
useful
for
another
projects,
also,
okay,
but
the
right
place.
I
think
my
my
opinion
is
that
it
should
be
included
in
the
integral,
if
have
organization,
not
in
the
FF
organization
issues.
A
B
Yeah
Sebastian
Han
also
had
some
thoughts
on
this.
It's
I
think
where
we
left
it
off
was
that
well,
if
I
can
think
about
the
summary,
the
summary
is
well,
the
proposal
is
all
should
does
this
belong
in
rook
well,
yeah,
it
seems
like
it
kind
of
fits
kind
of
fits
this
pattern.
We've
got
the
NGO
client.
What
about
a
Python
client,
its
version
with
the
rook
repo,
but
then
it's
it
was
awkward.
I
think
said,
commented
that
oh
well,
we
just
got
go
in
the
repo.
Why
would
we
want
Python?
D
Yeah,
it's
better
to
have
it
so
if
it
has
its
own
report
and
it
can
have
its
own
coverage
on
CI
own
tasks
and
also
I
think
in
terms
of
commitment,
if
you
have,
if
we
have
it
in
the
main
repo.
This
means
this
means
like
we
are
committing
to
updating
it
every
single
time.
Something
happens
to
I'm,
not
sure
we're
ready
for
that,
since
we
have
to
go
client.
D
A
Is
there
automation
to
keep
it
up-to-date
like
if
you
know
the
API
surface
area,
or
you
know
there
are
C
or
DS
instructs,
etc,
have
changed
in
rook
we
have
an
automatic,
you
know
build
process
to
generate
new
clients
and
stuff
like
that
go
clients.
Is
the
I
assume
that
the
Python
client
has
automation
to
do
that
as
well?
Yeah.
C
B
B
B
A
Yeah
I
think
I
think
in
my
opinion
here
you
know
for
like
the
general
idea
of
having
this
owned
by
the
rook
organization
and
you
know
being
under
the
same
licensing
and
governance,
etc.
I
think
is
something
that
I
have
no
problems
with
at
all.
I
think
that
this
is
seems
like
a
pretty
useful
or
pretty
pretty
pretty
cool
functionality
in
feature
set
here
to
be
able
to
have
a
Python
client
as
well
for
talking
to
the
rook
ap,
the
committees,
API,
their
book
series,
etc.
A
A
A
D
B
D
C
D
C
C
A
A
Fine
with
me
in
a
final
note
on
that
too,
is
that
I
I
always
do
find
the
history
to
be
very
worthwhile
when
looking
at
code
changes
or
why
something
is
in
there,
and
so
I've
done
that
as
well.
Instead
of
going
to
their
transfer
ownership
process
in
github
to
do
like
a
clone
and
then
add
as
a
remote,
the
new
organization
repo
and
they
just
pushed
to
that
remote
just
push
force
in
master
for.