►
From YouTube: Pairing on spiking out a developer framework for adding data types to be replicated by GitLab Geo
Description
Working on issue titled "Geo: Spike Self-Service Framework with Package Files": https://gitlab.com/gitlab-org/gitlab/issues/197319
A
Okay,
go
ahead,
so
we're
going
to
start
putting
some
code
out
and
I
think
what
Mike
and
myself
we
want
to
figure
out
is
like
the
initial
direction
on
the
documentation
that
Tom
books
there
I
think
we
are
going
to
start
by
the
replicator.
Is
that
correct
yeah
so
that
there's
there's
that
the
proposal
don't
put
there
is
a
little
bit
different
than
mine
and.
A
I
think
we
can
layer
on
abstract
a
few
things
on
that
initial
code,
but
because
the
code
base
has
so
many
technical
depth
right
now,
I
think
it
will
be
a
little
bit
difficult,
but
we
can
aim
to
go
that
direction,
but
I
would
like
us
to
start
more
or
less
from
what
I
started
or
maybe
improve.
On
that
thing,
please
share
your
feedback.
D
D
B
B
You
the
first
option
that
you
had
showing
before,
which
is
now
removed,
was
kind
of
what
Gabriel
had
more
in
mind.
I.
Think
and
I.
Don't
know
if
you
saw
that
Gabriel,
but
I
think
it
makes
sense
to
start
with
that,
and
it
will
be
a
little
bit
easier
to
transition.
Maybe
but
yeah
I,
don't
I,
guess
I'm,
saying
I
I
pushed
tone
to
remove
one
and
that
happened,
but
I
think
we're
all
okay
with
going
the
other
way.
First,.
A
Also,
one
thing
that
I
had
in
mind
with
that
proposal
is:
it
looks
a
lot
like
a
message
broker
or
a
message
gives
this
in
or
something
like
that
they
put
in
a
way
and
that's
on
purpose,
because
I
really
want
us
to
try
Dublin's
idea
of
having
a
different
message
queue
system
replace.
Even
we
I
think
like
that.
A
The
natural
progression
will
be
to
move
from
the
current
queue
to
the
unified
queue,
but
then
try
to
compare
that
with
what
our
options
the
unified
queue
would
help
us
reduce
the
amount
of
migrations
we
need
to
to
do,
but
maybe
something
else
like
either
wrapped
him
here
or
not,
say
or
whatever
else
having
to
final
solutions.
It's
easier
to
to
see,
benefits
and
downsides,
like
I,
think
that
this
the
current
proposal
allows
us
to
move
to
idea
of
those
directions,
bigger
change,
that's
what
I
had
in
mind
when,
when
I
was
designed.
B
B
A
Yeah
I
think
that
any
improvement
on
that
side
would
probably
we've
arrived
from
the
unified
queue.
To
be
honest,
I
don't
think
that
if
maybe
we
can
improve
something
on
the
code
base
today,
but
I
don't
think
we
would
be
able
to
like
to
make
a
big
dent
in
that,
like
the
unified.
Here
is
probably
the
best
way
to
improve
that,
because
then
you
have
like
one
way
to
do
it
or
not.
A
That
the
backfill-
maybe
at
least
for
their
posters
when
we
sew,
let
go
back
a
little
bit-
that
one
issue
where
I
suggested
to
do
the
refractory
on
how
we
start
the
reporters
to
split
the
reporter
model
into
at
least
three
today
will
be
probably
four
because
snippets
is
also
becoming
every
poster,
and
that
would
probably
help
us
on
the
repo
stirred
kind
of
data
making
it
generalizable
will
be
easy,
but
that
doesn't
solve
the
other
types
of
data
types
we're
dealing
with
package
files
right
now
right.
So
these
are
probably
something
objects.
E
A
B
A
D
F
B
B
So
this
is
what
I
I
don't
know.
I
mentioned
this
one
time,
but
when
we
first
added
package
files
it
could
have
been
done
where
we
just
added
them.
It's
like
upload
or
I,
don't
know
there,
so
it's
so
close
to
just
like.
If
we
could
have
just
made
it
upload
and
then
we
would
have
gotten
the
geo
functionality
for
free,
so
I
don't
know
it's
kind
of
weird.
A
A
A
B
B
D
A
I
think
that
the
the
migration
to
object,
storage
is
was
also
another
reason
to
put
down
on
the
database,
but
then
they
because
they
wanted
both
sending
files
to
file
system
and
send
files
to
object,
storage
and
that
wasn't
supported
by
default
by
carrier
wave
I,
think
it
needed
approving
it.
I
think
it
does
still
need
the
pony,
so
they
they
try
to
reuse
the
same
codebase
and
no
one
really
cared
about
like
making
a
good
architecture
out
of
it.
So
that's
how
we
ended
up
with
current
state.
A
B
Like
it
was
a,
it
was
becoming
a
huge
mess,
but
it
was
also
like
I,
don't
know.
We
were
constrained
in
a
lot
of
ways,
because
everything
was
like
a
little
bit
different.
All
the
uploaders
were
already
a
little
bit
different
and
so
yeah
it
was
already
complex
and
then
it
added
like
it
doubled
the
complexity.
So
here
we
are,
but
I
don't
know,
and
there
are
even
there
have
even
been
efforts
to,
like
you
know,
get
rid
of
attachment.
B
A
H
I
J
A
A
D
I
D
K
K
G
J
D
D
K
B
A
A
For
example,
let's
say
that
the
event
is
generated
inside
a
search
class.
Then
that's
the
discharge
class
also
needs
to
have
the
replicator
is
instantiated
by
it,
for
example,
if
you're
removing
something
it's
in
that
service
class,
that
you
probably
have
all
the
context,
information
or
something
like
that,
but
if
you
are
just
creating
a
file,
maybe
it's
the
the
model.
A
H
J
L
B
A
J
K
B
A
E
D
I
K
K
L
A
A
Glue
the
two
together,
so
you
get,
for
example,
that
within
the
POC
one
thing
that
I
had
to
replicate
was
cash-poor
event,
and
that
was
not
attach
it
to
any
object
to
any
model.
So
that's
one
way:
it's
I
got
the
am
attaching
those
to
a
model.
Is
this
optional?
It
would
happen
in
most
of
the
case,
but
it's
not
mandatory.
A
Another
way
is
we
can
generate
different
events,
so,
if,
like
you,
can
create
a
source
repository
event
and
create
a
wiki
repost
or
event,
or
something
like
that,
because
you
can
name
the
events
whatever
you
want,
you
can
also
trigger
whatever
event
you
want
and
they
can
relate
to
each
other,
but
I
think.
Ideally
it
would
be
related
to
one
model
that
doesn't
have
to
be
active
record
but
can
be
an
action
action
boundary.
B
B
A
A
D
D
A
B
E
A
J
B
A
A
B
J
A
B
B
A
B
D
E
E
H
D
G
A
G
A
E
E
D
A
I
A
I
B
D
B
D
D
B
B
J
A
D
E
E
B
E
A
We
know
the
like
how
the
event
has
to
be
stored
right
now.
We
can't,
but
maybe
we
can
refactor
it.
So
the
replicator
also
does
the
same
thing,
but
if
we
just
want
to
move
for
now,
I
think
we
should
create
a
new
event
store
and
then,
as
a
second
step,
we
refactor
that
and
make
that
part
of
the
replicator
I
can
actually
start
looking
at
this
right
now.
Okay,.
A
A
B
A
A
D
A
B
A
L
B
A
A
A
L
What
if
we
create
a
new
table,
we
have
some
field
and
we
point
this
to
the
Jew
event
logs
state
table
as
with
each
day
and
on
the
same
ii
don't
know:
do
you
have
a
new
event
that
you
read
this
new
new
kind
of
events
that
come
from
this
table
and
he'll
be
able
to
trigger
repeated
service
or
consumer
just
the
year
and
in
the
future,
and
your
spirit?
Migrating,
for
example,
have
five
data
types
and
out
for
three
of
them
are
red
using
this
new
table,
the
JSON
D?
L
B
B
D
B
L
B
A
L
B
D
D
L
L
B
A
A
B
H
B
H
Yeah
that
makes
sense,
I
was
thinking
about
the
cases
where
you
may
have
geo
enabled
you've
had
a
secondary,
informit
ever
reason.
You've
disconnected
it
so
you're
in
a
state
where
you
have
a
primary,
but
all
your
secondaries
are
disconnected
and
I
was
wondering
what
happens
when
you
reconnect
them,
but
I
could
guess
that's,
probably
quite
a
different
problem
to
be
dealing
with
I
hope
you
outside
the
scope
of
this,
in
any
case,
actually.
B
A
But
the
reason
why
I
put
this
right
there
is
that,
when
you're
setting
up
Geo,
you
start
by
setting
up
the
primary
and
then
you
do
the
initial
backup
or
you
do
the
initial
backup
and
then
you've
enabled
primary
I,
don't
know
which
order
we
suggest,
but
until
we
enable
the
secondary
there
is
no
replication
going
on.
But
if
we
start
generating
events,
when
you
set
up
the
primary
that
means
Q
is
enabled
for
code
base.
That
will
generate
those
events
and
there
is
less
things
to
back
few.
A
On
the
other
hand,
someone
may
be
trying
geo
they
set
up
the
primary,
they
turned
off
the
secondary
and
they
forget
to
delete
the
primary.
We
will
still
be
generating
those
events,
and
maybe
that's
why
this
code
is
here,
so
you
hit
in
this
way,
but
I'm,
not
sure
if
that's
something
we
can
continuing
or
not.
So
that's
why
the
question.
A
B
A
B
L
I
L
L
A
Can't
we
just
does
the
model,
has
the
information
of?
Can
we
struck
that
information
from
the
bottle
itself,
like
from
activity
record
itself,
I
think
we,
if,
let's
say
all
the
models
of
other
models,
have
the
same
relation
name.
Let's
say
it
is
Gia
log
or
something
like
that.
Something
internally
does
know
how
to
to
map
to
the
the
Frankie.
You
know
way:
I.
L
A
L
L
L
Yeah,
well,
we
are
going
to
do
that.
Nick
this
Evan
seeker
right
now
and
just
make
it
work
for
the
Juke
events
that
the
new
table
that
you
created
right
now
and
in
the
future
in
situ
migrates
this
other.
There
is
odd
events
to
the
new
table.
We
migrate
the
entire
offense
to
this
new
table
as
well.
You
don't
need
to
make
this.
L
A
Sorry,
for
example,
when
but
I'm,
just
let's
say
that
you're
creating
the
publish
created.
So
what
it
will
have
is
like
this.
Instead
of
create
cutting
and
creating
the
event
star,
we're
doing
the
same
thing
but
inside
of
the
replicator
itself,
and
then
in
the
future.
This
can
be
whatever
else.
We
want,
for
example,
can
be
calling
Kafka
or
Rabkin
key
or
something
different
yeah.
L
A
We
can
just
add
this
definition
on
the
bother
itself,
so,
instead
of
it
being
in
the
Winstar
or
here
it
is,
we
can
just
ask
that
as
well.
Here's
of
like
that.
But
if
we
just
write
it
on
the
model,
then
we
don't
have
to
do
anything
because
the
other
alternative
is
let's
open.
One
fire
here
can
be
the
same
cash
catch,
something
cache
invalidation
that
store.
D
D
A
H
A
B
B
A
L
D
B
A
A
A
It
can
be
simplified
in
in
a
different
way,
and
maybe
we
don't
even
need
to
do
this
thing,
because
the
publisher
will
know
where
to
start
the
whole
data,
so
we
can
skip
this
whole
method
and
if
we
go
to
a
message
broker,
we
don't
need
that
either.
So
this
is
just
because
we
have
to
have
the
things
in
the
way
we
have
right
now.
Okay,.
A
Is
what
when
you
call
go
back
to
the
replicator?
Well,
when
you
go
publish
and
you
pass
David?
Oh,
we
have
the
name,
but
it's
not
event,
I
think
yeah,
but
this
is
like
created
and
then
you
pass
all
the
data
if
you're
using
the
healthy
one
of
the
things
that
I
do
pass,
is
it's
slow
model?
So
if
you
are
in
the
projective
it
it
will
pass
the
project
model
and
the
instance
other.
So
you
can
poke
around
on
events,
but
it
also
accepts
I
betrayed
parameters
and
that
can
be
useful.
A
A
B
A
B
I
D
G
D
A
A
D
B
A
D
M
A
J
K
D
B
L
L
L
B
D
K
K
B
I
I
I
I
I
I
K
L
A
B
B
A
A
B
B
B
A
L
A
If
we
we
start
on
the
the
class
itself,
as
we
are
doing,
for
example,
with
model
I,
think
we
start
on
the
I.
Don't
oh
we're
not,
but
if
we
start
we
can
assume
that
it's
then,
when
we
are
calling
we
just
we
reassign
it.
But
then,
if
you
would
at
some
point,
we
we
use
the
replicator
and
we
don't
resent
it
corrected.
Maybe
we're
straining
30
later
something
like
that
and
I.
E
B
D
B
B
L
B
B
D
B
B
L
D
B
B
A
One
thing
that
we
can
do
is
create
a
different
method.
That
is
not
just
great
event
with
that.
Just
followed
the
new
unified,
cue
approach
and
that
fills
up
a
few
things.
For
example,
this
is
like
the
margin
Eric
one
that
will
work
with
the
old
events,
but
you
can
make
anyone
that
already
follows
some
structure
or
anyone.
Yeah.
D
A
D
I
L
A
D
I
I
I
L
L
L
B
B
D
A
Think
I
remember
why
I
had
a
lamented
I
advanced
marketing
and
why
I
had
like
to
describe
the
existence
of
an
event
it's
for
the
Geo
Locker.
Sir
part,
the
idea
I
had
in
mind
is
that
you'll
register
the
support
replicators
and
the
cursor
will
like
infer
all
the
events
that
it
can
handle
based
on
replicators
and
not
based
on
something
that
is
hard-coded
one.
Why,
and
why
that
that's?
Why
there's
like
this
reflection,
support
on
the
replicate
itself.
A
L
B
J
A
A
A
I
A
B
But
I
still
so
I'm
still
looking
at
that
event.
Name
is
outside
of
payload
here
and
that's
fine,
because
II
that
name
comes
out
here
and
then
getting
a
load
with
params
from
here.
Okay,
so
pram,
so
he's
two
different
things
here,
so
maybe
I
don't
know,
maybe
it'd
be
worth
naming.
There's
something
else
payload
this!
It's
fine
here,
okay,.
D
B
L
D
C
D
L
B
K
K
A
A
E
A
J
G
I
D
B
M
A
A
But
at
the
same
time,
it
can't
right
now,
because
we
want
to
make
sure
it's
being
stored
there
I,
don't
think
it
needs
to
be
integration
test.
We
can
do
this
as
a
unit
test
for
the
replicator
perhaps,
but
it
will
work
almost
as
an
integration,
because
if
you
create
the
model
and
it
will
check
on
the
queue,
if
that's
they're-
not
mm-hmm,
that
makes
sense
yeah.
A
And
the
tests
will
be
more
or
less
like
when
something
is
created.
We
expect
the
whole
block
to
create
a
new
model
on
the
database
itself,
like
that,
we
expected
to
persist
this
event,
and
this
whole
idea
of
persisting
an
event
can
also
be
extracted
as
a
helper,
something
it's
like
a
help
or
something
that
it
is.
You
won't
like
code
that
says
something
like
expect
this
to
generated
you
event
with
this
information,
and
we
can
assume
everything,
but
maybe
the
first
iteration
is
to
write
the
actual
test
and
then
extracting
to
something.
K
F
B
K
K
A
K
B
A
D
F
M
D
E
D
A
D
A
B
B
D
D
D
A
I
M
E
J
G
F
A
H
B
A
D
E
A
B
H
A
K
I
G
K
A
D
D
A
J
B
K
A
A
M
B
M
M
I
K
K
B
C
A
A
The
idea
is
that
we
are
going
to
remove
all
the
events.
Cars
anyway.
I
think
we
can
call
it
event,
name
because
it
scraps
it
better
and
like
this
is
like
ass
code
that
we
want
to
improve
anyway,
all
right,
because
it's
not
not
actually
a
type
and
they're,
not
instantiate.
In
anything,
you
already
turn,
and
the
name
is
actually
a
better
description.
Pretty.
B
B
B
You
yeah
so
okay,
alright,
well,
I!
Guess
we
can
just
call
this
meeting
a
success.
I
think
yeah.
We
got
through
a
lot
so
and
we
have
a
test:
that's
starting
to
come
along
for
the
replicator,
creating
an
event
and
that
will
have
been
a
lot
I
think
for
one
day
and
we've
talked
about
some
design
considerations
between
you
and
I
and
Douglas,
so
yeah
I
think
that's
going
well!
Yeah
all.