►
From YouTube: 2021-11-23 Object Storage WG meeting
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
So,
let's
kick
this:
let's
start
this!
Okay,
welcome
everyone
good
morning,
good
afternoon,
depending
where
you
are
this
is
the
object,
storage,
working
group
meeting
and
yeah.
This
is
the
date
is
wrong.
It's
the
23rd,
it's
not
the
22nd
yeah,
so
I
was
looking
at
the
agenda,
so
it's
the
23rd
of
november.
A
So
let's
start
with
last
week,
action
item
so.
A
We
had
kind
of
four
main
directions:
one
was
the
blueprint
the
blueprint
is
now
merged.
It's
part
of
it
it's
more
about
defining
the
problem.
The
solution
in
there
is
labeled
as
starting
point
for
the
the
conversation
in
this
working
group
and
the
working
group
is
the
dri
for
the
for
the
for
the
blueprint
as
well.
So
I
yeah,
I
think
we
are
going
to
edit
the
blueprint
as
we
progress
in
the
working
group
when
we
decide
what
we
want
to
tackle
the
solution,
we
think
it's
worth
pursuing
and
things
like
that.
A
So
he
started
doing
this
great
job
of
pinging
people
and
trying
to
understand
what
what
we
have,
what
we're
doing
to
make
sure
that,
when,
if
we
take
some,
we
make
some
decision,
we
are
not
overlooking
something
okay,
so
if
you
see
some
empty
spot
in
the
document,
if
you
happen
to
know
who
can
have
that
answer,
or
you
know
the
answer
yourself,
just
feeling
or
being
someone
that
can
help?
A
This
is
very
important
because
it
shows
us
it
helped
us
showing
how
broad
the
impact
of
the
of
this
working
group
can
be
and
can
help
us
getting
engineering
allocation
and
having
buy-in
from
several
groups,
because
it
touches
ver
various
part
of
the
cloud
base.
So
there's
another
effort
which
is
about
collecting
requirements.
The
conversation
there
started
jason,
you
were
active
there.
A
Also
yeah
I'll,
see
you
okay,
because
the
cat,
because
we
were
discussing
the
geo
stuff
so
that
that
conversation
kind
of
stopped.
Now
what
what
can
we
do?
Maybe
we
we
lost
a
bit
of
traction.
There
was
contributes
last
week
as
well
as
the
release
happening
yesterday.
So
yeah,
I
think
it's
normal.
But
what
can
we
do
to
progress
on
to
get
progress
on
collecting
requirements
and
starting
doing
something
more?
Having
more
actionable
something
more
actionable
around
this.
B
B
I
think
the
biggest
thing
is
we're
trying
to
make
sure
we
have
laid
out
all
the
current
expectations
so
that
the
new
requirements
are
accurately
filled
in
we've
started
reaching
out
to
other
teams
to
try
and
make
sure
that
their
product
managers
are
involved
and
they
understand
what's
going
on,
and
why
and
we
actually
just
had
david
chime
in
like
it
shows
us
five
minutes
ago
on
my
screen
as
an
example
with
a
bunch
of
information
from
the
package
team
site,
so
we're
still
rolling
in
more
folks
from
the
various
teams
that
have
buckets.
A
Yeah
I
I
do
agree
that
this
is
one
side
of
this
collecting
requirements
right,
because
we
want
to
make
sure
they
cover
the
on
the
existing
feature,
as
well
as
solving
the
pain
point
that
we
have
with
the
with
the
current
implementation.
A
So
I
was
thinking
about
so
how,
before
we
move
to
the
next
point,
so
my
point
here
is
that,
right
now
we
don't
have
a
real
plan.
We
kind
of
have
more
this
draft
plan.
That
is
part
of
the
of
the
blueprint.
So
I
am
expecting
that
we
will
end
up
with
alternative
solutions
right.
So
how
can
we
score
alternatives?
A
So,
for
instance,
something
that
gregor
mentioned
in
the
blueprint
today
was
the
maybe
instead
of
shipping
min
io,
we
can
think
about
implementing
our
own
service
that
handles
storage
so
that
it
can
just
go
to
object
storage
if
customers
wants
to
have
object,
search
or
in
local
storage.
But
then
local
storage
will
be
local
to
this
component
so
that
we
don't
have
the
issues
with
menial.
A
Like
I
mean
I
o
license
and
things
like
that
and
can
be
just
trimmed
down
to
the
specific
need,
because
we
don't
need
the
full
api
of
object
search
right.
So
this
is
something
we've
got
discussed
in
the
past.
It's
a
big
effort.
So
how
can
we?
How
can
we
just
score?
This
type
of
alternatives,
try
to
figure
out
if
they
are,
if
they
make
sense
or
compare
them
with
other
solutions.
B
Okay,
so
we
definitely
do
need
to
collect
a
couple
solution
options
because
we're
going
to
see
if
you
come
by
the
for
the
person
who
has
to
actually
implement
this
in
all
kinds
of
scale,
we
need
something
that
falls
into
the
boring
solution,
if
at
all
possible,
preferably
using
industry
standard
tools,
if
at
all
possible.
I'm
fully
aware
of
the
licensing
concerns
when
it
comes
to
various
projects.
B
The
good
news
is
that
our
team
is
very
familiar
with
with
navigating
around
the
licensing
requirements
for
that.
In
terms
of
how
you
interface
with
various
components,
I
should
say
that
the
distribution
team
is
very
familiar
with
that,
because
we
have
to
deal
with
it
so
often.
B
It's
not
invalid.
Please
understand
it's
concerning
because
of
the
level
of
complication
for
the
orchestration
of
it
right,
because
then
you
also
have
to
make
sure
that
all
of
the
endpoints,
because
you're
probably
going
to
need
more
than
one
how
to
scale
it
when
to
scale
it
requirements.
B
All
of
these
things
that
come
to
operational
patterns
are
really
hard
to
nail
down,
as
opposed
to,
if
you
have
a
known
good,
I'm
using
mid
io
as
an
example
in
this
case,
which
has
the
ability
to
run
in
a
clustered
mode
and
you
can
reach
it
as
a
service
load
balancer
in
front
of
it.
So
you
don't
care
about
which
node
you
hit.
B
Now
I
say
that
being
fully
aware
of
what
gitly
did
for
us
and
why
we
had
to
do
giddaly
in
the
first
place
we
needed
to
think
outside
of
that
box.
So
I'm
not
saying
we
shouldn't
consider
it.
I'm
saying
we
need
to.
We
need
to
remember
that
there
are
a
lot
of
already
known
unknowns,
and
that
means
that
there's
a
bunch
of
things
that
we
don't
know
that
we
don't
know
to
look
for.
A
Yeah
yeah,
I
mean
for
me
this
was
just
an
example
yeah
I
just
I
didn't
want
to
discuss
the
specific
solution,
but
was
more
just
making
a
point
that
we
will
have
a
alternative
proposals.
So
how
are
we
going
to
drive
this?
So
what
what
I
was
thinking
and
the
reason
why
I'm
fitting
this
conversation
inside
the
collecting
requirements
is
that
probably
we
could
extract
from
the
collecting
requirements,
some
kind
of
say
a
set
of
scores.
A
So
we
say
what
we
want
to,
let's
say,
have
an
easy
migration
path
or
we
just
extract
something
migration
path.
A
licensing
problem
say
amount
of
code
to
develop
things
like
I'm
just
saying:
random
things
right
and
then
we
and
we
can
score
alternative
proposals.
So
we
say
maybe
mean
I
o
there's
nothing.
We
have
nothing
to
code,
but
there
can
be.
A
There
will
be
a
license,
compliance
problem
right
so
and
the
other
say
around
you
see
we
developed
something
with
there's
no
licensing
problem
because
it's
our
own
ips,
but
then
it's
the
scope,
creep
and
just
handling
this,
or
maybe
we
can
add
security
concerns
as
well
right.
So
we
we
can
try
to
to
have
something.
That
is
that
we
can
agree
upon,
and
it
is
more
easy
to
show
and
explain
why
we
made
a
decision
instead
of
just
using
gut
feelings
or
just
going
this
endless
debate.
My
solution
is
best.
My
solution.
A
Is
it's
not
so
good?
So
this
was
my
point.
I
don't
know
if
this
is
something
we
can
we
we
we
can
start
extracting
from
the
from
this
effort.
So
if
say,
we
are
waiting
for
feedback
on
point
b,
because
we
still
don't
know.
If
everything
is
clear,
we
can
say
we
can
shift
the
focus
on
c
in
building
the
the
scoreboard
so
that
we
can
score
different
solutions.
A
A
Well,
let's
move
on
point
d,
so
this
is
lukasz
is
not
here.
I
I
remember,
maybe
ben
I
think
it
was
ben
prescott,
I'm
not
sure,
volunteer
for
helping
him.
So
this
is
a
an
extra
data
point
we
have
to
consider.
I
I'm
not
aware
of
anything
in
this
direction
that
has
been
made
so
far,
but
the
point
is
that
we
are
thinking
from
the
our
experience
as
engineers
working
on
object,
search
and
our
experience
as
running
github.com
on
object
storage.
A
So
what
are
our
pain
points,
but
customers
are
running
different
configurations,
namely
they
are,
some
of
them
are
azure,
and
things
like
that,
so
there
is.
This
is
an
effort
about
collecting
those
type
of
information,
so
what
our
customers
are
using,
what
are
their
pain
points
so
that
we
make
sure
that
those
pain
points
are
backfeeded
into
our
selection
of
the
best
approach,
and
things
like
that?
So
I
don't
think
we
have
an
update
on
this.
A
Unless
someone
knows
about
this,
if
not,
we
can
move
to
my
point
b,
point
two
is
quite
easy:
I'm
just
recording
all
the
meetings
and
uploading
them
there's
a
dedicated
playlist.
So
some
of
them
are
private
because
we
mentioned
some
customers
and
things
like
that.
So
just
make
sure
if
you're
looking
for
something-
and
you
can
find
it
just
switch
to
the
to
the
github
unfiltered
account
so
that
you
can
see
them,
but
they
are
older.
So,
okay,
so
any
extra
point
we
want
to
discuss
here.
A
So
there
is
a
there
is
a
one
effort
that
is
not
part
of
this,
for
that
I
mentioned,
which
is
also
start
working
on
some
poc,
because
we
are
all
engineers.
We
would
like
to
also
write
some
code
as
part
of
this
effort
right,
so
we
don't
want
just
to
only
write
markdown
documents,
which
is
good.
I
mean
we
have
to
iron
out
those
some
of
those
unknowns,
so.
A
The
thing
is,
we
should
list
those
un
unknown
unknowns
and
the
things
that
we
want
to
experiment
with
some
degree
of
pocs
so
that
we
can
gather
more
information
about
them.
So
I'm
not
aware
of
any
effort
in
this
direction.
So
if
anyone
has
ideas
or
wants
to
start.
A
A
B
You
know
that
you
don't
know
that
you
don't
know
them,
though
exactly
that's
the
problem
with
unknown
unknowns
right.
It's
a
matter
of
wisdom.
If
you
haven't
had
the
time
to
run
into
something
correlative,
you
don't
know
that,
there's
something
on
the
edge
for
you
to
run
into,
but
the
known
unknowns.
We
can
collate
that's
going
to
come
from
two
places:
customer
reports
of
pain
points
and
our
requirements
right.
So
I
can
tell
you:
there
are
the
three
major
ones
that
everybody
thinks
of
which
are
aws
gcp
and
azure.
Blob
storage.
B
These
all
function
entirely
differently.
The
next
one
is
there
are
s3
compliant
that
are
not
actually
s3
compliant
okay.
So
there
was
a
very
large
potential
customer
who
went.
We
have
our
own
s3,
it's
fully
compliant,
and
then
they
pointed
gitlab
at
it
and
watched
it
explode
because
they
were
missing
two
functions
in
the
api,
so
the
first
thing
to
care
about
is:
if
we
put
it
some
sort
of
concentrator
in
play,
it
has
to
be
able
to
speak
the
full
language
of
all
of
these
apis
right.
B
That's
one
that
that's
right
there.
Then
you
have
the
problem
of
azure
blob
storage
right,
it's
its
own
little
thing.
It
operates
in
its
own
way.
It
handles
most
of
the
same
things,
but
do
we
write
code
that
has
all
the
client
libraries
for
this
thing
and
this
thing
and
this
thing
which
is
part
of
the
complication
of
carrier
wave
and
fog?
Now
or
do
we
rely
on
some
translator
party
right?
B
The
upload
handler
minio
tries
to
address
this
with
its
gateway
functionality,
but
it's
in
the
same
boat
as
fog
and
carrier
wave
where
it
now
has
to
support
all
of
the
various
things,
and
there
are
caveats
of
we
support
most
of
this,
but
not
that
where
we
support
this,
but
there's
a
policy
issue.
We
support
this,
but
you
can't
use
multi-part
over
this
size
or
these
little
things
we're
going
to
find
a
bunch
of
those
by
looking
through
our
support
tickets.
B
A
Okay,
I
mean
this
is
something
important.
I
would
say
that.
A
I
think
that
in
our
documentation
we
are
kind
of
too
light
on,
say
what
we
support.
We
can
say
it
just
work
on
s3
compliant,
I
mean
it's.
Free
compliance
is
s3
compliant
and
if
you
are
not,
then
it's
fine,
obviously
right,
but
I
mean
we
mentioned
explicitly
azer,
I'm
sure
it's
mentioned
there
as
well
as
google
cloud
storage.
So
maybe
this
is
something
we
should
track
as
a
kind
of
qa
task.
A
When
you
say
if
we
claim
that
something
is
supported
and
has
to
be
tested
right
in
qa
and
make
sure
that
we
have
end-to-end
or
test
installation,
because
I
mean
we
are
not
using
all
of
those
right,
so
we
will
not
we,
we
will
not
be
able
to
notice
failure
in
this
attempt
unless
we
are
actually
exercising
that
test
and
that
code.