►
From YouTube: 2022-03-22 Object Storage WG
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
All
right,
okay,
so
yeah,
that's
just
the
two
of
us
today.
It's
the
apec
meeting
for
the
object,
storage
working
group.
We
don't
have.
A
Were
two
items
we
didn't
get
to
last
week
because
we
ran
out
of
time,
so
I
just
pulled
them
over.
So,
let's
see
so
jacob
and
jason
are
not
on
the
call,
but
let's
see
if
we
can
answer
them
anyway,
yeah.
So
one
of
the
questions
jacob
asked
was:
if
we,
if
we
make
a
new
bucket
mandatory,
can
we
do
that
without
waiting
for
a
major
version
release?
Because
we
have
been
talking
a
lot
about?
A
Can
we
reduce
complexity
by
just
saying
we
maybe
deprecate
certain
functionality
or
try
to
simplify
it
somehow,
but
that
might
require
interaction
by
the
customer,
of
course,
so
we
weren't
quite
sure
what
still
viable
to
do,
especially
with
15.0
coming
up
in
the
end
of
may,
I
believe
yeah
jimmy
range
you
just
want
to
verbalize
this.
B
Yeah,
so
there
are
two
items
I
wanted
to
mention:
the
first
one
is
new
functionality,
so
new
buckets
being
mandatory.
B
Basically,
if
you
want
to
do
that,
we
have
to
make
this
happen
in
15.0,
so
one
of
the
things
that
is
usually
challenging
for
for
users
for
customers
rather
is
jumping
to
the
jumping
between
versions.
So
it's
not
the
problem
of
timing
right
now.
It's
the
problem
of
what
happens
in
a
year
for
from
now,
so
we
still
see
many
customers
coming
into
14.0
from
12
version
12
or
something
like
that,
and
they
jump
versions
and
our
version
matrix
is
yeah.
B
Missing
missing
steps,
so
when
the
customers
do
miss
a
step,
they
don't
follow
the
exact
versioning
policy
that
that
we
laid
out
on
how
do
you
actually
jump
in
larger
steps
that
I've
seen
causes
a
lot
of
grief,
a
lot
of
problems
for
support
and
then
a
lot
of
problems
for
the
customers
as
well?
So
if
you
want
to
make
something
mandatory,
it
will
have
to
happen
in
15.0
communication
wise.
B
This
is
a
problem,
because
if
we
had
something
to
do
something
mandatory
to
do
already,
we
could
have
announced
it
today
and
that
we
would
be
inside
of
the
policy
right
like
two
months
in
advance.
People
can
start
preparing
that
and
whoever
jumps
will
get
a
deprecation
warning,
because
what
we
usually
say
is
you
need
to
jump
to
the
latest
version
to
the
last
version
in
the
major
series.
B
So
in
that,
in
our
case,
that
would
be
what
14
10
something
right,
and
that
would
give
you
all
sorts
of
deprecation
warnings
right
like
you
need
to
do
this.
You
need
to
do
right,
like
this
couple
of
things
before
upgrading
to
15
to
zero.
So
I
think,
unless
we
can
put
something
in
already
for
14.10,
so
for
the
next
version,
it's
going
to
be
a
very
tight
squeeze.
So
literally,
we
need
to
start
working
on
this
right
now
and
I
don't
like.
B
I
need
to
double
check
with
someone
from
product
to
see
whether
they
would
be
supportive
of
us
doing
this
right
now.
So
it's
doable
right
like
if
we
ship
it
with
14.10,
it
might
be
okay,
but
I
need
to
confirm
with
someone
from
product
whether
there
is
a
this
is
not
a
deprecation.
This
is
a
new
feature.
So,
theoretically
we
would
be
fine,
but
I
need
to
confirm
that
so
I
can
take
an
action
item
for
that
and
get
an
answer
asap.
B
A
And,
and
to
understand
better,
where
the
question
came
from,
was
this
about
having
a
uni
like
a
unified
single
bucket,
into
which
we
correct
everything
that
would.
B
A
B
That's
the
question
right
like
if
a
question
here
is
only
that
we
create
configuration
that
would
make
something
mandatory
so
that
people
have
to
actually
set
it
up
or
I
don't
know,
I'm
just
gonna.
I
don't
know
exactly
what
jacob
had
in
mind
here,
but
if,
if
the
the
challenge
here
is
only
to
make
something
available
so
that
we
can
build
on
top
of
it,
then
we
can
do
that
like.
B
I
don't
think
that
we'll
have
some
functionality
that
will
do
certain
things
for
that
buck
and
it's
more
about
creating
an
entry
point
for
us
to
build
on
top
of
it.
We
can
maybe
do
some
various
configuration
changes
automatically
based
on
that
and
so
on.
I
don't
know
exactly
what
in
mind,
but
that's
why
we
should
have
a
link
for
this,
so
we
we
can
cover
it
next
time,
but
I'll
go
I'll,
go
and
ask
a
couple
of
people
in
product
to
see
what
they
how
they
feel
about.
B
Adding
new
configuration
is
mandatory,
but
I'm
I'm
kind
of
more
curious,
also
about
something
that
I
read
in
in
slack
about
making
direct
uploa
upload
complete.
I
think
you
mentioned
that
matthias
yeah.
A
We're
still
trying
to
figure
out
what
that
would
mean
because
it
sounds
like
it
sound
because,
because,
at
the
end
of
the
day,
we're
looking
for
what?
What
will
we
recommend
as.
A
To
follow
going
forward
right
and
it
sounded
like
that,
the
consensus
is,
it
should
be
direct
upload,
but
it's
not
considered
complete
enough
to
actually
support
all
the
kinds
of
uploads
that
we
have
and
all
the
object,
storage
providers
that
we
support.
So
I
guess
one
item
to
unpack
would
be
to
understand
what
what
is
missing
exactly.
B
A
To
be
considered
complete
because
I
forgot
who
mentioned
it,
but
I
think
I
totally
agree
with
this
that
it's
super
important
like
if
we
tell
developers
and
customers
as
well
hey
you
can't
use
or
do
this
anymore.
We
need
to
give
them
an
alternative
and
point
them
to
something
that
we
say
you
should
be
doing
that
instead
and
so
whatever
that
will
be,
it
needs
to
be
working
yeah.
A
I
it
sounds
like
it
is
based
on
the
discussions
I've
seen
so
far,
but
I
I
cannot
confirm
this,
I'm
not
entirely
sure
I
I
saw
yeah.
This
is
actually
already.
I
don't
know
how
you
want
to
approach
this,
because
it
kind
of
relates
to
the
item.
I
think
in
the
item
two
here
as
well.
Maybe
we
can
talk
about
this
now
then,
can
we
come
back
to
jason's
question
at
the
end,
because
this
kind
of
came
up
again
when
I
was
trying
to
document
background
uploads?
A
This
is
something
I
kind
of
discovered
a
bit
late
in
this
whole
process.
I
was
very
focused
on
direct
upload
first
and
I
was
trying
to
understand
what
what
how
does
this
relate
to
direct
upload
kind
of.
Why
does
it
exist
and
are
they
mutually
exclusive?
And
when
should
I
use
what
so
so?
This
started
this
discussion
about
yeah
kind
of
the
cases
in
which
someone,
because
we
already
established
git
lab
the
company
for
for
our
galapagos
deployment
of
gitlab,
is
not
using
background
upload.
A
We
use
a
direct
upload
as
far
as
I
understand,
at
least,
and
but
there
are
cases
where
you
cannot
use
direct
upload,
and
you
already
mentioned
openstack
one
such
case,
but
that's
based
on
a
two
year
old
comment
in
an
issue.
So
I
think
it's
still
true
was
that
there
is
no
appropriate
integration
for
direct
upload
that
we
can
use,
because.
A
Configured
this
bucket
to
use
a
different
type
of
connection,
which
is
a
different
api
object
as
a
openstack
offers.
Then
this
will
not
go
down
the
direct
upload
routes
and
it
wouldn't
work.
So
so
we
need
to
fall
back
to
background
upload,
so
we
can't
just
yank
this
out
right,
because
that
would
then
break
someone's
setup.
So
so
yeah.
B
But
you
know
that's
one
thing:
whether
we
take
additional
burden
maintenance
burden
on
for
this,
or
do
we
break
someone's
setup
right
like
ultimately,
with
every
configuration
you
add,
and
we
have
added
many-
will
turn
into
someone's
production
configuration
and
will
break
something
for
someone
we
have
so
many
users
between
c
and
e,
that
use
gitlab
in
various
forms
and
fashions
that
I
would
be
very
surprised
if
we
don't
break
something
for
someone
it's
just.
B
What
do
we
want
to
take
on,
as
as
a
risk
for
the
company
for,
for
the
application
doesn't
have
to
even
be
for
the
company
right?
So
if
you're
talking
here
about
breaking
a
couple
of
users
workflow
in
order
to
improve
stuff
for
well
pretty
much
everyone
else,
maybe
we
are
okay
with
that.
We
just
need
to
make
sure
we
communicate
that.
Well,
so
let
me
think
a
bit
for
a
sec.
A
That's
a
very
good
question:
there
is
we
we
do.
I
think
we
do
track
this
in
in
you
with
usage
ping,
the
the
setup
it's
just
like
it
might
not
be.
I
don't
know
how
reliable
this
data
is,
but
I
believe
we
have
some
data
in
sizes
around
this
I
mean
honestly,
any
data
better
than
xero.
Is
yes
right,
so
I
don't
know
if
I
can
show
that
here,
maybe
not,
but
I
can
maybe
share
a
link
later.
B
Yeah,
if
you
give
me
the
link,
I
can
go
and
look
yeah
all
right,
I'll.
A
I'll
take
it
out,
I
think
I
had
looked
at
it
before.
I
also
looked
at
there's,
also
because
the
whole
customer
side,
and
and
mostly
the
omnibus
and
custom
chart
deployments
and
all
that's
like
the
that's
kind
of
the
biggest
unknown,
but
I
I
even
found
like
that
for
says.
It
wasn't
clear
to
me
anyway,
which
kinds
of
integrations
we
use,
and
it
looks
like
there's,
definitely
a
lot
of
paths
that
let
me
find
this
there's
a
different
request
here
that
seem
to
be
unused.
A
So
I
looked
at
this
is
just
seven
days
worth
of
log
events
from
kavanaugh,
but
we
actually
log
whenever
we
upload
to
an
object,
storage
provider.
Also
when
a
file
is
cached
locally,
we
log
an
event
to
specify.
But
how
did
we
upload
it?
And
it
looks
like
at
least
in
this
week
I
looked
at.
A
The
only
cases
I
encountered
was
what
we
call
local,
which
which
has
nothing
to
do
with
local
storage
yeah.
That's
actually
what
I'm
trying
to
clear
clear
up
here,
but
that's
basically
when
we
fall
back
to
disk
buffering,
which
means.
A
The
file
on
disk
before
before
it's
somehow
handled
in
rails
and
then
http
means
it
was
a
direct
upload
by
workhorse
using
an
s3
api.
I
suspect
the
preset
url.
I
need
to
look
at
it
again,
so
it
was
a
non-multi-part
upload
to
this
three.
So
these
were
the
only
two
cases
I
encountered
in
a
week
worth
of
log
events
for
sas.
So
so
I
don't
know
if
that
helps
answer
any
questions,
because
there's
a
bunch
of
other
cases
like
go
cloud
and
then
these
s3
multi-part
requests.
A
B
We
have,
I
forgot
exactly
which
feature
was
that,
but
that
one
we
used
to
talk
with
alessio
about
when
he's
back
next.
A
B
I
think
we
have
it
even
in
documentation
somewhere,
but
I
think
if
you
have,
if
you
have
a
link
to
the
virgin
bank
license
chart,
that
would
be
very
useful
for
me
to
actually
understand
if
we
haven't
a
mention
of
openstack,
that's
probably
better
than
nothing.
I
can
then
go
and
figure
out
where
to
go
with
this
information.
So
to
put
to
put
it
like
this,
we
might
need
to
work
with
product
to
deprecate.
B
This,
so
deprecation
means
announcing
that
we
will
be
removing
this
in
a
future
release,
whether
we
remove
it
in
15.0
or
not.
It
doesn't
really
right
it
matters,
but
we
are
so
close
to
15.0
that
right,
like
we
can
do
only
so
much
right,
but
the
important
part
is
that
we
start
working
on
the
deprecation
right
now,
which
requires
a
whole
story
of
you
know,
gathering
some
data
preparing
some
of
this
work
with
products,
putting
a
stop
on
possible
expansion
on
top
of
that
configuration
and
so
on,
and
so
on.
B
B
We
don't
know
yet
whether
we're
going
to
postpone
major
release.
No
one
said
anything
about
this,
but
prior
two
major
releases
got
pushed
out
by
one
month
for
various
reasons,
so
I
wouldn't
be
surprised
if
you
know
a
removal
that
we
need
to
happen
doesn't
get
scheduled
in
time
or
we
miss
it
for
whatever
reason
and
we
decide
as
a
company
to
push
things
out
for
a
month
again,
it
happens
two
years
in
a
row.
A
So
I
actually
had
a
question
related
to
this,
because
jacob
also
mentioned
on
slack.
Is
this
really
a
deprecation
because
we're
not
removing
openstack
support
right?
It's
really
just
that
they
offer
two
different
apis.
One
is
s3
compliant
and
the
other
is
an
api
called
swift.
I
I
I
only
very
briefly
looked
at
this.
I'm
not
really
sure
how
what
the
history
is
by
that.
But
if
we
were
to
just
say
well,
we
keep
openstack
support,
but
only
via
the
s3
api.
A
B
B
B
The
plan
that
would
be
the
plan
right
sure,
but
the
point
is,
if
it's
out
there,
if
there
is
any
data
showing
that
the
customers
are
using
this,
I
don't
know
how
we
would
make
the
distinction,
but
right
it's
out
there,
we
have
it
in
our
docs
somewhere.
Probably
that
means
someone
is
using
it.
You
know
the
xkcd
comic
right,
like
every
change
will
break
someone's
workflow.
So
there
is
a
chance
that
that
will
happen.
B
We
get
customers
responding
when
we
do
that,
so
anything
that
is
out
there
and
possibly
being
used
needs
to
follow
the
process
if
we
change
certain
things.
So
if
we
change
the
api
for
whatever
reason
I
don't
know
rename
a
field
or
whatever
that's
a
breaking
change,
and
we
need
to
announce
this
or
we
need
to
support
things
in
parallel
for
a
bit
to
give
folks
a
chance
or
customers
a
chance
to
do
this.
B
B
At
the
same
time,
we
need
to
at
least
attempt
to
to
do
right
to
follow
the
process
of
deprecation,
slash
removal
in
order
to
actually
avoid
any
any
challenges
there.
So
I
guess
my
point
here
is
like:
if
we
have
those
two
different
things,
if
you
want
to
do
one
item
or
announce,
one
item
is
no
longer
supported.
Let's
write
it
up
immediately.
Let's
write
up
what
the
impact
will
be
right
like
if
you're
using
openstack
this
way,
this
would
stop
working
for
you
once
we
remove
this
and.
B
B
We
could
then
be
right
under
the
two
release,
deprecation
rules.
So
if
we
are
sure
that
we
want
to
do
this-
and
this
is
the
big
blocker,
so
if
you
can
take
an
action
with
jakob
today,
right
like
in
the
next
couple
of
hours
actually
to
have
something.
So
maybe
you
can
start
writing
up
why
we
want
like
what
is
the
impact
of
this
confirming
with
him,
and
I
can
figure
out
whether
I
can
find
someone
who
would
add
something
to
the
blog
post.
B
A
Yeah
we
can
do
that.
I
actually
I
I
just
recently
closed
this
one
out
because
it
seemed
to
be
duplicating
another
issue
which
had
more
information
on
it
said.
A
Object
starts
direct
upload
to
on
as
default
kind
of
means
that
it
would
not
be
using
background
upload
and
there
wasn't
a
whole
lot
of
discussion
in
here,
but
maybe
we
can
just
revive
this
because
it's
a
bit
more
specific,
it's
actually
three
years
old,
so
it
looks
like
there
were
multiple
attempts
being
made
at
deprecating
this
and
for
you
know
different
reasons,
it
just
never
happened.
So
maybe
maybe
I
can
just
reopen
this
and
and
add
more
information
to
this
to
inform
what
needs
to
happen
here.
Yeah.
B
C
B
To
drop
off
for
my
next
call
matthias.
Thank
you.