►
From YouTube: 2021 06 21 APAC Sharding Group Sync
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).
B
You
yeah
good,
I
woke
up
to
like
I.
I
had
it
on
the
list
to
review
the
release
post.
Oh
yes
and
I
I
think,
there's
some
confusion
around
what
deprecating
something
means
and
what
removing
something
means-
and
I
think
I
I
may
want
to
like
record
a
small
video
on
what
these
things
mean,
because
it's
it's.
It
gets
confusing
when
people
use
these
things
differently
right
and
then
it
gets
confusing
for
our
customers.
B
A
B
Oh
yeah,
that's
exactly
what
I'm
looking
at
because
like
it
like
once
you
understand
this,
I
feel
it's
actually
simple
right.
It's
like
do
you
want
to
talk
about
things,
something
that
you
will
remove,
remove
at
some
point
in
the
future.
That's
a
deprecation!
You
know.
Are
you
removing
something
like
this
release?
That's
a
removal
right!
So
it's
a
yeah
but
the
it
gets
confusing.
B
Well
also,
I
think
then
at
least
from
me
reading
through
it.
It
really
helps
if
people
are
very
explicit
about
what
they
are
actually
deprecating
or
removing
right
and
like
if
I
see
a
deprecation
notice
or
removal
notice
that
doesn't
use
the
the
terms,
deprecation
or
removal.
I
get
really
confused
because
I'm
like
I
don't
understand
anymore.
What
you're
doing
yes
like
it's
like,
for
example,
like
we're
using
ruby
three
now
for
our
like
auto
devops
pipeline,
it
used
ruby
2.5
before
I'm
like.
B
Okay
is
ruby
2.5
gone
right,
that's
a
removal!
Is
it
something
that
we
shouldn't
do
anymore
right,
but
it
still
kind
of
works
right
and
we
will
remove
it
later.
That's
a
deprecation
then,
like
just
tell
me
right,
and
so
I
think,
there's
maybe
an
opportunity
to
just
do
a
five-minute
terminology
review,
because
it
is
confusing.
A
B
It
doesn't
help
that,
for
example,
now,
like
I
made
a
suggestion
last
release
where
deprecation
notices
in
the
release
post
had
a
a
due
date
that
was
rendered,
as
I
can't
even
remember
what
it
was
landed.
But
what
it
actually
is
is
the
removal
date
right,
because
that's
what
you
are
putting
in
to
a
deprecation
right,
you're
saying
I'm
deprecating
it
now
in
this
release
and
it
will
be
removed
in
three
releases
or
in
a
year
or
whatever,
but
they've
changed
how
it
is
rendered,
but
they've
not
changed
the
yaml
field
name
right.
B
B
C
Yeah,
I
would
love
to
kick
it
off.
I'm
excited.
What
did
I
write?
Okay,
yeah
looks
like
craig's
already
responded
to
me,
but
basically
I've
written
down
a
plan
already
for
what
we're
going
to
do
in
terms
of
migrating
the
ci
tables
to
a
new
database
with
a
minimal
downtime
process.
That's
in
the
merge
request
there.
C
A
lot
of
we
talked
about
earlier
on
in
this
project
was
like:
okay,
migration
helpers
application
code.
That's
going
to
help
us
perform
this
migration,
but,
given
that
we're
dealing
with
like
five
terabytes
of
data,
we
just
don't
want
to
be
copying
data
across
like
that
it
will
be
really
impractical.
So,
where
we've
landed
is
more
like
an
outside.
The
gitlab
application
replicate
state
in
databases,
point
dns
records
around
and
hey
presto,
we've
moved
everything,
but
what
that
means
is
it's
like.
C
The
whole
plan
there,
which
is
somewhat
lengthy,
is
all
outside
of
the
gitlab
application,
so
it
would
be
yeah.
It
would
be
beneficial
to
get
involvement
from
infra
earlier
on,
even
if
it's
just
like
glance
at
that
and
tell
us
if
we
are
on
the
wrong
track
or,
if
they're
just
completely
unwilling
for
us
to
tackle
it.
That
way,
and
then
we've
got
to
come
up
with
a
different
proposal.
B
B
Yes,
like
my
suggestion,
would
be
so,
if
I
understood
correctly
from
from
last
week,
there's
a
request
out
to
actually
get
an
sre
as
sort
of
a
stable
counterpart.
I
think
that's
going
to
be
quite
important.
I
would
just
ping
people
early
on
it
right
now
and
if
we
get
sort
of
engagement
in
a
timely
manner,
we
have
no
issue.
If
you
don't
hear
anything,
then
I
think
we
need
to
review
and
say
hey.
B
C
Okay,
I
had
the
next
one
on
there
too,
which
was
around
the
migration
plan
which
I've
written
up.
If
we
go
ahead
with
our
ci
instance
variables.
Moving
that
to
a
separate
database
and
being
that,
as
our
first
objective
it'll,
be
a
little
bit
two
steps
forward
and
one
step
backwards,
because
we'll
be
writing
code
to
migrate.
C
So
I
like,
I
said
I
think
it
might
be
fine
for
it
to
be
two
steps
forward,
one
step
backward
if
it
allows
us
to
start
writing
the
application
code
and
a
lot
of
things
ahead
of
time.
We're
getting
a
lot
more
clarity
on
this
stuff
now
and
they're.
Just
the
ci
instance.
Variables
plan
is
not
necessarily
as
aligned,
but.
D
I
I
don't
think
that
this
is
like
a
problem.
I'm
kind
of
like
thinking
that,
like
we
just
have
like
two
parts
like
one,
is
like
the
big
migration
and
second
one
is
like
application
changes.
The
tricky
part
is
like
if
we
follow
the
run
like
your
model
like,
we
can
not
surely
run
the
migrations
that
we
will
define
in
the
ci
path.
D
That's
that's
the
main
difference.
So
then
the
question
is
like
how
we
can
ensure
that
the
schema
of
the
ci
bus
after
migration
is
exactly
the
same
that
we
intend
this.
Might
this
schema
to
be
because
this
would
be
like
the
potential
problem
to
have,
but
I
I
guess
this
is
more
like
the
migration
validation
step
to
perform.
C
C
B
And
this
this
is
just-
and
you
can
tell
I
haven't,
read
this
in
detail,
but
this
is
essentially
like
handling
the
migration
on
on.com
in
production
right.
So
it's
assuming
a
certain
architecture
with
like
console,
patrony
and
so
on
and
so
forth.
For
now,.
D
Yes,
because,
like
we
want
to
like
do
it
with
the
minimal
downtime
and
like
force
by
lower
effectively
to
make
a
new
cluster
alterating
for
the
ci.
That's
really
like
that.
Yeah
the
whole
idea
behind
what
is
the
one
saying
then,
like
you,
actually
want
to
replicate
everything
and
drop.
What
is
not
needed.
B
C
C
If
you
want
to
refer
to
a
right
connection
to
the
database,
that
has
all
the
data
that
would
be
called
the
primary
primary
and
if
you
want
to
get
the
read
data
from
you
would
get
primary
replica
and
then
use
ci
primary
and
see
our
replica.
The
terminology
won't
work,
and
I
proposed
a
few
alternative
words,
but
I
mean
tong's
concern
is
legitimate,
that
it
doesn't
change
the
fact
that
rails
calls
it
the
primary.
C
D
C
Yeah
basically
like
I'll
put
like
an
example,
the
database
logs
will
say
like
db
duration,
primary
primary
second
and
then
you'll
have
db
duration,
ci
primary
duration.
Ci
primary
seconds,
like
that'll,
be
a
log
statement
to
explain
how
much
time
was
spent
in
the
database,
and
I
don't
think
we
want
to
have
this
and
it'll
also
be
represented
in
the
performance
bar
where
the
developers
see
already
the
word
primary
and
replica
used
in
the
performance
bar
and
it'll
stay
primary
and
then
primary
in
in
the
performance.
C
D
That's
the
tricky
part,
because
it's
the
problem
that
we
have
to
solve
anyway,
which
is
like
our
single
database
config,
contains
config
for
the
replica
and
the
priming.
So
there
is
actually
like
models.
These
are
two
distant
config,
so
I
think
we
need
to
model
that
after
listing
conflicts
and
then
your
db
role
is
exactly
your
connection,
name
from
the
from
the
config
line
from
the
database
yml.
And
then
you
don't
really
have
that
problem
with
like
appending
additional
role
to
the
existing
connection.
Name.
C
C
We
need
to
yeah,
but
I
agree
with
you
that
I
don't
know,
there's
also
a
communication
problem,
because
if
I
tell
you
I'm
talking
about
the
primary
database
that
I've
lost
the
ability
to
communicate
that
to
you
efficiently.
When
I
tell
you,
we
are
writing
code
that
is
dealing
with
the
primary
database
right
now
or
we
need
to
fix
up
the
code
part
that
deals
with
the
primary
database.
I've
lost
the
ability
to
communicate
that.
B
So
I
think,
just
from
my
geo
experience
we
had.
We
have
similar
problems,
it's
pretty
bad
right,
so
we've
started
essentially
only
referring
to
primary
as
sort
of
the
read
write
state
right
in
the
rather
than
a
name
for
something
because
it
can-
and
I
think
here
with
the
the
effort
that
we're
undergoing
it's
going
to
get
even
more
confusing
because
he
will
have
more
than
one
database.
That
is
beat
back
right.
So
maybe
we
should.
B
We
should
really
just
think
of
of
names
for
the
database
that
we
talked
that
we're
talking
about
and
then
talk
about
them
as
being
read
and
writeable
right
or
or
not.
Right,
because
that
that
is,
I
think
what
primary
and
secondary
were
meant
to
establish,
for
example,
within
the
petroni
cluster
right,
but
it
breaks
down
if
you
sort
of
span
it
like
across
those
things.
B
B
C
C
I
think
shared
is
also
a
good
word,
but
yeah
the
the
thing
I
want
to
think
about
to
how
we
communicate
it
to
other
developers
at
the
company.
We
want
to
be
like
super
clear.
Like
you
know,
there
are
two
databases
that
gitlab
works
with
the
shared
and
the
ci
databases,
and
you
know
most
people
are
going
to
just
work
with
the
shared
database.
B
I
like
shared
as
well,
but
you
know,
because
we
may
have
more
than
one
feature
database
as
well
at
some
point
right,
so
it
may
not
only
be
ci,
maybe
logs
or
archive
right,
where
we
name
it
after
what
it
contains,
but
shared
will
always
have
things
that
we
that
aren't
shared
or
common,
but
I'm
not
sure
that's
unique
enough
right
because
I'm
sure
there's
plenty
of
places
where
you
have
like
shared
things
going
on
in
code.
The
word.
C
B
D
B
B
I
mean
one
one
thing
to
like:
I
don't
know
like
we've,
just
moved
from
master
to
main
for
for
git,
right
and
but
main
is
not
really
the
thing
right.
If
you
were
using
ci,
then
it's
not
the
main
database
anymore.
Ci
is
right
so,
like
I
think,
shared
shared
fields.
D
That's
the
least
worse,
that's
tricky
because,
like
I
don't
know
like
it,
doesn't
feel
like
fully
correct
like
just
because,
like
we
have
minority
of
the
teachers
there,
we
still
gonna
have
like
the
ci
tables
for
a
very
long
time,
but,
like
I
think,
like
it's
still
indicating
that
like
without
these,
like
main
database
applications
still
cannot
function,
you
cannot
just
use
the
ci
database
for
it
to
function
so
you're
gonna
have
to
retain
this
for
very
long
time.
A
B
A
D
B
A
D
D
D
D
Like
as
of
also
the
configuration,
I
would
see
like
this,
let's
say
transformation
like
today,
we
have
load
balancer
key
under
configuration
database.
I
mean
in
ideal
world.
I
I
I
would
I
don't
like
using
graphical
through
out
of
the
database,
my
email
and
like
moving
away
from
from
this
like
way
of
indicating
graphical.
D
So
then,
I
think
it's
still
like
spirit
goal
for
the
gtk,
but
I'm
kind
of
considering
how
can
motivate
our
configuration
out
of
something
specific
by
using
replica
to
something
generic?
How
we
define
the
speakers
in
a
fresh
way,
because.
D
Because
like
why,
why
is
this
important,
because
this
allows
you
to
then
define
a
configuration
that
is
a
chartered
underscore
replica
and
clearly
indicating
the
models,
unlike
by
role
that
you
want
this
mother
to
always
be
using
replica
regardless?
What
else
you
do
today,
like
we
have
a
single
connection
and
like
we
have
pretty
complex
logic,
to
make
this
make
this
decision,
but
I
think
in
the
narrow,
the
sentiment
that
I
heard
from
it
is
like.
D
There
are
some
cases
that
we
we
could
really
always
use
replica,
regardless
of
the
system
state,
so
a
separate
connection
using
this
kind
of
database.
My
ml
would
actually
allow
us
to
define
how
you
want
to
access
data.
Is
it
like
always
replica,
or
is
it
more
like
a
session
based
based
on
context?
D
This
is
something
that
we
are,
I
think
missing
today,
and
this
is
something
that
we
can
probably
improve
because
also
like.
As
soon
as
you
add
the
config.
We
need
to
figure
out
how
we
fix
the
connection.
Copyright
on
active
record
base
for
the
load
balancer
stuff,
because
then
we're
gonna
have
a
single
session
for
many
databases
that
are
going
to
switch
over
between
primary
and
replica
and
do
not
start
have
to
fix
support
for
the
replication
lock.
D
So
that's
really
like
my
concept.
I
I
don't
know
how
we're
gonna
solve
this
replication
like
many
contexts,
because
we
need
to
fix
stickiness.
D
D
There
is
also
like
replication,
like
measurements,
want
to
to
figure
out
if
our
application
is
too
big.
So
I
think
this
is
the
first
battery
in
the
next
we're
gonna
be
reworking
our
replication
support,
repeater
support.
C
D
No,
you,
you
basically
specify
srb
record
and
we
do
on
the
application
site.
We
need
dns
to
find
all
the
all
the
hosts
via
service
discovery
to
which
we
connect
on
the
application.
It's
semi-dynamic
because
it's
not
updated.
It's
read
only
on
the
application
startup
I
think
or
like
when
the
worker
cycles,
so
it
doesn't
update
dynamically.
But
this
is
how
we
figure
out
all
databases,
so
we
don't
put
each
individual
host
in
the
load
balancer
host,
but
rather
we
put
a
slv
record
from.
C
Yeah,
so
we
won't
be
able
to
have
a
key
in
that
yaml
file,
that
maps
to
a
connection
pool
if
we
look
up
an
srv
record
and
generate
multiple
connection.
C
D
D
We
to
the
we
today
work
around
us
by
adding
local
answer
key
and
we're
implementing
that
connection
method
and
we
kind
of
create
connection
pull
of
the
connection
pulse
effectively
by
doing
service
discovery.
So
this
is.
This
is
no
missing
picture
of
the
race
six.
There
is
no
service
discovery
or
like
not
balancing
the
connections.
There.
D
In
ideal
world,
we
would
contribute
to
this
race,
I
think
in
today's
world
it
means
that
we
use
a
load
balancer
key
and
we
override
the
connection
so
probably
do
something
similar
to
what
we
we
actually
do,
some
exactly
what
we
are
doing
today,
but
I
think
it's
be
like
if
we
can
somehow
split
this
configuration
into
being
more
explicit.
D
So
I
don't
know
yet
exactly
how
this
design
gonna
look
like
in
the
edge.
I
don't
have
like
a
good
idea.
I
think
that
we
need
to
work
on
these
problems
once
we
have
many
databases,
software
to
see
like
how
we
can
make
it
work
with
my.
D
D
Here,
yes,
I
I
have
this
amount
that
I
started
rewriting
this
our
methods
in
this
session,
it's
kind
of
like
to
perform
my
key
half.
This
is
really
like
the
first
step.
The
next
obviously
like
doing
more
like
a
stack
based,
but
I
think
I'm
kind
of
thinking
that
like
as
soon
as
I
finish
that
I
will
probably
start
with
working
stickiness
to
be
more
model
based
instead
of
a
global
context
as
it
is
today.
D
C
Why
why
is
moving
the
stickiness
to
the
model
base
aligned
with
the
objective
you're
describing
of
using
rails
syntax,
like
does
rails
support,
model-based,
stickiness
or
you're,
just
seeing
that
as
a
performance
opportunity,
and
that's
why
you're
working
on
it.
D
Two
reasons
race
doesn't
suffer
stickiness.
The
stickiness
is
based
on
the
on
that
time.
D
It
kind
of
indicates
if
there
is
like
a
delay
of
like
two
or
three
cycles,
we're
just
gonna
stick
to
this
database,
but
our
stickiness
is
actually
looking
at
the
replication
log
and
then
our
application,
the
replication
lag,
is
dependent
on
the
database.
You
are
using.
D
So
if
you
are
sticking
to
the
say,
say
ci
instance
variable,
you
need
to
execute
read
of
the
verification
like
in
the
context
of
data
database
and
evaluate
that
today,
the
description
of
the
stickiness
is
defined
as
a
global
method.
Accepting
I
think,
the
the
first
parameter
being
a
key
which
is,
let's
say,
symbol.
Like
a
user.
D
Now
in
this
model,
you
will
have
to
transform
that
key
into
an
actual
model
to
know
the
connection
under
which
you
should
be
checking
replication
like
so.
In
my
sense,
I
think
it's
better
to
move
this
way
of
operating
into
model,
because
model
already
knows
databases
that
it
wants
to
use.
So
you
are
not
really
like
having
this
transformative
logic,
because
the
model
already
starts
describing
from
what
database
way
to
application
rack,
and
then
you
can
really
like
evaluate
it
on
top
of
model.
D
If
you
should
stick
so,
we
would
retain
the
current
stickiness
on
the
per
key
for
like
per
model
basis,
but
really
taking
back
out
the
database
effectively
holding
the
data
for
that
model,
because
if
you
stick
to
the
things
that
whatever
you
want
to
stick
to
this
here,
like
look
at
the
replication
out
of
the
ci
papers,
not
other
tables.
That's
that's
really,
like
my
perspective
on,
like
moving.
B
C
Yeah
it
did,
but
the
kind
of
next
topic
I
had
is
just
really
like.
I
think
what
camille's
talking
about
it
makes
sense
to
me.
It's
just
really
hard
to
know
how
deep
we
go
down
this
rabbit
hill,
because
some
of
it
is
not
essential
to
us
getting
gitlab
supporting
multiple
databases,
but
it
might
be
more
simple
for
developers
looking
at
the
code
so
anyway.
That's
that
I
don't
know.
That's
probably
just
me.
D
Yeah
so
like
like,
I
that
the
the
part
is
like
that
with
the
instance
variables,
it's
not
really
like
needed,
it's
going
to
be
needed,
the
more
we
move
more
tables,
because
we
leverage
stickiness
very
extensively
across
cold
ways,
and
this
has
become
a
problem
with
more.
B
B
Tongue
is,
is
yes,
kamin
is
not
true,
yet,
okay,
so
I'll
give
you
a
reminder.
So
the
reason
why
I'm
asking
is
that
for
me
it
is
important
to
have
a
place
where
I
can
essentially
surface
quickly
all
of
the
issues
that
all
of
you
are
working
on
regarding
to
sharding.
That
helps
a
lot
with
sort
of
asynchronous
just
checking
in
and
making
sure
that
things
are
are
available
also
for
craig.
I
think
it
helps
with
sort
of
question
number
four.
B
So
my
ask
is,
if
you
pick
up
an
issue
for
sharding,
please
just
label
it
with
sharding
active
that
makes
it
show
up
on
that
board,
and
then
you
know
we
can
like.
You
can
apply
the
correct
workflow
label
when
you're
working
on
it
or
investigating
it.
That's
maybe
a
second
thing,
but
that
would
be
amazing,
because
then
I
I
have
a
place
where
I
can
go.
Look
and
point
to,
as
the
like.
The
state
of
affairs
is
that
okay.
B
B
Yeah
that
just
describes
that
should
be
minimal
effort
right
and
if
you're
working
on
mr
doesn't
have
an
issue
create
the
issue
added
to
the
epics
right.
I
trust
that
all
of
you
are
able
to
do
that
and
then
the
last
thing
is.
It
sounds
to
me
as
if
everybody
is
actually
like
working
on
things
right
now
and
has
enough
to
do
and
we're
kind
of
clear
on
where
we
are
at.
But
I
want
to
make
sure
that
that
is
the
case,
because
otherwise
we
need
to
make
sure
that
we
get
that
clarity.
B
Cool,
that's
all
from
from
my
from
my
end,
I
am
around
right.
I'm
obviously
not
super
helpful
with
implementation
work,
but
I
am
very
interested
in
understanding
things
and
understanding
how
they
move
forward.
So
if
you
ever
have
a
like,
you
feel
like
you
want
to
have
a
chat
right
or
like
have
a
coffee
chat
and
just
outspect.
Some
ideas,
please
feel
free
to
reach
out,
but
I'm
I'm
trying
also
not
to
stand
in
your
way
while
you're
executing
on
those
things
just
so.
You
know.
B
Super
that's
all
from
my
end,
by
the
way
I
tried
to
explain
to
my
dad
on
the
weekend
what
we
are
trying
to
accomplish.
I
think
I
was
actually
relatively
successful
in
conveying
it,
and
so
I
feel
that
maybe
you're
not
a
bad
sign.
B
Yeah
you
know
like
honestly,
like
I,
I
still
think
like
I
do
this
every
my
my
father
tried
to
use
gitlab
and
he
is
not
able
to
like
figure
it
out
right
for
like
for
like
his
home,
page
or
stuff
like
that
and
independent
of
sharding,
I
think
actually
from
a
user
experience
standpoint.
That's
maybe
the
like
the
goal
right
is
somebody
who's
not
in
software
development
is
able
to
do
things
with
gitlab
to
at
least
some
degree.
I
think
we're
in
a
good
spot
and
we
are
definitely
not
there.
B
So
all
right
have
a
very
productive
rest
of
your
days
or
good
evening
for
dylan
and
tong.
I
hope
the
weather
is
not
too
cold,
otherwise,
see
you
on
wednesday,
bye.