►
From YouTube: GitLab 16.4 Kickoff - Enablement:Gitaly
Description
This is the Gitaly kickoff video for GitLab 16.4.
Planning Issue: https://gitlab.com/gitlab-org/gitaly-planning/release-planning/-/issues/14
Category Direction: https://about.gitlab.com/direction/gitaly/
A
A
capacity
notes
for
this
time
around
it's
the
end
of
summer
and
there's
some
PTO
for
certain
team
members,
so
we're
expecting
a
slightly
lower
than
normal
capacity,
but
nothing
significant
where
we're
going
to
actually
reduce
our
projected
capacity
for
the
month
objectives
and
themes
again,
please
feel
free
to
reach
out
and
see
our
Direction
page
if
you're
interested
in
what's
next,
and
why,
for
our
ongoing
focuses?
A
Currently,
our
themes
this
month
are
to
implement
right
ahead
logging
in
Italy.
This
is
an
ongoing
theme
that
we're
going
to
see
throughout
probably
the
next
couple
releases
as
we
implement
this.
We
have
an
open
epic
here
and
you
can
actually
see
that
this
is
quite
detailed
and
we
have
quite
a
bit
of
work
going
on
here.
There's
a
lot
of
issues
open
here
still
and
a
lot
of
things
that
are
in
going
or
ongoing
and
in
flight.
A
So
we're
very
excited
to
make
progress
here
in
an
effort
to
improve
both
our
Disaster
Recovery
situation
and
as
a
first
step
toward
our
distributed
architecture
raft,
which
is
also
also
a
feature
we're
looking
forward
to.
A
The
second
thing
we're
looking
at
is
our
server-side
backups
I
talked
about
this
last
month.
We
are
right
on
the
edge
of
these
being
finalized,
there's
a
little
bit
of
documentation
left
and
we
want
to
have
some
metrics
collection
involved
there.
So
we
understand
what's
happening
and
ensuring
things
are
working
to
better
enable
that.
However,
this
should
be
coming
out
next
release
and
we're
very
excited
for
that
as
I
think
it
solves
a
lot
of
customer
problems.
A
We
also
have
had
a
series
of
giddly
clustered
load-based
escalations
now
Gilly
cluster,
which
is
our
high
availability.
Repository
storage
solution
provides
a
ton
of
benefits
to
customers
who
need
High
availability
storage
for
the
repositories.
However,
when
you
use
a
voting
redundant
system
under
extremely
heavy
load,
you
will
see
that
it
actually
performs
slightly
worse
in
some
ways.
Namely
rights
are
somewhat
slower
and
if
the
cluster
becomes
out
of
sync,
which
is
expected
and
that's
sort
of
how
it
handles
the
fault,
tolerance,
getting
things
back
in
sync
can
be
somewhat
problematic
at
times.
A
Oh
we've
had
a
couple
of
our
larger
customers
having
some
issues
here
and
we've
recognized,
there's
a
few
ways
where
the
cluster
is
getting
out
of
sync
in
situations
where
it
may
not
need
to
be
desynchronized.
This
is
effectively
us
calling
a
resync
in
Gilly
cluster
out
of
undo
caution.
There's
a
few
issues
we're
looking
at
investigating
in
this
release.
A
couple
of
these
are,
you
know
around
disconnecting
repositories
from
an
object,
pool
I
needed
replication
jobs
and
introducing
reference
relations
via
tombstones.
A
Now
I
will
say
that
this
final
one
has
to
do
with
the
way
that
get
upstream
and
the
get
you
know,
project
as
a
whole
handle
deletions
when
the
deletion
occurs,
we
actually
have
to
whether
it
be
a
reference
deletion
or
anything
else.
We
have
to
actually
lock
the
nodes,
perform
the
deletion
and
that
forces
us
out
of
sync
of
the
multiple
nodes
in
a
cluster
and
in
non-busy
repo.
A
These
will
just
come
back
and
sync
very
quickly,
but
on
a
super
busy
repo,
it
can
take
hours
to
come
back
in
sync,
which
then
reduces
the
capacity
of
the
cluster
since
load
distribution
across
the
cluster
for
reading
does
not
work.
So
this
is
something
we're
looking
at
putting
into
Upstream
get
it's
a
contribution,
we're
very
excited
to
make
to
Upstream
git,
but
again
it
has
to
go
through
the
mailing
list
and
ensure
that
you
know
it's
done
the
proper
way.
A
So
we're
probably
looking
at
two
to
three
months
to
get
this
on
the
mailing
listing
and
receive
feedback
and
there's
no
guarantee
that
the
mailing
list
or
Upstream
git,
finds
this
to
be
beneficial
or
doesn't
have
feedback
that
will
change
the
course
of
this.
So
this
is
something
we're
actually
pursuing
and
we're
pretty
excited
for
the
final
thing
we're
looking
into
is
the
get
shot,
256
repository
support
now
that
get
version
2.42
does
not
consider
shot
256
experimental.
A
We
are
looking
to
roll
this
out
for
testing
for
our
customers.
Now,
there's
a
couple
things
to
note
here:
interoperability
between
sha-1
and
shot
256
is
not
something
we're
going
to
support
right
off
the
bat.
It's
not
actually
something.
That's
currently
supported
within
git
itself.
You
can
have
a
shot
one
repo
or
you
can
have
a
shot
256
repo,
but
you
can't
really
have
a
repository
that
contains
both
that's
sort
of
a
known
limitation.
A
We're
actually
nearing
a
point
in
this
epic
of
being
able
to
demo
it.
We
actually
had
some
internal
demos
the
other
day,
we're
able
to
actually
create
repos
from
the
command
line,
push
them
into
a
repository
on
gitlab
and
view
them.
A
lot
of
things
are
working
quite
well.
There
are
a
handful
of
things
on
the
rail
side
that
we're
looking
to
get
taken
care
of
and
those
are
actually
scheduled
out
in
16.4
as
well
16.5.
A
As
far
as
engineering
priorities,
there's
a
handful
of
flaky
tests,
we're
looking
at
sorting
out
these
have
been
scheduled
for
multiple
releases.
I
moved
them
all
to
16,
4
now
to
try
to
put
them
all
in
one
place,
we're
going
to
figure
out
what
to
do
with
these.
Hopefully
we
can
mitigate
these
or
resolve
them
throughout
this.
This
milestone,
there's
also
other
ongoing
customer
escalation.
Work
and
bug
fix
work
that
we're
pursuing
as
well.
A
So,
if
there's
questions
comments-
or
you
have
anything
else,
you'd
like
to
see
us
look
into,
please
feel
free
to
leave
a
comment
on
this
planning
issue
or
on
the
YouTube.
Video
I
do
check
them
about
the
middle
of
the
Milestone
cycle
to
see
if
anything's
going
on
no,
admittedly,
I
do
not
check
further
back
than
one
release.
Thank
you.
Everyone
for
your
time
and
have
a
great
day.