►
From YouTube: 2018-07-03 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
Thanks
for
pointing
out
the
scenario
for
removing
a
device
so
that
that's
what
I'm
testing
right
now
and
needs
a
couple
of
fixes
for
sure
it's,
it
didn't
just
work,
didn't
just
work
and
it's
not
just
as
simple.
Oh,
it's
just
a
few
lines
of
code.
Look
over
to
it's
a
pretty
good
orchestration
that
you
put
together
there.
B
B
A
A
Talk
out
for
this
meeting,
I've
got
a
meeting
scheduled
with
Alex
after
this
yeah
we'll
try
to
find
each
other
this
morning
now
sure
they're
you
in
mountain
time
now
I
am
oh
you're
in
the
future.
Okay,
when
I
run
the
features
yeah
all
right,
cool
sounds
good.
Okay,
so
that
I
think
we're
pretty
well
covered
on
that
I.
Think
we've
done
a
since
this
last
meeting
at
the
community
meeting
two
weeks
ago.
A
A
A
We
are
going
to
declare
the
Ceph
types
CR,
the
CR
DS,
to
be
beta
now,
and
so
what
that
means
is.
It
is
a
statement
about
the
stability
of
the
CR
DS
themselves,
so
any
changes
that
go
into
those
SEF
CRD
types
in
the
future
will
be
made
with
a
migration
path,
or
you
know,
with
backwards
compatibility
in
mind.
So
we
were
saying
that
the
SEF
CR
DS
are
stable
enough
to
declare
the
beta.
A
You
know
we've
declared
rook
itself
as
alpha
for
for
this
entire
time,
since
we
open
sourced
it,
but
we're
going
to
do
it
on
a
API
group
level
now,
which
makes
more
sense
for
tracking
maturity
of
different
portions,
of
the
projects
that
have
better
granularity
for,
for
you
know,
tracking
a
status
so
we'll
remove
the
overall
project
status
and
track
everything
by
API
group
now
by
UNICEF
or
cockroach
or
whatever
it
may
be.
So.
A
Is
correct:
Alex
18:32,
oh
I'm,
I'm
in
the
thick
of
so
the
unfortunate
part
about.
That,
though,
is
that
you
for
completeness,
you
know
we
hit.
This,
requires
migration
as
well,
so
we're
I'm
in
the
midst
of
supporting.
We
have
already
supported
the
migration
from
the
legacy
rocĂo
cluster
type
to
the
new
SEF
cluster
type.
A
You
know
the
rook
cluster
type
to
SEF
cluster
type
and
the
the
types
are
not
drastically
different
so
that
migration
logic
has
already
been
written
in
tested,
and
so
this
is
not
a
massive
change,
but
it
does.
You
know,
require
a
new
migration
path
and
I'm
working
on
that
now
and
it
sounds
like
I'll.
Probably
I'll
probably
get
be
finished
with
that
or
ready
to
take
its
master,
hey.
A
D
C
A
General
Bassam
I
totally
agree
with
you
as
well
that
you
know
master
builds,
are
not
a
general
guarantee
that
we
will.
They
will
be
supported,
for
you,
know,
migrations
and
upgrades
and
all
that
or
that
anything
will
be
remain
consistent
in
master
builds.
But
for
this
particular
scenario,
I
think
that
the
cost
to
benefit
ratio
is.
It
makes
sense
to
support
this
one.
So.
A
That
is
the
type
change.
Yes,
then,
the
might
so
there's
migration
logic
that
when
the
operator
comes
up-
and
it
sees
that
oh
you've
got
the
old
rook
cluster
type
from
you,
know,
0.7
and
it
in
place.
You
know
migrants
that
CRD
to
the
new
type
and
deletes
the
old
CRD,
and
your
does
the
bookkeeping
aspects
there
and
that
same
similar
logic
just
needs
to
be
done
as
well,
for
if
it
sees
the
old
self
SF
alpha
type
and
then
just
migrating
that
to
the
new
beta
type.
D
B
Well,
and
also
one
thing
to
consider
is
the
migration
code:
that's
already
been
written
from
old
types
to
the
well.
What
we
have
today
is
that
there
is
some
conversion
there,
that
sort
of
business
logic,
conversion
that
we
need
and
that
moving
from
now
to
the
beta
types,
it
will
be
a
really
just
a
direct
type
copy.
C
Basically,
the
code
we
currently
have
in
place
to
migrate,
zero,
seven,
two
zero,
eight
Co
decent
everything
else.
It's
only
needed
for
Sarah
seven
to
zero.
It's
only
for
glacial
zero.
If
we
move
to
0-9
we've
well,
normally
would
remove
key
code
cache
we
at
least
as
far
as
I'm
informed.
We
don't
really
support
upgrades
from
like
zero
six,
two
zero,
eight
for
example.
Okay,
so
I
think
that's
what
I'm
asking
here
isn't
that.
D
A
Don't
think
that
we're
you
know
making
that
promise
or
guarantee
for
the
future,
though
I
that
be,
you
know
the
way
that
this
you
know
has
you
know
been
rolled
out
already.
You
know
and
needing
to
do
another
type
change
and
supporting
that
I.
Just
I
feel
like
with
the
deployments
we
have
out
there
that
this
in
particular
needs
to
be
supported.
A
E
D
I
think
helping
them
wear
on
slack
or
you
know,
making
sure
in
the
release.
Notes
of
you
know
saying
something
if
you
have
master
and
there's
a
here's,
some
ideas
for
how
you
can
upgrade
that
you
know
there
I
yeah.
This
seems
this
is
a
I
mean
I.
In
retrospect,
I
wish
we
would
have
talked
about
the
beta
release
beta
types
before
we
did
the
migration
and-
and
we
didn't,
but
it
does
feel
like
it
does
feel
like
to
me
like.
We
should
not
do
this.
C
Okay,
providing
some
kind
of
script
kind
of
s
refused,
as
you
said,
with
helping
them
on
sale.
A
couple
of
migrating
from
a
master
to
a
net
tech
release,
know
I,
think
we
need
to
kind
of
do
more
than
that.
I
think
we
should
go
as
far
as
adding
in
for
master
at
least
adding
some
kind
of
warning
to
the
master
locks,
because
every
everyone
clicking
on
a
Ruger
website
on
the
docks
link
is
coming
to
roof
master
docks,
so
they
are
using
master
and.
C
D
Could
I
could
see
I
could
see,
you
know
compromise
being
that
if
we
don't
were
kind
of
directing
people
to
go
to
master,
then
I
think
Jarrod
would
argue
that
we
should
help
them
upgrade
and
the
cost
here
is
simple.
But
if
this
can't
be
it's
going
to
be
the
norm,
we
have
to
warn
people
not
to
deploy
for
master
yeah.
E
C
Is
does
kind
of
are
exactly
the
point
with
a
change
which
happened
where
we,
for
example,
among
count,
the
Montcalm
was
moved
to
a
sub
structure.
People
fit
they
had
like
old,
manifests,
but
more
up-to-date
images.
The
next
exactly
one
of
the
points
there
it's
extremely
hard
to
help
people
with
master
those
running,
because
you
can't
you
know
you
can't
really
tell
them
to
go
to
every
part
day
if
running
and
run
work
version
in
it.
So
you
can
see
which
is
the
bad
one
to
build
like
that.
So
as.
C
C
B
C
D
E
E
D
That
would
be
the,
but
I
would
argue
that
that
should
be
the
answer.
I
could
see
a
compromise
that
where
we
we
have
been
pointing
people
at
master,
whether
complicit,
Lee
or
explicitly
pointing
people
with
master
and
or
he's
no
warning
them,
and
you
could
say,
as
an
exception
for
this
build,
will
help
and
because
the
cost
is
small
well
will
write
a
little
migration
thing
that
we're
not
gonna.
Do
that
going
forward.
D
Your
proposal
at
the
operator
doing
it
I'm
saying
if,
if
our
current
behavior
is
that
we're
letting
people
get
install
master
and
and
they
feel
like
that-
that's
a
more
stable,
stable
release
because
we're
not
warning
them
and
we're
sending
the
docs
to
master
and
everything
else.
Then
we
should
fix
that.
D
A
I
think
that
I'm
comfortable
with
that,
given
that
we
are
also
going
to
you,
know,
have
some
sort
of
more
emphasis
or
steering
people
away
from
using
master
I.
Think
with
you
know
the
the
basically
the
default
approach
of
you
know.
Everyone
in
installing
master
by
default
is
has
gotten
us
into
the
situation
and
steering
away
from
that
would
would
definitely
help
us
out
and
yeah
I.
Think
if
we
didn't
support
this
migration,
there
would
be
a
lot
of
chaos
to
clean
up
from
the
community
in
on
slack
in
people's
clusters.
No
longer
working.
A
All
right,
let's
move
on
then
so
the
upgrade
testing
pass.
You
know
we've
kind
of
done
that
with
a
one
OS
d
per
pod,
but
we'll
need
to
you
know
in
master.
We
will
need
to
do
do
that.
For
you
know
our
RC,
our
release
candidate
builds
before
we
go
ahead
and
fork
for
the
0.8
release,
but
well
Travis
and
I
will
probably
both
both
do
that
independently
do.
B
C
B
A
D
C
D
Yeah
I
mean
there's,
there's
the
coding
and
automation
card
and
then
there's
the
actual
resources
where,
with
us
friends,
I'm
sure
we
can
pony
up
resources
in
a
number
of
places
to
do
this,
but
we
kind
of
need
we
kind
of
need
an
owner
for
for
the
integration
testing
I'm,
getting
it
resurrected.
Yeah.
A
A
Yeah
got
it
all
right,
so,
let's
just
get
through
the
tickets.
We
have
open
in
the
milestone,
and
you
know
once
we
haven't
already
talked
about,
so
we
talked
about
the
versioning
and
migration
and
stuff.
Now
this
it's
of
the
integration
tests
to
kind
of
make
them
a
little
bit
more
reliable
when
machines
or
instances
are
getting
reused
for
two
runs
in
a
row.
I
had
wanted
to
start
that,
but
I
you
know
need
to
focus
on.
You
know
migration
or
getting
other
things.
A
The
Jedi
date
release
so
I'm,
not
sure
if
this
is
necessarily
a
blocker
for
the
release
itself.
Honestly,
this
is
not
something
they
could
be.
You
know
going
master
afterwards
anyways,
because
it's
really
the
detriment
is
really
where
it
really
hurts.
This
is
on
pull
requests
and
getting
things
as
a
master.
It's
not
a
release,
focus
itself
honestly,.
A
B
A
B
C
Because
we
just,
we
should
make
sure
that
that
this
doesn't
happen
with
zero
debate
anymore.
Yes,
I
think
they
lost
like
like
one
or
two
knows
the
whole
or
most
owes
these,
and
that's
not
acceptable
to
be
like
that,
even
though
you
know
alpha
in
that
regard,
yeah
casted
punishments
right
there
previously,
but
yeah
yeah.
C
E
B
A
Yeah
my
gut
feel
on
this
one
is
that,
as
we're,
you
know,
Drive
we're
trying
to
converge
on
a
milestone
and
we're
driving
towards
a
a
set
list
of
items
that
we've
agreed
upon
that.
If
we
don't
have
a
lot
to
go
on
on
this
one
or
we
don't
have
you
know
many
reports
of
it
or
it
seems
like
a
difficult
scenario
to
reproduce
or
things
like
that
that
you
know
I
would
not
hold
there
really
specifically
for
this
and.
A
D
C
Well,
yeah
I'm
using
himself
just
a
few
seconds
ago.
I
did
okay,
I
was.
A
F
A
Awesome
thanks,
Caitlin,
okay,
so,
as
we
talked
about
there,
the
graduating
from
a
sandbox
CN
CF
project
to
an
incubation
project,
part
of
that
is
kind
of
getting
an
understanding
of
our
production
users
or
users
that
have
deployed
work
through
production
and
having
testimonials
from
them.
So
I,
don't
know
if
this
call
is
pretty
developer,
focused
so
I
don't
know
if
that's
we're,
gonna
really
find
any
production
users
on
this
call.
Necessarily
that
aren't
you
know,
contributors
and
developers,
but
that's
something
did
come
on
your
developer.
A
C
A
Yeah
I
have
a
list
of
people
that
I'm
already
in
community
and
I'm
gonna
I,
think
I'm
to
address
this
I'm
gonna
send
out
a
survey
or
just
a
question.
You
know
it's
you,
the
announcements
in
general
channel
two
to
five
tracks
down
some
more
users
that
may
be
able
to
tell
us
about
their
production
scenario.
Yeah.
D
F
I
also
be
curious
to
find
out
like
what
what
percentage
of
like
their
their
storage
in
general
is
real
courses
other
things,
because
it's
good
to
know
like
the
importance
of
it
but
like
if
there's
any
other
types
of
storage
in
there
to
and
it's
a
small
percentage
of
it.
It
makes
it
insignificant,
in
my
opinion.
So
it's
just
good
to
know
that
kind
of
stuff.
A
Yeah
Tony,
that's
it's
a
good
point.
That
was
the
part
of
the
survey
that
we
had
been
done
before
q.
Con
Europe
was
about.
You
know
what
the
size
and
scope
of
their
deployments
are.
So
you
captured
some
of
that
I,
don't
know
if
I
don't
think
we
captured.
They
know
what
other
non
rook
deployment
information
they
have
there.
A
Okay,
so
we
an
important
topic
here
as
the
community
continues
to
grow.
Is
you
know
how
support
can
be
provided
for
that?
The
community?
There's
no
question
that
Alexander
has
done
an
enormous.
You
know.
Job
that's
been
been
very
beneficial
to
the
community
for
providing
support
and
helping
out
users
with
questions.
A
You
know
during
basically
all
hours,
so
you
know
alex
has
been
an
absolute
rock
star
hero
on
that
front
in
a
really
really
grateful
for
all
of
his
work,
but
that
doesn't
that
doesn't
scale
when
you
know
Alexander
is
the
main
go-to
person
and
you
know,
there's
definitely
instances
of
users
that
you
know
I
just
come
directly
to
Alex
as
opposed
to
the
community,
which
you
know
further
increases
his
burden,
and
you
know
it
doesn't.
It
doesn't
necessarily
that
certainly
doesn't
help
scale
either.
A
So
I
wanted
to
open
the
floor
here
to
see
if
we
have
any
ideas
of
how
we
can
support
the
community
better.
With
the
very
limited
resources
we
have
there,
Travis
is
there
any
like,
as
the
Red
Hat
guys
have
become
more.
You
know
on
board.
With
you
know,
staff
in
a
containerized
cloud
native
environment
with
Brook.
Is
there?
Is
there
more
resources
for
from
Red
Hat
to
be
able
to
help
out
with
community
issues
and
support.
B
Not
that
I've
found
specifically
around
this
I
think
we've
definitely
been
when
a
specific
question
comes
up
or
tag
someone
who's.
You
know
who's
in
the
community,
like
dan,
has
been
answering
a
bunch
of
questions
or
to
have
some
the
PRS,
but
I
definitely
tried
to
stay
on
top
of
the
tune
and
tag
people
but
other
than
that.
Yeah.
Your
question
about
recent
other
resources.
D
Yeah
and
I
wonder
if
you
know
the
other
thought
I'd
hear
is
like
if
part
of
the
governance
of
the
project
includes
you
know,
bringing
in
people
that
can
help
not
only
contribute
to
code
that
contribute
to
community
around
the
code.
I've
seen
I've
seen
others
other
projects
that
have
done
similar
things.
C
A
And
you
know
Alex.
That
is
a
perfectly
acceptable
response
to
give.
In
my
opinion,
if
somebody,
you
know
pings,
you
directly,
you
can,
you
know
politely
redirect
them
to
the
general
channel.
That's
perfectly
acceptable,
you
know
you
know.
There's
no
obligation
to
you
know
respond
on
a
one
on
one
side
chat,
especially
because
you
know
the
support
that
is
given
to
that
user
can
be
beneficial
to
other
users
as
well,
so
it's
actually
a
detriment
to
the
community
as
a
whole.
F
So
will
Jays
think
of
rather
than
just
doing
it
all
over
slack
having
some
people
just
open
issues
right.
So
that
way
you
can
track
the
the
solutions,
because
searching
slack
is
kind
of
difficult
for
certain
problems
and
I
think
it's
it
rolls
over
like.
It
only
keeps
like
ten
thousand
messages
or
something
like
that.
I'm
saying
we.
B
A
Tony
I
definitely
do
with
you,
man
that
that
having
things
and
you
have
issues,
it
makes
a
lot
of
sense
in
a
lot
of
circumstances.
I
view
slack
as
a
you
know,
quick.
You
know
back
and
forth
hey.
What's
this,
you
know
issue
I
see
here.
Can
you
help
me
out
with
it
and
kind
of
doing
something
quickly
back
and
forth?
But
if
it's
a
you
know
a
systemic
issue
or
you
know
a
bug
or
something
that
needs
to
be
tracked
better.
A
You
know,
especially
for
our
you
know,
archival
or
for
your
future
help
as
well.
Then
a
github
issue
makes
a
lot
of
sense.
So
we
can.
We
can
probably
steer
more
things
towards
issues
than
we
have
so
far
that
that
makes
plenty
of
sense
to
me
and
there's
a
oh
yeah.
It's
only
just
a
real
quick
thing.
That's
you
know.
Google
searches
and
you
know
having
those
things
like
rook
issues
come
up
deal
thing.
C
A
A
C
A
F
C
A
Okay,
yes,
Alex,
do
feel
free
to
you
know
to
you,
don't
have
to
engage.
You
know
full
support
questions
on
in
one
on
one
channel.
It's
just
redirect
to
general
and
you
know
I
think
that,
probably
as
a
whole
that
you
know
the
community
and
some
of
us
can
can
pitch
in
more
so
you
know
feel
free
to
you
don't
have
to
respond
everything
immediately.
A
I
would
say
if
you're
you
know,
especially
if
you're
over
burdens,
you
know
that's
you
know
me
or
you
know
we
Travis
or
some
of
the
Red
Hat
guys
or
other
community
members
as
well
can
can
you
know
get
to
the
answer?
You
know
maybe
not
right
away,
but
eventually
I
think
the
community
can
support
itself
still
pretty
well.
Perhaps.
B
E
C
D
C
C
It's
just
not
as
fast
as
you
know,
at
least
for
if
there
it's
it's
faster
to
create
initiative,
because
if
you
create
the
issue
you
get
to
template,
which
is
the
next
point
cut
off,
the
people
have
a
template
where
they
have
to
fill
it
out
or
should
fill
out
where
we
directly
have
kind
of
all.
The
information
are
your
questions
on
something,
and
this
kernel
and
stuff
like
that
summit.
Yet
we
can
kind
of
instantly
became
looking
if
it's
yeah
already
known
or
something
well.
F
I
mean
like
how
no
one's
just
staring
at
slack,
though
right
the
whole
time,
like
immediately
answering
someone's
question,
there's
still
there's
still
delay
there,
I
mean,
even
if
you
get
an
email
in
your
inbox
like
that,
I
would
say
the
response
times
are
comparable
your
mailing
list
and
slag.
It
may
be
like
people
wouldn't
formulate
the
questions,
the
same
way
right
on
slack
or
a
mailing
list,
but
I
I.
D
I'd
say
that
people
are
going
to
come
in
on
different
channels.
We
should
probably
just
have
like
the
flower.
If
something
looks
like
an
issue,
we
just
it
should
be
an
issue
and
get
out
when
it
comes
on
a
mailing
list
or
it
comes
on
slack
or
it
comes.
However,
no
you
should
direct
people
to
create
issues
in
github.
E
A
I
bet
I
think
we
all
are
in
agreement
on
that
one.
Another
issue
or
another
item
that
that
Alex
had
brought
up
is
that,
with
the
issue
template
we
have
some.
Sometimes
it
is
not
used
by
by
the
user
and
and
I
think
alex
is
curious
if
there
was
any
sort
of
consensus
amongst
community
of
if
it's
worth
trying
to
start
troubleshooting
those
issues
without
that
information,
or
that
should
be
more
of
a
you
know,
kind
of
a
requirement
for
the
user
to
provide
that
information
so
that
they
can
be
more
effectively
helped.
A
C
Basically,
the
question
is
if,
for
example,
a
user
who's
an
issue,
but
it
doesn't
fill
out
the
template
and
the
question
is:
should
we
already
begin
looking
at,
you
know,
troubleshooting
the
possible
problem?
Yes
without
the
information,
for
example,
which
route
version
and
stuff
like
that,
because
it's
it's
kind
of
like
if
somebody
opens
an
issue
like
that,
this
is
what
I'm
like
yeah
hey.
Can
you
please
fill
out
the
template,
so
we
get
the
information,
at
least
for
my
son?
That's
if
we
don't
have
some
information.
F
C
C
People
we
all
used
to
put
a
life,
yet
nobody.
C
This
basically,
what
I'm
asking
if
we
just
point
them
hey,
please
fill
out
the
template
or
if
we
already
go,
do
you
think
it
could
be
dissin?
You
know,
like
already.
F
I
think
that's
a
total
waste
of
time
trying
to
troubleshoot
something
without
information.
Right
I
mean
that,
like
any
scalable
support
organization,
a
larger
company
wouldn't
even
like
work
on
a
case
they
didn't
have
certain
information.
I
mean
you
can
do
that
when
the
community
is
this
big
right,
but
as
it
grows,
it
just
begins
to
waste
your
time
you
don't
get
your
actual
work
done.
So
people
need
to
give
the
relative
information
that
you
need
to
troubleshoot
an
issue
and
they
need
to
work
with
you.
C
E
A
Think
we
have,
we
have
agreement
on
that
yeah,
okay,
so
I
just
wanted
to
bring
up
the
you
know.
We
had
had
a
someone
from
the
communities
suggest
a
Luxio
support
which
I
am
not
familiar
with
at
all,
and
I
was
wondering
if
anybody
already
had
a
an
opinion
on
on
that
or
knew
much
about
that
particular
storage
product
provider,
I'm,
not
sure
exactly
I.
A
E
A
C
D
A
All
right
so
I
think
that
that
was
all
that
I
had
written
down
here
and
I've
got
some
action
items
here
as
well
that
we
need
to
follow
up
on
I'd
say
that
this
whole
the
whole
topic
about
you
know
warnings
about
deploying
to
master,
and
you
know,
having
master
examples,
potentially
referencing.
The
last
release
I
think
that
that
might
be
that's
what
that's
supporting
in
master
itself,
I
think
I'm,
not
sure.