►
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
So
Josh
asked
me
to
go
over
the
monitor
code,
so
I
want
to
talk
a
bit
about
the
architecture
and
the
pieces
of
the
system
for
people
who
are
interested
in
working
on
it
or
find
themselves.
Maybe
we're
trying
to
do
whatever
I've
been
involved
in
the
set
product
for
a
while
and
I've
done
a
lot
of
work
here
over
the
years
and
I'm
working
now
on
updating
some
of
the
collection
systems
and
things
so
I'm
pretty
familiar
with
it.
A
So
here's
a
listing
of
the
monitors
of
the
monitors
files
that
we
use
inside
of
sourcetree,
the
sort
of
I
mean
they're.
All
important,
but
sort
of
the
key
points
here
are
that
the
main
monitor
class,
perhaps
everything
together
in
monitor,
H
and
CC
the
different
pieces
are
the
well.
The
monitor
is
a
pack
system.
A
That
means
that
we
will
elect
a
leader
or
all
the
monitors
get
together
and
they
like
a
leader
using
the
Elector
and
election
logic
stuff
and
then
that
leader
is
responsible
for
ordering
all
the
incoming
updates
the
system
and
he
grants
leases
to
the
to
the
to
the
PM's
and
they
can
serve
reads
to
all
the
clients
of
the
set
system.
That
logic
is
embedded
inside
of
the
pack
to
set
H
for
doing
the
updates,
and
then
the
packs
of
service
is
the
interface
that
we
use
for,
inter
for
making
those
kinds
of
changes.
A
A
A
See
ya?
So
if
we
look
at
the
code,
this
is
the
Seth
Mondesi
file
and
in
the
source
directory
in
the
main
sub
source
directory.
The
main
thread
or
the
main
function
is
pretty
standard.
We
do
a
lot
of
set
boot
up,
stuff
and
parse
flags
and.
A
A
So
if
you're
not
familiar
with
paxos,
it's
basically
a
street,
it's
an
ordered
stream
of
of
events
or
commits
or
updates,
and
the
Paxos
algorithm
is
actually
utterly
indifferent
to
what
they
are.
It's
just
that
the
system
you
propose
an
update
to
Paxos,
and
then
the
system
accepts
it
or
says
no
you're
out
of
date.
You
you
need
to
come
up
to
date
first,
so
the
bootstrap
process
is
how
we
make
sure
we're
up
to
date
and
enjoying
B
system
as
as
as
one
of
the
as
one
of
things
I
do.
A
A
A
A
So
we
can
handle
probe
and
it
was
either
a
and
if
you're
one
of
the
running
systems-
and
you
got
the
probe
or
if
here's
the
new
guy
starting
up,
then
you
got
a
reply
and
when
you
get
a
probe,
you
just
say
you
validate
that
it's
someone
who
maybe
should
be
talking
to
you
and
you.
If
you
are
not
part
of
the
system-
oh
yeah,
okay,
sorry.
A
Right
if
we
get
a
probe-
and
we
say
oh
you're
way
newer
than
we
are-
that
we
better
start
over.
Otherwise
we
just
replied
to
them.
With
the
monitor
map
that
we
have
to
make
sure
that
they're
up
to
date
with
who's
supposed
to
be
in
the
system
and
the
patches
versions
that
we
have,
then
the
bootstrapping
honor
gets
that
reply
and
E.
B
A
So
when
you
start
up,
this
is
dealing
with
the
many
different
ways
we
gives
you
to
start
up
monitors,
so
you
can
turn
them
on
just
by
you
can
turn
on
a
new
monitor
just
by
giving
it
the
IP
addresses
of
one
of
the
existing
monitors,
in
which
case
it
will
create
a
temporary
Mon
map
that
has
the
month
the
other.
The
other
monitor
as
a
no-name
monitor
with
the
IP
address,
and
so
we
want
to
give
it
its
real
name,
which
will
usually
be
a
or
B
or
C
or
whatever.
A
A
A
If
the
message
said
that
they
had
a
quorum,
that's
cool
if
we
were
somehow
part
of
the
quorum
like
because
we
rebooted
and
the
timeout
had
any
timeout
for
the
quorum
ending
hasn't
it
hasn't
heard
for
the
quorum
like
failing,
hasn't
ended,
yet
that
we
must.
Let
me
just
start
a
new
election
starting
elections
is
how
we
enter
a
system.
A
And
that's
the
basics
of
bootstrapping,
so
this
this
election
thing
is
an
important
part
of
set
of
other
stuff
packs
of
system.
In
some
types
of
systems
you
can
just
join
an
existing
system
and
be
like
hey
I'm,
alive
now
and
then
you'll
start
like
getting
the
and
you'll
just
join
automatically
join
at
the
pion
or
in
some
systems
are
out
leader
election
and
everyone
can
propose,
and
so
you
just
start
receiving
the
proposals
and
you
can
promote
yourself
and
Seth.
A
You
can't
do
anything
if
you're
not
part
of
the
quorum,
and
so
if
you
want
to
join
the
quorum,
you
start
an
election
and
if
someone
else
wants
to-
and
if
someone
knows
notices
that
the
time
out
happens,
you
just
starting
to
laugh.
Everything
is
on
starting
an
election
and
then
the
quorum
consists
of
whoever
the
quarren
consists
of
a
leader,
which
is
the
person
who
won
the
election
and
then,
whichever
replicas
or
peons
they
and
acknowledge
them.
When
they
do
the
finish
so,
elections.
A
Elector,
as
this
name
implies,
its
job
is
just
the
handle
elections.
It's
the
logic.
It
can
Scott
an
election
logic,
state
that
handle
sort
of
and-
and
this
really
exists
so
there's
unit
testable
and
that
handle
is
the
logic
of
dealing
with
the
IDs
and
the
proposals
think
like
the
monitor
ID
and
whether
it's
submitted
to
propose
or
aren't,
accept
or
something
and
the
Elector
class
itself
deals
with
the
messages
and
the
time
outs.
A
A
A
So
the
election
message
is:
have
this:
have
this
type
and
we
just
dispatched
them
down
to
the
elector.
A
A
A
A
A
So
if
we
have
a
lower
number
than
them,
then
we
would
win,
and
so,
if
we
are
already
handling
an
election
and
we've
acknowledged
someone
else,
then
we
don't
care,
because
we
have
already
voted
for
someone
else.
In
the
end,
the
ordering
estatic
otherwise
hey
I
should
win
so
I'm
going
to
propose
an
election
to
everybody
else.
A
A
A
We
make
sure
that
we're
up
to
date-
or
we
start
over
again
and
if
we
then
got
an
AK
from
everybody,
then
we
get
to
declare
victory,
which
consists
of
sending
out
a
victory
message
and
then
waiting
to
get
to
get
another
victory
act
from
from
our
peons.
If
we
don't
get
the
victory
act
in
time,
then
we
can
also,
then.
B
A
Alright,
so
let's
go
look
at
the
monitor
some
more
then
it's
look
at
the
win
election,
just
a
transition.
So
when
you
an
election,
then
you.
A
We
are
the
sort
of
interesting,
so
the
monitors
all
need
to
have
the
same
set
of
commands
or
you
get
some
even
if
they
might
be
different
versions
because
you're
doing
upgrade
so
we
actually
set
Soviet
leader
actually
provides
the
villain
commands
to
the
monitors
and
it
sends
them
out
and
then,
if
the
monitor
gets
a
command,
it
doesn't
recognize
sort
of
scored.
The
leader
commands
that
it
just
forwards.
It,
though
we
tell
pacs
us
that
were
the
leader
and
that
we've
won,
we
tell
our
mom
map,
monitor
that
we've
finished
an
election.
A
A
A
There's
some
common
stuff
yeah,
so
we
have
to
take
the
quorum
to
our
feature,
lists
and
oh
yeah,
so
routed
requests.
I
will
talk
about
router
requests
in
a
bit
okay,
but
that's
important
resending
room
because
the
leader
might
have
changed
and
we
were
out
requests
to
leader,
sometimes
okay.
C
A
Yes,
that's
important,
the
monitors
are
else,
they
say,
I
mean
are
all
more
or
less
single-threaded.
A
They
run
on
the
they
run
on
the
main
dispatch
loop,
so
messages
come
in,
they
get
put
into
this
badge
and
they
get
operated
on.
This
is
important
because
the
packs
of
system
needs
to
be
strictly
ordered,
and
so,
if
we
get
far
enough
along
I,
see
a
lot
of
checks
for
that
and
and
the
single
threading
is
part
of
how
we
like,
we
could
shard
it
up
into
multiple
threads,
but
we
haven't
done
any
other
work
for
that.
C
A
A
So
there
can
be
several
different
message
types.
Many
of
them
will
be
if
you're
doing
something
on
the
command
line
that
like
Seth
Oh
it
set,
Mon,
OSD,
update
or
whatever
will
be
of
the
command
type.
So
the
monitor
realize
that
it's
command,
it
sends
it
into
the
handle
command
function,
and
this
runs
through
some
checks
and
eventually
it
says.
A
A
A
That's
been
in
a
while
right,
it's
the
important
bit
an
attack,
so
service
class,
there's
two
important
functions
that
the
children
implement.
Those
are
pre-processed
query
and
prepare
update,
so
the
peons
have
Lisa's
the
line
of
the
server
reads,
and
so
pre-process
query
is
how
you
is,
is
how
you,
how
you
deal
with
reads
or
writes,
to
discover
that
you
need
to
handle
them
and
preach,
so
you
send
in
a
send
and
hop
in
to
pre-process
query,
and
if
it's
a
read
you
can
serve
any
understand
it.
A
You
can
serve
it
locally,
but
if
it's
bright
you
can't-
and
in
that
case
you
return
false
and
then,
if
it's
something
that
and
that
tells
the
fact
of
service-
okay
I
can't
deal
with
this
deal
with
this
as
a
deal
with
this
without
doing
an
update.
If
you
are
not
the
leader,
you
then
need
to
actually
submit
the
message
to
the
leader,
so
we
just
forward
that
what
time
is
it
we're
about
halfway
through
okay?
So
we're
not
gonna
look
at
the
details
of
the
system,
but
we
forward
the
request
to
leader
and
that.
A
And
so
we,
and
so
we
have
this
routered
request
thing
and
an
important
message
that
wraps
up
the
actual
message
and
we
send
that
off
and
we
insert
it
into
the
routed
requests
map
which
you
might
recall
during
the
with
wound
connection
election.
We
are
resetting
the
read
request
to
the
new
leader
and
then
once
the
message
of
rise,
the
leader,
it
goes
to
the
normal
request,
processing
flow,
so
it
gets
pretty
processed
and
it
was
just
a
read
that
the
peon
didn't
understand
because
it
was
out
of
date
it
gets
handled.
A
Otherwise
we
will
prepare
update.
We
have
to
wait
repair
the
update
until
the
local
packs
of
services,
readable
or
sorry
its
writable,
when
updates
are
in
progress
because
we
are
in
the
process
of
committing
a
new
OSD
map,
then
we're
not
writable.
So
we
have
to
wait,
in
which
case
it
just
goes
onto
a
retry
list.
But
then,
eventually
we
are
ready
to
prepare
an
update.
A
And
then
we
will
process
the
message
appropriately
and
then
hopefully
we
return
true.
If
we
still
need
to
return
true,
if
we
made
an
update,
we
might
not
return
true
because
it
turns
out
to
be
a
valid
update
or
because
it's
a
duplicate,
update
or
something
in
which
case
we
don't
need
to
do
anything.
Otherwise,
the
packs
of
service
may
say.
Oh,
we
need
to
propose
something
immediately
or
what,
like.
C
A
For
proposes
practice
languages
when
you
want
to
make
an
update
to
Paxos,
you
propose
the
update
from
the
leader
the
route
to
the
peons,
and
then
they
acknowledge
it,
and
then
it's
committed
once
and
it's
committed
once
a
majority
of
the
system
in
his
has
written
it
down
to
this.
But
the
way
you
know
it's
committed,
isn't
getting.
It
get
an
acknowledge
message
from
the
majority
of
the
system.
A
It's
been
a
while,
since
I've
looked
at
this,
so
I
make
it
a
little
more
hesitant,
but
so
we
have
a
timer.
We
propose
every
and
seconds
if
nothing
else
has
happened
and
we
have
updates.
This
is
sort
of
and
there's
a
lot
of
heuristics
here.
That
really
exists
because
we
want
to
propose
regularly
in
order
to
maintain
progress.
For
instance,
if
you're
like
the
OSD
map
needs
to
get
updated
for
needs,
sometimes
need
to
get
updated
priorities
finish
peering,
so
you
want
that
happening
quickly
like
if
you're
an
appearing
storm.
A
A
A
And
then
all
right,
I
guess
it's
actually
it's
a
full
OST
map
and
then
it
creates
an
incremental
and
in
the
pending
anyway,
it's
sort
of
the
state
that
the
system
is
going
to
go
into
once
we
commit,
and
then
we
say
that
we're
proposing
we
set
up
timeouts
and
finishes
well.
Actually,
okay,
did
we
get
rid
of
it.
A
A
The
transaction
is
sort
of
the
instructions
to
the
monitor,
store
to
how
to
make
the
update
that
we
want
to
make,
and
then
we
send
a
message
asking
all
the
others
to
again
with
this
new
proposal
number
since
we're
the
leader,
assuming
that
we
aren't
they
assuming
we're
still
the
leader,
then
this
is
just
and
we
haven't
timed
out
without
noticing
it.
Then
this
is
just
going
to
go
through,
but
we
send
them
a
message.
Saying:
hey
you
get
a
new
value.
A
A
A
So
we
decode
the
command.
We
have
a
standard
command
format
that
we
use
for
sending
them
along
the
wire
and
then
there's
the
prefix
is
sort
of
is
the
the
actual
command
ID,
and
this
is
a
little
bit
messy
parsing.
But
it's
it's
a
consistent
system
for
us
throughout
mostly
monitor
you
will
compare
the
prefix
and
try
and
find
them
when
it
matches
to.
Oh
sure
it
looks
like
a
crush,
so
we
want
to
set
a
crush
map.
A
And
in
prepare
we're
not
gonna,
be
able
to
actually
do
the
update
because
we're
only
preparing,
but
we
want
to
validate
it,
that
it's
a
valid
crush
map
to
set.
So
we
make
sure
that
we
can
decode
it.
And
if
we
can't,
then
we've
set
an
error
that
it's
invalid
and
reply
which
we'll
look
at
in
eventually.
A
B
A
A
A
A
We're
just
going
to
wait
for
a
new
commit
to
happen
because
it
all
because
the
new
crush
map
isn't
super
urgent
and
it'll
it'll
happen
within
a
couple
of
seconds.
Anyway,
or
possibly,
we
found
a
felony
or
develop
an
error
during
validation
that
it
was
invalid
or
that
it
had
already
been
done
or
something
in
which
case
we
just
replied.
A
Okay,
that
was
a
bit
messy,
but
that's
sort,
that's
sort
of
the
basic
message
below
and
it's
actually
kind
of
an
intro,
so
we
got
13
minutes
left
I
can
pick
out
something
else,
but
this
is
a
good
time
for
questions.
If
there
are
things
that
people
want
to
know
about
in
general
and
the
monitors
or
in
something
specific
that
we
saw
today.
A
A
A
A
A
So,
like
any
monitor
is
allowed
to
anchor
is
allowed
to
increment
the
epic
and
call
an
election,
and
so,
if
you're
joining
you,
but
you
need
to
be
a
newer
like
if
you're
trying
to
join
a
quorum
that
you
weren't
in
before
you
need
to
be
a
newer
election
epoch.
This
is
just
I
mean
it's
the
standard
trick.
You
have
a
number
that
continuously
increments
to
make
sure
that
you're
all
the
way
up
to
date
and
that
you're
not
like
processing
old
messages
from
any
previous
epoch
or
some
or
something
of
that
nature.
B
A
So
the
the
monitors
TV
store
is
a
key-value
TV,
which
is,
and
a
key-value
TV
I
believe
is
in
this
common
code.
But
it's
a
it's
a
wrapper
of
key-value,
but
basically,
what
this
is
doing
is
just
wrapping
up
nowadays
rocks
TV,
originally
local
TV
for
us,
so
the
monitor
storage,
it's
all
key
value
based
and
it
this.
This
monitor
TV
store
class
mangles.
A
Sorry,
the
the
packs
of
services
will
sort
of
will
say,
hey
store
and
then,
if
mangoes,
together,
the
pack
so
service
name
with
like
OSD
map
and
the
with
OSD
map
and
an
epoch
number
to
just
turn
them
in
to
turn
in
the
key
value.
Access
isn't
that
the
OSD
monitor
has
into
straight
key
names
and
the
values
that
are
associated
with
them.
A
B
What's
rig,
yep
I
was
recently
trying
to
make
some
fix
so
I
had
any
questions
about
the
pending
incremental
map.
So
I
was
wondering
if
the
pending
incremental
map
is
is
kind
of
refreshed
for
each
a
talk
or
what?
What
is
the
life
cycle
of
that
pending
incremental
map?
I
was
just
trying
to
understand
that
the.
A
A
A
So
the
actual
service
class
logic
works
in
terms
of
a
logical
pending,
although
it's
all
maintained
by
the
by
the
subclass
implementations,
but
that
pending
will
be
created
on
the
leader
when
it
becomes
the
leader
or
whatever
it
is
encoded.
Whenever
it
does.
Whenever
decides
to
compose
an
update,
I
think
you
should
have
seen
that
going
by
and
it
can
be
discarded,
I
think
when
it
needs
to
reset
so
the
OC
monitor
we
have
a
create
ending
and
it
when
you
create
a
pending.
A
A
B
Something
simple
like
like
a
down
stamp:
for
example
within
the
was
the
X
info
and
I
wanted
that
information
to
be
committed,
so
I
was
trying
to
understand
the
flow
of
how
we
go
about
committing
things
into
the
first
you
to
be
pending
incremental
and
then
finally
find
it
to
be
disk
or
wherever
into
the
host
map.
Okay,.
A
So
we
actually
the
the
the
down
flags
are
bit
messy
are
bit
weird
we
have
and
the
incremental
has
this
pending
OSD
state
set
map
from
the
OSD
and
then
it
X,
and
then,
when
you
apply
an
incremental,
you
X
or
I,
think
it's
how
it
works,
or
maybe
the
presence.
Now
the
president's
just
means
swap
from
previous
I
think,
which
is
an
expert
but
anyway.
A
B
A
And
it
will
then
encode
it
immediately
and
send
it
out,
and
at
that
point
the
proposal
is
happening,
but
the
OSD
met
and
the
OSD
monitor
system
is
no
longer
writable.
It's
readable,
while
they're
happening
I
think
but
I'm
suddenly
not
writable.