►
From YouTube: 2020-10-26 Multi Large Working Group
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).
B
Yeah,
so
I
wanted
to
share
that.
Currently
around
eighty
percent
of
projects
on
gitlab.com
are
using
cloud
native,
build
logs.
We
see
no
visible
reddish
or
performance
impact.
B
The
new
architecture
has
been
proven
to
be
resilient
enough
because
during
the
weekend
on
saturday,
we
had
this
object,
storage
service
degradation
and
build
logs
were
working
correctly,
except
of
slightly
increased,
build
wall,
clock
time,
our
correctness,
verification
mechanisms,
detect
the
small
number
of
malformed
locks,
it's
around
0.002
percent
of
all
the
locks,
so
we
are
investigating
that,
although
the
number
seems
very
small,
we
would
like
to
understand
why
it's
happening.
B
We
have
also
enabled
this
feature
for
a
customer
on
premises.
You
can
see
the
link
to
the
slack
threat
in
the
agenda
and
that's
all
I
wanted
to
share.
C
Yes,
I
I
can
speak
about
like
I
cannot
turn
on
video.
Sorry,
unfortunately,
so
did
you
talk
about
my
gitlab
pages?
So
did
you
not
yet.
C
Okay,
so
like
we
achieved
like
the
full
rollout
of
what
we
can
achieve
today,
which
is
like
75
percent
of
the
request,
plus
60
of
the
domains
to
like
to
have
much
higher
rollout.
We
use.
We
need
at
this
moment
like
to
perform
data
migration
because,
like
we
actually
serving
with
gita
pages,
all
the
recent
deployments
of
pages,
but
we
don't
have
the
pure
data.
I
also
like
link
a
bunch
of
the
different
aspects
in
the
in
the
doc.
C
So
if
you
are
interested
about
the
cost
estimates,
how
much
we
will
be
saving
and
how
much
we
can
shrink
our
infrastructure
with
that
and
also
like
to
epics,
where,
like
in
one,
we
track
all
the
remaining
engineering
work
for
the
gitlab.com
rollout
and
like
second
epic,
for
the
github.com
rollout
and
like
what
dependencies
and
like
what
are
the
next
steps,
it's
being
like,
currently
filled
like
with
more
data
as
we
like
develop,
for
example,
after
this
gcs
soft
edge.
C
We
we
actually
survived
that,
but
we
also
noticed
like
a
few
aspects
that
we
may
improve,
so
we're
just
gonna.
Do
it
and
like
this
kind
of
like
an
outage
that
we
had
with
the
gcs
and
it's
not
gonna,
make
pages
like
to
be
much
more
resilient
to
this
kind
of
failures?
Maybe
any
questions
do
you
have
about
like
these
sections
that
I
put
there.
D
C
C
I
think
that,
like
the
next
exon
is
what
we
are
being
blocked
on
and
for
me
it's
like
the
storage
bucket.
It's
really
part
of
our
next
rollout
aspect,
and
this
is
something
that
we're
gonna
need,
probably
like
wednesday
or
tuesday
this
week,
in
order
to
start
like
testing
the
next
aspect.
So
far
as
like
the
timeline
goes,
I
think
we
are
pretty
much
on
the
track
to
ready
to
start
doing
some
proof
of
concept
of
the
data
migration.
This
release.
C
B
So,
basically,
I'm
if,
regarding
the
blockers
or
the
next
steps
for
cloud
native,
build
logs,
I
think
it's
just
increasing
the
rollout
to
100
on
github.com
soon
and
closing
the
epic
about
gitlab.com
rollout.
So
yeah.
A
B
A
B
Think
that
should
go
back
to
what
has
been
done,
and
the
next
is
andrew.
E
Thanks,
yes,
I
just
wanted
to
share
that.
I've
been
working
on
a
fun
financial
model
to
help
us
kind
of
think
through
some
of
the
opportunities
for
a
multi-large
instance.
E
So
you
know
we're
thinking
about
eu
and
china
and
some
other
locations,
and
so
I
put
together
sort
of
an
initial
model
to
capture
the
costs,
potential
costs
of
a
multi-large
site,
and
then
it's
trying
to
answer
the
question
of
like
how
many
users,
how
many
paid
users
would
we
need
to
make
that
site
financially
viable.
So
I
linked
the
issue
there.
This
is
just
an
initial
stab,
but
I'd
love.
If
anybody
has
any
comments
or
feedback
feel
free
to
go
in
there,
the
spreadsheet
should
be
available
to
everyone.
E
A
Andre
I
just
had
a
quick
question:
are
the
the
cost
model?
Is
it
using
the
current
reference
architectures.
E
Yeah,
so
it's
based
it's
based
off
of
our
existing
infrastructure
for
gitlab.com,
which
shouldn't
map
closely
with
the
50k
user
reference
architecture.
E
A
Yeah
the
reason
I
asked,
because
one
of
the
things
that
we're
working
on
json
has
been
working
on
this
is
to
sort
of
map
the
current
reference
architectures,
which
are
photoshop
managed
into
cloud
native,
so
they're
going
to
look
slightly
different,
so
we'll
keep
you
looked
into
that
in
case
you
wanna,
you
know
you
end
up
needing
to
adjust
the
cost
model,
so.
F
Yeah
for
sure
well
before
I
go
into
it
congrats
on
the
gitlab
pages
rolled
up,
when
I
saw
an
outrage
and
get
my
pages
this
weekend,
I
was
like
that's
logical
that
we
have
some
some
teething
problems
with
a
new
functionality,
but
it
was
a
cloud
provider
letting
us
down
so
great
work
by
camille
and
everyone
else
for
such
a
big
change,
it's
gone
very
smoothly
and
the
day
that's
coming
is
that
we
have
a
large
financial
services
provider
interested
in
get
lab
managed
for
them,
but
on
their
own
hybrid
cloud
account.
F
I
think
we
set
a
threshold,
but
I
don't
remember
it.
I
think
I
set
a
threshold
of
10
million
dollars
ar
that's
a
customer
like
that
would
have
to
add
so
we're
not
going
to
do
this
for
everyone.
F
I'd
advise
this
group
to
start
looking
at
best
practices,
and
this
is
the
way
we
did
it
with
git
host
was
we
kind
of
fell
into
that?
I
think
we
know
that.
There's
a
lot
of
infrastructure
software
providers
that
offer
a
managed
service,
mongodb,
elasticsearch
kafka.
F
I
think
we
should
learn
from
them.
We
should
look
at
what
how
they
offer
that
and
understand
the
nitty-gritty,
like
what
cloud
providers
do
they
offer
it
on
who's,
whose
account
is
it
on?
How
is
it
built?
What's
the
vpc
setup
process,
what
are
the
access
controls?
Who
can
access?
What
who
can
do
what
so
that
we
can
figure
out
what
the
best
practices
are
and
yeah
I'd
love
for
this
meeting,
maybe
to
decide
like
who
can
do
a
deep
dive?
But
if
you
start
with
questions.
F
Yeah,
I'm
not
sure
I'll
answer
your
question
directly
so
feel
free
to
make
this
a
two-way
conversation.
But
if
we
want
to
back
out
of
this
like
this
is
the
time
we
still
have
a
window
of
opportunity
of
a
week
or
two
to
say:
okay,
we're
just
not
going
to
do
this
as
a
company.
F
If
we
don't
reach
that
expectations
with
the
customer
in
a
week
or
two,
then
we're
going
down
this
path
and
we'll
have
to
deliver
now
the
customer
doesn't
care
how
we
deliver
it
as
long
as
it's
like,
reliable
and
up,
and
things
like
that,
but
I
think
it's
very
likely
we'll
end
up
with
the
the
hosting
it
on
the
hyper
clouds.
F
The
three
western
hyperclouds,
I
think,
that's
what
and
elastic
and
kafka
are
doing
a
kafka
issue
just
put
confluent
in
the
commercial
company
behind
kafka
and
then,
if
you
host
it
on
cloud
providers,
look
you
know
that
your
instances
are
going
to
go
down
and
things
like
that.
So
in
that
case,
I
think
it
makes
sense
to
host
it
cloud
native,
and
I
think
this
will
not
be
the
last
customer
and
if
it's
a
success
and
our
margins
are
acceptable,
we
might
lower
the
bar
and
and
do
it
for
a
lower
dollar
amount.
F
So,
and
we
learned
with
github
that
auto
scaling
is
like
very
important
and
very
hard
to
get
right.
So
I
think,
if
you
don't
do
it
cloud
native
you'll
end
up.
F
Writing
your
own
cluster
manager,
which
is,
I
think,
a
business
I
don't
want
to
be
in
so
yes,
the
short
answer
is
yes,
probably
this
needs
to
be
cloud
native,
and
this
is
probably
limiting
or
limiting,
but
this
this
this
will
be
cloud
native,
even
though
that
will
not
be
ideal
for
the
first
customer,
but
it
will
be,
it
will
be
better
for
the
company
yeah
100
customers
in.
A
Yeah,
I
mean
the
reason
I
ask
is
because
so
clearly
this
would
be
a
very
high
profile
customer,
where
we
we
own
their
infrastructure
and
application
stack.
Our
cloud
native
dates
were
sort
of
in
july
of
next
year.
A
I
would
assume
that
that
would
have
to
be
brought
in
significantly
depending
on
when
customers
would
expect
this,
and
if
the
cloud
native
stuff
is
not
ready,
then
that
essentially
translates
into
essentially
assigning
people
to
operate
this
instance,
because
it's
going
to
be
very
different
from
gitlab.com,
no
matter
what
we
do,
even
if
we
use
the
reference
architectures,
which
is
something
we
could
do.
One
of
the
things
we
haven't
figured
out
yet
is
how
to
go
from
one
point
to
the
next
in
a
sort
of
in
an
online
fashion.
A
F
F
F
A
F
Going
to
be
team,
that's
responsible
and
they're
going
to
report
up
to
people
and
that
team,
together
with
the
people
they
report
up
to,
can
decide
what
they
want
to
do.
They
don't
want
to
roast
it
on
raspberry
pies,
because
it's
more
reliable.
Let's
do
that.
I
think
uptime
is-
is
of
the
utmost
importance.
A
So
I'm
happy
to
take
point
on
this
and
drive
this
and
have
something
for
the
end
of
the
week.
As
far
as
an
answer
of
whether
we
should
do
this
and
how
we
might
do
it.
A
Yeah
tune,
you
have
a
question.
G
Yes,
basically,
my
question
is:
do
we
expect
that
the
customers
configuration
will
be
kind
of
customized
for
their
specific
requirements,
and
then
that
will
lead
to
the
question
we
plan
to
support
them
and
then,
when
we
get
more
and
more
customers
that
we
host
for
them,
how
to
scale
the
support
to
for
those
customers?
G
G
F
And
right
now
we
have
eight
terraform
scripts
at
get
lab,
so
we
we're
standing
on
eight
different
ways
to
install
like
a
non-cloud
native
installation.
So
there's
people
working
on
that
and
probably
the
basis
of
that
is
gonna,
be
our
performance,
environment
building.
And
so,
if
we're
not
going
to
go
cloud-native
for
probably
we
should
use
that.
But
those
are
decisions
that
jerry
will
make.
G
A
I
just
want
to
add
one
comment
to
that.
If
I
may
so,
customization
is
the
extreme
case
and
that's
usually
an
easy
note
to
almost
any
customer.
The
thing
that
they're
really
going
to
push
is
prioritization
and
we
should
definitely
build
a
process
that
allows
for
that
internally.
We
manage
that
to
be
in
for
that
stuff,
but
this
is
going
to
be
an
entirely
different.
Ballgame
we've
lived
through
some
of
that
with
t-mobile.
A
This
is
going
to
be
a
game
changer,
because
now
it's
their
instance
and
so
they're
gonna
push
for
that.
So
we
should
be.
We
should
definitely
and
I'll
make
sure
we
cover
that.
Have
awareness
that
they're
going
to
push
for
their
priorities.
Gitlab.Com
will
be
an
entirely
different
thing
that
they
well.
They
won't
care
about
it,
but-
and
I
think
that's
what
we're
going
to
see
the
most
stress
on
and
in
my
experience
and
prior
lives
customers,
may
you
know
you
may
say
no.
A
F
Exactly
and
I
think
as
a
best
practice-
maybe
not
mention
customer
names-
I
don't
know
whether
it's
private
or
public,
but
I
think
we
should
just
not
do
it
in
in
these
things.
You
can
put
it
in
the
chat
if
people
need
it,
but
I
think
exactly
that,
and
I
think
it
would
be
great
to
talk
to
some
existing
providers
and
see
what
they've
done.
That's
probably
not
on
their
website.
We
probably
need
to
talk,
but
like
we're
not
competing
with
confluent.
F
Maybe
we
can
get
someone
there
to
help
us
same
for
data
stacks
and
there's.
Let's
first
make
a
list
of
all
the
people
offering
this,
but
there's
there's
a
lot
of
companies
offering
this.
This
is
the
permanent,
the
most
prominent
business
model
to
monetize
open
source
software.
So
let's
learn
from
how
they
manage
that
and
then
that's
a
complex
answer.
F
A
Out
all
right,
josh
yeah
sure
I
was
just
curious
if
we've
done
any
diligence
on
collecting
the
requirements,
you
know,
for
example,
whether
they
need
to
have
or
prefer
to
have
some
kind
of
peering
going
on
between
the
instance
and
their
own
infrastructure
for
deployments,
or
something
like
that,
as
well
as
availability
and
other
requirements
that
might
go
through
and
also
kind
of,
who'd
be
the
best
person
to
connect
with
on
on
these,
to
require
an
account
team.
F
Yeah
we
haven't,
and
I
think
we
shouldn't,
I
think
we
should
think
of
what
we
want
to
offer
and
then
go
back
to
them.
I
think
if
we
do
it
the
other
way
around,
if
you
ask
someone
first
what
they
want
and
then
you
say:
oh
you're
not
going
to
get
it
three
months
later.
That's
not
great!
I
think
we
should
go
back
and
say:
okay.
Well
in
case
you
want
to
manage
service,
not.com
and
not
self-manage.
A
Yeah,
I
don't
just
I
don't.
I
agree
with
you
completely
that
we
want
to
define
it
on
our
terms.
I'm
just
curious.
You
know
from
could
be
as
interesting
input
if
we
already
have
some
idea.
What
we're
looking
for,
but.
F
A
H
So
I
think
you're
mostly
answered.
I
think
what
I
was
going
to
suggest
here
is
that
the
a
customer
like
this
is
is
most
likely
looking
for
us
and
what
what
we're
going
to
offer
from
the
perspective
of
what
we
enable
for
them
and
kind
of
defining
that
around
the
services
and
like
service
levels
and
so
like
internally.
H
We
need
to
evaluate
how
we
provide
that,
and
you
know
what
mechanisms
we
need
to
put
in
place
to
to
deliver
on
that,
but
most
of
that
won't
necessarily
need
to
be
part
of
the
offering
details
other
than
where
maybe
some
choices
that
that
we
want
to
be
a
little
bit
more
deliberate
about
make
a
difference
like
if
you
know,
if
we
want
to
say
that
there's
a
preferred
hosting
provider,
something
like
that.
But
we
we
don't
necessarily
need
to
delete,
deliver
in
the
details
of
this
to
the
customer.
H
F
And
it's
not
going
to
be
preferred
hosting
a
provider,
it's
going
to
be
like
this
only
works
on
these
clouds
like
and
then,
and
then
they
can
say.
Well,
I
you
only
deliver
on
an
adb
house,
but
I
really
need
it
on
gcp
or
azure
and
we
can
consider
that,
but
there's
a
way
to
find
out
which
customer
it
is,
and
we
can
guess
what
cloud
they
want
to
use,
but
like
it's,
this
is
not
even
preferred.
This
is
like
clearly
delineated
like.
F
F
D
Yeah,
so
I
I'm
basically
seeing
this
as
a
potential
opportunity
to
just
prep
for
the
instance
where
we
might
be.
You
know,
running
self-managed
or
sorry
managed
services
for
fedramp
customers,
basically
aligning
with
like
a
cloud
provider
that
we
might
end
up
using,
and
you
know
tooling,
these
managed
services
to
that
provider
and
those
types
of
team
structures
that
we
would
have
set
up
in
place.
Just
basically
maybe
a
nice
walk
scenario
before
we're
doing
the
run
of
fedramp.
If
we
get
to
that
point,.
F
F
A
Moving
on
to
what's
next
camille,
I
have
followed
up
with
brent
on
the
storage
bucket,
so
I'll
have
an
answer
for
you
tomorrow
and
then
gregors.
Do
you
want
to
verize
your
section?
I.
A
H
Yeah,
I
just
had
a
couple
comments
there
that
for
one
for
custom
domains,
we
need
to
be
careful
with
the
iep
address
that
people
have
their
a
record
set
to
in
some
cases,
and
also
that
we
are
cache
control
editors
and
that
are
said
right
now
are
not
conducive
to
putting
this
in
front
of
a
cdn.
So
we'll
need
to
look
at
that
as
well,
but
maybe
this
is
too
detailed.
I
just
wanted
to
make
sure
that
was
taken
into
account.
A
Yeah-
whatever
this,
I
would
drive
this
through
the
architectural
workflow,
because
that
would
allow
us
to
essentially
collect
and
connect
with
everybody,
who's
who's-
the
main
expert
on
this,
so
we
can
put
the
right
set
of
work
together
so
and
also
another
follow-up
item
on
the
cloud
native
reference
architectures
json
has
been
slammed,
so
I
may
approach
some
folks
to
add
some
help.
A
I
was
thinking
about
someone
in
infrastructure
because
you
know-
or
I'm
thinking,
skyrec
or
folks
like
this,
who
have
a
lot
of
kubernetes
knowledge
to
just
try
and
help
out
to
get
these.
We
need
to
get
these
restaurants
architectures
done.
Otherwise
we
can.
We
can
move
forward
with
the
homework
anyway.
That
is
all
I
have
for
today.