►
From YouTube: Pages Sync 2020-08-19
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
A
Recently,
we've
added
somebody
from
scalability
to
the
object,
storage
effort
and
it's
blown
up
the
scope
in
a
different
direction,
and
I'm
I'm
struggling
a
little
bit
with
like
sequencing
and
what
we're
supposed
to
be
doing
and
actually
understanding
also
like
the
technical
work.
So
I'm
hoping
that
I
can
get
a
little
bit
of
an
overview
on
what
we're
looking
to
do
technically,
because
I
do
get
pulled
into
these
meetings
and
I'm
expected
to
surface
like
what
actually
are
we
changing
and
doing.
And
how
does
this
impact
our
instrumentation
of
pages
for
customers?
A
B
Yeah,
first
of
all,
with
the
scalability,
the
main
focus
of
the
scalability
team
right
now
is
in
coupling
puma,
and
that
is
what
they
kind
of
almost
done
with.
I
guess
I
would
say
at
least
half
done,
because
a
lot
of
measure
quest
has
already
been
merged
with
the
main
object,
storage
effort.
B
Basically,
we
had
this
push
from
the
top
at
some
point
to
reconsider,
using
zip
archives,
which
we've
chosen
a
couple
months
back
and
just
use
direct,
what's
called
direct
object,
storage
method
when
we
just
upload
every
single
resource
from
the
pages
archive
to
a
separate
entity
on
the
object
storage.
B
So
how
that
actually
unfolded.
We
had
a
very
long
meeting
like
I
mean
with
a
lot
of
people
a
couple
weeks
ago
and
jacob
from
the
scalability
team
decided
that
he
may
start
with
the
poc
for
the
direct
object
storage
approach.
So
he
started
it.
It
didn't
took
very
long
from
him.
Like
a
few
days,
I
would
say-
and
one
nice
idea
like
basically
what
we
were
doing
before
with
the
object
storage
effort.
B
We
were
like
re-implementing
part
of
the
pages
logic
to
work
with
the
object,
storage
or
some
underlying
storage,
but
yeah,
and
the
plan
and
jaime's
current
proposal
was
to
basically
re-implement
some
of
this
code.
What
jacob
did
was
a
little
different.
Basically,
he
abstracted
away
the
file
system
level
to
a
separate
entity
to
yeah
which
can
be
like
accessed
as
a
file
system
which
can
be
accessed
as
objects,
direct
object,
storage
way
or
zip
archive.
B
It
doesn't
really
matter
there,
but
it's
might
be
a
little
easier
for
director,
brick
search
but
whatever
so
when
we
were
reading
it.
I
realized
that
yeah.
This
is
like
a
great
idea.
We
need
to
do
this
virtual
file
system
layer,
regardless
of
the
approach
we
will
take
and
we
had
like
we
like
last
week
with
jaime.
B
We
were
discussing
that,
like
which
approach
we
should
take
and
the
last
week,
because
jaime's
poc
wasn't
really
fully
fully
functional
versus
jakub's
prc
and
because
there
was
some
other
unknowns
there
with
the
zip
archives,
we
decided
that
probably
like
we
were
like,
we
were
regretting
a
lot
that
we
give
up
all
these
benefits
from
the
zip
archives,
which
allows
much
easier
management
of
the
projects
and
like
yeah,
we
basically
we
don't
need
to
unzip
anything.
B
B
If
you
remember
it
was
causing
some
issues
recently,
yeah
so
but
yeah
we
decided
that
probably
this
direct
book
storage
is
safer
method,
even
though
it's
more
complex,
but
at
the
at
that
point
of
time
there
were
less
unknowns
in
there,
but
we
kind
of
left
ourselves
a
room.
We
knew
that
camille
will
be
back
this
monday,
so
we
kind
of
make
a
decision
made
the
decision
that
yeah
we
are
looking
this
way.
But
let's
wait
for
camille.
B
Let's
say:
let's
see
what
he
has
to
say
so
yeah
camille
was
got
back
monday
and
starts
basically
asked
for
how
we
were
doing
and
yeah.
He
also
liked
a
lot
with
this
virtual
file
system
idea,
which
was
like
what
jacob
did
was
actually
already
merged
by
them.
So
he
started
improving
it
to
yeah
abstract
like
another
layer
which
I'm
like
I
I
won't
go
into
details
but
yeah
and
then
building
a
zip
on
top
of
this
virtual
file
system.
B
So
today
we
basically
have
a
working
poc
from
camille
for
the
zip
archive,
and
we
have
just
had
a
meeting
like
half
an
hour
ago,
finished
meeting
with
jacob
camille
yeah
jacob's
nicole,
rachel
me.
B
B
A
C
B
Yeah,
so
sorry
for
not-
including
you
I'll
make
sure
to
invite
you
next
time,
yeah
so
yeah,
so
we
kind
of
today
we
were
like.
Basically
jacob
was
convinced.
He
also
tried
to
implement
zip
himself
and
what
he
said
is
that
yeah,
both
approach
is
working
and
it's
not
more
complex
to
implement
zip
than
direct
object
storage,
and
since
we
like
me
and
camille,
leaning
towards
the
objects
towards
the
zip
archives,
because
it's
easier
to
manage
data
this
way,
we
would
just
we
decided
that
yeah
we're
going
to
this
direction.
B
So
our
current
plan,
like
basically,
I
will
outline
it
tomorrow
and
break
down
two
issues.
But
the
main
idea
is
to
get
something
in
the
production
working
on
the
this
zip
architecture
as
soon
as
possible
and
like
we
were
discussing,
maybe
we
will
start
with
some
other
project,
but
we
were
discussing
actually
sorry.
B
We
were
discussing
starting
with
docs
gitlab.com,
because
it's
a
big
enough
project
with
a
lot
of
traffic,
also
with
a
big
zip
archive
and
like
the
size
of
the
zip
archive
kind
of
matters
for
the
performance
yeah
I
mean
for
evaluating
if,
if
all
our
performance
hacks
actually
work
as
we
expect
and
they
work
locally,
but
it
would
be
nice
to
make
sure
in
production
that
everything
works
as
we
expected
so
yeah.
This
is
like
the
main
first
step.
B
The
second
one
probably
will
be
to
outline
the
immigration
for
the
dot
com,
because
it's
most
likely
it
will
be
the
single
most
time
consuming
piece
of
work.
B
Yeah
and
I
haven't
created
it,
but
this,
like
probably,
I
probably
should
include
both
of
you,
nicole
and
jackie
camille,
also
suggested
that
we
go
through
the
timeline
and
like
outline
everything
like
when
we
will
have
this
working
well,
we
have
next
step
working
and
all
that,
so
we
decided
that
we
kind
of
start
this
discussion,
asynchronously
so
yeah.
My
plan
for
tomorrow
is
to
create
all
these
issues
write
some
comments.
B
C
So,
just
to
add
to
that
just
to
make
it
clear,
so
the
the
zip
archive
was
the
direction
we
had
stubbed
out
weeks
ago
and
and
the
issues
and
ethics
that
are
existing.
There
show
that
the
we
were
just
asked
to
kind
of
evaluate
and
make
sure
that
was
the
right
direction,
and
so
we've
done
we've
accomplished
that
and
through
that
we
came
out
with
this
extra
layer,
which
is
the
abstraction
in
the
virtual
file
system,
which
is
fantastic.
C
So
we'll
need
to
do
some
updating
to
make
sure
that
those
issues
and
epochs
accurately
reflect
you
know
having
to
build
the
zip
archive
method
on
top
of
the
vfs
and
that
piece
wasn't
there
before,
but
in
terms
of
everything
else
that
vlad
mentioned
that
the
epic
for
the
migration
plan
is
there
it's
just
empty.
C
So
now
it's
time
now
that
we
have
that
final
technical
piece,
we
can
start
stepping
out
that
that
outline,
which
is
what
we
intend
to
do
next,
so
I
just
wanted
to
kind
of
make
sure
it
was
clear
that
that
actually
was
our
original
direction.
We've
just
kind
of
added
some
some
details
there
that
we're
missing.
C
A
So
to
repeat
back
what
I
would
have
heard
in
a
short
succinct
way.
We
went
through
a
path
of
evaluating
a
virtual
file
system
to
abstract
some
of
the
work
that
we
were
looking
to
just
implement,
zip
archive
for
and
now
we're
going
to
go
forward
with
the
virtual
file
system
and
we'll
layer
on
top
of
it.
Our
original
direction
for
the
zip
archive
for
pages-
and
this
will
allow
us
to
reduce
some
of
the
rework.
C
Yeah
and
we
have-
and
some
of
that
work
for
the
vfs
was
already
done
and
merged
by
jacob,
so
we'll
just
be
doing
some
additional
polish
there
and
getting
that
fine-tuning
it
to
work
with
the
zip
approach.
Okay,
perfect.
B
Yeah,
I
guess
like
we
will
certainly
do
some
cleaning
up
while
we're
working
on
it,
but
I
would
say
that,
like
the
biggest
cleanup
should
be
done.
B
B
Yeah
and
just
to
go
back
a
little,
this
like
jacob
and
camille
help
was
actually
very,
very
helpful
because,
before
that
we
were
thinking
how
we
will
implement
all
this,
and
now
like
jakob's
idea,
was
great.
It's
it
simplified
the
whole
architecture
for
zip
a
lot
and
camille
already
built
basically
working
poc
on
top
of
it.
B
So
currently,
what
we
need
to
do
is
just
basically
take
this,
get
it
to
a
mergeable
state,
merge
it
and
yeah,
I
guess,
even
with
even
like
we
spent
a
few
weeks
iterating
there,
but
I
think
it's
it
saved
us
us
much
more
time
than
it
took
us.
A
Yeah,
because
initially
we
thought
that
instrumenting,
the
zip
archive,
would
take
a
long
time
to
optimize
right
and
it
would
take
a
long
time
to
get
to
a
place
where
we
think
it
would
be
able
to
handle
performance.
At
least
that's
what
I
recall
from
our
first
conversations
back
in
february.
So
it
sounds
like
the
brunt
of
the
lifting
that
we
initially
thought
would
be
on.
The
zip
archive
side
will
actually
be
instrumented
by
the
vfs.
B
Not
really,
it
should
be
done
on
zip,
but
camille
kind
of
have
done
already
half
of
it.
I
would
say:
okay
yeah,
but
the
there
was
actually
another
problem.
We
were
implementing.
How
pages
were
serving
files
and
vfs
actually
abstracted
this
way?
So
now
we
can
just
reuse
code.
We
already
had.
A
A
B
Would
say:
yeah,
okay
idea,
but
currently
we
haven't
started
thinking
about
self-managed,
we're
mostly
thinking
about
making
migrating
the
dot-com
as
soon
as
possible,
which.
A
I
think
is
the
right
priority.
I
was
just
more
thinking
ahead
of,
given
that
the
mass
of
our
customers
are
self-managed,
how
this
is
going
to
impact
that
install
base
and
that
we're
not
thinking
of
instrumenting,
something
that
will
only
work
on.com.
So
just
checking
in.
C
It
will
work
across
the
board.
I
think
to
both
of
your
points.
It's
going
to
be.
It's
gonna,
take
a
little
bit
more
thought,
though
so
that'll
definitely
be.
A
first
step
is
the
dot
com
portion,
and
then
we
can
think
a
little
more
detail
about
the
self-managed
piece
and
just
to
kind
of
highlight
one
of
the
things
vlad
already
mentioned,
but
I
think
it's
worth
reiterating
is
that
so
we
have
this
poc
from
camille.
C
We
have
the
vfs
layer
that
was
implemented
by
jacob,
so
we,
the
good
news,
is
even
though
this
took
a
bit
of
time.
A
good
chunk
of
the
work
is
there
and
we
just
need
to
get
it
in
a
mergeable
state.
The
next
big
piece
there
will
be
taking
a
real
life
project,
which,
like
was
mentioned.
Doc's
docs.gitlab.com,
is
a
great
example.
C
Getting
that
deployed
in
a
maybe,
not
perfect
state,
but
just
getting
it
working
and
deployed
so
that
we
can
flush
out
bugs
and
that'll
give
us
a
really
great
idea
of
what
the
migration
would
require
and
that'll
help
us
to
stub
out
that
flush
out
that
migration
plan
a
little
bit
better.
So
that
just
wanted
to
highlight
that,
as
once,
we
kind
of
get
this
in
a
mergable
state.
That's
kind
of
a
good.
C
B
A
I
remember
the
incremental
rollout
and
that
we
kept
hitting
click,
but
so
that
I
just
wanted
to
see
like
how.
A
B
I
hope
this
migration,
like
the
rollout
part,
will
be
a
little
easier
because
we
didn't
have
a
feature
flag
mechanism
for
pages
at
the
moment,
so
we
implemented
not
very
efficient
way
when
we
needed
to
conduct
srs
every
time.
We
need
to
change
something
now
when
everything
controls
through
this
api,
we
can
actually
just
leverage
feature
flags
we
already
have,
so
any
developer
can
flick
them
at
will.
So
it
will
be
easier
this
way,
but
there
is
a
little
like
with
the
current
with
the
zip
archive
and
any
object
storage.
B
There
is
actually
two
pieces.
First
is
the
migration
of
data
to
the
object
search
and
the
second
is
rollout,
so
we
can
do
those
two
simultaneously,
probably
somehow
I
don't
know
yet
like
I
haven't
thought
of
the
way
to
do
so,
but
yeah
I
mean
it's
a
little
simpler
at
some
point
and
it's
probably
more
complex
at
the
other,
because
basically,
it's
two
stages:
instead
of
one
roll
out
one
for
data
and
one
for
actual
serving.
B
Yeah-
and
we
probably
will
need
to
add
more
sites
because,
like
one
of
the
concerns
with
any
approach,
is
memory,
consumption
of
the
pages
demon.
So
on
one
website
it
may
work
fine
without
any
noticeable
difficult
difference,
but
yeah
once
we
start
adding
more,
especially
if
we
start
to
add
more
like
bigger
sites
with
comparable
to
dogs.com,
then
we
can
see
the
huge
increase
in
memory,
especially
if
something
will
be
leaking
which
is
possible
so
yeah.
B
Well,
that's
I
I
don't
know
I
I
I'm
just
trying
to
say
that
yeah
there
is.
It's
really
foreseen.
Yeah
yeah.
A
I
gotcha
all
right
perfect,
so
to
recap
some
actions
I
heard
earlier
glad
you'll
post
the
outline
of
our
next
steps
and
recording
of
the
meeting
with
camille
and
jacob
that
happened
earlier
and
then
you're
gonna
work
on
some
issues
about
adding
the
abstraction
layer
and
how
that
impacts,
the
zip
archives
and
then
from
what
nicole
said,
it
sounds
like
some
of
our
existing
scope
needs
to
get
updated
with
that
information
as
well.
C
Can
I
I
just
want
to
add
one
thing
there.
That's
probably
interesting
or
of
importance
to
you,
jackie,
is
that
there
was
a
conversation
around
range
requests
and
so
the
initially
that,
with
the
zip
approach,
those
will
not
be
supported.
The
impact
of
that
it
was
agreed
is
small,
because
we
don't
necessarily
have
data
to
know
where
that
would
actually
impact
the
page's
customers
and
and
for
example,
that
would
be
used
for
like
if
they're
doing
a
lot
of
video
playback
on
their
sites
etc.
C
So
that
can
definitely
be
done
as
a
separate
iteration
that
will
come
later
and
that
will
kind
of
help
us
determine
as
well.
How
many
customers
would
be
impacted
that
by
that
and
but
the
overall
consensus
was
that
was
generally
low
and
not
a
huge
deal
to
add
as
a
separate
iteration
as
well
as
I'm
sorry
did
you
want
to.
A
Yeah,
let's
go
ahead
and
create
the
issues
for
that.
So
when
we
do
start
rolling
this
out,
it's
like
an
opt-in
thing.
If
people
want
to
upload
it
or
start
providing.
Some
experience
like
the
best
thing
that
we
can
do
is
have
a
place
for
the
tams
to
then
link
their
accounts
that
are
impacted
by
this.
C
Yeah
and
we'll
make
that
clear,
glad
that
that's
not
part
of
the
nbc
but
a
separate
iteration
as
well
as
the
geo
support
jackie,
is
another
one
that
will
need
to
be
called
out
as
a
separate
iteration
as
well.
A
What's
really
good
with
geo
fabian-
and
I
talked
a
little
bit
about
this
at
length-
is
that
our
prescription
is
that
we'll
just
redeploy
pages
sites
for
customers
and
not
have
to
worry
about
serving
them
from
object
storage?
So
I'm
not
sure
if
we
even
really
need
to
go
down
that
path
of
of
having
object,
storage,
supported
in
a
geo
way,
of
course,
we'll
create
the
issues
and
if
they
get
uploaded
heavily
or
if
there's
requirements
like
from
like
gitlab.com.
A
If
we
decide
to
create
different.com
instances
across
the
globe,
we
might
need
to
create
separate
object.
Storages
for
different.com
instances,
not
sure
how
that
like
shakes
out
technically
but
bobby-
and
I
have
definitely
talked
about
this-
a
lot
the
geo
product
manager
so
that
we're
not
blocking
geo
as
far
as
they're
being
able
to
go
to
market
but
they'll
create
issues,
get
them
uploaded,
and
then
I
think
the
biggest
thing
is.
If,
if
we
do
instrument.com
and
other
locations,
we
might
have
to
see
how
that
impacts,
how
we
support
object,
storage,
great.
B
B
Yeah
and
we
can
implement
it
if
it
is
required,
yeah.
C
A
Okay,
I
know
that
we're
one
minute
over
time.
Thank
you
all
so
much
for
breaking
this
down.
For
me,
I
really
appreciate
it.
I
look
forward
to
learning
about
the
technical
discussion.
I
know
that
with
both
release
generation
and
the
release,
cli
camille's
opinions
and
thoughts
really
shape
how
we
want
to
instrument
something.
So
it's
good
that
we're
having
those
discussions
so
early
in
our
path.
Thank
you
all
for
owning
this
and
really
taking
it
forward.
I
appreciate
it.