►
From YouTube: GitLab 15.0 Kickoff - Enablement:Memory
Description
Kickoff for the Memory Group for the GitLab 15.0 release
Planning issue: https://gitlab.com/gitlab-org/memory-team/team-tasks/-/issues/112
Memory Group Past Kickoff Videos: https://youtube.com/playlist?list=PL05JrBw4t0Kq1HDOIfQ8ov6lfyJkWK2Yr
Presentation by: Yannis Roussos, Sr. Product Manager, Memory and Database Groups
A
A
So,
first
of
all,
during
in
14.8,
we
split
the
way
we
export
site
matrix
into
a
separate
process.
That
means
that
we
now
have
two
different
endpoints
for
the
health
checks
for
sidekiq
and
for
the
for
the
metrics
from
fourteen
point,
eight
to
four
to
fifty
to
fourteen
point.
Ten.
We
allowed
for
all
configurations
to
be
active.
A
We
kept
supporting
them,
but
but
starting
on
15.0,
you
have
all
instances
have
to
change
their
configuration
and
support
different
ports
for
those
two
different
endpoints
and
also
change
their
setup
to
also
to
to
use
the
the
two
different
ports,
our
second
application.
We
have
also
deprecated
the
require
the
the
request
profiling
feature,
so
we
want
starting
on
15.0.
A
It
will
not
be
available.
We
are
moving
any
missing
functionality
to
the
performance
bar
and
we
are
planning
to
make
it
available
on
self-managed
distances
for
production
environment
in
early
minor
ratios
of
15
hitler
15..
So
now
to
our
top
priorities.
Our
first
top
priority
are:
is
our
revamping
our
application,
metrics
exporters,
so
some
path
in
gitlab
in
general,
we
use
prometheus
to
store
our
metrics.
A
So
at
the
moment
we
have
two
competing
approaches
to
serve
those
application
methods
prometheus.
So
we
have
various
in-app
exporters
that
are
part
of
the
rails
code
base
and
we
also
have
the
gitlab
exporter
a
separate
project
and
dependently
deployed
collector
and
server
that
is
used
in
some
cases.
So
this
approach
has
two
major
issues.
There
are
two
separate
code
bases
to
maintain,
but,
more
importantly,
the
current
exporters
face
numerous
efficiency
challenges
and
what
we're
working
towards
at
the
moment.
This
is
a
long-term
effort.
A
So
in
40.10
we
completely
completed
our
effort
of
moving
the
metric
server
out
of
the
puma
primary
prumar
is
our
web
server
and
we
have
deployed
it
to
gitlab.com
and
we
are
very
satisfied
with
the
results
that
we
are
seeing.
So
this
is
completed
and
with
that
completed
and
with
the
prior
previous
effort
on
also
moving
the
metrics
exporter
out
outside
of
sightly,
we
now
have
all
our
exporters
as
separate
servers
running
a
separate
servers.
So
now
we
are
working
towards
this
new
exporter.
It
will
be
a
separate
new
project.
A
A
So
in
15.0
and
going
forward
we're
going
to
keep
on
working
on
making
this
exporter
production
ready
so
that
we
can
use
it
in
gitlab.com
and
all
our
instances
and
our
final
top
priority
for
15.0
is
updating
the
supported
ruby
version
to
3.0.
So
at
the
moment,
gitlab
uses
ruby
2.7,
but
we
expect
the
end
of
life
of
ruby
to
2.7
to
be
march
of
2022
2023.
A
Now
it's
2022.,
so
we
want
to
be
preemptive
and
preemptively,
update
our
support
and
to
ruby
3.0.
This
will
also
be
beneficial
when
we
want
to
to
upgrade
to
to
rails
to
rail
7..
So
there
are
a
lot
of
moving
parts
here
we
are
affecting
and
we
have
to
update
the
we
are
affecting
the
whole
gitlab
code
base.
A
We
have
done
a
lot
of
work
already.
Our
main
task
for
15.0
is
to
have
a
green
build.
That
means
that
nothing
breaks
in
my
gitlab
when
using
ruby3
and
including
our
q8s
and
then
move
to
start
supporting,
builds
that
use
ruby
3
for
all
our
ways
of
deploying
deploying
git
lab
and
also
support
for
ruby
3
for
all
our
the
libraries
that
we
use
inside
gizla
and
there
are
a
lot
a
lot
of
libraries.