►
From YouTube: Renault Team and Geo Team discuss Git CDN
Description
The Team from Renault and the Geo team discussed Git CDN (https://gitlab.com/grouperenault/git_cdn) and potential opportunities for collaboration
B
B
So
I
don't
do
any
implementation
work,
but
I'm
always
thinking
about
what
we
are
going
to
do
next
to
serve
our
customers,
and
so
I'm
quite
excited
to
see
this
project
because
it
ties
into
some
potential
things
that
we
were
planning
to
do
in
2021
for
geo,
and
so
I
decided
to
to
actually
reach
out.
So
that's
me:
maybe
we
can
go
through
the
the
geo
team
first
because
we
are
essentially
the
guests
alex.
D
F
D
H
I
think
that's
all
of
us,
okay,
so
I
will
start
I'm
a
nicola
schoenster
from
renault,
so
I'm
a
product
owner
on
several
continuous
integration
services
that
we
developed
inside
renault
on
the
git
sedan
is
part
of
it
other.
As
you
I'm
not
doing
any
implementation,
I'm
just
trying
to
build
up
a
roadmap
for
services
and
to
keep
the
service
aligned
with
our
needs.
I
A
K
B
B
I
thought
we
could
use
this
time
to
get
to
know
each
other
a
little
bit
and
understand
where
we
are
coming
from,
and
so
obviously
our
team
in
gitlab
maintains
the
geo
replication
and
also
the
disaster
recovery
capabilities,
and
so
I
stumbled
upon
that
because
this
was
linked
as
an
interesting
project
actually
by
our
our
ceo
sid,
and
so
I
decided
you
know
I
had.
I
had
not
seen
this
before
that.
B
All
of
all
of
those
questions,
and
I
can
tell
you
what
I
know,
which
is
maybe
not
as
much
so.
I
know
that
that
renault
uses
gitlab
already
right.
I
mean
that
is
pretty
obvious
from
seeing
that
you
host
all
of
these
functionalities
on
on
gitlab,
but
I
am
I'm
not
so
familiar
with
sort
of
the
your
journey
to
actually
creating
this.
This
package
yourself,
so
maybe
that's
sort
of
my
first
question-
is
like
tell
us
a
little
bit
about
the
history
of
this
this
this
project
and
how
you're,
using
it.
B
H
C
H
I
C
H
I
F
I
Repository
3
is
a
40
gigabyte
of
of
guitar
repository,
so
we
need
to
download
that
all
the
time.
So
sometimes
we
want
to
go
back
from
scratch,
so
we
have
to
optimize
also
the
going
back
from
scratch
and
it
was
a
bit
the
same
for
other
projects.
Those
are
very
large
projects
because
there
is
for
autonomous
driving.
There
are
lots
of
video
data
in
order
to
do
the
test
kind
of
thing.
So
that's
why
we
needed
some
mirroring
local
linear
to
the
ci
workers.
I
Yeah
when
we
started,
we
had
a
lot
of
servers
inside
our
own
data
center.
So
we
wanted
to
reuse
that
that's
why
we
have
a
system
where
the
all
our
workers
are
inside
our
internet
and
we
have
a
central
repository
that
is
in
the
cloud
so
that
we
can
share
the
source
code
to
other
companies
as
renault,
because
we
have
a
lot
of
partnerships.
I
Yeah
and
by
the
way
other
thing
is,
we
have
a
starter
license
and
this
this
is
the
main
reason
why
we
are
not
using
geo
or
one
of
the
reason
why
we
are
not
using
geo.
The
second
reason
is
that,
as
we
started
dcdn,
I
I'm
not
sure
I
didn't
follow
the
exactly
your
future
set,
but
at
the
time
the
the
mirroring
was
executed
every
year,
every
10
minutes.
I
It's
it's
not
every
10
minutes
like
like
jail,
but
even
with
that,
you
get
some
some
delay
during
the
mirroring
and
it
has
been
very
difficult
to
synchronize
the
ci.
We
had
to
add
a
job
in
the
beginning
of
hci
and
query
the
the
the
master
git
repository
to
to
get
the
old
repository
status,
the
commit
where
it
was
in
the
main
branch
and
then
make
sure
this
was
exactly
the
same,
and
the
replication
was
done
in
the
mirrors.
I
B
I
I
B
I
Workers
yeah
that's
true
for
for
push
replication,
that
that
would
mean
that
the
central
git
has
direct
access
to
the
mirroring,
and
it's
not
the
case
for
security
reasons.
Our
cloud
is
separated
and
cannot
initiate
any
connection
to
the
internet,
which
can
be
done
in
the
reverse
way.
They
are
proxies,
so
so
the
proxy
are
only
a
one
away,
only
from
intranet
to
the
cloud.
B
Another
question
that
I
I
had,
and-
and
this
is
something
that
we
are
thinking
about
for
for
customers
like
yourself-
is
that
in
some
instances,
there's
maybe
also
sort
of
a
cost
factor
where
it's
like
you're
you're
interested
in
specific
git
repositories,
maybe
right
for
your
developers,
maybe
for
ci,
not
so
much,
but
you
like
being
able
to
do
things
on
demand
rather
than
replicating
everything.
All
the
time
also
has
a
cost
implication.
Did
that
play
a
role
for
you
in
that
decision,
as
well.
I
I
I
I
B
B
I
B
I
I
We
think
that
we
have
a
lot
of
traffic,
I'm
not
sure
exactly.
How
is
the
traffic
on
gitlab,
but
we
are
always
impressed
when
you,
when
we
look
at
the
actual
results.
So
so
it's
about
20
terabytes
per
week
on
a
single
single
decision.
So
probably,
as
we
have
three
this,
we
didn't
look
at
all
the
results,
but
it's
more
like
a
50
60
20
per
week
that
is
moved
inside
the
local
network
and
then
our
machine
are
pretty
big.
I
We
put
initially
a
lot
of
ram
because
we
thought
that
the
fire
system
cache
would
be
important,
but
back
in
september
we
switched
from
spinning
disks
to
ssd
disk,
because
in
the
end
we
couldn't
fit
everything
in
the
in
the
ram
cache,
and
we
we
had
a
lot
of
activity
in
the
spinning
this,
and
this
was
causing
a
lot
of
high
latency
and
a
lot
of
slowness.
Where
experience.
So
that's
why
we,
we
now
recommend
that
ssd
disks
are
used
for
for
such
data.
I
I
I
I
J
So
the
first
level
is
the
guitar
repo
in
the
git
cdn,
and
then
we
have
rules
criterias
to
cache
the
upload
pack,
not
all
the
time,
but
when
we
clone
from,
I
think,
is
a
clone
for
all
objects.
I
think
so.
The
first
the
the
chart
to
the
right
is
the
number
of
requests
we
we
have
on
cdn
versus
the
number
of
queries
we
do
on
awws.
C
I
Time
we
don't
even
have
to
carry
aws
in
terms
of
upload
pack,
but
what
we
do,
what
is
very
important
is
that
we
always
fetch
the
infrarefs.
So
in
order
to
know
that
we
are
aligned
with
the
main
server,
we
always
fetch
the
infrared,
and
we
we
know
that
italy
already
heavily
caches
the
infraref.
So
this
doesn't.
This
is
not
so
much
of
a
problem,
but
this
is
very
important
and
it's
a
key
measure
to
make
sure
that
we
are
always
up
to
date
with
the
master.
J
B
I
B
B
E
Yeah
this
this
was
great.
Thank
you.
So
much
really
fascinating
to
see
see
your
use
case.
I
was
just
curious
about
the
the
the
tooling
that
you
have
to
to
track
some
of
these
to
track,
like
the
checks
on
these
metrics,
like
the
cash
ratio.
How
how
are
you
getting
that
that
data
is
that
pr?
Is
there
like
an
api
to
that
into
the
git
cdn?
Do
you
have
like
separate
instrumentation
that,
like
in
a
different
repo
that
you're
using.
I
I
So
to
one
of
the
issues
is
so
I
think
io
allows
a
lot
of
requests
at
the
same
time
very
efficiently,
but
then
lots
of
a
lot
of
things
happen
at
the
same
time.
So
the
the
the
main
way
we
we
do
debug,
that
is
by
using
logging.
So
we
are
using
a
big
logging
infrastructure
with
the
elastic
search
keyboard.
So
those
are
kibana
dashboards
that
you
see
and.
I
So
so
that's
a
lot,
so
we
we
are
logging
a
lot
and-
and
we
have
investing
a
lot
in
structuring
the
logs
so
that
each
log
has
a
lot
of
data
associated
with
it.
That
allows
to
track
it
where
it
comes
from.
What
what
are
the
status
of
this
request
and
and
that's
that's,
how
we
do
it,
but
it
was
a
long
process.
I
It's
very
difficult
to
know
exactly
what
kind
of
data
we
must
have
add,
because
we
we
need
to
not
pull
too
much
logs
in.
If
we
don't
do
that,
then
the
elastic
will
just
overload
and
we
are
also
thinking
about
doing
a
promoter's
endpoint
in
order
to
collect
metrics
so
that
we
don't
realize
that
much
on
logs
because
really
logs,
it
consumes
a
lot
of
data
and
resources
in
order
to
be
processed.
B
I
Yeah
the
problem
with
metrics
with
prometa
use
is
that,
as
we
were
experimenting
on
the
thing
it
when
you
do,
metrics
is
at
the
time
where
you
really
master
your
product.
You
know
exactly
what
kind
of
issue
you
will
have,
so
you
can
put
matrix
point
at
the
at
the
right
place,
but
yeah
we
with
git
cdn.
I
There
has
been
a
lot
of
very
difficult
to
debug
issues,
so
so
in
in
that
case,
just
having
one
log
in
particular
to
make
some
hypotheses
on
the
issues.
Problem
was
very
important
and
it
allows
us
to
to
debug
things,
and
now
we
are
pretty
happy
because
we
we
don't
have
too
much
issues
anymore.
So
so
we
are
in
the
phase
where
we
open-sourced
it
last
year
and
and
yeah,
we
will
go
into
more
cleaning
up
the
code
and
that
kind
of
thing.
B
Yeah,
thank
you
on
this.
This
was
a
great
presentation.
It
helped
with
a
lot.
I
think
there
is
a
lot
for
us
here
to
digest
as
well
before,
because
we,
we
are
a
little
bit
short
on
on
time
and
I
want
to
be
respectful
of
your
agenda,
but
I
can
share
sort
of
my
perspective
on
on
this
and
why
I
think
this
is
quite
interesting
for
us.
B
Following
that
we
are
quite
interested
in
improving
our
capabilities
in
the
geo
replication
area,
and
I
I
am
aware
that
one
of
the
use
cases
that
many
of
our
customers
have
is
you
know
using
g04ci,
you
know,
and
they
face
some
of
these-
these
issues.
You
know
with
regards
to
the
you
know
our
ability
to
handle
all
of
these
interactions,
which
is
you
know,
I
think
exactly
what
you.
B
You
know
how
some
of
these
things
may
fit
together
or
not
right,
because
gitlab
has
a
very
different
technology
stack,
for
example,
you
know,
but
you
know,
maybe
there
are
some
some
ways
we
can
actually
learn
from
each
other
here
or
make
use
of
of
your
amazing
work,
because
I
think
that
that
would
be
really
really
fun.
Quite
frankly,
and
so
that's
that
is
where
we
are
currently
at.
So
we
we
still
have
sort
of-
let's
say
three
month
runway.
B
I
B
I
think
it's
it's
nice
to
see,
because
this
must
work
particularly
well
for
your,
like
gitlab
installation,
because
that
is
what
what
you
you're
using
right
now.
I
think
for
us,
the
there's
also
a
question
of
how
like
could
like.
We
are
very
much
at
the
beginning
of
our
thinking.
So
please
take
none
of
this
as
a
we
are
going
to
do
this
right.
I'm
I'm
thinking
out
loud
here.
You
know.
From
my
perspective,
you
know.
B
B
This
is
how
how
it
works
with
with
gitlab,
maybe
there's
an
option
for
some
form
of
sort
of
a
more
plug-in
based
architecture
right
where
we,
you
know,
say
hey
if
you
want
to
use
geo,
and
you
want
to
use
git
cdn
as
your
backend
for
for
your
replication
for
some
of
those
things.
This
is
how
to
do
it.
B
That
would
be
quite
quite
neat
because
I
I
foresee
you
know
there
may
be
different
different
strengths
and
weaknesses
for
for
this
replication
style
right
and
what
you
need
to
accomplish
with
it,
and
so
those
are
some
some
of
my
thoughts
at
the
moment.
I
think
the
I
think
what
we
probably
won't
be
able
to
do,
but
please
team
members,
correct
me
is
all
of
this
is
written
in
python
right
we
run
on
on
ruby
right,
so
you
know
we
we
would
not
be
able
to.
B
E
Yeah
yeah
I'm
curious
to
hear
others
thoughts.
I
I
guess
I
yeah
I
mean
we
could
still
yeah,
maybe
not
into
say,
like
the
the
main
gitlab
rails
code
base,
but
I
think
we
certainly
with
like
omnibus,
like
our
distributions,
like
with
our
omnibus
package,
we
we
integrate
things
that
are
written
in
in
other
languages.
So
so
you
know,
maybe
that's
a
potential
option
to
explore.
C
Something
that
came
to
mind
for
me
is
the
we
have
the
one
click
installs
for
our
operations
like
the
get
get
lab
operations
stuff,
and
this
could
be
a
a
good
potential
item
for
that,
because
so
the
one
click
installs
include,
get
lab
runners
and
stuff
like
that,
so
that
you
can
just
like
put
them
in
a
kubernetes
cluster
right
or
maybe
now
aws.
Also,
this
could
be
a
cool
thing
in
there.
I
Yeah,
so
basically,
our
release
in
is
a
docker
image.
So
so,
if
we
are
talking
about
kubernetes,
so
it's
very,
very
simple
to
be
plugged
in
in
a
kubernetes
environment.
In
fact,
we
are
doing
all
our
rolling
update
with
docker.
We
are
not
using
a
kubernetes
cluster
because
we
have
a
bare
metal
servers
because
we
need
so
much
performance.
So
we
don't.
We
didn't
want
to
to
add
some
overhead.
I
B
Well,
I
think
I
think
there
are
also
some
other
potential
opportunities
here,
for
example,
for
this
specific
ci
use
case
right.
I
know
that
the
requirements
are
on
what
you
must
be
able
to
do
with
your
replication.
Engine
are
a
little
bit
different,
for
example,
from
a
disaster
recovery
use
case,
and
so
you
know
that
may
also
be
an
interesting
story,
saying
if
you
want
to
use
you
know
a
git
cdn
just
for
for
ci
right.
We
can.
B
You
know,
because
that
would
be
quite
useful.
We
we
could
wrap
that
there
as
well
and
say
for
this
specific
thing.
We
rely
on
cdn,
for
example,
to
make
sure
that
you
always
get
the
latest
latest
changes,
because
I
think
quite
a
yeah,
because
I
know
at
least
a
few
very
large
customers
who
have
very
large
repositories,
who
also
use
a
a
different
build
infrastructure
for
some
things
and
there
that
may
be
helpful.
I
I
C
B
You
know
to
make
it
possible
ultimately
that
that
folks
can
benefit
from
from
the
work
that
you
have
have
done
here
in
in
gitlab
as
well,
because
I
think
if
that
makes
sense
you
know,
then
I
think
that
that
would
be
a
great
collaborative
piece.
The
specifics
of
how
to
do
that.
You
know,
I
think
we
we
will
have
to
to
think
a
little
bit
more
about
and
yeah,
but,
like
I
really
I'm
quite
impressed
by,
but
what
you've
built
here
and
how
how
it
seems
to
perform.
B
Yeah
and
maybe
what
I
can,
what
I'll
do
in
the
next
as
a
sort
of
follow-up,
is
I'll,
summarize
the
call
and
send
it
into
the
issue
that
we
that
we
created?
That's,
maybe
also
a
question
for
me.
I
just
reached
out
in
your
issue
tracker
because
that
felt
like
the
most
the
simplest
way
of
actually
getting
in
touch.
B
Is
that
a
good
place
for
us
to
also
continue
sort
of
some
async,
some
async
work?
If
we,
if
we're
interested
in
chatting
to
reach
out
in
there
and
just
have
a
discussion
and
then
if,
if
the
need
arises,
actually
get
on
a
call
again,
because
that's
a
workflow
that
we
are
quite
familiar
with
inside
gitlab
and
we
can
cross-link
to
to
our
own
development.
I
Yeah,
I
guess
this
is
the
main
way
of
doing
open
source
and
that's
why
we
we
open
sourced
it
in
in
this
manner.
So
so,
but
let's
continue
on
the
issue,
we
are
all
listening
to
the
events
for
for
this
issue.
So
that's
fine
and
and
yeah.
I
I
don't
know
if
you
want
to
have
a
live
chat
or
something
maybe
we
can
do
that
later,
but
for
now
probably
should
be
fine.
B
B
You
know
for
for
geo
going
forward
and
how
we
will
do
that,
and
then
I
think
when,
when
we
have
some
some
ideas
there,
then
we
can
start
a
discussion
and
see
you
know
what
your,
what
your
input
is
as
well,
because
I
think
would
be
great
to
keep
you
keep
the
keep
you
in
the
loop
on
on
those
bits
and
see
what
we
can
come
up
with
cool
cool
yeah.
Thank
you
so
much
for
your
time.
I
like.
B
I
was
very,
very
happy
that
you,
you
know
you
accepted
the
the
call
and
that
you
were
happy
to
meet
and
we're
yeah
we're
also
available.
If
you
ever
are
interested
in
something
specific
to
jio
or
if
you
have
any
questions
or
anything
for
us,
please
feel
free
to
reach
out.
You
can
ping
me
in
in
issues
or
other
team
members.
I
Okay,
I
guess
we,
we
are
very
happy
as
well
to
have
been
protected
by
by
you.
We
are
very
proud
that
this
will
be
used
intelligent
product
and
that
that's
basically
the
way
we
wanted
to
do
it
open
source
so
that
we
can.
We
are
happy
about
our
product
and
we
want
to
have
other
people
using
it.
It's
not
a
core
business
of
renault.