►
From YouTube: 2022-04-26 - Object Storage 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).
A
B
Yeah,
this
is
just
a
heads
up
that
the
documentation
rework
is
like
yeah,
I
I'm
just
like
it
was.
It
was
a
long
time
in
the
making
and
actually
contains
less
detail
than
I
had
initially
intended
to
cover.
But
yeah,
like
have
a
look
like
tell
me
if
you
think
this
is.
This
is
a
good
introduction
into
the
main
concepts,
because
I
think
maybe
yeah
like
this
high
level
view.
B
Hopefully
it's
going
to
be
useful
to
get
into
it,
but
that's
enough,
for
you
know
you
know,
let's
say,
there's
new
people
joining
joining
this
effort
and
they
need
to
get
productive,
whether
it's
enough
or
not.
For
this,
I'm
not
sure,
but
that's
something
we
can
decide
on
in
a
in
a
separate
step
so
which
relates
to
my
second
point
there,
which
is
we
do
have
guidelines
as
well,
which
I
did
not
update
for
how
to
actually
add
a
new
upload.
As
oh.
B
I
see
jacob
also
left
the
comment
there
that
we
already
have
an
issue
to
improve
that
yeah,
because
I'm
thinking
this
could
be
a
good
opportunity
to
look
at
these
kind
of
guard
rails.
We
might
want
to
put
in
place
which
could
just
be
a
call
out
if
there's
anything,
we
want
yeah
contributors
not
to
do
anymore.
That
could
be
a
simple
way
to
improve
on
those
yeah.
So
yeah
just
have
a
look,
and
let
me
know
what
you
think.
C
So
I
just
wanted
to
say
that
yesterday
I
was
talking
to
a
teammate
to
warm
in
to
try
and
get
him
up
to
speed
on
how
things
work,
and
I
could
point
him
to
the
merge
request
because
the
thing
wasn't
merged
yet,
and
he
said
it
was
really
helpful.
So
just
his
feedback.
D
C
Awesome,
thank
you.
So
I
think
it's
working
already
and
yeah
about
the
second
point.
I'm
sort
of
getting
ahead
to
the
third
point
that
liam
added
that
the
scalability
frameworks
team
is
going
to
get
more
involved
and
do
more
stuff.
C
I
agree
with
you
that
we
should
also
look
at
those
instructions
for
adding
a
new
object,
storage
thing,
because
I
took
a
brief
look-
and
I
still
mentioned
to
but
still
talk
about
the
workhorse
issue
tracker
and
the
old
project
which
we
got
rid
of
over
about
a
year
ago,
so
they're
not
up
to
date
but
yeah.
I
proposed
that
scalability
frameworks.
C
Well,
probably
me,
I
read
the
merch
request
and
I
look
for
someone
in
the
work
or
I
ask
feedback
from
the
working
group
to
review
if
it
looks
better
because
we
have
the
yeah,
I'm
really
just
getting
ahead
of
things
and
I'm
speaking
for
liam
a
bit,
but
we
have
the
capacity
to
do
these
sort
of
things
and
it's
a
good
way
to
get
started
and
for
us
to
get
familiar
with
yeah
the
status
quo
and
the
things
we
want
to
be
improving.
B
B
Another
point
I
I
I
forgot
if
you
jacob,
had
brought
it
up
before
or
if
it
was
alessio
was
the
idea
that,
should
we
just
ask
everyone
to
not
add
new
buckets,
but
just
if
you
need-
and
you
upload
just
put
it
in
uploads
the
uploads
bucket,
there
was
something
that
sounded
very
pragmatic
as
a
way
to
kind
of
contain,
like
that
kind
of
complexity,
a
little
bit
these
kind
of
things
we
want
to
call
up
here.
D
B
But
that's
not
something
like
individual
contributors.
Working
on
features
have
control
over
right.
That's
more
like
a
like
a
cross-cutting
concern
right,
you're.
D
C
Yeah,
so
very
good
call
out.
I
I
think
that
the
first
thing
to
do
is
to
not
change
anything
and
just
make
sure
there's
an
up-to-date
list
of
how
to
do
it,
because
that
also
helps
communicate.
To
ever.
I
mean
people
inside
the
working
group,
already
kind
of
know
how
bad
things
are,
but
if
we
have
an
up-to-date
list
that
says
this
is
what
you
need
to
do.
C
A
Before
we
get
too
far
ahead,
I
want
to
add
a
couple
of
points.
It's
already
three
now
the
things
that
we
discussed
since
the
beginning.
So,
first
of
all
again,
thank
you,
but
yes,
because
I
was
reading
the
document,
and
I
think
it's
really
on
to
the
point,
because
we
had
this
problem
in
the
beginning,
with
things
that
were
orthogonal
to
the
the
whole
problem
and
was
really
hard
to
understand.
A
Where
we're
talking
about
implementation,
configuration
or
uploading
technologies
and
the
new
one,
even
as
you
said,
it
contains
less
from
what
we
had
before
it's
really.
It
just
explains
you
what
you
need
to
know,
so
I
really
like
it
on
things
being
outdated.
I
think
I
remember
when
we
started
the
working
group
that
there
is
a
page
somewhere
in
the
documentation
which
still
states
that
object
storage
is
not
available
on
community
edition,
so
we
we
have
plenty
of
things
like
that.
A
That
being
said,
the
final
part
where
we
were
discussing
about
the
single
bucket
I
do
agree
having
a
list
where
it
explain
what
it
takes
today,
it's
easier
to
sell
improvement
because
you
just
now
we
are
removing
this
step
and
this
step
and
this
step.
But
I
want
to
point
out
that
the
upload
buckets
already
has
a
subfolder
structure.
Where
is
basically
storing
things
that
are
not
real
uploads,
so
a
couple
of
examples
because
they
came
out
from
the
investigation
we
did
in
the
beginning.
Merge
requests.
C
C
D
A
D
About
it,
a
particular
case
is,
you
know,
like
artifacts,
particularly
the
artifacts
bucket
is
actually
where
the
build
logs,
but
because
a
build
log
is
actually
a
component
piece.
D
B
B
Why,
if
I
add
a
new
upload,
why
would
I
not
be
able
to
add
it
to
an
existing
bucket
instead
of
like
what
is
the
necessity
of
adding
a
new
bucket.
B
C
B
Right
they
would
not
solve
that
problem,
but
it
would
solve
the
problem
of
instead
of
having
to
maintain
11.
We
would
kind
of
cap
up.
We
would
like
stop
that
number
from.
Maybe
that's
not
worth
it.
I
don't.
I
don't
know
it
was
just.
I
thought
it
was
a
very
I.
C
And
it
would
be
much
easier
to
introduce
this
change
once
we
have
a
clear
list
of
steps
that
is
up
to
date
that
people
can
follow,
because
then
we
can
remove
some
items
and
say
define
a
subdirectory
here
on
the
uploads
uploader
and
move
ahead
from
there.
C
B
So
do
we
have,
or
can
we
come
up
with
a
list
somewhere
in
an
issue
or
a
google
doc
of
what
exactly
is
wrong,
outdated
or
just
incomplete
about
the
current
instructions.
E
C
C
I
can
think
of
a
single
use
case,
which
is
I'm
a
developer
and
I
want
to
add
a
new
feature,
and
I
have
to
use
my
own
buckets
because
I'm
not
on
the
cicd
team,
where
we
already
have
our
own
bucket,
I'm
just
making
a
joke,
but
I'm
a
developer.
I
need
to
create
a
new
bucket.
How
do
I
do
that?
C
A
C
A
Yeah
now
my
point
is:
there's
an
extra
step
after
that,
once
jason
tell
you
how
to
do
it
is
that,
then
those
configurations
need
to
be
applied
in
kate's
workload,
for
instance,
so
that
gitlab.com
can
make
use
of
those
new
features
as
well
as.
If
someone
wants
to
test
this
on
staging
staging
graphs,
we
have
plenty
of
environments
now,
so
these
are
definitely.
These
are
missing
step
right
now,.
C
Exactly
this
is
part
of
the
part
of
the
goal
like
because
I'm
writing
it
for
a
developer
who's
working
for
gitlab
inc,
so
they
want
to
see
their
feature
deployed
on
gitlab.com
yeah.
C
D
Instances
for
smaller
instances
in
certain
projects
that
you
know
it's:
okay,
it's
not
that
bad!
You
just
make
a
bucket.
You
make
sure
the
permissions
are
good,
but
they
get
lab.com
scale.
Now
we
have
to
include
it
in
dcp
we
have
to
have
a
gcs
bucket.
We
need
to
have
the
appropriate
permissions.
We
need
to
set
up
the
cdn.
We
need
to
do
it.
It
gets
like
the
infrastructure
task
to
actually
operationalize.
D
C
Yeah
we
just
need
to
I
I'm
not
trying
not
into
how
much
detail
will
we
end
up
going,
but
there
needs
to
be
some
sort
of
high
level
breakdown
of
these
are
all
the
things
you
need
to
do
and
that
you
need
to
think
about,
and
I
think
it
yeah.
I
mean
your
your
point
of
just
using
the
uploads
stuff.
The
uploads
pocket
for
new
features.
Is
it's
a
very
good,
pragmatic
idea,
because
anybody
who's
using
optic
storage
probably
already
has
the
uploads
in
a
in
a
bucket.
A
C
Okay,
david
is
not
here,
he
does
say
some
bring
up
an
interesting
point,
but
I'm
not
sure
if
it
makes
sense
for
me
to
react
while
he's
not
here.
Okay,
I'm
going
to
react
anyway.
C
David
is
talking
about
this
in
the
context
of
package
and
when
I
look
at
it
from
the
context
of
scalability
frameworks,
I
think
I
just
don't
want
this.
I
don't
want
to
just
solve
this
for
package.
C
I
want
to
solve
this
for
everything,
but
but
I
would
ask
david-
and
I
can't
because
he's
not
right
here
and
not
here
right
now-
is
with
what
timeline
he
needs
this,
because
I
think
this
is
on
our
list
of
things.
A
Yeah
I
was
reading
the
david
proposal
and
I
think
that
basically
is
trying
to
select
what
came
out
of
all
the
alternative
or
slight
variation
of
the
solution
that
we
proposed
with
something
that
is
a
real
pain
point
for
his
sim.
So
was
trying
to
say
very
politely
if
we
are
not
going
somewhere
as
a
company,
we,
as
a
team
package,
should
definitely
fix
this,
so
this
is
the
subset
of
the
problem
space
that
we
need
to
fix
for
us.
So
that's.
C
C
Yeah,
I
think
well,
it
depends
a
bit
if,
if
package
implements
something
on
top
of
the
current
system-
and
we
make
somehow
we
manage
to
make
the
current
system
same,
then
we
just
do
the
same
same
thing
twice.
So
it's
it
probably
won't
break,
but
it
is
a
wasted
effort,
but
on
the
other
hand,
if
they
need
something
with
a
certain
timeline,
then
I
don't
know
at
this
point.
I
don't
know
when
we
can
solve
the
general
problem
when
we
can
have
that
solved
so
that
that's
a
decision
I
can
make.
C
A
E
Yeah
I'm
happy
to
to
jump
in
on
this.
I
think
I
put
it
as
a
shared
item
cause.
I
know
I
thought
there'd
be
a
lot
of
overlap
with
some
of
the
things
that
you
were
talking
about,
that
you've
been
spending
your
time.
Looking
at,
I
think
when
I
was
on
this
call.
E
Probably
a
month
ago
now
I
mentioned
that
we
were
hoping
for
scalability
frameworks
team
to
be
able
to
spend
some
more
dedicated
time
on
implementing
some
of
that
output
of
this
working
group
and
some
kind
of
additional
improvements
to
object,
storage
as
well.
We
we've
been
given
the
green
light
to
go
ahead
and
do
that
and
one
of
the
and
again
I
know
jack.
E
I've
mentioned
this
earlier
in
the
call,
and
one
of
the
things
you
want
to
try
and
achieve
in
the
scalability
frameworks
team
is
to
create
kind
of
like
the
one
way
of
doing
it,
and
I
think
that's
something
we
we've
also
mentioned
a
few
times
on
this
call
around
the
multiple
ways
of
doing
it,
as
we
just
did
in
the
previous
point
that
do
we
solve
something
just
for
one
use
case,
or
should
we
try
and
solve
it
for
all
of
those
use
cases
and
when
there's
not
necessarily
been
an
owner,
I
think
that's,
what's
led
to
the
fragmentation
that
we've
seen
not
just
in
object
storage
but
in
in
other
services
and
components
in
gitlab
as
well,
and
so
we're
effectively
going
to
take
a
bit
more
kind
of
ownership
of
this
using
the
ownership
model.
E
I've
linked
through
in
the
agenda-
and
we
have
an
ownership
model
outlined
in
the
handbook
and
the
rough
thinking
of
ours
at
the
moment
is
that
object.
Storage
was,
would
stay
decentralized,
but
the
scalability
frameworks
team
would
be
kind
of
like
the
special,
the
speciality
team.
I
think
we
call
it
in
a
handbook
who
kind
of
like
takes
care
of
the
core
and
takes
all
of
these
requirements
and
ultimately
try
to
deliver
that
core
framework
to
support
the
the
one
way
of
doing
it.
E
So
I
think
all
of
the
output
of
this
working
group
will
form
the
input
of
some
of
the
things
that
we're
doing
as
jacob
just
said.
There's
there's
so
much
to
do
it.
I
think.
E
So
obviously
the
people
this
call
and
in
the
wider
group
are
the
people
who,
I
guess,
are
most
connected
and
care
most
about
the
the
future
of
object,
storage
and
getting
it
right.
So
there'll
be
close
collaboration
going
forward
between
scalability
and
the
people
in
in
this
working
group
and
kind
of
other
teams
who
have
involvement
with
with
object
storage
as
well
yaakov.
I
don't
know
if
you
have
anything
to
add
to
that,
like
specifically
around
the
way
that
you've
been
thinking
about
solving
these
problems.
E
C
C
Yeah
so
so
far
there
are
five
high-level
problems.
I'm
not
saying
this
is
exhaustive,
but
this
is
so.
This
is
a
start.
C
The
deleting
objects
during
callbacks,
which
leads
to
postgres
saturation,
as
you
know,
so
that
is
problematic
and
the
high
level
solution
to
that
is
asynchronous
objects.
Deletion
doesn't
say
how
we're
going
to
achieve
that,
but
that's
probably
where
we
want
to
take
that
this
has
to
do
with
the
immutable
keys
so
because
they're
not
immutable,
you
have
to
do
these
copies
and
we
get
that
mess.
C
Then
there's
the
security
problem
of
unauthenticated
uploads,
where
on
the
catch-all
route,
this
is
the
thing
matthias
discovered
that
we
have
the
skip
rails,
pre-authorizer,
that
is
on
all
requests,
and
then
we
go
through
all
the
upload
logic
in
workhorse
without
ever
pre-authenticating
on
certain
on
a
lot
of
requests
and
anytime,
there
is
a
there
have
been
multiple
security
incidents
in
the
past,
around
processing
uploads,
because
you're
processing,
image
files
and
those
things
are
just
prone
to
security
incidents.
C
So
that's
something
we
want
to
do
short
term
and
yeah,
there's
all
sorts
of
like
legacy
code
problems,
and
I
consider
background
upload
one
of
them.
We
have
an
issue
for
that
now,
but
one
win
is
going
to
turn
that
into
an
epic
because
to
properly
remove
background
uploads,
we
probably
have
to
do
multiple
stages
and
I
added
an
item
for
the
documentation
refresh
and
we
may
end
up
single
buckets
to
this
table
to
this
list,
but
yeah.
This
is
our
starting
point,
and
these
are
some
concrete
issues
that
we
have
now.
C
A
I
have
one
question
which
is
probably
is
spread
across
several
of
those
items
so,
but
I
want
to
just
make
sure
if
it's
in
in
your
idea
and
by
your
men,
you're
as
a
the
team
owned
that
will
work
on
this,
which
is
carrier,
wave
removal.
C
Yeah
we're
thinking
about
that.
I
I
talked
about
it
with
one
win
and
we're
trying
to
figure
out.
One
of
the
problems
with
this
is
that
it's
such
a
bowl
of
spaghetti
and
it's
not
clear
which
spaghetti
is
safe
to
pull
on
and
yeah.
C
One
thing
one
win,
and
I
are
going
to
think
about
now,
is
whether
we
can
add
the
new
storage
to
carrier
wave
that
abstracts
away
the
difference
between
file,
storage
and
fog,
storage,
to
pull
more
ownership
of
this
code
into
gitlab,
and
then
maybe
at
one
point
you
can
get
rid
of
carrier
wave.
I
think
tossing
out.
Carrier
wave
altogether
is
more
risky,
but.
C
C
C
It
part
of
this
and
I'd
rather
talk
about
these
type
of
problems
than
we're
being
very
specific
about
once
the
gem
is
gone,
we're
we're
going
to
be
better
off,
but
it's
probably
going
to
I
yeah.
I
don't
know,
what's
going
to
happen
with
carrier
wave,
but
it's
we
definitely
need
to
do
something
with
it.
A
C
E
E
Yeah,
I
I
think,
there's
a
piece
of
work
for
us
to
do,
and
I
think
this
will
probably
inspire
that
piece
of
work
in
frameworks
around
defining
what
we
mean
by
core
framework
for
object,
storage
and
I
think
that'll
probably
have
some
functional
requirements,
some
non-functional
requirements,
but
one
of
the
points
we
add
here
is
adding
new
object.
Storage
features
is
complicated.
One
of
the
ways
to
solve
that
is
by
improving
the
documentation.
E
I'm
sure
there's
also
technical
things
that
we
can
do
to
make
plugging
in
easier,
and
I
think
when
we
define
kind
of
what
we
mean
by
core
framework,
that'll
be
one
of
the
things
we
can
cover
and
we'll
talk
about
kind
of
like
or
how
it's
formed
right
and
is
carrier
wave
part
of
that
as
a
dependency,
so
yeah,
hopefully,
that's
something
that
will
come
inside.
A
Okay,
as
jason
pointed
out,
I
didn't
notice
that
we
are
not
a
time
but
bus
time.
So
sorry
about
that,
no
I
mean
we
enjoying
the
school
so
just
want
to
say
to
wrap
this
up.
We
should
definitely
try
to
frame
this
together
with.
How
can
we
declare
that
we
are?
A
We
are
done
with
the
working
group,
so
maybe
we
should
try
to
find
some
time,
maybe
jakob
me
and
liam,
or
to
just
try
to
to
came
to
a
conclusion
and
say
the
working
group
is
done
here
and
now
the
frameworks
team
is
picking
up
and
continuing.
So
let's
think
about
this,
let's
think
what
we
need
for
dealing
with
the
ongoing
stuff
and
yeah.