►
From YouTube: GitLab 14.1 Kickoff - Enablement:Sharding
Description
Kickoff for the 14.1 release for the Sharding team.
Planning issue: https://gitlab.com/gitlab-org/gitlab/-/issues/333382
A
Hello,
everyone,
my
name
is
fabian
simmer,
I'm
a
group
product
manager
in
the
enablement
stage
of
gitlab,
and
I
will
walk
you
through
our
plans
for
14.1
for
the
sharding
group.
Let
me
quickly
share
my
screen.
So
I'll
walk
you
through
this
planning
issue
here
so
before
I
do.
I
would
like
to
take
a
step
back
to
explain
the
context
of
the
work
that
the
sharding
group
is
doing.
A
Around
70,
17
or
18
of
the
reads
can
be
attributed
to
ci
but,
more
importantly,
writes.
Almost
50
percent
of
the
rights
are
to
do
with
ci
tables
and
reads
can
be
scaled
by
providing
green
replicas
rights.
So
changes
in
the
database
are
a
lot
harder
to
scale
and
in
order
to
accomplish
this,
we're
going
to
move
the
ci
tables
into
the
into
a
different
database.
A
A
It's
very
important
that
every
change
that
we
make
is
also
supported
for
our
self-managed
customers
and
that
specific
features
that
are
very
reliable
or
database
technology
such
as
geo
are
also
supported
to
give
you
a
high
level
overview
of
the
road
map.
So
we
anticipate
that
the
entire
project
will
take
until
the
end
of
q4
2021.
A
So
the
upcoming
release
for
gitlab.
We
are
going
to
focus
on
achieving
a
goal
which
is
to
have
gitlab
actually
working
with
more
than
one
database.
So
how
are
we
going
to
accomplish
this?
So
we
had
some
discussions
inside
the
team.
We're
trying
to
do
something
really
minimal
here,
we're
going
to
focus
on
a
single
ci
table,
ci
instance
variables.
First
out
of
you
know
around
50
that
we
know
we
will
need
to
actually
move
to
a
separate
database,
and
this
table
has
some
properties
that
are
quite
useful
for
us.
A
A
So,
let's
focus
on
support
for
many
databases
first,
which
is
also
directly
related
to
the
goal
that
we're
trying
to
accomplish.
Actually,
you
know,
working
with
more
than
one
database
for
14.1,
we're
only
going
to
focus
on
a
subset
of
issues
that
are
important
to
actually
have
this
work,
with
the
specific
ci
instance
variable
table,
and
so
in
order
to
accomplish
this,
we
will
have
to
disable
the
rails
legacy
connection
handling,
we've
recently
upgraded
to
rails
6.1,
which
has
native
support
for
multiple
databases.
A
We
will
need
to
handle
multiple
schemas.
Importantly,
we
also
need
to
make
sure
that
our
development
environments
are
supporting
many
databases,
so
our
engineers
can,
you
know,
develop
rapidly.
So
this
is
something
that
we
need
to
focus
on
and
we
need
to
make
omnibus
and
cloud
native
gitlab,
at
least
configurable
with
many
databases.
A
A
A
We've
actually
just
made
a
decision
to
focus
on
a
very
small
subset
of
of
items
of
tables,
one
to
be
precise,
which
is
the
ci
instance
variable
table.
These
are
instance,
wide
settings.
You
can
define
variables
that
then,
would
be
inserted
into
your
ci
jobs
and
on
github.com.
This
is
currently
empty,
which
simplifies
our
migration,
because
we
don't
need
to
actually
migrate
anything
for
this.
A
A
In
a
parallel
track,
as
I've
just
explained
for
our
first
iteration
to
support
many
databases-
the
ci
instance
variables
is,
you
know
essentially
empty
on
gitlab.com,
so
it
simplifies
a
few
things,
but
we
already
know
that
one
of
the
main
challenges
of
executing
this
pro
project
will
be
actually
creating
migration
tooling
to
handle
us
moving
data
around
between
multiple
databases,
and
so
this
is
going
to
take
more
than
one
milestone.
We
already
know
that,
and
we
are
in
the
process
of
figuring
out
how
to
do
this
most
efficiently.
A
A
There's
many
different
problems
to
solve
here,
and
this
is
really
important
to
get
right
because
we're
obviously
moving
data.
So
we
need
to
be
very
mindful
that
once
we
roll
this
out,
it
works
as
expected,
and
we
also
believe
that
we're
probably
going
to
like
roll
do
this
several
times,
just
to
make
sure
that
everything
is
in
place.
So
in
14.1
we
are
going
to
actually
focus
on
figuring
out
what
kind
of
migration
helpers
are
needed.
A
The
solutions
for
that
adam,
an
engineer
in
the
team
has
already
laid
out
a
few
different
ideas
on
how
to
actually
execute
it
and
we're
going
to
like
move
forward
with
that
concurrently
to
the
other
work,
because
we
know
that
this
is
going
to
be
something
that's
going
to
be
very
important.
So
we
want
to
be
sure
to
start
this
early,
so
we're
not
going
to
have
a
bottleneck
later
later
on
when
we're
working
on
it
and
that's
it
for
14.1.
This
is
quite
ambitious.
Already.
A
I've
laid
out
the
specific
issues
here
for
the
milestone,
there's
also
a
bit
of
preparation
planning
to
be
done,
because
this
is
a
big
change
for
gitlab.
So
we
need
to
involve
feature
teams
and
other
other
groups
early
on
to
make
them
aware
that
this
is
sort
of
coming
coming
up.
Most
importantly,
will
be
the
collaboration,
I
think,
with
the
infrastructure
teams
to
make
sure
that
we
can
deploy
on.com
in
a
way
that
is
safe
and
understood.