►
From YouTube: 2021-12-21 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
Okay,
thank
you
jesus
spanish
record,
so
it's
the
the
co-host
is
working
which
is
good.
Okay,
so
welcome
everyone
good
morning,
good
afternoon.
This
is
the
21st
of
december,
and
this
is
the
object,
storage
working
group.
A
Let's
get
this
started
with
the
agenda
items,
so
the
first
items
are
the
action
items
for
last
week.
So
we
had
this
ongoing
effort.
First
one
is
describing
the
current
status
of
the
object
storage,
where
matthias
was
mostly
working
on
diving
things
happen,
making
or
making
sure
that
we
collect
all
the
information.
A
I've
wrote
my
thoughts
on
it
and
I
think
that
the
main
takeaway
is
that
there
is
more
than
what
we
expected
in
the
sense
that
we
had
documentation
about
uploads
and
most
that
documentation
is
mostly
orient
is
mostly
thinking
that
the
problem
from
user
uploading,
something
while
going
through
the
code
trying
to
figure
out
what
we
have
there.
A
This
is
quite
different.
It's
an
extra
use
case.
Another
thing
that
surprised
me
is
that
we
also
have
a
direct
fog
usage
in
one
feature,
only
which
is
the
live
trace,
which
is
kind
of
unique,
but
it's
something
to
keep
in
mind
and
then
we
have
file
level
encryption,
which
is
on
terrafor
yeah
and
terraform
state
files.
So
these
are
the
things
that
surprised
me
out
of
this
for
sure
the
we
should
update
the
documentation
to
mention
that
there
is
this
extra
use
case
and
that
are
kind
of
yeah.
I
mean
we.
A
B
I
have
one
question:
it's
related
to
the
point
number
five,
which
I
added
just
just
a
moment
ago
about
updating
the
blueprint
I
feel
like
the
blueprint
we
have
right
now
is
kind
of
outdated
based
on
what
we
have
learned
recently.
B
We
are
also
not
confident
that
the
solutions
and
iterations
described
there
are
also
something
like
you
know.
We
want
to
actually
implement
so
yeah.
So
that's
that's
the
only
remark
I
hear
here
that
I
have
here
that
actually,
after
learning
about
the
current
state,
we
could
you
know
document
it
better
in
the
blueprint.
A
I
have
no
strong
opinion
on.
Where
is
the
right
place
to
document
this?
So
if
we
think
that
the
the
blueprint
is
the
right
one,
let's
go
for
the
blueprint,
I
mean
the
blueprint
was
mostly
there
for
describing
the
problems.
Problems
are
the
ones
that
are
described.
The
solution
are
marked,
as
this
are
some
hypothetical
directions
we
can
take,
but
the
dri
is
the
working
group,
so
we
can
definitely
update
that.
B
Yeah,
I
mean,
of
course
it
should
not.
The
blueprint
should
not
contain
a
lot
of
technical
details
and
implementation
details,
but
I
still
feel
like
it's
a
bit
outdated,
so.
B
D
How
about
how
about
making
sure
that
the
investigation
is
linked
inside
of
the
blueprint
and
the
actual
documentation
is
updated?
We
have
some
documentation
that
is
talking
about
the
types
of
object,
storage,
processing
we
are
doing
so
maybe
we
can-
or
rather
I'm
suggesting
that
maybe
we
leave
blueprint,
as
is
apart
from
the
fact
that
something
came
out
of
it
right
like
it
was
a
starting
point.
D
A
In
a
documentation
page,
we
used,
we
mentioned
that
object.
Storage
is
not
available
on
community
edition,
which
was
kind
of
surprising
back
in
2018.,
okay,
point
number
b,
collecting
requirements
so
gregor's
up
to
you.
B
So
I
I
did
some
initial
requirements
gathering
in
this
google
spreadsheet
linked
in
there.
I
do
realize
that
it's
not
very
detailed,
and
there
are
just
a
couple
of
points
with
some
very
short
explanations
in
in
a
comment
for
each
row,
so
it
feels
like
there
is
not
a
lot
of
information
there,
but
I
think
it's
actually
a
good
start.
There
are
like
22
requirements.
B
B
We,
of
course,
may
want
to
describe
their
their
currents
a
bit
a
bit
better.
I
do
also
realize
that
probably
not
all
of
them
are
there
but
yeah.
I
think
that
the
documentary
I
created
might
be
a
good
starting
point
for
the
collaboration.
B
So
I
think
that
removing
like
making
it
possible
to
have
a
storage
that
does
not
depend
on
nfs
should
be
in
the
requirements
for
solution.
Like
my
shipping,
my
min
io
is
one
of
the
solutions
right
so,
but
I
think
that
decoupling
github
from
nfs
for
everyone,
not
only
in
the
cloud
native
installation
but
every
every
everywhere
else,
that
might
be
a
requirement,
but
we
need
to
decide
because
it's
interesting.
So
what
happens
when
there
is
a
single
node
installation
with
one
or
two
engineers
working
on
it?
B
Do
we
want
to
store
files
on
disk
in
there
or
do
we
want
to
have
a
solution
like
min
io?
That
would
be
the
same
everywhere.
Basically
right
in
case
of
a
bit
larger
installation,
we
would
replace
min
io
with
something
else,
but
like
this
is
a
balance
I
believe
we
need
to
find,
and
there
is
no
good
answer
or
on
how
we
want
to
solve
that.
Yet
I
believe
I
might
be
mistaken.
B
Jason
might
be
able
to
correct
me
if
I'm
wrong,
but
it
feels
like
this
is
one
of
you
know
the
decisions
that
this
working
group
need,
or
one
of
the
questions
that
this
working
group
needs
to
find
an
answer
for
how
we
want
to
approach.
Dnfs
compatibility.
E
Right-
and
this
actually
is
it's
that,
but
also
one
of
the
main
reasons
that
it
was
brought
up,
is
to
remove
dual
path,
so
you
either
are
just
object,
storage
or
nfs
instead
of
going
okay,
which
one
am
I
and
which
route
do
I
take
so
right
now
we
end
up
in
a
situation
where
it's
complicated,
because
we
don't
have
a
single
method.
So
when
a
functionality,
that's
handling
data,
that's
not
get
is
developed.
They
develop
first
on
the
file
system
and
then
bolt
on
object
storage.
C
E
Midio
should
never
be
backed
by
nfs
and
that's
a
that's
a
that's
something
of
how
min
io
works.
Okay.
Well,
I
mean
I
just
mean.
E
E
Effectively
in
the
future,
we
actually
only
want
to
have
one
code
path
right:
okay,
yeah.
We
we
want
to
stop
going,
is
object,
storage,
present
or
not,
and
just
go
object
store.
Is
this
present?
This
is
where
my
bucket
is.
This
is
where
I
put
my
files
right
rather
than
having
both
that's
that's
the
true
end
goal
at
some
point.
E
That
will
mean
that
we
have
to
do
rate
tasks
and
things
that
actually
do
migrations
of
things
that
currently
have
the
ability
to
sit
on
the
file
system
that
need
to
be
moved
to
object,
storage
and
that's
not
just
uploads.
That's
also
every
other
component
that
we
have
and
interact
with
that
can
be
file
or
object
based,
including
the
registry
as
an
example
makes
sense
thanks.
B
Yeah
and
I
I
think
that
one
of
those
many
solutions
is
to
build
this
artifact
registry,
you
even
like
it
might
be
a
gut
way.
It
might
be
a
fully
fledged
artifacts
registry,
but
then
the
the
question
of
how
do
we
handle
files
stays
the
same
like?
Is
that
a
single,
a
single
registry
that
will
obviously
persist
files
on
disk?
And
how
do
we
scale
that
solution?
B
If
someone
wants
to
move
to
multi-node
installation-
and
I
think
this
is
an
er
quite
important
discussion-
and
I
added
this
requirement-
called
single
code
path
for
single
storage
place
the
couple
from
nfs
into
the
requirements.
I
think
this
is
this
is
very
important,
but
still
it's
not
clear
how
to
achieve
that,
and
whether
it
should
be
min
io
or
something
else
with
a
bit,
but
that
we
have
better
control
over.
E
E
The
important
part,
is
understanding
whether
we
should
expect
and
treat
this
as
a
not
only
first
class
but
first
option
and
what
our
path
is
to
get
there.
However,
the
main
reason
that
this
group
is
around
is
because
object.
Storage
is
so
disparate
and
implemented
in
too
many
ways,
so
they
all
tie
together,
but
they
focus
on
let's
get
one
contiguous
implementation
and
then
let's
make
it
first
class
and
then
let's
make
it
default
kind
of
in
that
order
of
operation.
A
Thank
you,
jason
for
making
this
so
clear.
I
mean
I
I'm
happy
that
how
you
just
described
this
makes
a
lot
of
sense
in
all
the
the
process
that
we
have
done
around
this
yeah.
I
completely
agree
with
you
on
this.
B
Like
before
we
do,
what
are
your
expectations
about
what
should
happen
with
these
scoring
document
or
requirements
document?
Do
we
want
to
review
the
requirements
at
more,
remove
some
or
do
some
initial
scoring
on
on
min
io
or
like?
I
think
we
should
have
some
kind
of
an
action
point
after
the
meeting
about
what
should
happen
next
with
this,
I.
A
Think
that
we
need
solutions,
we
can't
score
solution
if
we
don't
have
them
because
those
aren't
I
mean
these
are
names,
but
no
solution.
Min
io
in
itself
is
not
a
solution.
It's
just
the
removal
of
a
pain
point.
It's
an
enabler
for
doing
some
of
the
improvement
that
we
need,
but
that's
not
a
solution.
A
B
D
Could
you
explain
a
bit
more
about
this
scoring
system
and
like
what?
What
exactly
you're
trying
to
achieve
by
having
this.
B
B
Be
a
bit
more
objective
because
it
feels
like
there
are
many
solutions
to
our
problems,
so
the
idea
here
is
to
enumerate
all
the
requirements
and
things
that
we
want
to
achieve
and
do
some
kind
of
scoring.
That
would
make
it
easier
to
understand
what
I'm
sorry.
I
need
to
do
something
with
this
kid
we'll
be
back
in
like
five
minutes.
C
Yeah,
I
don't
know
if
this
was
brought
up
on
a
previous
call,
but
the
what's
the
difference
between
the
stateless
and
staple
artifact
registry
like
what
I
don't
even
know,
what
a
what
a
state
full
artifact
right.
D
B
D
B
I'm
sorry
so
yeah
the
the
netflix
series
ended
and
I
had
to
switch
to
the
next
one
so
yeah.
So
the
idea
here
is
to
replicate
what
we
did
in
the
ic
gearing
working
group.
B
This
was
how
eric
approached
this
problem
of
having
multiple
competing
solutions
and
uncertainty
around
which
one
is
the
best
one
so
and
it's
kind
of
objective,
because
we
do
have
requirements
and
we
can
score
how
well
given
solution
falls
into
you
know,
requirements
to
make
it
a
bit
more
visible,
which
one
of
the
solutions
might
be
a
preferred
solution,
so
this.
This
is
why
I
suggested
creating
this.
This
google
spreadsheet.
With
this
you
know
naive,
scoring
like
0
10..
There
are
there.
B
C
B
Yeah,
so
so,
basically,
these
are
just
placeholders
for
solutions,
I'm
not
suggesting
any
of
them
just
yet,
except
of
do
nothing
like
that's
also
an
option
that
I'm
quite
certain
that
we
don't
want
to
choose.
B
But
I
put
these
two
stateful
container
stateful
and
stateless
registries
there,
because
I
imagine
that
a
state
less
would
be
something
like
container
registry
before
having
been
integrated
with
its
own
database,
where
it
does
not
own
the
objects
that
are
in
there
like
it.
It
holds
them,
but
it's
rail
site
that
owns
them
and
stateful
would
be
like
the
container
registry
with
database,
where
the
objects
are
being
tracked
within
the
boundary
of
the
artifacts
registry.
C
B
D
C
Well,
so
now
that
I
understand
what
was
meant
by
stateful
artifact
registry,
I,
like
the
the
proposal
that
I
came
forward
with
a
couple
weeks
ago
or
whenever
it
was,
was
to
basically
just
like
leverage
our
existing
container
registry
implementation
and
whether
we
spin
up
a
separate
instance
of
that
for
other
artifact
types
aside
from
containers
or
leverage.
The
same
instance
as
like
an
implementation
details
for
some
concern,
but
I
think
yeah
that
would
fall
under
stateful.
C
D
I,
like
the
only
question
I
had,
is
just
to
make
those
cells
more
clearer
for
future
consumption.
That's
that's!
I
am
I'm
not
for
one
solution
or
another.
B
B
So
this
is
when,
when
you
think
about
the
solution,
we
need
to
actually
think
about
when,
where
the
boundaries
are
where
the
ownership
is-
and
we
know
that
there
are
two
solutions
to
owning
the
objects
metadata,
but
there
is
third
thing
that
we
have
not
discussed
yet
is
who
owns
the
business
rules
of
handling
uploads
and
objects
right
now,
most
of
the
business
rules
are
in
rails.
B
So
that's
that's
another
aspect
of
it's
not
only
about
where
the
where
who
owns
object
metadata,
but
also
who
owns
business
rules
around
handling
them,
transforming
them
encrypting
them.
B
Yeah,
probably
like
I
guess
it
might
be
more
complex
than
that,
but
imagine,
for
example,
what
needs
to
happen
with
a
file
so
that
we
transform
that
or,
for
example,
where
we
encrypt
that
right
now
there
is
this
proposal
of
managing
secure
files
inside
gitlab
and
I
think
darby
phrase
implementing
this
right
now
to
store
signing
keys
for
mobile
applications
so
that
that's
yet
another
set
of
business
rules
that
our
rails
application
we
need
to
handle
to
encrypt
files.
B
C
D
And
then
another
thing
that
I
think
is
a
bit
different
to
the
ic
gearing
working
group
is
that
there
was
a
clear
dri
for
who's
going
to
execute
what
here
grading
things
without
actually
knowing
that
there
is
going
to
be
a
backing
of
you
know,
engineering
power
behind
it
is
going
to
be
another
dimension.
We
need
to
consider
so
I
would
I
would.
I
would
kind
of
go
down
two
parallel
paths
here,
or
rather
I
would
suggest
that
we
go
to
two
different
parallel
parts
here.
D
Figuring
out
what
kind
of
options
we
have
getting
to
the
point
where
we
can
actually
go
down
the
grading
route?
There
is
another
parallel
point,
which
is:
how
do
we
get
to
the
baseline
from
which
we
can
actually
start
working
on
any
of
the
solutions
that
we
select
right
now
from
everything
I
understand
about
what
is
investigated
and
and
what
was
done,
and
we
have
four
different
types
of
implementations
in
in
gitlab
or
how
object
storage
is
being
treated.
We
need
to
get
that
down
to
a
certain
manageable
number
b.
D
We
have
a
glaring
problem
with
carrier
wave
right.
It
just
does
not
scale
anymore
and
it's
creating
problems
left
and
right.
So
we
need
to
consider
addressing
that.
So
it's
not
even
about
cr
carrier
wave
replacement.
It's
about
getting
getting
the
situation
to
the
point,
to
status,
to
the
point
where
carrier
is
no
longer
so
a
problem.
E
D
B
D
Disagree
on
that
one,
a
bit
because
you've
seen
how
these
things
happen.
When
you
actually
start
developing
right,
we
have
some
general
ideas
of
what
short
term
we
can
actually
do
when
we
start
working
on
it
and
implementing
will
be
guided
with
that.
D
So,
instead
of
instead
of
tying
these
two
things
immediately
together,
I
still
think
we
need
to
get
to
a
baseline
point
where
we
can
then
see
how
that
short-term
strategy
will
be
impacted
by
the
the
long
term,
one
right,
so
I
I
still
think
there
is
some
prep
work
prior
to
to
developing
a
full
short-term
strategy
that
we
can
do.
B
I
need
to
think
about
that,
but
I
kind
of
agree
with
you:
there's
probably
something
we
can
do
to
improve
the
situation
in
the
short
term
yeah.
It's
just
not
clear
to
me.
Perhaps
what
I'm
missing
here
is
to
define
the
goals
of
the
working
group
itself,
because
obviously
the
working
group
cannot
be
responsible
for
doing
stuff
where
there
is
no
capacity
within
the
working
group
to
do
stuff.
B
In
most
cases,
I
I
don't
think
it's
feasible
for
the
working
group
team
members
to
actually
even
improve
object,
storage
situation
in
the
short
term.
That
probably
should
be
an
engineering
allocation
and
long-term
solution.
That's
completely
different
beast
something
that
needs
a
budget
and
it's
it's
a
bit
more
difficult
but
yeah.
So
my
suggestion
is
to
actually
you
know,
refine
the
the
objectives
and
goals
of
the
working
group
to
make
it
more
explicit
of
what
the
outcome
of
our
meetings
should
be.
B
A
Yeah
in
regard
of
the
the
short-term
goal,
I
think
that
there
is
the
the
proposal
that
I
made
on
point
two
is
quite
is
really
focusing
on
on
the
pain
point
and
is
kind
of
achieved.
It's
achievable
in
a
couple
of
months,
and
I
would
say-
and
it's
still
kind
of
it's
just
tidying
up
things
so
that
then
we
can
think
about.
Where
do
we
want
to
move?
Which
is
the
next
solution
rather
than
just
thinking?
What's
the
perfect
solution
is
more
about?
A
We
have
things
that
are
working
things
that
are
not
working.
How
can
we
put
fix
things
together
and
yeah,
and
then
we
have
a
baseline
where
we
can
say
okay,
this
is
what
we
have
is
not
dissimilar
to
how
we
store
metadata
today.
So
in
terms
of
we
are
not
going
to
do
big
data,
migrations
or
things
like
that.
We
there's
no,
for
instance,
there's
no
object,
storage,
interaction
in
terms
of
migrating
information
to
one
place
to
another
one.
A
We
can
handle
everything
on
background
migration
just
to
realign
database
and
things
like
that,
and
then,
when
we
have
a
baseline
implementation,
we
can
say:
okay,
we
really
want
to
move
this
to
the
oci
artifact
registry.
Fine,
we
have
one
thing
to
migrate,
which
is
a
base
solution
and
we
migrate
it
or
we
want
to
build.
We
decide
to
build
a
component
because
we
have
more
control
over
it.
Fine,
it's
still
one
thing
to
migrate.
B
In
that
regard,
I
feel
like
knowing
what
the
ideal
solution
might
be
or
semi-ideal
like
we
don't.
I
don't
think
we
need
to
strive
for
perfect
solutions
here,
but
good
enough
solutions
are
good
enough.
So
if
we
know
what
the
good
enough
solution
might
be,
we
can
we
can
iterate
toward
it
a
bit
more.
You
know
responsive,
like
I'm,
not
sure
how
to
explain
that,
but
it
feels
like
without
knowing
what
the
this
good
enough
solution
is
going
to
be.
B
We
might
do
a
lot
of
work
that
we
will
need
to
either
revert
or,
or
somehow
you
know,
extent
or
augment,
but
one
thing
that
I
actually
fully
agree
with:
is
it's
going
to
be
infinitely
easier
to
iterate
towards
any
solution
if
we
decouple
stuff
and
that's
why
the
proposal
of
replacing
carrier
wave
sounds
quite
good
to
me,
because
it
decouples
stuff
from
career
wave
rails,
active
model
and
it
makes
it
much
easier
to
iterate
into
any
direction
we
decide.
We
want
to
go
so
yeah
just.
D
A
quick
question:
does
this
proposal
alessia
and
I
know
we
are
at
time.
Does
this
proposal
exclude
any
future
solutions
that
we
might
come
up
with.
A
C
A
Yeah,
so
I
mean
this
is
kind
of
trying
to
bring
everything
on
par
with
direct
upload
so
that
everything
can
go
through
the
thing
and
then
we
have
a
baseline
where
we
can
migrate
to
the
next
solution.
The
important
bits
here
is
that
there
is
the
the
strong
decouple
between
database
called
back,
so
it's
active
model
codebacks
and
object
storage,
api.
We
treat
those
two
things
as
two
separate
entities
and
there's
you
will
never
wait
for
an
api
call
during
database
transaction
and
vice
versa.
A
D
So,
just
a
quick
thing
before
I
drop
off,
I
would
like
to
know
whether
it
would
be
possible
for
all
of
you
or
more
most
of
you
to
actually
align
whether
this
is
a
solution
that
we
can
consider,
because
for
this
type
of
solution
on
this
size,
I
can
actually
find
a
way
to
fund
the
efforts
and
actually
get
a
move
on
which
would
theoretically
free
up
all
of
you
to
actually
continue
investigating.
D
What
is
the
actual
long-term
solution
we
want
to
strive
for
by
that
time,
we
might
like,
if
I
manage,
to
find
someone
to
fund
this
effort,
and
they
start
working
on
this
they'll-
get
acquainted
with
the
situation
enough
so
that
they
can
actually
catch
up
relatively
quickly
with
whatever
the
solution
might
might
end
up
being
for
the
for
the
long
term.
D
But
I
would
need
to
know
whether
this
is
something
that
most
of
you
want
to
get
behind
and
whether
this
is
something
that
will
actually
buy
us
some
time,
which
is,
I
think,
what
I'm
asking
here,
the
most
like
bias.
Sometimes
so
we
don't
deal
with
incidents,
security
halls
and
so
on,
so
that
we
can
work
towards
a
large,
a
larger
change
when
it
comes
to
like
the
long
term
of
object
storage.
D
So
I
need
to
I
need
to
drop
off,
but
thanks
a
bunch
for
the
discussion
really
enjoyed
it
and
hope
you
have
a
good
holidays.
If
you're
celebrating.
A
So
I
think
we
can
answer
this
question.
I
mean
we
are
past
time.
We
can
answer
this
question
synchronously,
it's
just
a
matter
of
just
asking
everyone
to
take
a
look
at
that
proposal,
see
if
it's
adding
extra
complexity.
If
it's
removing
complexity,
if
it's
going,
you
know,
is
it
simplifying
or
not?
So
if
we
think
it's
falling
short
somewhere
and
then
we
can
make
a
decision,
I
mean
if
we
can
get
this
off
of
our
plate
and
continue
working
on.
What
do
we
think
is
the
long-term
solution?