►
From YouTube: 2021-01-11 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
A
B
A
Okay,
camille
vladimir.
D
Okay,
I
guess
it
can
waste
strength
right
now,
so
we
shoot
today
and
discuss
our
next
plan.
Currently
we
have
rake
tasks
which
should
be
run
in
second
stage
in
production,
and
then
we
plan
to
basically
yeah
move
every
install,
including
stockholm
to
the
new
architecture.
D
By
touching
the
top
and
yeah
that
sounds
doable
yeah
also,
can
you
mention
that
we
chose
draketask
to
run
this
in
a
controllable
way,
on.com
I'll,
be
able
to
retry
and
see
how
everything
goes
yeah,
but
we
will
convert
it
to
the
background
migration
for
the
self-managed
in
order
to
make
it
more
seamless
for.
D
E
So
like
we
have
like
the
right
task
prepared,
there
is
like
a
future
and
the
swift
running
background
migration
and,
like
we
don't
really
know
what
to
anticipate
in
terms
of
the
data
consistency.
So
hopefully
this
will
allow
us
to
iterate
faster
and
like
in
more
controlled
way,
but
like
basically
the
same
code.
We
then
launched
on
the
in
the
background
migration
for
the
on-prem
installation
and
as
a
final
thing,
semi-manual
process,
but
we
have
that
pretty
well
documented.
So,
let's
see
how
it
goes
like.
We
need
gary
help
on
like.
E
I
I
have
the
question:
do
you
do
anyone
have
like
any
concerns
about
this
approach
of
like
starting
this
data
migration,
we're
actually
looking
at
the
migrating
about
five
terabytes
of
the
data?
That
way-
and
this
is
why
it
is
like
the
background
migration
and
the
way
how
it
is
done,
like
not
really
controllable,
not
really
easily
retrievable,
like.
We
assume
that
this
is
basically
too
risky,
because
it
could
potentially
degrade
the
performance
and
like
be
very
hard
way
to
interrupt
the
process.
B
So
I
haven't
read
this
in
detail,
but
I
assume
that
for
a
while,
whenever
you
know
you
migrate
some
pages,
then
we
start
using
the
new,
the
sip
one,
and
then
the
database
ostensibly
knows
this
like
something
somewhere
knows:
I'm
either
gonna
get
this
from
sip
or
I'm
gonna,
get
it
from
nfs.
E
Yes,
like
basically
what
happens
every
new
deploy
uses,
zip,
basically
right
what
this
migration
does.
It
creates
an
archive
and
store
this
as
a
zip,
so
basically
track
replicates
the
correct
the
current
deploy
mechanism.
So
basically
it
changes
entering
the
database
to
indicate
hey.
This
is
like
your
archive
that
you
should
be
using
right
now.
This
is
exactly
what
it
does
like
this
migration.
E
What
actually
performs
it
like
goes
to
nfs
pool,
so
the
files
put
them
in
the
archive
uploads
to
object,
storage
links
them
to
the
project
to
be
used
and
basically
on
the
next
pages
refresh
of
the
rpg
would
start
using
the
new
archive
if
like,
if
anything,
goes
wrong.
There
is
like
the
feature
flag
that
can
basically
kill
the
whole
mechanism
and,
like
fall
back
to
the
old
way
of
serving
data,
so
we
can
like
roll
back
at
any
point.
E
B
Okay,
all
right,
hey,
brandon,
I'll
review
that
with
you,
so
we
can
cover
the
different
cases,
but
it
it
does
sound
like
we
can
probably
do
some
queries
before
we
start
the
migration
to
have
an
idea
of
how
far
along
this
is,
what
progresses
that
take
it
and
all
that,
and
I
can
ask
what's
that
to
help
us
with
that
as
well.
B
E
B
E
E
Not
make
like
very
extensive
debugging
information
of
the
migration
process
while
it's
being
executed,
so
it
kind
of
starts
out
like
all
potential
errors
in
the
data
migration
right
and
like
the
progress
in
the
migration.
So
it's
actually
like
very
like
exhaustive,
in
amount
of
the
information
that
it
produces
about
the.
B
All
right,
I
know
sre
is
very
constrained
at
the
moment,
so
I
may
just
volunteer
to
run
this
myself
and
just
spend
time
between
meetings.
Doing
this
so
I'll,
take
a
look
at
it
tomorrow
and
then
I'll
circle
back
with
brent
and
then
we'll
figure
out
who
does
it,
but
if,
if
the
sres
can't,
then
I
know
they're
super
busy,
then
I'll
just
take
it.
B
A
Camille
just
so,
I
have
a
flavor
for
what's
what's
the
timeline
it
was.
I
tried
to
look
at
the
issue
and
see
if
there
was
a
timeline
in
the
issue.
It
didn't
jump
out
at
me.
So
if
it
isn't
there,
I
apologize
for
missing
it.
E
I
mean
like
we
have
individual
issues
like
assigned
to
the
milestones,
but
if
you
talk
about
this
running
of
the
particular
particular
migration,
it
really
depends
on
the
sre
being
available
with
that.
So
as
soon
as
we
have
the
person
on
the
infrastructure
side,
the
go
week
that
are
with
us,
we
we
have
the
accurate
timeline
and
expected
finish
date
like
we.
E
A
E
B
Especially
with
my
follow-up
question,
which
is
going
to
be
and
again
I
haven't,
read
the
issue:
is
there
a
way
to
throttle
this?
So,
for
instance,
you
know,
let's
say
the
platform
starts
is
under
heavy
stress.
E
Or
off
this
is
why
we
decided
we've
directed
us
because,
like
it's
right
now
sequential
and
you
can
interrupt
that
in
anything,
okay,
it's
like
if
platform
is
misbehaving
and
like
we
wanted
to
actually
run
this,
to
understand
the
rate
of
the
migration
to
optimize
that
if
it
needs
to
be
faster
than
that,
so
it's
designed
to
be
initially
slow
because
we
don't
know
really
what
to
anticipate
when
we're
gonna
be
pulling
zipping
uploading
data,
but
also
we
don't
know
how
much
stress
it's
gonna
to
produce
and
like
to
answer
your
question
like.
E
If,
if
platform
is
like
misbehaving,
you
can
just
interrupt,
and
it's
gonna
basically
start
from
the
moment
that
you
interrupted
okay.
B
A
Right
I'll
circle
back
sorry,
I'm
gonna
say
that's
good
to
hear,
because
I
literally
just
asked
that
on
the
on
the
change
management
issue
as
well,
but
thank
you
for
putting
one
of
those
together
but
yeah.
I
wanted
to
make
sure
that
we
had
an
end
on
cord
to
pull.
While
we
were
doing
this
as
well,
but
yeah,
jerry
I'll,
add
it
to
our
one-on-one
to
to
just
that
review
together.
F
B
F
Yeah,
I
just
wanted
to
ask
if
we
are
running
this
is
a
rare
task.
That's
fine
great!
Do
we
expect
once
we
enable
the
background
migration?
Do
we
want
to
be
able
to
test
this
on
staging
slash
production
as
well
just
to
cover
that
use
case?
So
I
don't
know
whether
we
want
to
have
one
percent
of
the
data
behind
just
to
cover
it
with
the
background
migration
just
to
see
what's
happening,
or
did
you
even
think
about
that.
E
We
did,
we
did
not
get
to
get
back
to
running
that
as
a
background
migration,
but
I
think
your
suggestion
is
very
good
and
we
should
definitely
like
think
about
running
that
on
the
staging.
I
would
be
not
very
into
running
that
on
the
production
once
we
migrate,
but
we
can
definitely
run
that
and
simulate
that
on
staging
fairly
easy
that
it
did
run
properly.
F
Cool
and
then
the
next
question,
like
will
you
and
vlad
work
on
this
just
asking
because
of
the
time
zones?
If
you
find
an
sre
who
is
in
a
similar
time
zone,
it
can
significantly
speed
up
the
cycle.
B
C
Right
and
in
this
particular
case,
it's
not
that
you
can't
use
oauth,
it's
that
the
automation
of
setting
it
up
fresh
is
going
to
be
a
little
complicated.
C
B
A
Yeah
I
was
gonna
just
making
a
side
note
to
myself
to
to
chat
with
dave
about
getting
somebody
from
his
team
to
assist
here.