►
From YouTube: 2021-01-12 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
Yep,
I
think
it's
it's
probably
been
six
weeks.
I
think,
since
our
last
1.4
release
so
to
pick
up
a
few
little
fixes,
but
also
like
updating
the
base
image
of
the
operator,
the
step
operator
to
the
latest
ceph
release,
which
has
some
cbds
fixed
to
security
things.
It's
good
to
pick
up
and
also
just
kind
of.
B
Getting
see
the
helm
so
that
helm
issue,
you
see
there
I
added
later
in
the
agenda,
but
we
can
talk
about
it
now.
Basically,
what
this
is
I've
known
about
this
for
a
long
time,
and
I'm
surprised
nobody
really
reported
on
it
until
now,
but
it's
really
a
good
thing
to
fix.
So
after
we
release
a
new
miner
release
so
1.5.
In
this
case
we
haven't
been
running
the
promo
pipeline
right.
Sorry,.
B
B
So
I
yeah
I'm
gonna,
I'm
working
on
that
change.
Hopefully,
today
I
don't
think
it'll
be
difficult.
I
just
wanna
con
firm
and
double
check
and
triple
check
that
running
the
promote
pipeline
doesn't
cause
any
issues
or
conflicts
with.
A
Yeah
and
charleston-
I
I
don't
think
it
will-
and
I
do
also
have
some
confidence
that
if
you
were
to
do
like
promote
an
older
1.4.x,
if
that
didn't
do
exactly
what
you
wanted
to
like
home,
was
identifying
that
one
as
the
new
alpha
or
stable
or
whatever
channel
it
is
that
you
could
rerun
the
latest
1.5
promote
and
that
will
you
know
get
that
one
back
into
the
you
know
head
or
the
latest
state
that
you
that
you
would
want.
A
Yeah
yeah,
we
also
do
we
also
the
promote
you
know
does
does
do.
Does
the
the
promoter
would
work
on
the
container
images
as
well
too
right
or
is
it?
Is
that
just
do
we
don't
have
a
promote
specific
just
for
home
right.
B
A
Yeah
the
images
one
might
be
interesting
because
it
might
you
know
it
might
then
put
because
we
do
like
a
dash
alpha
or
whatever,
like
and
within
the
container.
The
image
name
like
we
tag,
use
the
alpha.
Whatever
channel
tag,
we
put
that
on
the
that
image
that
you
just
specified
to
promote
so
that
may
overwrite.
You
know,
like
the
1.5
being
the
latest
release
as
being
the
one
that
also
has
the
staple
tag
on
it,
so
that
we
may
need
to
rerun
it
to.
B
A
C
A
Yeah
and,
and
if
not,
I
think
that
anything
any
of
those
steps
there
are,
you
know
you
could
you
could
just
run
it
again
for
the
latest
1.5
we're
going
to
get
back
to
a
good
state
either
in
the
images
if
something
funny
happens
or
the
chart,
if
something
funny
happens,
I
I
think
I
have.
D
B
A
Got
it
okay,
so
we
move
on
to
1.5
patch
release
as
well
too.
This
week
later
on
in
the
week,
we're
planning
on
doing
a
1.5
yeah.
B
Just
same
sort
of
thing,
just
kind
of
on
the
cadence,
no
critical
issues
with
this
that
I
can
think
of,
although
I
might
be
forgetting
something
since
then,
here
yeah
things
a
couple
things
are
in
progress,
but
I
don't
think
anything
blocking
either
yep.
Okay,
oh
one
thing
related
to
1.4
as
well
on
that
release,
so
there
was
with
helm2
being
deprecated.
B
We
were
using
helm
2
up
until
the
1.5
release
and
I
hadn't
backported
that
to
1.4,
but
really
all
of
our
older
builds
are
broken
on
helm
2..
I
did
back.
I
did
make
a
smaller
change
that
we
could
backport
to
1.4,
so
we
can
get
the
helm
build
even
working
again
in
1.4,
so
that's
already
merged
excellent,
but
one
yeah
that
did
require
also
a
couple.
Other
changes
that,
like
updating
the
crds
to.
B
D
C
B
B
Okay,
let
me
repeat
that
last
thing
again,
so
that
there
will
be,
I
wanted
to
do
the
minimal
back
port
to
1.4
as
possible,
but
helm
3
was
requiring
me
to
update
the
crds,
so
we
have
v1
crds
for
the
helm
chart
in
that
1.4
patch
release,
which
I
I
tested
as
good
as
I
could.
I
don't
see
any
issues
with
that
upgrade
in
apache
release,
but
something
just
to
be
aware.
A
Yeah
interesting
it
so
like
the
the
crds
for,
like
the
not
you're,
not
talking
about
like
home-based
helm,
related
series.
You're
talking
about
you
know
just
like
seth
related
crds,
right
right,
interesting
yeah
and
in
general
we
haven't
had
many
problems
with
like
when
we
upgraded,
we
did
a
release
that
had
the
upgrade
of
those
crds
in
you
know
the
main
line,
the
most
recent
releases
that
was
smooth
enough
as
well.
There
too
did
it.
It
didn't
have
any
specific
migration
steps.
B
C
B
B
C
All
right
we
can
move
on
to
the
community
topics
section
here.
A
C
A
Travis
you,
you
were
able
to
meet
with
so
you've
put
forward
this
plan.
Here
you
were
able
to
meet
with
the
yucabyte
folks
lat
just
last
week
and
you
have
an
update
on
that.
It
looks
like
yep
so.
B
To
report
back
from
them,
they
I
mean
they
have
been
largely
not
in
the
rook
community,
so
it's
like:
where
are
they
well?
We
found
them.
So
thanks
for
those
their
contact
info
and
they've
had
some
turnover
in
the
team.
So
the
original
people
who
worked
on
the
rook
operator
they're,
not
there
anymore.
B
And
you
know
what
would
it
take
to
doesn't
really
make
sense
for
them
long
term
to
support
two
operators
so
which
one
are
they
going
to
go
support
and
we
talk
through
what
that
means
like
do
they
do?
They
add
the
features
to
rook
and
start
using
rook
full
time,
or
do
they
basically
pull
out
of
rook
and
and
focus
on
their
operator
sdk
based
one
so
that
it's
really
up
to
them
to
decide
and
when
that
was
open
with
them,
you
know
whatever
they
feel.
B
B
They
did
not
say
I'll
ping
them
earlier
this
week.
Let's
see
so,
we
can
like
I'd
like
to
know
by
the
next
meeting
what
they're
thinking
for
sure.
B
I
think
it
will
just
be
all
around
a
good,
clear
delineation
of
who
owns
what
what
the
ship
cycle
is,
or
recently
cycles,
issues
prs
and
everything
which
are
99
of
the
time
or
maybe
not
that,
but
it's
specific
to
that-
that
storage
provider
and
then
the
common
you
know
we
can
have
in
a
common
place
of
course,
but
that's
that's
the
real
key
to
make
these
operators
efficient
from
a
project
standpoint.
B
And
like
if
edge
of
best
comes
up,
comes
back
and
says
yes,
okay,
we're
ready
to
replace
our
operator.
That
that'd
be
a
good
time
to
to
look
at
the
separate
repo,
for
example,
but
yeah.
I
really
like
the
idea,
the
the
logistics
of
getting
it
done.
B
I
don't
feel
like
I've
worked
out
my
mind
yet
because
it'll
be
a
pain
but
we're
gonna
say
something
jared.
A
Oh
no,
I
mean
in
general
I
think
that
that
is
not
a
a
bad
thing
at
all.
You
know
like
it,
becomes
more
easy
to
focus
and
maintain
on
a
you
know:
we've
done
some
kind
of
like
some
tricks
to
you
know
be
able
to
build
only
a
specific
provider
within
the
monolith
repo.
So
it's
you
know
it's
kind
of
taking
that
a
step
further
and
providing
further
isolation
and
independence,
and
that's
nothing.
I
have
a
problem
with
it
all.
C
No
just
real
quick
hi,
guys,
sorry
for
it
hey
happy
new
year.
I,
for
example,
when
we
do
code,
hygiene
and
stuff
like
that,
where
we,
when
we
bump
versions
of
let's
say,
controller
runtime.
This
can
also
affect
other
operators
too,
and
having
to
do
the
work
for
stale
operators
is
also
like
feels
like.
It
feels
like
unnecessary
work
to
do
as
well.
C
A
That's
best
for
your
breaking
them
yeah,
exactly
if
you're,
not
the
co-owner
of
that
of
those
other
stories
writers,
you
don't
actually
have
the
insight
to
make
sure
to
understand
or
assess
the
impact
that
a
change
has
yeah
cool.
That's
that's.
B
Yeah
and
one
thing
that
I
think
will
make
this
conversion
simpler
to
separate
them
out
too,
is
the
github
actions
where
we
really
want
to
do
everything
in
github
actions
instead
of
jenkins,
because
if
we
don't
have
to
maintain
the
jenkins
and
separate
pipelines
and
whatever
it's
just
github
actions
like
it'll
be
a
lot
smoother
to
do
that
transition.
So
we're
we're
still
working
on
that
conversion,
for
even
the
triggering
the
release
builds
and
master
ci,
and
all
that
it's
fully
working
for
the
pr
ci,
the
ci
for
prs.
A
Oh
yeah
yeah
to
using
github
actions
more
right,
yeah!
That's
a
good!
That's
a
good
question!
I
have
not
looked
recently,
but
that
would
be
really
good
to
know.
A
Okay,
cool
somewhat
related,
I
guess
so
the
rook
dot
releases
and
the
book.charts
repos.
I'm
sorry
buckets!
A
Sorry,
our
those
are
still
part
of
upbounds
aws
account
and
just
to
have
you
know
the
like
sovereignty
ownership,
all
that
sort
of
stuff.
That
makes
more
sense
to
to
move
that
to
the
the
shared
rook
aws
account,
so
that
all
of
the
resources,
the
aws
resources
are,
are
there
under
a
single
account.
Everyone
has
access
to
them
as
well
too,
so
that
we
have
a
proposal
here
to
migrate.
Those
buckets
over
to
the
rook
aws
account
and
I've
kind
of
outlined.
What
the
steps
would
be
there.
A
And
then
the
proposal
also
includes
note
a
little
bit
of
down
time
for
jenkins
to
during
the
migration
of
copying
everything
over
and
so
we're
not
having
like
duplicates
or
split
brain
or
anything
like
that.
Do
you
do
you
see
any?
Are
there
any
big
concerns
or
anything
with
that
travis
sub
alex,
explain.
D
Oh
okay,
okay,
cool
yeah.
I
think
that
makes
sense.
Otherwise
I
don't
I
don't
know
if
github
has
like
a
bucket
storage
that
we
might
be
able
to
use,
but
it
seems
like
that's
not
entirely
necessary.
So.
C
D
Yeah
yeah,
I
don't
know
if,
with
the
cncf
since
we
get
extra
github
action
runners,
I
don't
know
if
we
also
get
any
like
benefits
for
like
storage
space
or
anything,
that's
another
thing
we
could
possibly
think
about
here,
but
is,
is
not
necessary.
A
Yeah,
I'm
not
super
up
to
date
on.
I
have
a
fairly
minimal
knowledge
with
github
actions
and
such-
and
I
don't
know
if,
whatever
storage
you
know
like
assets
of
releases
etc,
are
because
we
do
this
for
every
master,
build
too
right.
It's
not
just
releases,
it's
a
chart
and
images
etc
for
binaries
blah
blah
for
every
single
master,
build
as
well
too.
But
I
don't
know
how,
if
you
can
do
like
set
up
home,
chart,
repo,
etc
because,
like
rook.charts,
is
essentially
the
backing
store
for
that.
B
D
E
Well,
I'm
not
the
only
one
using
it
so
now
for
real,
like,
like
I
have
a
gift
repository
basically
well
simply
called
charts
and
like
there's
github
actions
and
all
that
to
builds
and
even
lint
validates
like
the
helm,
charts
and
then
it
will
be
built
and
pushed
onto
the
github
pages,
which
is
on
the
github
pages
branch.
I
think,
or
something
like
that,
like
it.
E
E
Interested
in
the
yeah.
E
Though,
I'm
not
too
sure
if
it
would
fit
for
our
case,
because
that
case,
at
least
from
a
point
would
be,
you
have
the
repository
with
the
cha,
with
the
helm,
charts
as
a
whole,
either
like
a
separate
repository
or
it
would
be
integrated
into
the
existing
github
action.
Workflows,
for
example,
that
we
have
right
now
in
the
rook
repository
or
in
split
of
repositories.
Then.
A
Yeah,
the
that's
it
there's.
Definitely,
it
sounds
like
some
more
things
to
understand
there,
the
lowest
cost
from
an
implementation.
You
know
engineering
perspective
with
the
least
amount
of
risk
in
terms
of
you
know,
changing
moving
parts
or
a
system,
that's
kind
of
been
in
place
for
a
few
years
now.
So
you
know
since,
like
the
0.0.1
or
2,
or
something
like
that
that
the
lowest
risk
would
be,
you
know
just
moving
them
to
a
new
s3
bucket
that
the
rook
account
owns
with
a
minimal,
absolutely
minimal
number
of
changes
there.
A
So
that's
what
I'm
inclined
to
do,
but
I'm
interested
in
these
other
innovative
ideas
here
as
well.
I
just
don't
know
enough
about
them
to
assess
them
properly.
B
I'm
also
interested
in
a
lower
risk
one
so
that's
or
simpler
one
to
do.
Yeah,
fair,
interesting
ideas.
E
A
Yeah
blaine,
I
will
add
this
to
my
notes
of
things
to
chat
with
the
cncf
in
our
next
sync
up
there
so
I'll
remember
to
bring
that
up.
B
Yeah
also
jared,
I
think
that
if
we
can
just
plan
around
when
we're
not
planning
a
batch
release,
which
is
simple
enough-
and
we
give
it
a
couple
of
days
where
we
just
agree-
we're
not
doing
any
releases,
hopefully
that'll
be
sufficient
time
and
we
wouldn't
even
need
to
disable
the
the
charts
from
master
or
whatever.
If
we
lose
a
couple,
master
builds,
for
example,
it'd
be
fine.
While
this
is
in
progress.
A
Yes,
not
doing
it
around
like
capacitance
yeah.
Definitely
I
mean
we'll
coordinate
artur
or
a
balanced,
sre
infrastructure.
Guy
he's
he
could
be
dry.
He
could
drive
this
for
us
and
I
will
coordinate
we'll
get
in
the
rook
slack
and
we'll
coordinate,
maybe
on
the
test
channel.
We've
done
a
lot
of
talking
about
jenkins
and
builds
and
stuff
like
that
there
so
we'll
coordinate
there
and
make
sure
that
we
don't
just
start
pulling
switches
and
stuff
with
when
the
community
isn't
ready.
A
Perfect
cool,
alrighty
blaine.
The
next
agenda
item
here
is
yours:.
D
D
I
I
mean
I
I
think
that's
better
for
her
in
the
in
the
long
in
the
long
run,
but
I
asked
her
to
add,
like
rook,
open
source
contributions
to
her
linkedin,
even
though
she
can't
add
anything
without
richie
and
left
her
a
recommendation
there,
but
yeah.
I
think
that's
the
update.
I
don't
know
if
anyone
has
any
questions
or.
B
A
Update
there
blaine
all
right,
so
I
think
we
can
move
down
to
the
pr's
and
issues
discussed.
We
did
discuss
this
one
earlier
here
right,
travis
yep.
We
already
did
yeah,
okay
cool,
then
that's
any
then
action
items
to
go
over.
B
B
So
I
need
to
open
that
pier
and
then
and
have
that
public
discussion
on
it
as
far
as
the
1.6
roadmap,
this
was
just
a
carryover.
From
last
time
I
did.
I
did
write
some
thoughts
down
and
seb
and
blaine,
and
I
also
brainstormed
on
it
so
I'll
open
that
roadmap.
Pr
soon.
A
C
No,
I
just
just
just
want
to
add
up
onto
what
travis
just
said:
do
we
need
to
have
a
documentation
item
for
the
roadmap,
or
can
we
just
have
a
backlog
instead
and
we
move
cards
from
run
one
releases
to
another
or
because
I
feel
like,
I
feel
like
it's
easier
to
update
cards
and
link
them
to
issues
instead
and
it
would
be
potentially
more
up-to-date
instead
of
adding
a
dark
page
for
that.
But
I
don't
have
any
preference.
It's
just
just
a
question.
I
guess.
B
C
But
maybe
they
could
they,
they
could
be
more
like
they
could
more
give
more
insights
if,
if
the
road
map
was
public
in
the
sense
that
it
could
be
part
of
the
like
the
the
cards
like,
we
could
have
items
as
part
of
kirby
shoes,
and
we
just
put
all
of
them
into
the
backlog.
So
it
would
be
easier
for
people
to
interact
with
an
issue
instead
that
okay,
I'm
looking
at
the
dock
and
then
like
how
do
I
interact
with
that?
D
Yeah
we
could,
we
could
still
keep
the
doc
to
make
it
like
easy
for
people
to
find,
but
really
just
have
that
be
nothing
but
a
a
little
like
explanation
that
we
track
our
road
map
using
like
github
milestones
or
whatever
and
then
just
link
to
there
and
then
just
make
sure
that
we
either
link
to
just
the
milestones
overall.
B
Yeah
and-
and
I
think,
there's
two
reasons
that
I
have
kept
kept
updating
that
or
wanting
to
update
that
roadmap.
So
so,
first
of
all,
it
forces
forces
us
to
think
about.
Where
are
we
going
with
the
project
and
at
a
higher
level
than
individual
issues
and
second
of
all,
people
who
want
just
the
30-second
glance
at
what's
going
on,
or
maybe
the
five-minute
overview
like
they
can
just
glance
through
it
and
and
see
it
if
they
have
to
go
read
through
individual
issues
on
a
project
board.
C
C
A
Well,
I
think
I
I'm
not
100
sure,
but
I
believe
that,
like
having
a
project
roadmap,
you
know
the
root
of
the
repo
well,
first,
it's
it's
definitely
a
very
common
convention
and
that
people
can
expect
it.
Even
if
they
don't
know
much
about
the
project
they.
A
They
can
find
it
there.
They
can,
like
you,
know,
see
everything
listed
in
one
place
there
without
having
to
get
interactive
and
it's
nice
on
mobile
and
all
that
you
know
it's
just
an
easy
to
consume
overview
there,
but
I
think
it's
also
like
a
a
was
the
you
know:
infrastructure,
co,
best
practices,
badge
thing:
it's
like
a
requirement
for
one
of
those
requirements
too.
The
project
has
like
a
roadmap.md
at
the
at
the
root.
That's
updated
and
stuff
like
that
too.
A
D
A
Like
you
can
make
it
additional,
so
you
have
like
some
items
listed
there,
but
then
have
like
a
link
to
hey.
If
you
want
more
interactivity
or
to
see
it,
dynamically
updated
over
time
as
people
are
working
like
here's,
a
link
to
the
board-
maybe
that's
useful,
but
having
like
a
static
roadmap
where
people
can
make
it
a
simple
markdown
seems
to
be.
You
know
a
fairly
common
convention
and
expectation.
B
Right
and
I
think
making
sure
we
need
to
make
sure
the
roadmap
stays
high
level
because
as
soon
as
it
starts
tracking
individual
issues,
it's
just
it's
just
too
much
detail
and
that's
what
we
should
use
the
project
board
for
but
yeah.
I
agree
with
you
jared
that
well
and
I
didn't
realize
that
actually
about
the
badge
and
all
that,
but
it
makes
sense
if
people
expect
it
and
it's
a
convention,
then
okay.
C
I
wasn't
aware
of
that
convention,
but
I
think
it's
fine
to
have
it.
It's
just
that,
I'm
afraid
that
sometimes
it
will
be
outdated
and
but
we
can
work
around
that.
I
guess.
A
Yeah,
I
think
the
themes
in
it
should
hopefully
not
get.
You
know
out
of
date,
like
the
specific
issues
and
stuff
that
state
is
better
tracked
with
a
more
dynamic
tool,
but
then
the
map,
as
travis
mentioned,
should
should
be
more
high
level
than
that
like
what
are
the
themes
that
we're
accomplishing.
D
A
All
right,
then,
we
can
go
ahead
and
wrap
it
up
for
this
week.
Thanks
everybody
for
the
first
2021
rook
community
meeting
here
and
we'll
we'll
see.