►
From YouTube: 2021-11-09 Object Storage WG - AMER
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
This
is
the
object,
storage
working
group
meeting
for
the
us
america's
friendly
time
zone.
So
we
had
another
code
this
morning,
so
we
went
to
the
first
three
four
items
in
the
agenda.
I
encourage
you
to
watch
the
recording.
If
you
have
a
question
or
if
you
want
to
bring
back
some
of
those
topics
you
just
put
them
at
the
end
or
in
the
agenda.
We
can
discuss
them
again.
A
B
A
That
I
want
to
point
out,
which
is
relevant
to
all
of
you
as
well,
is
that
we
kind
of
agreed
point
three.
We
kind
of
agreed
to
just
have
alternate
this
meeting
between
epoch,
friendly
and
america's
friendly
time
zone.
So
we
do
every
other
week
because-
and
maybe
we
could
consider
extending
the
time,
say
45
minutes
we
can
decide
this
later
on,
let's
see
how
it
goes,
but
this
morning
we
had
yeah
quite
a
struggle
to
defeat
the
conversation
in
the
30
minutes
window.
A
And
so
the
point
is
that
this
is
a
working
group
is
not
engineering
allocation,
so
we
are
going
to
try
to
came
out
with
an
architecture
with
a
solution
that
we
can
prove
with
proof
of
concept
and
with
small
implementation,
but
we
are
not
going
to
fix
the
entire
spectrum
of
this
problem
in
this
working
group.
A
So
we
want
to
validate
that.
The
effort
is
visible.
We
want
to
validate
the
solution,
fits
our
need,
and
then
we
can
create
epics
and
things
that
then
can
go
through
the
enduring
allocation
so
that
we
make
sure
that
engineers
can
be
assigned
to
it.
And
this
gets
scheduled.
And
then
we
basically
get
out
of
the.
C
A
A
A
Basically,
this
is
quite
it's
a
bit
technical,
but
I
think
it's
important
that
we
came
up
with
what
are
the
requirements
before
we
get
into
the
details
of
the
implementation,
also
because
just
reading
the
lists-
and
the
comments
that
were
made
in
here
seems
like
we
are
already
drifting,
so
I
would
just
re
quickly
through
this,
which
is
basically
one
point
is
that
we
would
like
to
be
able
to
prefix
every
object.
A
A
There's
point
three
is
important,
which
is
the
one
one
of
the
biggest
problem
is
that
we
copy
file
from
one
bucket
to
another,
one
which
is
needed
in
certain
use
case,
but
is
not
necessary
in
all
of
them.
So
we
want
to
make
sure
that
we
are
not
spending
time
coping
things
from
one
bucket
to
another
one,
because
this
is
causing
troubles.
There
are
basically
there
are
limits
around
this,
because
then
we
request
may
time
out
and
there
is
cost
involved.
A
I
think
I'm
happy
that
jason
is
here,
so
I
think
that
removing
local
file
storage
support
is
something
we
should
keep
in
mind,
but
is
not
our
primary
goal,
because
there
are
a
lot
of
complexity
around
this.
A
So
as
much
as
we
can
keep
workers
code,
as
is
so
that
it's
already
able
to
write
files
on
disk
and
we
keep
the
implementation
generic
enough.
A
Maybe
it's
better
than
just
focusing
only
on
object,
storage
because
then
we
will
have,
and
if
the
customer
doesn't
have
object,
storage
we
go
through
a
completely
different
code,
but
that
we
don't
really
want.
In
my
opinion,
oh
yeah
geo
replication
is
not
an
important
thing
and
then
there's
point
seven,
which
is
kind
of
tricky,
because
I
added
this
one,
which
is,
it
should
be
possible
to
upload
more
than
one
file
on
a
single
http
request
and
later
on
the
on
the
agenda,
I
found
something
that
we
say
we
removed
multiple
file.
A
Uploads
through,
I
think,
was
a
security,
merge
request
or
something
like
this,
and
this
is
not
true,
because
graphql
is
able
to
upload
up
to
10
files
on
the
single
request
as
well
as
when
we
do
an
artifact
upload.
We
expect
to
write
the
artifacts
and
the
metadata,
which
is
another
file.
C
Well,
let
me
chime
in
on
in
regards
to
the
object,
storage
versus
local
files.
Only
olessio
is
100
on
point
right
now
is,
ideally,
we
may
want
to
eventually
get
to
the
point
where
we
don't
have
to
worry
about
local
file
storage.
This
has
been
a
long-standing
proposal.
We
could
standardize
on
the
single
storage
methodology
and
it
would
remove
a
lot
of
complication
in
the
code.
C
C
The
reason
this
is
complicated
is
there
are
customers
that
aren't
big
enough
to
warrant
the
complication
of
object,
storage,
they're,
not
very
big
they're
50,
100
users
running
a
self
instance,
probably
inside
of
a
docker
container,
but
then
yeah.
C
C
B
Thank
you
can
I
can.
I
just
also
make
a
remark
that
everything
I've
read
so
far
in
the
agenda
and
the
discussion
unfortunately
didn't
have
time
to
review
the
recording
made
back.
There
is
a
lot
of
ideas
here.
There
is
a
lot
of
things
we
want
to
do.
Can
we
just
do
one
thing,
and
I
know
this
is
not
going
to
be.
You
know,
probably
the
most
impactful
we
we
should
select
something
that
is
most
impactful
for
this
working
group.
B
So
if
we
are
looking
at
carrier
wave
as
being
the
biggest
security
whole
or
concern-
or
you
know
like
thing
that
that
doesn't
really
scale
anymore,
should
we
focus
on
just
that
and
when
I
say
that
I
also
mean
find
a
replacement
architecture
for
it
without
changing
the
rest
of
the
architecture
and
then
create
working
groups
after
the
fact,
for
you
know
ensuring
that
what
it
stands
stay
here,
ensuring
that
we
have
a
prefix
or
that
can
be
like
the
first
thing
that
we
do
like
if
this
is
really
important
for
us.
B
A
I
mean
this
is
kind
of
a
very
specific
implementation
that
is
completely
outside
of
everything
else,
but
is
built
on
a
framework
that
is
inside
the
application.
And
if
we
don't
stop
that,
instead
of
dealing
with
just
the
design
management
feature,
there
will
be
10
features
by
the
time
we
reach
that
point.
So
having
let's
say
a
map
of
what
we
want
to
do
may
help
us
just
yeah
just
making
the
right
decision
about.
What's
the
first
thing
to
work
on,
even
if
it's
just
two
of
them.
B
And
we
also
know
that
all
the
other
items
that
are
described
are
pain
points
for
the
customers
specifically,
but
are
not
necessarily
as
impactful
as
as
carrier
with
specifically
right,
as
in
you
know,
like
the
fact
that
we
don't
have
a
prefix
for
buckets
is
inconvenience,
it's
hard
to
figure
out,
what's
happening
when
debugging
and
you
can't
really
easily
put
everything
in
one
bucket.
A
For
workers
to
know
where
to
store
those
those
those
objects
in
the
bucket,
he
has
to
point
to
a
specific
feature
bucket.
So
the
idea
of
having
the
catch
or
one
is
that
you
you?
Basically
don't
you
don't
care
either
if
there's
a
pre,
the
prefix
or
not?
But
the
point
is
that
the
api?
So
if
we
have
a
casual
bucket,
we
can
design
this
api
so
that
we
can
store
everything.
A
A
B
Right
well,
one
one
of
the
things
to
also
consider
is
it's
usually
the
first
thing
we
do
when
when
we
write
code
right
like
the
first
thing
we
do,
is
we
add
yet
another
solution
to
the
problem?
The
famous
x
kcd
right?
Can
we
think
about
this,
as
what
can
we
remove?
Rather
so,
if
we
go
a
bit
backwards,
maybe
that
also
crystallizes
some
of
the
pass,
because
we
now
we're
now
talking
about
adding
yet
another
level
of
apis
to
actually
handle
some
of
this.
Can
we
talk
about?
B
What
can
we
actually
remove?
First,
to
see
whether
we
can
simplify
the
problem
before
we
go
into
a
full-blown
solution
for
everything.
C
Right,
I
agree
here
from
the
actual
application
deployment
consumption
perspective,
having
the
requirement
that
every
single
thing
have
a
separate
bucket,
because
they'll
interact
with
them
differently
and
some
of
them
can't
coexist
safely
is
a
distinct
point.
C
C
B
I
I
definitely
agree
that
we
need
a
list
of
requirements
like
without
that
we
we're
not
there's
no
point
there.
What
I'm!
What
I'm
also
trying
to
say
here
is
that
we
are
always
trying
to
discuss
some
solutions
and
I
don't
think
that's
a
good
move
right,
because
we
are
already
talking
about
adding
something
new.
You
shouldn't
add
something
new.
B
We
should
think
about
removing
things
because-
and
I
I
hope,
like
not
only
the
requirements
of
what
we
want
to
achieve,
but
also
the
the
current
state
needs
to
be
clearly
laid
out
and
again,
I'm
not
saying
that
work.
You
did
already
also
on
the
blueprint,
doesn't
lay
this
out,
but
it
probably
needs
more
socializing
people.
So
that's
another
thing
that
we
need
to
consider
that
more
people
need
to
be
familiar.
B
Even
if
it's
true
only
this
working
group
need
to
be
familiar
with
the
general
issues,
create
or
write
up
the
requirements
that
we
also
have
and
then
only
talk
about
what
kind
of
solutions
do
we
want
to
go
through.
So
I
don't
know
how
often
any
of
you
participated
in
working
groups,
but
you
know
one
of
the
things
that
makes
folks
uncomfortable
about
working
group
is
that
it
takes
time
to
create
this
common
knowledge
and
you
it's
natural
right,
like
you're
all
engineers,
you
want
to
go
in
towards
solutions
immediately.
B
What
I'm
saying
is
it's
okay
to
take
a
bit
of
time
to
actually
discuss
this
share,
a
common
understanding
as
long
as
we
time
box
it
so
that
we
don't
sprawl
it
too
much.
So
you
have
a
fairly
large
group
of
people
that
want
to
participate
in
this,
so
try
to
also
spread
these
tasks
around
with
people.
So
this
is
not
only
you
doing
work.
B
There
are
other
people
in
here
as
well,
so
I
would
kind
of
suggest
that
you
find
a
way
all
of
you
find
a
way
to
contribute
to
the
requirements
list
to
the
current
state
of
things
as
well,
and
you
have
starting
points
right
unless
you
had
created
that
blueprint.
Many
people
have
reviewed
it,
but
not
everyone
who
is
in
this
group,
so
it
could
be
one
useful
thing
for
people
to
do.
Have
you
know
a
shared
outside
of
working
group
session
where
people
are
trying
to
share
that
knowledge
and
understand?
B
What's
done
there
and
possibly
review
the
image
request
and
get
it
into
a
state
where
it
can
actually
be
merged?
It's
number
one
and
number
two
folks
like
stan
and
some
other
folks
who
know
some
of
these
requirements.
They
can
help
out
writing
them
out
as
well.
In
one
common
place
and
time
box
say
you
need,
I
don't
know
a
week
or
two
weeks
to
do
this
in
two
weeks.
B
We
want
to
have
a
clear
set
of
requirements
and
a
couple
of
other
things,
and
at
that
point
we
want
to
discuss
this
next
set
of
actions
which
is
review,
create
cut
lines
and
move
forward.
So
if
you're
expecting
that
you're
going
to
be
talking
about
implementation
in
the
next
month
or
two,
I
think
you
we
all
need
to
readjust
some
expectations.
I
think
it's
more
important
in
this
case
to
actually
share
this
knowledge
between
folks.
The
more
people
know
about
it,
the
more
the
easier
it
is
to
actually
find
a
better
solution.
B
B
Need
to
do
instead,
just
almost
at
times
just
one
more
item
like
the
the
poc
ideas
in
there
are
not.
That
is
a
good
idea
as
well.
Right
like
there
are
some
suggestions
further
down
the
line
where
there
is
a
discussion
about
what
can
be
poc.
That's
another
great
thing
that
you
can
paralyze.
There
is
no
reason
why
a
group
of
folks
in
this
working
group
cannot
split
off
into
a
poc
group
that
will
be
prototyping
couple
of
options
just
to
see
what's
out
there.
What
kind
of
technical
solutions
are
out
there?
B
So
if
you
have
a
group
that
works
on
like
the
previous
two
items
and
a
group
that
works
on
pocs
at
some
point,
you
need
to
share
those
that
knowledge
across
these
different
groups,
but
at
the
same
time
you're
at
a
stage
where
you're
trying
to
ramp
up,
and
that
could
be
like
a
very,
very,
very
good
use
of
everyone's
time
and
yeah
before
everyone
jumps
into
the
poc
group.
Every
other
group
is
also
very
important
because
you
get
to
learn
about
gitlab
much
much
more
as
well,
which
is
a
good
thing.
A
Okay,
so
to
try
to
wrap
this
up,
so
we
need
a
group
working
on
the
requirements,
a
group
working
on
the
trying
to
figure
out
the
current
status
of
the
implementation
and
groups,
starting
exploring
some
of
the
boc
ideas
regarding
the
finally
current
implementation.
I
already
started
having
some
challenges
on
this,
because
the
bucket
ownership
document
is
still
not
filled.
A
B
A
B
So
I
can
take
that
as
an
action
item.
If
you
share
that
item
with
me
with
a
specific
ask,
I
can,
I
can
raise
it
up
even
today,
actually
because
I'm
announcing
this
working
group
in
the
engineering
allocation
meeting
as
well
to
try
to
explain
what
kind
of
work
is
coming
everyone's
way
as
well.
So
share
that
with
me
and
I'll
I'll
get
that.
D
Yeah
I'd
like
to
second
that
in
the
last
two
engineering
allocations
that
has
been
a
big
problem,
in
my
opinion,
being
thrown
into
things
that
you
have
no
context
on
and
being
extremely
inefficient.
As
a
result,
we
need
to
prioritize
collaboration
and
real-time
collaboration.
B
Honestly,
if,
if
I
just
consider
the
type
of
problem
we
have
here
with
object,
storage
and
to
be
clear,
it's
not
necessarily
a
problem,
but
it's
a
it's
definitely
something
we
need
to
act
on.
I
think
no,
I
think
I
know
I
know
how
much
time
and
effort
it
took
alessio
to
build
out
this
level
of
knowledge
of
object
storage.
If
we
try
to
do
this
really
rapidly
across
groups
and
just
give
them
pieces
without
giving
them
the
context,
we're
going
to
have
more
problems
rather
than
less.
B
A
Okay,
so
great
conversation,
we
are
at
time.
So
I
just
wrote
this
three
action
items:
I'm
gonna
refine
them
and
trying
to
create
groups
of
things
so
also
people
from
the
upper
time
zone
can
pick
something
to
work
on
and
then
we
I
will
update
this
meeting
schedule.
So
I
suggest
next
one
will
be
hammer
friendly
next
week,
america's
friendly
and
then
we
do
add
back
a
box,
so
we
can
and
then
we
iterate
on
this
so
every
other
week.
I
will
update
this
as
well
and
so
yeah.