►
From YouTube: GitLab 16.3 Kickoff - Enablement::Gitaly
Description
Gitaly Kickoff for GitLab 16.3
Planning Issue - https://gitlab.com/gitlab-org/gitaly-planning/release-planning/-/issues/13
A
A
A
We
have
a
lot
of
PTO
scheduled
at
the
end
of
summer
here
as
we
approach
the
August
dates,
therefore,
we're
expecting
a
slightly
lower
than
normal
capacity
for
the
16.3
Milestone.
So
I
just
want
to
point
that
out
before
we
get
started,
I'm
going
to
highlight
a
few
things
here
that
we're
very
interested
in
delivering
that
I
think
will
have
a
large
customer
impact.
I
may
not
highlight
everything
in
order
to
keep
the
timing
of
this.
You
know
reasonable,
so
that
people
will
be
able
to
see
this
in
a
brief
amount
of
time.
A
The
first
thing,
one
of
our
key
objectives
here
is
server
side,
backups
I'll
go
ahead
and
click
over
to
that
right
now
we
have
a
blueprint
online,
which
I
link
in
the
planning
document
right
here,
and
the
blueprint
is
sort
of
our
engineering
planning
engineering,
design
paperwork
that
we
do
in
a
way
that
allows
us
to
get
broader
audience,
participation
and
review
of
sort
of
architectural
or
more
major
changes.
Server-Side
backups
have
been
a
bit
of
a
concern
for
our
users.
Rightfully
so,
and
we
are
addressing
those
in
this
way.
A
As
you
can
see,
we
have
service
hiding
criminal
backups,
which
is
being
worked.
These
are
all
sub
Optics
and
sub
issues,
and
we
have
almost
completed
the
MVC
for
this.
So
we're
quite
excited
about
that.
We
want
to
continue
working
on
these.
We
think
these
are
going
to
bring
tremendous
value
to
our
self-managed
customers
and
therefore
we're
we're
trying
to
finish
off
that
mvp.
A
The
second
thing
I
want
to
highlight
is
the
implementation
of
right
ahead
logging
in
Italy.
This
is
actually
a
whole
separate
topic
that
is
sort
of
a
sub
piece
of
implementing
a
raft-based
decentralized
architecture.
For
our
prefect
transition
over
to
Raft
that's
about
a
year
out,
we're
thinking,
maybe
a
little
less
but
the
red
hand.
Logging
is
actually
utilized
in
a
lot
of
ways
and
we're
hoping
to
leverage
this
for
Disaster
Recovery
operations,
potentially
backup
operations
and
some
other
operations
at
gitlab
and
for
our
customers.
A
A
Finally,
under
engineering
priorities,
we
are
investigating
opportunities
around
the
get
bundle
URI.
This
is
pretty
exciting.
This
is
a
new
feature
for
git
Upstream
itself.
These
bundle
Uris
are
locations
where
git
can
download
one
or
more
bundles
in
order
to
sort
of
bootstrap
an
object
database.
What
this
means
to
the
users
is
bundles
could
be
stored
in
multiple
locations
and
when
an
initial
clone
takes
place,
those
bundles
can
be
pulled
in
place
of
having
to
query
the
server
for
that
data.
A
This
gives
us
a
lot
of
flexibility
actually,
because
there
are
opportunities
here
where
we
could
actually
reduce
load
from
CI
pipelines.
We
could
actually
Geo,
distribute
bundles,
there's
a
lot
of
opportunity
here
where
we
could
put
those
bundles
on
like
an
object,
storage
device
potentially,
and
this
would
allow
clients
access
to
those
and
it
would
be
routed
to
the
closest
server
to
them
through,
like
a
geolocation
system.
A
So
that's
a
pretty
exciting
opportunity
for
this
release,
we're
not
necessarily
planning
on
implementing
anything,
but
we
are
trying
to
explore
what
this
could
allow
us
and
sort
of
then
prioritize
based
on
what
this
investigation
shows
will
prioritize
features
coming
out
of
this.
So
that's
a
pretty
interesting
opportunity
for
us,
and
additionally,
I
wanted
to
sort
of
talk
about
a
couple
of
the
technical
debt
things
we're
looking
to
eliminate
this
release.
We
want
to
remove
the
in-memory
implementation
of
some
of
the
replication
jobs
queue.
A
This
is
something
that's
been
ongoing
and
it's
something
we're
sort
of
trying
to
finalize,
and
we
are
really
right
now
in
a
position
where
we
can
finalize
this,
which
is
pretty
exciting.
It's
been
a
long
time
coming
and
that
will
eliminate
the
in-memory
implementation
for
this
replication
jobs
and
that
opens
up
doors
for
us
going
forward
for
other
things.
So
that's
really
exciting.
A
The
final
thing
is
they
get
attributes.
We
now
have
an
opportunity
to
read
these
directly
off
of
the
repository
itself,
so
there's
really
no
reason
for
us
to
read
them
out
and
store
them
in
a
separate
file
anymore
or
extract
them.
This
does
make
our
repository
storage
a
lot
simpler
and
it
allows
us
to
move
storages
around
in
an
easier
way
without
having
to
worry
so
much
about
the
app
the
attributes
files.
A
A
As
always,
if
there
are
any
questions,
please
feel
free
to
either
leave
a
comment
on
this
video
or
go
ahead
and
leave
comments
on
the
issues
themselves
or
this
planning
issue.
We
welcome
all
participation,
I,
look
forward
to
discussing
this
with
anybody
who's
interested.
If
you
ever
want
to
reach
out
to
me
or
my
team,
please
feel
free
to
do
so.
We'd
be
happy
to
talk
to
you
about
opportunities
or
improvements
that
you
see
in
our
product.
That
we'd
like
to
you,
know,
hear
about
and
understand
better.