►
From YouTube: 2022-03-29 Object Storage WG
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
Okay,
it
looks
like
we're,
live
yeah,
welcome
to
the
object,
storage,
working
group
sync,
this
is
the
americas
meeting
yeah
I
already
mentioned
before.
I
didn't
have
that
much,
but
we
did
have
like
an
interesting
development
last
week,
which
was
that
we
kicked
up
the
deprecation
process
for
background
uploads,
which
was
a
little
bit
of
like
a
last-minute
decision,
but
with
the
big
15.0
milestone
coming
up
end
of
may,
there
is
a
unique
opportunity
to
do
some
house
cleaning.
A
A
We
knew
that
would
be
around
how
to
best
approach
this
and
like
give
out
some
guidance
for
users
who
are
currently
using
this,
but
we
just
had
to
make
a
call,
and
basically
it
all
came
down
to
given
the
the
data
we
had
and
then
we
looked
at
it
didn't
appear
to
be
a
highly
used
configuration
so
and
it
does
create
a
lot
of
complexity
in
the
back
end,
so
we
just
saw
an
opportunity
there
to
do
it,
so
we
did
it
yeah.
A
So
basically,
what
fell
out
of
this
is
this.
Next
issue,
which
fabian
was
amazing,
like
he
stepped
in
super
quickly
and
brought
up
the
deprecation
notice
as
well
for
the
release
post.
So
we
have
a
new
issue
now,
which
is
basically,
let's
put
together
some
guidance
so
that
you
know
we
actually
give
our
users
something
to
work
with
if
they
are
facing
this
deprecation,
if
they
need
to
deal
with
it.
A
So
I
guess
the
the
question
here
that
came
up
immediately
was
how
jacob
already,
by
the
way
he
already
left
some
comments
around
how
this
could
work.
I
think
he
already
revised
this
somewhere
else.
Maybe
there's
a
simpler
way
to
do
it,
but
of
course
we
should
probably
test
this
somehow
and
yeah
just
write
up
some
documentation.
A
Maybe
a
blog
post,
I'm
not
totally
sure
how
we
usually
do.
This
yeah
make
sure
it
works
and
then
kind
of
publish
that
as
soon
as
possible,
so
that
users
we
can
give
users
a
heads
up
as
well
yeah.
I
don't
know
if
there
were
any
thoughts
on
this
already,
because
all
pretty
fresh,
I
mean
it
kind
of
happened
late
last
week.
A
So
like
especially
we're
looking
to,
we
need
a
bit
more
help
in
like
figuring
this
out.
This
is
also
kind
of
new
to
me.
I
haven't
worked
with
this
before,
so
I'm
definitely
open
for
suggestions
for
how
to
best
like
do
this.
You
know
maybe
yeah,
I
don't
know.
I
guess
we
would
have
to
have
some
kind
of
synthetic
setup
where
we
connected
to
the
affected
object
stores,
which
I
think
it
was
actually
more
than
openstack.
A
I
think
it
was
rackspace
as
well
so
yeah
we
should
probably
set
this
up
and
actually
make
sure
that
these
instructions
work
before
we
publish
them.
Obviously,
some
sounds
like
this
might
might
be
something
that
could
be
time
consuming
so
yeah.
What
I
would
ask
simply
is
like
if
I
could
get
some
help,
yeah
to
make
sure
that
this
like
goes
into
someone's
backlog,
so
that
we
actually
do
this
and
get
it
done,
because
it's
not
that
much
time
left.
A
I
guess,
like
you
know,
we
kind
of
probably
want
to
be
proactive
here
and
get
this
out
sooner
than
later,
and
not
just
on
the
day.
We
actually
remove
support
for
this.
B
And
to
be
fair,
you
know
if
we
say
it's,
it's
coming
coming
short
that
in
reality
we
won't
actually
fully
deprecate
it
until
we
have
a
migration
path
as
much
as
we
may
want
to
do
that
from
an
application
perspective.
B
A
You
may
not
remove
it
until
we
have
a
migration
path
because
we
already
deprecated
it
like
that
already
happened
like
it
happened
as
a
late
addition
to
the
14.9
release,
notes,
yeah,
okay,
gotcha,
yeah
yeah.
For
sure
I
mean
it
is
targeted.
It
is
considered
a
breaking
change
right,
so
we
don't
have
that
much
wiggle
room
there.
I
guess
unless
we
wait
another
year.
That
would
be
unfortunate
because
that
had
been
open
for
three
years.
I
believe
this
issue
that
this
was
not
even
known
right.
A
I
don't
think
there
were
any
new
facts.
Even
that
surfaced.
I
think
I
think
it
was
just
like
it
kind
of
you
know
other
priorities
and
and
all
that,
so
it
kind
of
slipped
several
times,
so
we
never
got
around
to
doing
it.
So
I
guess
now
we're
finally
looking
due
to
it-
and
I
don't
know
how
yeah
and
like
which
team
at
gitlab
would
be
best
suited
if
any
to
look
into
this.
A
Ideally,
like
a
team
that
has
already
dealt
with
object,
storage,
integration
configuration,
but
I
don't
know
who
that
would
be
so
that's
kind
of
where
I
need
help
from
ems
and
pms.
I
guess.
C
I
was
I
was
about
to
ask
about
that
question.
Do
you
say
that
this
is
the
first
time
I've
joined
this
meeting
for
working
group
and
the
reason
I've
done?
That
is
so
I'm
one
of
the
ems
now
in
sustainability
and
I've
got
a
bit
more
context
around
what
we've
been
doing
here
I
actually
said
earlier.
I
know
jacob
has
spent
time
looking
into
this.
Yes,
he's
been
around
for
a
long.
A
Time
so
he's
one
of
the
few
individuals
we
have
to
lean
to
lean
on
a
lot
because
he
has
just
a
lot
of
context,
also
rather
historic
decisions
that
have
been
made
and
yeah
like,
but
but
that's
not
to
say
that
jacob
needs
to
do
that's
right.
C
Yeah,
absolutely,
I
think
he
he
kind
of
gave
me
a
brief
summary
last
week
and
I
think
the
the
impression
I
got
from
marin
when
I
spoke
with
marin
earlier
today,
and
previously
was
sometimes
when
things
are,
don't
necessarily
have
clear
owners.
They
come
into
scalability,
which
is
okay
at
the
moment.
I
think
that's
a
that's
a
model
that
we're
trying
to
make
work
and,
but
obviously
like
this
particular
issue
that
we
have
open.
C
A
Group,
it's
not!
We
don't
have
like
engine,
we
don't
have
formal
engineering
allocation
right,
just
to
be
clear,
like
working
groups
are
fairly
well.
I
don't
want
to
say
informal,
but
like
it's,
maybe
a
lighter
process
right.
So
it's
really
just
like
folks
who
either
have
context
or
some
interest
in
the
topic
they
get
together
and
just
kind
of
group
around
it.
A
But
this
is
not
something
any
of
us
works
on
full
time
and
it's
very
hard
to
get
commitments
out
of
people
which
is
understandable
because
everyone,
all
of
us,
we
still
work
on
our
like
normal
backlog,
work
as
well
and
our
respective
teams.
A
So
so
it's
been
all
voluntary
so
far
and
and
like
this
is
particularly
difficult
because
there
are
very
few
individuals
at
gitlab
who
kind
of
know
have
a
really
good
understanding
of
the
entire
thing
you
know
top
to
bottom
like,
and
this
is
kind
of
a
deep
stack
like
this
is
really
kind
of
fall
away
from
you
know
how
do
clients
initiate
uploads?
How
does
this
all?
How
do
these
requests
propagate
through
workforce,
the
rails,
application
and
then,
finally,
into
some
upload
destination?
A
There
was
a
lot
of
confusion
upfront
around
you
know,
using
like
we
weren't,
using
like
the
same
language
consistently,
and
then
people
thought
they
were
talking
about
the
same
thing,
but
we
were
talking
about
different
things,
and
so
so,
basically,
so
far,
we've
been
spending
mostly
our
time
on
trying
to
actually
get
on
the
same
page
honestly,
like
do
some
archaeology
around
what
has
happened
in
the
past
and
why
you
know,
write
documentation
and
kind
of
yeah
like
think
about
what?
A
A
We
just
I
just
learned
this,
like
just
being
part
of
this
working
group,
that
we
did,
we
don't
use
it
on
forget
lab,
says
it's
not
considered
appropriate
for
any
cng
deployment
and
that's
kind
of
what
we
want
to
be
focusing
on
in
the
future.
So
this
seemed
like
a
good
candidate
to
just
pick
and
say
just
to
like
you
know,
pry
into
this.
Somehow,
let's
get
rid
of
this
see
what
needs
to
happen
to
do
it.
What's
the
impact
is
it
acceptable?
A
It
really
it's
basically
considered
tech
that,
at
this
point,
is
my
understanding
and
quite
a
significant
chunk
as
well,
and
do
you.
D
A
So
this
is
a
great
question
and
it
tends
to
get
very
confusing
when
we
get
to
these
discussions,
because
there
are
a
lot
of
aspects
that
factor
into
this.
But
it's
a
really
great
question
and
it
actually
relates
specifically
to
this
issue
because,
yes,
definitely
no.
We
do
not
support
direct
upload
for
all
of
the
object,
storage
providers
that
we
support
and-
and
that
was
one
of
the
reasons
why
users
were
still
using
this
background-
upload
feature
because
they
couldn't
use
direct
upload
with
that
particular
object.
A
Storage
provider
because
we
require
my
understanding
is
we
require
either
like
an
amazon,
s3
compatible
api
or
it
needs
to
be
azure
or
gcs
block
storage,
so
that
workforce
can
upload
directly
to
these
object
stores.
And
you
know
we
probably
could
add
new
apis
to
support
that.
But
I
guess,
like
the
idea,
was
also
to
keep
you
know
not
let
the
complexity
in
workhorse
blow
up
too
much,
especially
if
it's
a
if
it's
a
provider
that
it's
smaller
than
those
and
not
used
much
so
so.
A
That
was
one
reason,
though,
why
some
customers
were
using
background
uploads,
where
sidekick
moves
files
into
object?
Storage,
rather
than
workhorse
directly,
so
it
was
a
blocker
as
well
for
yeah,
basically
having
direct
upload,
enabled
for
all
buckets
by
default.
D
D
At
it,
from
the
perspective
of
like
was
background,
uploads
supported
everywhere
as
an
alternative
to
direct
upload,
but
you
answered
it.
I
think
you
answered
both
questions,
but
I
think
I
just
had
it
backwards
where
it's
it's
background,
upload
that
is
generally
what's
supported
everywhere
and
and
we
just
need
to
flesh.
A
D
A
A
Just
kind
of
learning
all
of
this,
like
just
being
part
of
a
working
group.
What
I
do
know
is
that
direct
upload
and-
and
honestly
this
is
just
me
looking
at
code
and
like
talking
to
people
so
direct
uploads
and
background
uploads-
also
mutually
exclusive
in
terms
of
like
code
paths
through
the
application,
so
one
will
be
ignored,
so
they're
kind
of
like
in
terms
of
like
switches
in
the
settings.
They
look
like
siblings,
but
I
think
they
are
actually
treated
as
a
mutually
exclusive
switch.
A
So
you
can
only
have
you
can
only
either
upload
everything
through
background
uploads
for
everything
through
direct
upload.
That's
my
understanding
of
it.
A
I
don't
know
if
we
want
to
get
into
the
reads
of
this,
and
this
is
kind
of
what
I'm
still
trying
to
fully
understand
myself
and
write
it
down,
which
has
turned
out
to
be
way
more
complicated
than
I
thought
it
would
be,
because
there
are
some
code
paths
as
well,
where
files
do
also
not
go
down.
This
direct
upload
route
is
my
understanding
because
we
have
like
there
are
cases
where
we
upload
from
the
application
to
object
storage
in
a
sidekick
job,
but
I
think
that
is
not
what
we
call
direct
sorry.
A
I
think
that's
not
what
we
call
background
upload
as
a
general
mechanism
to
move
things
into
object,
storage,
but
don't
quote
me,
but
I
think
that
I
use
cases
where
and
I
can't
even
name
one,
but
I
thought
I
had
seen
it
mention
where
just
just
just
by
name
virtue
of
something
already
being
part
of
an
asynchronous
operation
in
gitlab,
because
there
is
already
psychic
job
running.
We
also
upload
things
to
object
storage
from
there,
yeah,
in
which
case
it
it.
A
B
B
B
Whereas
when
a
user
requests
an
export
it'll
get
queued
into
sidekick,
sidekiq
will
actually
go
through
gitaly
to
generate
the
export
for
all
the
git
data
and
then
go
pull
all
the
data
from
the
database
and
then
export
that
as
far
ball,
that
gets
stuck
into
object.
Storage
from
the
sidekick.
That
content
makes
it
into
the
bucket,
but
never
went
through
workhorse
at
all,
so
it
all
depends
on
where
the
content
got
to
wherever
it
is,
whether
it's
from
the
user
from
somewhere
inside
the
system.
B
The
very
short
answer
on
how
that
comes
into
background
upload
or
not
is
background.
Upload
doesn't
affect
that
kind
of
data
right
system
generated
data
has
nothing
to
do
with
background
upload
it.
It
is
a
background
job,
but
it's
not
background
upload
background.
Upload
is
specific,
exactly
uploaded,
it
got
written
somewhere
and
then
some
other
job
came
to
the
file
system,
pulled
it
and
actually
uploaded
it.
A
Yes,
thank
you
so
much
for
yeah
clarifying
this,
because,
honestly,
this
is
something
that
caused
great
confusion
in
myself
at
first
as
well,
because
background
background
upload
seems
to
suggest
well,
it's
just
like
in
general,
like
sidekick
uploading,
something
to
our
source,
but
that's
not
actually
true.
It
has
a
very
specific
technical
meaning,
which
is
that
it
is
like
a
client
uploaded
file
that
moves
through
workhorse
and
workforce
buffers.
This
file
on
shared
storage.
A
It
might
be
nfs
or
local
storage
whatever
it
is,
then
it
proceeds
to
pass
the
request
to
rails
and
then
rails
runs
the
sidekick
job
to
move
this
file
from
that
cached
location,
into
object,
storage,
which
then
also
all
happens
in
in
ruby,
so
that
that's
kind
of
like
contrary
to
direct
uploads,
where
this
whole,
like
back
and
forth,
does
not
really
happen.
A
Yeah,
it's
it's
a
multifaceted
program.
It's
it's
been
very
interesting
to
learn
how
it
works.
It's
very
complicated
and
there
are
good
reasons
like
why
it's
complicated
I
mean
some
of
them
are
historic,
just
by
virtue
of
how
things
have
grown
and
when
projects
had
been
prioritized
and
then
some
work
didn't
get
finished.
So
we
had
to
move
on
to
other
things,
which
then
yeah
caused
some
of
that
yeah
overlapping
functionality,
where
we
couldn't
really
remove
either
of
them
completely.
A
D
Yeah,
what
I
was
trying
to
ask
before
I
realized
I
was
muted
was
like
was
the
mechanism
that
you
just
described
where
the
file
is
is
buffered
to
shared
storage,
request
is
passed
along
to
rails,
and
then
the
object
is
is
picked
up
by
sidekick
is.
Is
that
the
formal
definition
of
background
uploader,
or
were
you
describing
just
some
other
way
that
things
sort
of
happen?
In
the
background
like.
B
Okay,
that's
that's
the
path
is
user
content
comes
in
through
workhorse
and
where
possible,
workhorse
handles
everything
where
not
rarely
possible
rails
handles
it
and
then
writes
it
to
a
disk
that,
whatever
that
disk
is
the
sidekick
has
access
to
that
pulls
it
off
the
disk
and
puts
it
in
object,
storage,
yeah!
That's
what
we
need
to
get
rid
of
right.
D
A
Like
the
exporter,
like
jason,
mentioned
one
case
that
would
fall
into
this,
which
is
not
considered
a
back.
It's
not
considered
a
background
uploader
in
in
the
sense
we
talk
about
here,
because
this
is
kind
of
the
automated
mechanism
by
which
all
sorts
of
files
that
come
in
through
a
cl
a
web
client
and
make
it
through
the
application
stack,
are
automatically
uploaded
to
object.
Storage.
That's
what
we're
describing
here
right.
C
A
Yeah
so
user
initiated,
I
jason.
Maybe
you
can
correct
me
as
well,
but
I'm
not
sure
if
that's
100
correct
either,
because
I
believe
there
are
cases
where
is
it
like
gitlab
runner
or
like
where
we
have
other
systems
as
well,
that
might
be
posting
artifacts.
So
it's
not
technically
always
user
initiated.
B
B
B
Initiated
that's
a
correct
yeah
way
to
say
that
exactly
whether
it's
the
the
runner
that
is
uploading,
artifacts
or
job
logs
or
containers
or
npm
packages,
etc,
etc,
etc.
These
are
all
client
initiated,
blob,
uploads
right
those
go
through
workhorse,
they
go
through
rails
and
then
those
end
up
out
there.
B
D
D
B
It's
it's
complicated.
We
do
care,
but
that's
probably
one
of
the
things
we
need
to
touch
least
because
it
works
natively
with
direct
upload
now
without
much
of
an
issue
and
if
you're
honestly,
using
that
as
a
background,
uploader
you're,
probably
in
a
huge
amount
of
pain,
just
managing
that,
especially
if
you
have
a
large
fleet
of
runners.
B
A
Like
this
is
basically
honestly
what
90
of
this
working
group
has
been
about
so
far
is
really
like
drilling
into
this.
Uncovering
all
these
layers
of
complexity,
trying
to
understand
why
things
are
the
way
they
are,
what
we
should
fix
and
yeah
and
which
direction
we
want
to
move
as
well
and
yeah.
It's
very
it's
very
easy
to
get
carried
away
because
there's
just
so
many
constituents
to
this
and
the
this
whole
complexity.
Matrix
is
quite
large.
A
I
would
say,
because
there's
so
many
independent
things
that
factor
into
this,
it's
quite
difficult
to
to
say
like
also
where
should
we
start
right
so
so
yeah?
So
I
think
that's
kind
of
why
we
kind
of
try
to
try
to
aim
low
at
first,
let's
say:
let's
first
yeah
really
understand,
what's
going
on
document
it
and
then
identify
kind
of
the
low-hanging
fruit.
If
there's
anything
like
that,
where
we
can
say
okay,
this
is
this.
A
This
moves
us
in
the
right
direction,
at
least
it
might
not,
it
might
not
be
a
complete,
like
you
know,
game
changer,
but
at
least
we
whenever
we're
moving
in
the
right
direction,.
C
That's
helpful
context
for
me,
certainly
actually
that
summary.
When
I
spoke
to
jakob
about
this
last
week,
it
was
clear
that
there
was
kind
of
like
I
think
my
naive
question
was
like.
So
what
do
we?
What
do
we
do?
Next?
How
do
we
get
started
on
this?
It's
clear
that
there's
a
lot
more
or
a
lot
of
research.
That
still
perhaps
needs
to
happen
to
answer
the
earlier
question
about.
If
you
can
work
on
yourself,
you
might
work
on
this
going
forwards.
C
I
think
there
is
an
understanding
in
scalability
that
we
will
dedicate
some
capacity
to
this
at
some
point
in
the
future.
I
think
one
of
the
things
we
want
to
try
and
do
in
scalability
is
give
I
guess,
or
kind
of
focus
on
more
consistent
interfaces
around
these
areas
and
these
challenges
in
a
system
where
there
is
a
lot
of
complexity.
C
I
think
it's
definitely
ticks
that
box.
I
think
that
that,
in
part
is,
is
why
jakob
has
been
involved
and
he
actually
put
a
sort
of
a
write-up
together
a
proposal.
I
don't
know
if
that
was
what
you
were
talking
about
earlier.
Matthias
regarding,
I
think
I've
linked
to
the
issue
in
the
agenda
is
this:
is
this
one,
the
unified
blob,
storage,
one?
No,
so
there's
an
actual
issue,
so
I
think
it
goes
beyond
just
the
background
uploaded
stuff.
I
think
it's
a
more
application.
C
This
is
probably
you
actually
have
commented
on
that
from
from
what
I
remember
yeah-
and
I
I
think
he
is
kind
of
keen
like
in
his
right
to
start
thinking
about
what
solutions
could
look
like,
and
I
think
the
outcome
of
my
discussion
with
him
last
week
was
he
wanted
to
get
more
input
from
the
group
on
his
ideas
here.
I
think
he
also
said
it
would
have
been
great
to
have
some
feedback
from
alessio,
who,
I
know
has
kind
of
like
led
on
this.
Previously
alessio
is
back
next
week.
A
C
Jakub
is
out
next
week,
so
that
gives
leslie
a
week
to
get
back
up
and
running
and
then
maybe
and
catch
him
up
and
work
with
the
group
on
that
but
yeah.
In
summary,
I
think
scalability
is
a
place
where
we're
happy
to
dedicate
some
time
to
taking
this
forward.
So
I
appreciate
that
this
is
definitely
a
group
effort
and
I
also
don't
want
a
communist
to
too
much
at
the
moment.
While
I
don't
have
a
full
understanding
of
these
requirements
from
the
project.
A
Well,
yeah.
Thank
you.
Thank
you
very
much
again
have
any
questions
just
leave
them
in
the
walking
group
slack
channel.
I
I
try
to
answer
questions
as
they
come
in.
I
I
often
have
to
look
it
up
myself.
I
figure
out
myself
first,
but
that's
why
we're
all
here
right.
B
But
we're
about
at
time
technically
we're
pushing
it
right
there.
Actually,
I
just
read
the
issue
twice
and
I
realized
that
that's
not
quite
the
same
thing
that
ben
and
I
have
talked
about
there's
this
concept
of
a
unified
blob
storage,
but
there's
also
the
concept
of
single
bucket,
which
would
allow
a
customer
to
have
one
bucket:
that's
replicated
across
regions
versus
multiples
and
or
one
storage
point
with
one
set
of
credentials
versus
many
things,
simplifying
configuration,
iam,
etc,
etc.
I
will
find
that
link
yep
good
point.
A
Right
thanks
everyone,
I'm
gonna,
stop
recording.
D
D
I
haven't
met
him
yet,
but
a
while
back
when,
when
this
working
group
was
like
pretty
early
stage,
I
had
suggested
like
I
mean
it's
much
more
ambitious
than
the
proposal
he's
made,
but
but
that
we
could
we
could
pivot
what
we
currently
call
package
to
be
like
the
more
general
owner
of
artifacts
and
we
could
potentially
even
use
like
the
same,
like
distribution
based
artifact
registry
for
addressing
use
cases
outside
of
just
container
images.
D
So,
like
I
mean
you
know,
I
don't.
I
don't
know
that
it
necessarily
makes
sense
for
like
arbitrary
file,
uploads
like
screenshots
and
stuff
stuff
within
and
embedded
in
issue
comments
and
stuff
like
that,
but
but
certainly
for,
like
all
all
sorts
of
software
artifacts
and
packages
and
potentially
even
like
backups
and
imports
and
exports
and
and
things
like
that,
all
the
work
we're
putting
into
scaling
up
the
the
container
registry,
like
you
know,
could
be
repurposed
as
a
more
general
purpose,
artifact
registry.
C
And
marshall,
I
suggest
you
meet
with
jacob.
He
and
I
quote
him
on
this.
He
calls
himself
a
gitlab
dinosaur.
I
think
he
was
technically
the
first
technical
hire
he's
been
with
gitlab
since
the
very
beginning,
yeah
the
context,
which
will
be
useful
for
other
parts
of
your
role.
I
imagine
as
well.
A
D
I
should
I
should
sync
him
up
with
with
jiao
from
package
too,
because
I
know
zhao
has
like
similar
ambitions
in
terms
of
like
reusing
the
work
that
they've
put
into
the
container
registry
to
like
be
more
generally
useful
and
they
certainly
seem
to
have
like
the
most
experience.
Doing
like
a
large
scale.
Object.
Storage,
migrations,
like
bioblob
migration.
Since
that's
what
they've
been
in
the
midst
of
doing
for
the
past
several
months
with
the
migrating,
the
entire
container
registry
database
and
whatnot.
A
Yeah
sure,
okay,
we
had
time,
I'm
gonna,
stop
the
stream,
and
I
well
I'll,
see
you
next
week,
hopefully
with
a
lesson
again.
This
one.