►
From YouTube: Ceph Docubetter Meeting 2020-10-29
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
A
There
is
an
issue
in
this
fs
documentation
where
the
top
level
links
were
not
working.
Joss
collin
brought
this
to
my
attention
and
it
was
because
there's
a
mixture
of
talk,
trees
and
sections
being
used
in
this
ffs
guide.
Originally,
I
was
going
to
completely
change
the
way
that
that
was
done,
but
after
talking
to
patrick
who's
in
charge
of
the
cefs
of
the
cfs
development,
I
I've
decided
to
close
that
pull
request
and
make
another
run
at
it.
A
I
spent
three
days
earlier
this
week,
building
the
documents
over
and
over
again
and
getting
all
of
the
procedures
exactly
in
order.
There
were
some
misnumbered
ordered
lists
and
I
am
awaiting
comment
on
that
from
josh
and
neha
and
keifu
the
other,
so
two
more
pieces
of
new
business
before
samford's
presentation.
A
A
So
they
don't
look
like
they're
engineer,
written
so
they're,
professionally
written
and
then
lens
brought
up
in
the
self
leadership
team
meeting
yesterday
that
the
dashboard
documentation
links
don't
work
on
octopus.
So
there
are
these
schooltech
things
that
come
up
when
you
parts
of
the
dashboard
and
since
we've
moved
to
read
the
docs
in
order
to
provide
a
working
search
on
the
docs
that
doesn't
work
so
we're
still
in
the
first
12
hours
of
figuring
out
what's
going
on
there,
and
that
was
less
time
than
I
thought
with
that.
A
B
B
B
Basic
digital
convention
and
working
on
all
of
the
things
on
this
slide
at
some
point
in
the
future,
and
these
things
don't
seem
very
company
specific.
So
hopefully
these
are
things
that
there
is
lots
of
other
companies.
Organizations
are
probably
also
interested
in
having
smarter
clients
that
do
some
or
all
these
things
and
and
other
things
as
well,
depending
on
their
use
case.
B
So
that's
all
that's
all
well
and
good.
There's,
obviously
some
like
benefits
here.
This
is
definitely
hard.
I
will
also
say
the
raido's
code
base.
Is
it's
just
huge
and
it
changes
all
the
time
and
I
I
think
it's
easy
to
think.
Oh,
it's
just
not
worth
the
effort
and
that's
kind
of
fair
it
is.
It
would
be
a
ton
of
effort
document.
The
whole
thing
so
I
want
to.
B
What
they
really
need
to
know
is
what
is
the
contract
that
they're
being
held
to
with
the
server
and
the
language
that
contract
is
written
in?
Is
the
language
of
raido's
protocol
messages
of
the
of
the
messages
that
the
server
is
going
to
send
to
them
and
of
the
messages
that
they
are
required
to
send
back
in
order
to
maintain,
if
you,
if
you
cover
that,
like
this
high,
like
most
of
the
important
information
for
enabling
smart
clients
is
out
there.
B
So
here
are
a
few
ideas
I
have
for
sort
of
possible
formats.
This
documentation
could
take
I'm
not
strongly
pushing
for
any
of
these
ideas
and
just
throwing
them
out.
There
want
to
start
brainstorming
putting
these
ideas
out
there.
I
will
say
that
this
that
these
sort
of
serialization
diagrams
for
the
wire
protocol
were
quite
helpful
for
me,
and
so
maybe
something
like
that
would
be
in
order,
but
mainly
I
want
to
know
sort
of
what
do
other
people
who
are
watching.
A
Thank
you
sanford.
I
am
in
favor
of
documenting
the
protocol
messages.
That's
like
the
very
first
step.
I
also
agree
that
if
we
try
to
document
the
radius
code
base,
then
the
sans
shift
like
impossibly
and
when
josh-
and
I
first
talked
about
it-
he
was
like
anybody
who
can
anybody
who
can
read
the
the
actual
commits
themselves
can
just
see
what
was
done
and
abstracting.
A
A
B
A
A
Not
not
yet
I'm
sure
there
will
be
specific
questions,
but
you
know
yeah.
So
the
other
thing
which
is
not
in
the
not
in
the
notes,
but
I
want
to
mention,
is
that
anthony
made
these
massive
contributions
to
the
docs
over
the
last
two
weeks
and
so
that
that
caused
me
to
read
through
line
by
line
aloud.
A
I
actually
read
everything
that
you
wrote
aloud
anthony
hours
yeah,
so
thank
you
very
much
to
anthony
for
doing
a
line
edit
on
some
of
our
documentation
and
that's
unless
you
guys
have
any
sort
of
new
business
or
anything
that
you
want
to
to.
I
mean
sanford
just
brought
up
this
new
documentation
initiative,
but
anything
that
you
want
attention
given
to
that's
going
to
be
it
for
the
meeting.
Does
anybody
have
anything.
C
Well,
you
know,
as
as
I
went
through
you
know
doing
you
know
you
know
kind
of
the
dumb
stuff
capitalization
and
you
know
life
is
capitalized,
it's
not
an
acronym
and
it's
not
lowercase.
You
know
that
that
kind
of
stuff
is
easy,
but,
as
I
got
into
the
operations
documents
I've
I
found
increasing
angry.
I
had
to
resist
the
rabbit
hole
factor
because
increasingly
found
a
lot
of
it
is
really
old.
I
mean
some
of
the
things
that
I
did
were
to
you
know.
There
were
places
where
it
you
know.
C
File
store
was
the
only
back
end
and
it
talked
about
the
new
kraken
release.
Yeah,
there's
a
there's
a
lot
of
old
stuff
in
there
and
I
had
to
resist
the
urge
to
just
get
it
on
and
start
over
yeah.
It
was
that
one
document
I
came
close
as
you
saw,
and
so
I
mean
there
were
documents
in
there
that
I
had
to
force
myself
not
to
touch
because
they
pretty
much.
C
A
There
are
things
in
in
our
docs
that
go
back
to
2012
that
have
just
been
sitting
there
since
2012
until
about
four
or
five
months
ago.
I
think
that
there
were
places
where
it
referred
to
2013
and
2016,
as
those
were
as
though
those
were
contemporary
and
what
I
would
like.
What
I
would
prefer
is
that
every
time
we
do
a
release.
A
We
start
over
again
completely
from
the
ground
up
and
then
build
everything
that
doesn't
mean
that
we
have
to
rewrite
every
single
guide,
but
it
means
that
we
re
review
every
aspect
of
the
documentation
determine
whether
it's
baby
or
bath
water.
Does
it
stay
in
the
new
version
or
does
it
does
it
remain
in
the
old
version?
And
I
also
like
I'm
in
a
way
just
repeating
what
you
said,
but
the
force
of
what
you
said
is
on
my
mind
every
day
of
my
professional
life.
A
And
so
with
octopus
that'll
be
the
first
time
that
I
am
on
board
for
the
development
of
new
documentation
from
the
beginning.
I
would
like
to
do
that
for
octopus.
We
have
about
five
months
before
the
release
of
octopus,
and
I
would
like
to
I
think
I
mean
it's.
I'm
sorry
yeah
I
mean
pacific,
not
octopus.
Octopus
was
one
where
they
running
beside
that.
In
fact,
I
just
realized.
C
One
of
the
things
was,
you
know
the
you
know
you
know
putting
stuff
in
there.
How
much
you
know
you
know,
does
every
sentence
begin
with?
If
or
you
know
do
we
just
you
know,
put
something
in
there
saying
you
know,
for
you
know,
beginning
with
a
document
saying
you
know,
for
you
know
using
you
know,
file
store,
or
you
know,
upstart
or
whatever
you
know,
go,
look
at
the
the
nautilus
documentation
or
something
and
delete
yeah.
How
much
how
much?
How
much
of
the
the
older
stuff
do
we
carry
forward?
C
You
know,
because
you
know,
as
alex
knows,
I'm
sure
there
are
plenty
of
people
running
both
file,
mixed
file,
store
and
blue
store
clusters,
because
completely
repaving
them
is
is
not
always
possible,
for
example,
and
so
you
know
how
much
how
much
you
know
dude
how
much
of
the
do
we,
you
know,
put
that
in
there
and
how
much
do
we
rely
on
you
know
if
you're,
if
you
to
not
learn
about
older
stuff,
go
back
and
look
at.
You
know
edit
the
url
kind
of
a
thing.
A
I
think
of
the
golden
age
of
microcomputer.
Documentation
is
like
the
commodore
64
guide,
all
the
early
apple
apple
ii,
stuff,
where,
like
there's
on
on
the
first
page
of
the
of
the
commodore
64
users
guide,
it
says,
find
the
thing
in
the
box.
It
looks
like
a
typewriter
and
then
like
over
the
next
110
pages.
It
takes
you
through
to
poking
values
in
the
memory
directly,
so
like
it
steps
you
through,
but
the
assumption
there
is
that
you
have
the
kit.
A
You
have
all
the
same
hardware,
and
so
it's
like
the
same
architecture,
and
when
I
started
like
naively,
I
was
like
okay
well,
this
is
how
you
set
up
stuff.
So
now
I
have
this
document
and
then
over
the
months
it
came
like.
Oh
no,
the
the
potential
architectures
of
on
which
this
piece
of
software
is
going
to
be
deployed
are.
A
They
they
ramify
and
ramify
and
ramify,
and
there's
no
way
to
know
exactly
what
anybody's
going
to
do.
So.
I
have
this
this
deeply
in
inbuilt
desire
to
ship
a
standard
kit
to
everybody
and
then
build
an
understanding
based
on
that
standard
kit
and
then
trust
the
reader
to
be
able
to
develop
their
knowledge
from
there.
A
C
You
because
stuff
adm,
rook
self-deploy,
you
know
you
know
any
of
the
other
things
that
people
have,
and
you
know
I
struggled
with
that
in
the
book
too,
and
it's
like
okay
and
need
to
have
insp.
You
know
some
installation
example,
but
you
know
I
I
can't
document
everybody's
installation,
so
I
kind
of
punt
it
and
just
put
it.
I
think.
As
that
ansible,
you
know,
you
know
that's
a
fantable
or
stuff
or
book.
You
know
and
we've.
You
know,
we've
heard
you
know
over
time.
C
C
Fans,
you
know
and
kind
of
the
moving
target,
and-
and
you
know
so
I
mean
you
know-
I
mean
modulo,
you
know
red
hat,
you
know
favoring
red
hat
solutions,
yeah
and
I
don't
have
a
good
answer
for
this
either.
Is
you
know
what
you
know?
Do
we
try
to
docum?
You
know
what
do
we
try
to
include
and
what
we
not
try
to
include
in
there,
and
so
you
know
I'm
happy
for
some
guidance
there,
as
I
dig
into
the
thornier
parts
of
the
documents
that
need
to
be
updated.
A
A
C
A
There
was
a
period
of
time
I
think
about
2014
2015,
where
docker
like
there
was
a.
It
was
a
desktop
environment,
dock
for
a
while
as
well,
and
so
there
was
a
lot
of
documentation
back
then
that
had
to
be
modified,
and
so
what
I
decided
was,
with
the
exception
of
the
red
hat
and
susa
like
dnf
and
zipper.
I
don't
remember
if
it's
yam
and
zipper
anyway,
we
would
we
would
gesture
in
the
direction
of
those
packages
and
then
leave
it
to
each
of
the
individual
distros
to
handle
their
own
documentation.
A
C
C
A
I
favor
like
rendering
some
territory
of
the
information
legible
and
having
that
as
like
the
the
central
path
and
assuming
that
the
completely
ignorant
reader
will
come
to
it
and
be
able
to
read
through,
like
just
just
follow
through
this.
This
main
path
and
then
they'll
have
enough
skills
to
then
start
making
their
own
decisions.
A
There's
a
place
for
the
everything
you
can
do
it
like
the
cookbook
once
you
once
you
have
the
basic
skills
like
this
is
a
spoon.
This
is
a
pot
yeah.
Then
I
think
so
anyway.
I
I
separate
these
in
my
mind
into,
and
I
know
we're
running
low
in
time
here.
I
separate
these
two
things
in
my
mind
into
tutorial
on
the
one
hand
and
reference
on
the
other,
like
you
need
tutorials,
so
that
you
can
learn.
What
even
is
this
so
that
you
can
begin
to
generate
questions?
A
You
don't
even
know
that
you
have
yet.
All
you
know
is
like
I
want
to
do
a
thing,
but
I
don't
know
any
of
the
like.
I
have
an
end
goal
in
mind,
but
that
end
goal
might
be
like
produce
antimatter
and
that
might
be
impossible
and
I
might
have
to
come
up
with
a
a
simpler
end
goal.
It
can
actually
be
practically
achieved.
A
I
I
have
been
working
toward
exactly
that
sort
of
thing.
I
have
been
slowly
building
these
these,
I
don't
want
to
say
moires,
but
like
customs
in,
like
you,
do
this
sort
of
thing
in
documentation
in
the
following
way,
and
this
is
all
building
up
to
a
fundamental
new
taxonomy
of
the
docs.
However,
like.
A
Tons
that
there
are,
there
are
three
different
cephadium
deployment
guides
and
I
want
to
kill
two
of
them,
but
every
one
of
those
requires
delicate
political
negotiation
with
people
okay
like
and-
and
I'm
like
I'm
sensitive,
I'm
old
enough.
Now
that
I'm
sensitive
to
all
the
work
that
everybody
has
done.
If
I
was
younger,
I
would
just
be
like
let's
rip
all
this
out
and
start
over,
but
now
like.
I
know
that
this
page,
even
though
it
might
be
old
people,
have
it
in
their
head.
It's
like
a
thing
that
they
refer
to.
A
C
A
C
C
A
I
would
also
like
to
be
changing
the
structure
of
the
docks,
and
I
would
also
I
would
like
to
standardize
it
so
that
it's
either
all
using
top
trees
or
all
using
sections.
But
again,
each
of
these
each
of
these
different
guides
was
built
by
a
specific
team
and
they
had
their
own
ways
of
doing
it.
So.
C
A
A
I
I
want
to
do
exactly
what
you
want
to
do,
but
I
want
to
have
something
really
good
to
offer
all
of
these
developers
who
are
not
thinking
about
the
structure
of
the
documentation
at
all.
Otherwise
we
wouldn't
be
in
the
situation
that
we're
in
now.
I
want
to
have
something
to
offer
that
people
come
and
go
and
yeah
yeah
yeah
there
have
been
there's
been.
I
know
three
docs
guys
before
me.
I'm
two
minutes
over.
I'm
really
sorry
for
for
running
two
minutes.