►
From YouTube: GitLab 13.1 Kickoff - Create:Gitaly
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).
A
Hi,
I'm
james
ramsey
group
product
manager
here
at
gitlab
for
the
create
stage
of
the
devops
lifecycle,
and
this
is
the
giddily
13.1
kickoff
call
in
the
next
release.
Gitlab
13.1,
which
will
be
released
on
june
22,
we're
working
towards
strong
consistency
for
gili
clusters
and
to
summarize
what
gilly
clusters
are.
A
Let's
take
a
look
at
the
documentation
today
by
default.
If
you
install
gitlab
you'll
have
one
giddily
node
that
is
running
on
the
same
server
and
where
your
git
repository
data
is
stored,
but
for
large
gitlab
instances
it's
common
to
split
that
out
onto
a
separate,
dedicated
server
and
in
fact
a
lot
of
customers
want
to
have
multiple
servers
standing
by
so
that
if
one
of
them
goes
down
another
one
can
pick
up
the
read
and
write
requests,
improving
fault
tolerance.
So
this
would
be
part
of
what
would
be
a
high
availability
configuration.
A
So
what
we've
been
working
on
with
gili
clusters
over
the
past
number
of
releases
is
implementing
this
new
proxy
router
and
the
ability
to
have
multiple
giddily
nodes,
all
with
replicas
of
the
data.
So
the
problem
that
we're
trying
to
solve
in
13.1
is
around
consistency.
A
A
So,
in
order
to
do
this-
and
this
is
the
epic
that
we're
using
to
track
this
work-
we
need
to
make
a
number
of
changes.
We
evaluated
a
bunch
of
different
approaches
and
in
13.0,
which
is
the
release,
that's
just
about
to
ship
and
we've
been
implementing
a
proof
of
concept
using
pre-receive
hooks,
so
a
pre-receive
hook
gets
fired
on
the
server
whenever
you
push
data
you
might
use
this
to.
A
I
know
make
sure
that
you
don't
push
secrets
or
that
there's
lots
of
things
you
can
use
a
pre-receive
hook
for,
but
we're
also
building
a
prototype
that
would
implement
a
transaction
where
the
the
giddily
node
talks
to
this
prefect
server
and
the
tracking
database
and
says
oh,
I'm
conducting
a
transaction.
I
want
to
make
sure
that
multiple
nodes
have
a
copy
of
this
data.
A
A
We
want
to
cover
the
other
kinds
of
operations
that
come
through
the
git
interface.
With
this
sorry,
the
gitlab
interface,
where
we
directly
change
data
in
git
through
lower
level
commands
that
don't
trigger
a
pre-receive
hook.
So
what
we're
going
to
do
in
13.1
is
implement
special
dedicated
hooks
inside
of
git
to
manage
ref
update
transactions.
A
And
allow
us
to
get
coverage
of
all
right
operations,
so
that's
that's
really
exciting.
The
other
part
is
we
go
back
to
the
diagram
at
the
moment.
We're
only
sending
data
to
the
primary
gilly
node,
not
the
secondary
replicas,
and
so,
if
we're
going
to
have
agreement
between
all
of
the
servers
over
what
the
repository
should
look
like,
they
all
need
to
have
a
copy
of
the
data,
and
so
what
we're
going
to
implement
is
proxying
of
the
write
operations
proxy,
the
data
to
all
the
gilly
nodes.
A
We
want
to
take
what
we
build,
put
it
onto
gillab.com,
for
a
small
selection
of
repositories
that
we're
testing
with
and
verify
that
this
works
as
we
expect
verify,
the
transactions
succeed,
look
at
how
long
they
take
compared
to
a
normal
ride
operation.
So
we
understand
the
latency
and
also
do
a
bunch
of
other
monitoring.
This
is
a
incomplete
list
of
the
things
that
we'll
be
monitoring,
we'll
be
looking
to
add
more
as
we
go
through
the
development
process,
so
that
we
can
understand
exactly
how
it's
behaving
in
production.