►
From YouTube: GitLab 12.9 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
Ramsay
group
product
manager
here
at
gilt,
and
this
is
the
giddily
12.9
kickoff
for
the
release
that
will
be
coming
out
on
March
22.
So
there
are
two
major
projects
that
the
Gili
group
is
working
on
at
the
moment,
the
first
of
which
is
high
availability
for
giddily.
The
very
first
version
of
this
that
we've
been
working
on
for
quite
a
while.
A
Over
the
last
releases,
we've
been
working
on
getting
an
early
iteration
of
this
into
gitlab,
comms
production,
environment
to
start
testing,
and
so
in
October.
We've
got
the
first
version
into
our
staging
environment
and
then,
most
recently
in
late
January,
we
started
observing
replication
in
production.
A
Here's
a
showing
get
data
in
the
repository
view
or
merge
request,
for
example,
and
so
today
those
requests
go
directly
to
the
get
early
nodes
and
in
the
Alpha
we'll
be
implementing.
We
have
we've
already
implemented,
but
we'll
be
making
it
available
in
an
alpha
state
as
prefect,
proxy
and
router,
and
what
this
does
is
it
Maps?
A
This
favours
availability
or
up
time
over
consistency,
because
it's
eventually
consistent.
If
there
are
unreplicated
changes
to
the
replicas.
Those
changes
will
be
lost
from
the
server,
so
this
is
definitely
not
the
final
solution
and
actually,
if
I
go
back
to
the
MBC,
you
can
see
that
by
the
time
we
reached
general
availability,
which
we
hope
to
do
by
thirteen
point
O.
The
architecture
will
be
more
sophisticated,
but
still
on
an
eventually
consistent
basis.
A
A
There'll
be
a
database
for
tracking
the
replication
queue
in
the
alpha,
that'll
be
in
memory,
and
so,
if
prefect
restarts
or
crashes
the
replication
she
would
be
lost.
So
we
we
actually
plan
to
add
this
database
in
the
beta
stage,
which
we
will
be
working
on
12.9
and
then
the
introduction
of
console
as
part
of
the
architecture
in
the
final
sort
of
push
towards
GA
will
help
us
manage
leader
election
across
the
get
early
nodes.
What,
if
I
over
curves
keeping
track
of
that,
so
that
we
can
have
multiple
prefix?
A
And
this
point,
all
the
components
of
the
h.a
architecture
are
highly
available.
I
would
suggest,
if
you're
interested
in
this,
taking
a
closer
look
at
the
epoch,
which
has
got
some
more
information
about
design
and
also
in
the
Alpha
epoch,
which
explains
a
little
more
about
with
valium,
which
are
present
in
the
Alfa
and
also,
if
you
read
the
epic
for
the
GA
version,
which
can
be
found
here
like
with
your
miss
slinky
and
general
availability.
It
will
describe
the
shortcomings
that
we
expect
in
the
minimal
generally
available
version.
A
One
of
the
primary
shortcomings
of
the
MVC
generally
available
version,
which
we're
working
towards
is
eventual
consistency.
Our
long-term
goal
is
not
to
be
eventually
consistent,
but
to
be
strongly
consistent,
but
we
wanted
a
foundation
to
iterate
off
of
so
today.
The
architecture
looks
a
little
bit
like
geo,
where
you
push
something
and
then
it's
replicated
asynchronously
to
a
replica,
but
there's
a
different
architecture.
A
There's
a
lot
of
different
are
pieces
that
get
lab
users
to
communicate
with
the
git
repository
as
well
as
the
git
protocol
itself.
Then
we
need
to
work
out,
and
so
it's
important
that
we
start
understanding
the
challenges
of
three
phase
commits
and
strong
consistency
sooner
rather
than
later,
so
that
we
can
have
a
clear
understanding
of
the
difficulty
how
we're
going
to
tackle
this
problem,
because
we
want
to
come
out
of
the
first
version,
which
is
eventually
consistent
and
immediately
start
running
towards
stronger
consistency,
so
watch
this
space.
A
We
hope
to
learn
more
about
this
during
12.9.
So
hopefully
this
might
even
result
in
some
immediately
actionable
items
in
the
next
release,
and
particularly
a
clear
roadmap
for
beyond
thirteen
point
o
beyond
the
generally
available
NB
c--,
but
when
we
might
get
to
a
strongly
consistent
version
of
high
availability
for
get
early.
A
That's
the
first
and
most
significant
focus
of
the
guillotine
and
12.9
continuing
to
work
on
getting
high
availability,
ready
and
in
production
so
that
we
can
start
iterating
towards
strong
consistency.
This
is
important
for
lots
of
customers
and
we
were
treating
as
a
top
priority.
The
second
item
that
we've
been
working
on
in
the
backburner
for
quite
a
while-
and
it's
it's
a
really
great
I'm.
A
Sorry,
a
really
great
feature-
is
improving
support
for
enormous
repositories
and,
if
you've
been
following
the
mailing
lists
or
other
media
about
gifts-
and
you
may
have
heard
of
partial
clone
and
we've
been
contributing
to
the
work
of
partial
clone,
which
makes
working
with
larger
repositories
easier
by
allowing
you
to
selectively
clone
data
rather
than
cloning
everything.
So
if
you've
got
a
massive
repository,
partial
clone
means
you
can
say,
I
only
want
to
download
some
of
that.
A
Don't
give
me
the
large
files
only
give
me
the
small
files
and
then
download
the
big
ones
on
demand
or,
alternatively,
you
can
also
scope
these
partial
downloads
by
file
paths.
So
you
can
say.
Actually
this
is
a
mono
repo
I,
don't
need
the
back-end
code,
because
I'm
a
front-end
engineer
and
we
actually
can
run
some
sort
of
demo
app
off
the
front
end
without
leaving
all
the
backend
components,
and
so
you
can
work
with
a
smaller
repository,
smaller
working
copy
and
improve
performance.
A
This
is
probably
not
ideal
if
you're
uploading,
gigabytes,
size,
fineries
or
you've
got
a
long
history
in
your
process.
Repository
you've
got
all
these
old
binary
files
and
maybe
they're
only
twenty
hundred
Meg's,
but
they
quickly
accumulate
hundreds
of
gigabytes.
If
you
don't
need
access
to
those
all
the
time
and
you're
using
partial
clone,
you
probably
want
to
offload
those
of
expensive
block
storage
to
a
cheaper
object,
storage,
alternative,
and
so
one
of
the
things
we're
working
on
is
adding
dumb
HTTP
driver
support
promises.
A
So
this
is
a
smart
git
protocol
and
it's
a
dumb
git
protocol
and
the
dumb
give
protocol
really
allows
you
to
just
use
a
simple
HTTP
request
say:
get
this
object.
You
don't
have
to
negotiate
halves
at
once.
You
don't
have
to
go
through
the
usual
rigmarole
of
the
git
protocol,
which
is
good
most
of
the
time
because
it
makes
getting
faster
and
more
efficient.
A
Less
data
gets
transferred
and
yeah
it's
ideal
for
most
use
cases,
but
if
we're
wanting
to
offload
large
be
individual
files
to
object,
storage,
having
the
support
for
promise
or
remote
switch
is
part
of
partial
clients.
Implementation
that
use
the
dumb
HTTP
GET
protocol
will
allow
us
to
offload
some
objects,
hopefully
to
object
storage
while
leaving
the
commonly
accessed
small
objects
on
a
fast
high-performing,
storage
radio.
So
this
allows
systems
administrators
to
transparently.
A
Separate
the
storage
of
big
files
from
small
files-
and
this
is
really
exciting
if
we
can
make
this
work.
So
this
is
one
of
the
things
that
we're
working
on
at
the
moment
and
there's
other
improvements
coming
to
partial
clone
on
the
mailing
list
and
so
watch
the
release
post
for
those
we're
collaborating
with
github
and
Microsoft,
and
other
parties
who
are
working
on
this.
So
partial
clones
fast
check
out
a
really
exciting
improvements
to
get
and
we're
doing
our
best
to
support
them
and
contribute
to
their
development
as
this
space
evolves.