►
From YouTube: 2022-02-01 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
The
recorded
computer
all
right
welcome
to
the
object,
storage
working
group
on
sync.
This
is
the
americas
meeting,
I'm
taking
over
from
for
alessio
for
the
next
two
months
here
yeah.
I
I
added
a
couple
points
to
the
agenda
that
kind
of
I
I
thought
might
be
worth
talking
about.
If
you
have
anything
else,
just
let
me
know
towards
the
end,
we
can
just
add
them
on
at
the
end.
A
Let's
first
go
through
the
action
items
from
last
week
or
the
I
guess
I
was
the
previous
meeting.
Actually
so
not
all
of
you
might
have
been
part
of
that.
There
were
two
things
in
progress:
one
was
the
object,
storage
bucket,
categorization
issue.
A
It
had
the
the
issue
had
a
different
name
previously,
and
this
might
be
a
bit
confusing
because
I
broke
this
up
into
two
so
that
we
have
one
that
really
only
contains
the
has
the
focus
on
the
actual
categorization
of
the
object,
storage
buckets
and
I
broke
out
a
separate
one
for
more
holistically,
describing
the
current
implementation
of
object,
storage
and
uploads,
maybe
in
general,
because
we
found
that
maybe
that
is
not
well
understood
enough,
both
inside
and
outside
of
the
group.
A
This
first
came
up
when
we
started
to
talk
about
requirements
and
like
how
would
we?
How
would
we
score
them?
There
was
the
need
to
better
understand
the
complexities
behind
this,
which
then
kind
of
prompted
us
to
maybe
have
a
harder
look
at.
What
is
it
we
actually
have
right
now
like
which
pieces
are
responsible
for
what
and
just
like
document
this,
and
this
will
also
be
beneficial
for
any,
like
newcomers
who
might
join
after
this
working
group
concludes
and
might
start
working
on
this.
A
So
that
said,
this
issue
that
we
had
already
closed.
We
actually
found
that
maureen
pointed
out
today.
A
It's
kind
of
like
a
moving
target
right
because
having
one
bucket
per
per
feature
or
port
per
type
of
upload
is
just
that's
the
status
quo,
that's
what
it
is
now
and
of
course,
like
every
so
often
we
will
add
to
this,
so
there
has
actually
been
a
new.
A
I
haven't
looked
at
this
in
detail
yet,
but
marine
just
pointed
me
to
this
on
select
today
that
there's
we're
actually
looking
to
add
new
buckets,
so
we
might
actually
have
to
go
back,
and
we
should
probably
look
at
this
as
well
and
see
how
that
will
fit
into
this
configuration
matrix
or
you
know,
honestly.
A
Maybe
we
can
just
reach
out
to
whoever's
working
on
this
and
ask
them
to
have
a
quick
look
and
see
if
they
can
leave
a
quick
comment
on
on
this
existing
issue
here
for
how
this
could
be
slotted
in,
because
this
is
kind
of
how
we
went
about
this.
We
didn't
ourselves.
Look
at
each
individual
feature
to
see
how
exactly
it
is
it's
done
for
most
of
them.
We
actually
had
help
from
other
teams,
so
that
was
very
useful.
B
So
mathias
a
question
for
you
and
everyone
else
actually
here
does
this
live
anywhere
else
outside
of
this
issue
like
this
table.
C
Yeah
I
was
going
to
ask
the
same
thing
because
it's
super
useful
information,
I
think
for
everyone,
so
this
should
definitely
go
somewhere
in
the
documentation.
You
know.
A
That's
a
great
point:
what
we
could.
B
What
we
can
do
is
go
to
charts
and
omnibus
and
add
in
one
of
the
headers
right
like
how
do
you,
I
add
a
new
bucket
or
so
on,
right,
like
in
the
configuration
itself,
link
it
there
and
say
basically,
when
you
are
adding
something
to
this
list,
go
and
update
the
documentation
as
well,
and
that
way
you
have
don't
have
to
deal
with
that
and
that
allows
us
to
at
least
not
think
about
new
items
coming
in
right.
Let
it
grow
naturally
kind
of
exactly
and.
B
A
Right
so
a
transfer
table,
this
would
just
be
a
markdown
right.
We
would
have
to
find
a
good
place
for
that
where
that
would
live.
Probably
the
developer
docs
for
object,
storage,
uploads.
A
Exactly
and
then
we
would
prompt
developers
to
update
this
whenever
you
set
an
omnibus
and
charts.
B
Yeah,
that's
where
they
usually,
they
need
to
add,
expose
new
configuration
options,
okay
and
probably
get
at
some
point
as
well,
but
I
think
the
easiest
thing
to
do
is
to
focus
on
omnipotent
charges.
B
Know
what's
good
that
issue?
Has
the
infrastructure
issue
actually
has
a
list,
so
you
can
just
follow
that
list
and
go
to
the
merge
request.
Oh.
B
A
Yeah,
that's
a
good
point
cool
all
right.
A
I
find
it
easy
to
see
when
I
put
a
highlight
on
it
all
right
that
that's
this
that's
pretty
much.
It
maybe
just
super
quickly.
So
this
one,
which
confusingly
has
the
title
of
that
the
previous
the
title.
The
previous
issue
had
originally
this.
We
newly
created
because
this
here
the
idea
was
to
really
focus
on
the
actual
implementation,
not
so
much
the
structure
if
that
makes
sense
of
like
which
features
map
to
which
buckets.
A
But
this
is
really
about
how
do
how
to
upload
not
just
object,
storage,
how
do
uploads
work
because
it's
quite
complex
and
I'm
still
going
through
it
and
I
just
started
by.
I
said
I
just
started
with
the
developer
docs
and
because
I
think
for
me
it's
actually
super
interesting,
because
I
have
never
implemented
an
upload
at
gitlab.
So
for
me,
I'm
kind
of
I'm
this
newcomer
right,
I'm
kind
of
like
the
perfect
persona
for
this.
A
At
the
existing
code
and
the
existing
docs-
and
I
find
it
really
hard
to
understand
so
I
think
we
should
make
an
effort
at
documenting
this
better
and
providing
very
specific
guidance
for
for
which
combinations
of
all
of
these
possible
yeah,
like
these
different
dimensions
that
we
have
to
upload.
You
know
what
what
type
of
upload
is
it
you
know?
Is
it
disbuffered?
Is
it
a
direct
upload?
Does
it
go
to
local
storage
or
remote
storage?
A
It
would
be
nice
to
have
more
comprehensive
examples
as
well,
and
so
I
know
gregorish
had
like
opinions
on
this
as
well
he's
not
on
this
call,
but
I
can
ask
him
yeah
this
one
next
week
as
well,
because
I
think
he
even
wanted
to
make
this
a
bit
like
wider.
Even
but
I
don't
know
exactly
what
ideas
he
had
in
mind
so
we'll
have
to
see
still
and
of
course,
to
everyone
here
in
the
meeting
as
well
whoever's
watching
the
recording.
Please
leave
any
comments
or
suggestions.
A
What
you
think
could
be
improved,
whether
that's
just
improving
the
existing
documentation
or
add
new
documentation.
Please
add
your
thoughts,
and-
and
it
would
also
be
great
if
we
could
find
a
dri
for
this.
That
would
not
mean
you
have
to
write
all
of
this
yourself,
but
if
we
had
someone
who
would
be
willing
to
make
sure
that
we
make
progress
on
this,
that
would
be
great.
A
This
could
just
be
like
I
don't
know,
prompting
folks
every
now
and
then
to
go
ahead
and
especially
people
that
may
have
already
worked
with
it.
That
might
be
maybe
the
fastest
way
to
document
the
bits
they
know
and
it
could
just
be.
We
said
it
might
be
easier
if
we
want
to
collaborate
on
this,
to
just
throw
it
in
the
google
doc
for
now
and
then
transfer
it
into
proper
markdown
later
on.
It's
just
it's
just
faster.
That
way.
B
I
have
a
question:
it
makes
sense.
I
have
a
question
if,
if
the
group
actually
considered
while
this
is
being
investigated-
which
I
think
is
a
good
thing
like
absolutely-
we
should
write
down
like
how
some
of
these
things
work,
because
if
it
takes
five
people
to
figure
this
one
out,
that's
not
a
good
sign
right,
but
I'm
wondering
is
there
a
way
for
us
to
somehow
stop
or
slow
down
the
addition
of
new
things
in
the
under
in
in
the
undesirable
implementations?
B
So
if
we
say
that
we
want
direct
upload
right,
these
are
the
considerations
you
have
for
direct
upload.
This
is
how
it
works
and
so
on.
Maybe
if
we
can
create
like
a
stack
list
and
say
you
know,
these
three
options
are
valid.
Fourth,
one:
if
you
want
to
do
this,
then
you
need
to
jump
through
additional
hoops,
meaning
you
need
to
talk
with
someone
who
has
been
working
on
this
and
so
on,
and
we
don't
have
to
like
create
a
large
list
where
we
are
going
to
save.
B
Like
only
do
one,
we
can
also
say
just
remove
this
one
last
option
and
that
way
we
cannot
reduce
new
items
being
added
to
the
undesirable
implementation,
like
I'm
wondering
whether
that's
useful
to
think
about
right
now-
and
this
is
not
the
only
thing
we
are
doing
obviously-
but
this
is
like
one
small
item
that
we
can
consider
to
just
you
know
reduce
the
amount
of
things
that
need
to
be
done,
because
this
is
getting
out.
A
A
I
think
it's
a
great
idea.
Personally,
I
still
have
the
problem
that
I
don't
even
know
what
is
desirable
or
not
so
I'm
kind
of,
I
think,
I'm
not
there.
Yet,
I'm
still
at
the
point
where
I
don't
understand
how
this
works
currently,
so
that's
what
I'm
still
trying
to
figure
out
and
make
sure
that's
written
down
somewhere,
and
that
does
not
mean,
of
course
we
can
work
towards
what
you
just
said.
A
I
mean
there
are
certainly
people
in
inside
and
outside
of
the
working
group
that
understand
it
much
better
than
I
do
and
who
probably
have
an
opinion
on
this
yeah.
I
don't
know
so
I'll,
just
give
it
back
to
the
room
if
anyone
is
on
the
call
who
has
already
some
insight
there
or
if
we
just,
we
can
also
take
it
as
an
action
item
for
next
meeting
to
raise
the
question
again,
because
I
think
it's
it's
a
pretty
good
idea
to
that.
A
B
You
can
also
consider
making
this
as
a
step
two,
so
you
see
you're
having
the
outcome
that
you
say
that
you
want
to
have
something
written
in
the
documentation
and
you
can
add
outcome
number
two
make
it
a
list.
Yeah
sure
sounds
good.
It
doesn't
have
to
have
like
large
discussions.
Large
discussions
will
come
after
you
write
all
of
these
things
up
and
have
a
common
understanding
of
what
is
desirable
and
not,
and
then
you
know
it
could
just
be
how
you
create
the
document
that
is
affected.
A
A
Should
we
take
an
action
item
now
already
or
should
we
just
kind
of
let
this
sink
in
a
bit
and
wait
for
all
of
the
emea
joiners
to
think
on
this
as
well?
First,
do
you,
okay,
I
mean
I
can
I
can.
I
can
take
an
action
item
for
just
reminding
people
about
you
know
giving
this
some
thought
it
might
be
a
bit
too
early
to
actually
act
on
this,
but
I
think
it's
a
good
idea
so
yeah,
I
guess
we
can.
We
can
just
say
think
about
ways
to.
B
A
Okay,
all
right,
so
these
are
a
bit
in
like
random
order,
but
let's
just
look
at
them
one
by
one.
I
was
just
going
through
the
epic
again
this
morning
and
I
was
just
wondering
if
anyone
had
any
contacts
on
on
this
issue
because
yeah
there
was
no,
there
was
no
description
and
but
it,
but
it
is
open.
So
I
wonder
if
anyone
had
any
contacts
there,
so
I
could
flesh
this
out
a
bit
more.
I
was
basically
just
looking.
B
So
I
know
a
bit
of
context
around
not
the
issue
per
se,
but
the
intention
of
things
behind
it.
This
was
to
create
a
blueprint
that
would
describe
the
current
situation
and
set
some
terminology
that
people
can
rally
around.
So,
if
you
I
mean
you
can
already
see
this
was
created
a
year
ago,.
B
Right-
and
this
was
you
know,
alessio's
starting
point
to
actually
start
raising
visibility
and
start
consolidating
some
of
the
knowledge
he
had
and
then
also
start
gathering
support,
so
the
blueprint
itself
is
merged.
So
I
think
this
issue
could
just
be
closed
because
it's
yeah.
A
Okay,
yeah
yeah.
Definitely
if
this
was
primarily
to
get
the
boot
print,
in
which
I
found
very
helpful
as
well
launching
into
this
all,
then
then,
maybe
we
should
just
close
it
out
as
done
and
anything
that
still
needs
to
be
added
or
changed
or
anything
else.
We
want
to
do
in
that
direction.
We
can
always
create
new
issues
for
that
right.
Yeah.
B
I'll
I'll
just
change
this,
the
labeling
and
close
it.
I
think
it's
okay,
cool.
A
Thank
you
thanks
excellent,
so
that's
done
what
else
yeah.
A
So
this
came
up
again
when
I
was
just
playing
around
with
the
code
a
bit-
and
I
remember
alessia
had
mentioned
this
as
well-
that
one
criticism
of
the
current
implementation
was
that
we
have
one
authorized
endpoint
per
per
resource,
that
we
allow
direct
uploads
for
which
well,
obviously,
it
complicates
the
implementation,
because
you
have
to
edit
end
times
over,
and
I
guess
like
again
looking
for
smaller
self-contained,
fairly
simple
things
that
I
hope
would
move
us
in
the
right
direction,
that
this
is
not
a
game
changer.
A
If
we're
going
to
do
that.
But
I
was
wondering
if
it
could
make
sense
at
this
point
to
explore
this
idea
a
bit
further
yeah
to
look
into
having
a
single
authorization
endpoint
for
uploads,
so
that
workhorse
would
always
go
to
the
same
endpoint
before
uploading,
to
object,
storage
and
and-
and
I
don't
know,
kind
of
see
what
falls
out
of
that-
it
doesn't
have
to
be
at
this
point.
It
doesn't
necessarily
have
to
be.
A
You
know
production
quality,
but
I
kind
of
wrote
this
from
a
standpoint
of
I
don't
actually
know
how
complex
this
would
be.
There
are
some
complications
because
it
would
have
to
currently,
because
we
have
all
of
these
different
buckets
instead
of
one,
we
would
have
kind
of
a
single
place
in
the
rails
code
base.
A
A
Maybe
that
might
be
a
good
thing
to
pick
up
as
well
in
parallel,
especially
if,
if
there's
people
in
the
work
group,
who
maybe
you
don't
want
to
work,
a
documentation
or
something
you
know
and
just
get
you
know,
do
something
hands-on
and
actually
code,
something
yeah.
That's
why
I
created
this.
Do
you
think
that
makes
sense.
A
I
wish
I
wish
david
was
on
the
call,
because
he
I
think
he
had
thoughts
on
this.
C
Yes,
I
I
was
going
to
to
say
from
a
security
perspective.
I
really
like
the
idea,
because
we
centralized
the
authorization
on
a
single
point
rather
than
spreading
the
the
authorization
across
different
components
so
yeah.
I
really
like
that,
but
I
remember
having
issues
when
I
I
work
on
specific
security
issues
with
david
on
package
uploads,
where
it
was
not
so
easy
to
to
kind
of
do
that
with
the
workhorse.
C
So
I
think
there
is
definitively
probably
the
the
best
person
to
to
ask
questions
about
the
interactions
between
different
components,
because
I
know
we
struggle
to
make
to
make
it
working
properly,
so
so
yeah
yeah
it
took
it's
too
bad.
It's
not
on
the
call
right
now,
but
yeah.
A
Yeah,
I
I
really
like
the
idea.
Okay,
great,
no,
that's
great
feedback.
Already
I
mean
we
can
we
can.
We
can
can
shop
async
around
this
as
well,
and
you
know
just
to
do
it
on
slack
and
see
if
anyone
has
capacity
to
look
into
this
and
again
this
doesn't
have
to
be.
I
know
you
know
everyone
just
you
know
you're
just
doing
this
on
the
side
here,
but
I
feel
like
we
need
to
make
some
progress
with
like
the
hands-on
stuff
as
well
and
yeah.
A
David
did
some
great
work
already,
with
exploring
active
storage,
for
instance,
and
I
think
we
should
also
be
okay
with
the
idea
of
writing,
something
that
we
then
toss
out
right.
We
just
should
spend
too
much
time
on
it.
You
know
just
explore
an
idea
and
see
what
falls
out
of
it.
I
think
this
can
be
super
helpful
to
kind
of
like
feel
out
the
direction
and
yeah
what
the
complex
complexities
are
that
come
with
these
things.
B
Agreed
we
should,
we
should
have
like
we
shouldn't
be
having
tens
of
pocs
to
you
know,
rewrite
the
application,
but
something
else
localized
is.
This
is
a
great
idea,
I
think,
yeah.
I
think
exactly
not
arguing
about
like
whether
right
like
the
implementation
is
going
to
be
easy
or
not,
but
I
think
it's,
a
general
idea
of
consolidation
actually
sounds
like
a
good
approach.
A
All
right
cool,
excellent
yeah
again
I
I,
if
we
don't
find
anyone
now,
please
you
know
just
think
on
it.
If
you're
potentially
interested
in
working
on
this,
otherwise
I'll
just
leave
it
leave
it
open
for
a
while
now
and
see.
If
anyone
has
time
to
pick
it
up.
A
What
else
did
I
have
oh
yeah?
I
just
I
created
this
because
this
is
very
much
me
looking
at
what
we
have
and
just
trying
to
wrap
my
head
around
it,
and
I
found
that
so
there's
two
things.
I
think
we
can
improve
the
status
quo.
One
is
to
look
at
the
the
actual,
I
kind
of
like
what
you
touched
on
marine
earlier
with
the
blueprint
we
tried
to
introduce
like
a
common
language
as
well
around
these
things
right,
so
we
know
we're
talking
about
the
same
stuff.
A
You
know
if
someone
says
direct
upload,
we
kind
of
know
what's
meant
by
this.
I
do
not
find
these
reflected
in
the
code
base.
I
find
this
makes
it
very
tricky
to
look
at
the
current
implementation
and
kind
of
map
this
back
to
all
of
these
ideas
that
we
have
proposed
or
the
concepts
that
already
exist,
and
we
refer
to
in
the
blueprint,
but
also
in
discussions.
A
So
I
think
it
could
be
a
great
of
great
help
to
new
newcomers.
To
you
know
the
code
base
and
the
whole
upload
stack
that
we
currently
have
to
just
go
in
and
see.
A
You
know
not
changing
any
behavior,
but
seeing
like
can
we
kind
of
you
know,
you
know
rename
this
or
like
yeah
kind
of
reflect
the
language
better
that
we
use
in
the
code
base.
So
that's
easier
to
understand
and
kind
of
map
back
to
what
we
have.
I
think
that
would
have
helped
me
definitely
like
trying
to
make
sense
of
the
current
implementation
more.
A
I
also
found
it's
like
rajiv
documented,
and
I
don't
mean
like
in
markdown
files
but
close
to
the
code
that
you
actually
work
with,
so
that
could
be
like
a
small
task
as
well
maybe
more
geared
to
someone
already
familiar
with
the
stacks,
so
I
mean,
I
think,
maybe
the
pool
of
people
to
work
on
this
one
is
a
bit
smaller
than
maybe
the
other
issues
we
have,
but
I
think
that's
that's
always
something
that
is
useful
to
do,
and
it
would
help
future
us
as
well
and
other
people
joining
this
effort
to
just
dig
into
this
and
contribute.
B
That's
a
that's
a
great
great
idea.
I
really
like
that.
Yes,
what
you
can
consider
then
doing
the
with
this
is
actually
make
it
something
that
is
more.
Like
you
you're
saying
like
newcomers
that
are
more
familiar
with
workhorse.
I
actually
think
this
might
be
a
good
opportunity
for
folks
who
are
practicing
golang,
and
we
have
many
many
people
in
the
company
doing
that
to
you
know,
get
their
first
feel
of
development
in
a
real,
controlled
environment.
So
to
speak,
because
we
are
not
expecting
them
to
change
behavior.
B
We
are
expecting
them
to
understand
code
change,
the
naming
to
align
with
what
we
are
talking
about.
I
actually
think
that's
a
perfect
opportunity
for
people
to
practice
a
bit,
so
I
would
go
as
far
as
saying
that
this
is
probably
a
first
contributors,
type
of
thing
that
you
can
share
in
development
channels
across
right
like
to
managers
as
well,
because
managers
know
which
team
members
might
be
practicing
go
a
bit.
B
It
could
be
a
a
good
opportunity
for
folks
to
just
participate
yeah.
I
think
that's.
B
Sorry,
regardless
of
whether
they
know
the
whole
object
story
story
or
not,
they
don't
necessarily
need
to
know
that
part.
So,
if
that,
if
that
issue
gets
formal
formulated
in
a
way
that
is
more
like
you
have
this,
make
it
into
this
and
document
how
this
actually
functions
right.
That
could
be
a
great
item
for
folks.
A
Yeah
great
I
mean
I
can
definitely
float
this
in.
You
know,
select
channels
as
well
like
golang
and
and
workhorse
to
see.
I
actually
see
these
posts
like
every
now
and
then
from
people
asking
hey.
I
would
like
to
you
know
start
working
workhorse,
but
I
don't
really
know
where
to
start
so
yeah.
I
can
definitely
upload
this.
I
mean
we
can
say
if
if
we
don't
find
anyone
within
the
next
week
or
so,
I'm
I'm
happy
to
work
on
this
as
well,
because
I'm
I'm
also
in
a
similar
position.
A
I
have
contributed
workers
a
little
bit,
but
it
was
a
very
focused
effort
on
just
one
component
of
workhorse,
so
I
haven't
really
been
around
the
whole
thing.
So
if
no
one
else
picks
this
up,
I
can
take
it
as
well.
B
A
B
A
Okay,
great,
that's
all
I
had
in
terms
of
agenda
points.
We
have
two
minutes
left
any
closing
remarks
or
questions.
A
All
right,
then,
you
can
have
two
minutes
back
up
your
time
and
I
would
say,
we'll
see
each
other
next
week
or
in
two
weeks.