►
From YouTube: Object Storage WG: 2022-04-12
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
B
I
was
actually
wondering,
should
we
start
with
jacob's
point,
because
it's
more
important
because
there's
a
it's
attached
to
a
date-
and
I
did
the
point
I
brought
up-
we
can,
we
can
do
it
later
so.
C
D
Brave
moment
where
we
said
we're
going
to
deprecate
background
uploads,
and
we
got
the
deprecation
message
in
on
time
for
the
15.0
release
and
that's
great,
but
we're
not
done
there
and
we
need
to
do
something
so
that
we
can
wrap
it
up,
and
we
have
some
had
some
thoughts
floating
about
about
how
to
make
this.
D
So
we
sort
of
did
things
in
the
wrong
order
like
there
was
a
deadline,
so
we
first
said:
okay
we're
going
to
make
the
deadline,
then
we're
going
to
figure
out
how
to
do
it,
and
now
we
still
need
to
figure
out
how
to
do
it
and
have
a
story
for
people
when
they
reach
15.0
and
I've
been
trying
some
things
of
how
to
how
to
deal
with
this.
So
the
the
the
problem
really
with
we're.
Actually,
not
literally,
I
don't
know
if
we're
literally
deprecating
background
uploads
but
another
way
to
phrase.
D
The
problem
is
support
for
rackspace
and
openstack,
because
those
are
two
optic
source
providers.
We
support
now
where
we
don't
have
direct
upload
support.
D
D
Already
so
I
think,
to
be
rid
of
background
uploads,
we
need
to
have
a
migration
path
for
rackspace
and
openstack.
A
I
was
I'm
trying
to
remember
because
I
think
that
wow,
so
my
theory
started
turking
over
yeah,
whatever
so
yeah.
I
was
saying
I'm
trying
to
remember
what
happened
here,
but
if
I
remember
correctly
at
least
openstack
should
have
an
s3
compatibility
layer
which
in
the
past
we
said,
if
you
enabled
that
you
should
be
able
to
switch
to
direct
upload,
then
I
think
no
one
ever
tested
this,
but
that's
the
problem.
Yeah
yeah.
So.
D
So
I
I
tried
looking
into
that,
because
I
thought,
if
we're
going
to
say
just
turn
on
the
s3
compatibility
layer,
I
should
at
least
have
a
link
to
where
it
says
how
to
do
that,
and
I
can't
find
that-
and
I
spent
probably
at
least
an
hour
googling,
for
how
do
I
turn
on
like
how
does
it
even
work,
the
s3
compatibility
layer
in
openstack-
and
it's
very
not
obvious,
so
it
feels
a
bit
disingenious
to
send
users
into
the
woods
and
say
just
turn
on
this
thing
that
we
don't
even
know
where
it
is.
D
D
It
also
has
an
ec2
compatibility
layer.
So
I
think
you
need
to
go
into
the
ec2
compatibility
layer
to
create
fake
amazon
credentials,
and
then
you
need
to
run
an
s3
middleware,
which
is
some
sort
of
python
middleware
on
your
swift
web
server
thing
and
then
use
the
fake
ec2
credentials,
and
then
you
can
use
that
that
that
sort
of
I
got
very
vague
hints
about
that.
That
is
how
it
works.
D
So
I
I'm
not
even
able
to
test
it.
I
don't
know
how
to
install
this
thing.
I
tried
reading
the
installation
documentation
for
openstack
and
it
was
terrifying.
D
D
Rackspace
uses
openstack,
so
you
can
have
openstack
swift
buckets
on
rackspace,
but
they
also
have
their
own
custom
api,
which
I'm
guessing
predates
their
adoption
of
openstack,
and
we
support
both
these
things
and
it'd
be
really
nice.
If
you
could
just
have
one
bucket
and
say
I
access
it
through
the
rackspace
cloud
files,
api
or
xss3,
the
swift
api
or
through
the
s3
compatibility
layer
and
everything
is
still
there.
D
So
what
I
considered
instead
was
to
use
a
sort
of
cloud
rsync
tool,
there's
something
called
rclone,
which
is
an
open
source
tool
that
tries
to
be
rsync
for
cloud
providers
which
is
kind
of
nice.
So
you
can
you
configure
you
install
it
locally
and
you
configure
a
bunch
of
endpoints
in
a
config
file
and
you
then
have
credentials
for
that.
And
then
you
can
say
sync
this
bucket
on
this
provider
to
that
bucket
on
that
provider,
and
then
it
makes
it
happen.
D
So
it's
I
think
it's
the
right
tool
for
the
job
and
I
think
it
would
work
so
that
seemed
like
the
best
path
forward
to
be.
But
then
I
had
another
interesting
problem,
which
is
how
can
you
be
confident
that
you've
updated
your
object?
Storage
configuration
correctly
well,
there's
a
number
of
problems.
I
mean
one
of
the
problems
is
what
if
somebody
has
configured
12
different
buckets
on
openstack,
because
is
it?
What
is
the
number
12?
How
many
buckets
do
we
support.
D
We
need
a
number,
let's
say
10.,
so
somebody
has
configured
10
different
openstack
buckets
for
10
different
features.
D
How
do
you
find
out
when
do
you
find
out
also
like
if
you
do
a
cut
over?
How
do
you
even
know
if
your
system
is
using
the
new
buckets,
because
the
old
bucket
still
has
all
your
data
in
it,
and
when
I
was
experimenting
with
this,
I
was
using
image
attachments
on
notes,
because
those
are
very
easy
to
check.
D
I
just
go
into
a
clean
gitlab
server,
create
issue,
grab
a
random
image,
drag
and
drop,
and
I
can
see
if
it's
working
or
not,
and
if
I
change
the
settings,
I
get
a
404
on
the
image.
So
I
know
the
image
is
gone,
but
that
is
very
specific
to
image.
Uploads
like
how
do
you
test
that
you
correct
migrated,
merge
request
disks
correctly?
How
do
you
test
that
you
configured
lfs
blobs
correctly?
D
How
do
you
test
that
you
configured
artifacts
correctly?
Do
we
expect
people
to
step
through
10
features
and
test
them
by
hand
and
make
sure
that
they're
still
working.
B
Do
we
have
any
sense
of
who,
who
those
effective
users
or
customers
are?
Could
we
reach
out
to
one
or
two
of
them
and
maybe
work
with
them
to
see
like
how
they've
been
using
it
and
how
we
could
help
them
migrate?
It
and
then
maybe
just
yeah,
hope
that
this
might
translate
to
all
the
other
openstack
users
as
well,
because
it
wasn't
that
many
right,
at
least
according
to
our
data.
It
was
like
literally,
you
know,
two
handful,
like
a
dozen
yeah.
A
B
Now
that
I
think
about
it,
it
was
a
while
ago,
but
there
is
an
internal
dashboard
that
is
not
publicly
accessible,
where
I
think
it
includes
the.
I
think
you
can
opt
out
of
it
as
well,
but
if
you're
not
opted
out,
it
should
include
the
the
url
of
where
that
installation
is
hosted
as
well,
and
I
think
there's
some
correlation
ids,
that
you
can
correlate
these
log
events
back,
but
it
was
a
while
ago.
So
I
don't
know
if
it's
still
around.
D
I
think
that
would
be
well.
That
would
be
our
promise
to
make.
A
Yeah,
but
still
this,
I'm
thinking
why
you
are
just
playing
this
yeah
right,
so
yeah.
So
the
thing
is
that
the
system,
because
of
how
we
store
those
information
in
gitlab
itself,
the
airclone
path-
seems
trivial
in
the
sense
that
the
data
on
the
database
will
still
be
okay,
because
we
generate
the
url
mangling,
the
system
configuration
plus
what's
stored
in
our
database,
but
this
means
that
you
can't
really
do
a
live
migration
here,
like.
D
A
To
do
when
we
developed
the
migration
path
from
local
storage
to
remote
storage.
D
What
I
started
drafting
in
that
guide
was
just
to
say,
do
a
sync:
while
the
system
is
active,
so
you
have
a
first
sync
and
then
take
take
a
maintenance
window
and
do
a
second
one,
and
then
you
know
that
your
users
aren't
writing
new
data
and
then
turn
the
system
back
on,
and
then
you
at
least
don't
have
to
copy
everything.
You
still
have
to
list
everything.
Of
course
right.
D
So
it's
it's
not
it's
not
going
to
be
very
fast,
but
that
would
I
think
that
would
be
reasonable
a
reasonable
way
to
do
it.
Migration,
like
this
so
yeah
the
difficult
thing.
The
way
I
see
it
is
it
it's.
It
stays
a
bit
fake
and
hand
wavy
and
just
use
our
clone
and
it'll
work
out,
and
I
I
I
I
can't
make
it
a
whole
lot
better
than
that.
D
I
I'm
not
sure
how
to
make
it
much
much
better
than
that,
and
I
don't
know
if
we're
comfortable
or
if
maybe
it
is
appropriate
to
hand
it
to
our
users,
like
that.
Maybe
it
isn't.
B
I
I
don't
know
either,
and
I
I
mean
I
definitely
appreciate
the
empathy
for
users
here,
but
we
also
need
to
keep
in
mind
that
this
came
back
as
a
community
contribution.
If
I
remember
correctly
the
the
original
implementation
for
this
we,
this
is
something
we
have
never
tested.
We
have
never
worked
with,
so
I
would
be
surprised
if
the
expectation
here
is
that
that
we
would
like
guide.
You
know
all
of
our
users
exactly
how
to
migrate
away
for
from
an
object,
charge
system
that
we're
not
using.
B
So
I
don't
know
like
maybe
it's
a
question
of
expectation
management,
but
I
think
anything
we
help
in
terms
of
you
know
pointing
the
right
direction
is,
is
great,
but
to
lay
out
like
a
very
detailed
path
for
how
that
would
work
for
a
particular
customer.
D
D
It
depends
on
the
customer,
so
maybe
we
need
to
go
to
support
and
ask
if
they
know
know
anybody
who's
using
openstack
or
rackspace
cloud
files,
because
in
practice
not
all
users
are
the
same,
and
if
a
customer
with
a
big
account
complains,
then
we're
going
to
end
up
spending
more
time,
helping
them
than
we
would
if
the
people
are
were
affected
or
not.
Yep.
No
definitely.
B
And
also,
I
don't
think
we
need
to
be
super
hasty.
I
mean
we.
We
we
published
a
deprecation
notice
with
14.9
and
we
intend
to
remove
it
for
15
00,
but
not
everyone
needs
to
immediately
update
to
15.0
right
the
day
it's
released,
so
so
it's
not
like
on
the
release
date
of
15.0
users
will
be
affected
by
this
right.
It's
only
if
they
try
to.
D
D
C
A
A
I
don't
know
how
many
of
you
remembers,
but
basically
we
have
this.
Maybe
it's
nightmare
as
well,
but
we
have
this
flag
on
the
database,
which
is
the
storage
which
I
think
one
is
local
or
zero
is
objects,
remote
object,
search
whatever,
so
we
could
have
a
third
value,
which
is
this
legacy
storage,
so
that
the
point
is
that
you
want
to
upgrade
now.
D
A
D
Sounds
a
little
bit
like
the
proposal
I
made
where
we
can
keep
some
data
in
an
old
location
and
write
data
to
a
new
location
which
I
still
like,
but
which
is
not
something
you
just
could
quickly
come
up
with,
so
I'm
not
sure
we're
in
a
position
to
implement
that.
If
we
did
that,
I
don't
think
we
should
touch
all
the
database
records,
but
we
should
have
a
logic
the
other
way
around.
If
you
have
the
old
flag,
you
have
the
whole
system.
D
Another
problem
with
updating
the
database
is
that
whether
people
are
in
this
state
of
having
an
issue
with
openstack
depends
on
gitlab
yaml
and
not
in
the
database.
So
we
shouldn't
encode
this.
The
current
state
of
gitlab
ymo
into
the
database,
because
the
apping
can
come
in
and
change
gitlab
yaml
and
then
all
these
database
rows
are
wrong.
D
Yeah,
I
don't
know
if
I'm
explaining
it
well,
but
this
these
things
are
orthogonal
and
I
think
they,
if
we
make
them
not
orthogonal.
C
D
So
I
I
didn't
really
prepare
this
well.
One
one
option
is
to
keep
to
stay,
to
stick
with
this
arc
long
story
and
to
ask
support
if
they
know
anybody
who
needs
more
help
with
it.
D
I
guess
the
risk
with
this
arc
loan
thing
is
that
somebody
wants
to
upgrade
and
they
get
stuck
and
they
have
a
hard
time
and
and
yeah.
B
But
to
pick
up
your
point
from
earlier
again
about
adding
support
for
openstack
and
rackspace
in
workhorse,
who
I
mean?
How
have
we
answered
these
questions?
In
the
past
I
mean
I
guess
like
having
support
for
s3
compatible
providers
seems
like
a
no-brainer,
but.
D
That
was
a
big
deal
that
we
were
for
some
reason
we
started.
We
started
out
trying
to
avoid
this,
and
it
was
only
because
there
was
some
very
specific
s3
feature.
We
wanted
to
support
that.
We
couldn't
support,
otherwise
that
stan
added
the
ability
to
do
this.
D
Okay,
so
here's
a
crazy
path
forward
that
I
don't
know
how
people
well,
people
will
think
we
could
give
workhorse
the
path
to
gitlabiamo
and
then
workhorse
can
read
all
the
rails
config,
including
the
openstack
config,
and
then
it
becomes
a
whole
lot
easier
to
do.
Direct
uploads
things.
D
If
we,
if
we,
if
we
don't
do
that,
then
use
the
workhorse
config
file
needs
to
have
a
section
to
support
rackspace
credentials
or
openstack
credentials,
and
people
need
to
fill
that
in
and
all
that.
D
B
Yeah,
it's
also
it's
the
implementation.
Difficulties
are
one
question,
but
another
question
is
today:
it's
openstack,
you
know
what
is
it
going
to
be
tomorrow
I
mean,
I
think
we
also
need
to
kind
of
ask
ourselves
yeah.
Someone
was.
A
B
It
just
it
adds
maintenance
overhead
for
us
as
well.
This
is
a
commitment
we
are
making
to
support
this
right
and
sure
like
if
this
comes
in.
It
always
looks
very
appealing
right.
If
there's
a
merge
request,
hey
we're
using
openstack,
here's
an
mr
that
adds
this
functionality.
You
know
it's
kind
of
like
well
good.
Now
we
get
this
functionality
for
free,
but
then
we're
kind
of
sitting
on
it
and
we're
not
using
it.
We
don't
know
if
it
works,
we're
not
testing
it.
You
know
it's
just.
B
D
B
A
E
Thanks
for
calling
that
out,
we
do
know
that
aws
and
related
aws
do
function.
We
have
a
very
large
number
of
vocal
customers.
That
would
tell
us
if
that
was
not
working
as
well
as
we
do
have
the
functionality
to
actively
and
do
accurately
test
it.
A
Yeah,
one
of
my
points
at
the
beginning
of
this
working
group
was
that
we
had
this
large
number
of
s3
or
object
storage
like
implementation
in
the
wild,
and
basically
some
of
them
are
also
stated
in
documentation
and
things
like
that.
But
then,
if
you
ask
engineers,
there's
no
way
for
them
to
test
those
things
or
even
if
you
think
about
our
qa,
is
not
testing
all
of
those
things
that
we
are
supposed
to
support.
So
if
you
support
something,
we
should
have
at
least
two
ways.
D
It
would
be
nice
to
get
rid
of
open,
openstack
and
rackspace,
because
we've
found
out
that
they're
very
they're
hardly
used
and
it
does
add
a
maintenance
cost
but
yeah
who
can
decide
if
how
good
our
story
has
to
be
for.
So,
if,
if
we
do
this
arc
long
story
like
how
good
does
the
story
have
to
be.
B
Can
we
it's
a
good
question?
I
mean
it's.
It's
almost
like
a
pro.
It's
almost
like
a
product
question
in
a
sense
right,
because
we
did
we're
removing
a
part,
a
feature
that
was
part
of
our
product
and
now
the
yeah.
Now
the
question
is
how
how
abruptly
do
you
want
to
just
yank
out?
You
know
the
rag
award
that
we
just
want
to
like
yeah
make
that
smoother.
D
Well,
thanks
for
the
discussion,
everyone,
I
think
the
first
thing
I'll
do
is
find
out
who
to
reach
out
to
and
support
and
see.
If
we
know
if
we
know
anybody
through
support
who's
using
openstack
and
then
we
can.
D
Maybe
like,
if
we,
if
we
know
nobody,
then
we
can
be,
we
can
keep
things
a
bit
simpler.
D
And
people
in
support
would
also
be
able
to
give
feedback
on
whether
the
documentation
makes
sense,
because
if
it
becomes
a
problem,
then
somebody
from
support
will
be
the
first
one
to
be
confronted
with
it
and
they
will
look
at
the
documentation,
we're
writing
and
if
they
say
oh,
I
can
do
this
with
our
clone.
Then.
D
B
We
can
we
can
we're,
not
gonna,
be
able
to
cover
that
today.
I
just
thought
at
this
point:
it
might
be
maybe
more
efficient
to
synchronously
go
through
some
of
the
documentation
we
have
looked
at.
We
had
like
worked
on
before
and
like
some
of
it's,
I
think
already
not
correct
anymore,
at
least
to
the
extent
I
understand
it.
So
I
was
hoping
that
we
could
just
do
that
on
one
of
these
calls
instead,
but
it
doesn't
have
to
be
today.
It's
probably
not
not
enough
time.
B
B
If
that
switch
disappears,
I
actually
notice
that
direct
upload
defaults
to
false.
So
if
background
uploads
are
not
available
anymore
for
object,
storage
and
direct
upload
defaults
to
false
that
that's
not
really
a
great
place
to
be
in
right,
I
mean
we
should
then
think
about.
Do
we
want
if
we
used
to
on
or
remove
it
all
together,
they
should.
A
Be
removed
together
because
there's
no,
if
direct
upload,
is
false,
it
it
doesn't
work,
so
it
simply
doesn't
work
so
they
I
didn't.
I
don't.
I
thought.
A
A
D
If,
if
that
upload
is
false,
doesn't
that
imply
that
we
first
create
a
an
entry
with
storage,
local
and
then
a
psychic
drop?
That's
no
yeah!
That's
it!
No!.
A
B
It
will
be
gone
right,
I
mean
background,
will
just
not
exist
so
then
the
question
is:
what
does
it
do
if
the
only
options
are
direct
upload
and
something
it's
carry.
C
B
B
Honestly,
which,
for
if
you
have
a
very
small
gitlab
installation
that
might
be
okay
right
from
a
performance
standpoint,
you
know,
if
I
don't
know,
if
you
have
like
a
single
node
gitlab
or
something,
and
maybe
it
talks
to
mineo
or
whatever
then
not
having
direct
upload,
enabled
and
just
always
uploading
through
the
rails
controller
might
be
okay.
A
A
Okay,
so,
as
I
said,
we
are
at
time,
debit
point
is
really
interesting.
I
encourage
who
wants
to
review
that
think
I
yeah
I
mean.
I
think
that
it
is
good
some,
some
of
the
point
it
is
making
about
the
code,
duplication.
We
can
work,
we
can
work
around
them
or
think
through
if
there
are
other
alternatives,
but
also
the
the
idea
of
I
mean.