►
From YouTube: 2021-12-14: 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
B
Yeah
I
closed
this
out
that
there
are
still
some
gaps
that
I
wasn't
able
to
figure
out.
I'm
thinking
because
we
spend
a
lot
of
time
on
it
already
and
it
wasn't
completely
sure
like
how
how
we
would
use
that
information
going
forward.
I
would
say
like:
let's
just
see
you
know
if
we,
if
we
still
need
to
fill
in
these
gaps,
we
can
just
do
it
like
when
we
need
it
on
on
a
particular
task
other
than
that
we
we
have
a
structure.
B
A
Thank
you,
mathias
yeah,
I
agree
with
you.
I
mean
we
can
fill
the
blanks
if
we
need
them.
I
want
to
go
to
marin
with
this
just
to
figure
out
what
he
needs
out
of
this,
because
there
are,
as
we
say,
that
in
the
beginning,
there
are
kind
of
two
needs
for
for
this
collection
of
requirements,
no
collection,
collection
of
status.
What
we
have
right
now,
the
current
feature
set
one,
was
that
we
take
into
account
what
we
have
to
design
the
new
system.
A
C
C
It's
not
clear!
Yet
if
that's
a
good
direction
or
not
more
discussions
will
be
required,
and
I
think
that
in
order
to
make
this
a
bit
more
objective,
we
need
to
enumerate
these
requirements
at
container
registry
as
a
solution
scored
proper
like
correctly,
and
this
will
actually
shed
some
light
on
how
good
or
how
bad
solution
this
might
be.
C
D
I
posted
a
comment
on
that
in
the
package
team.
We
have
a
glimpse
of
what
it
is
of
using
the
container
registry
to
get
data,
because
we
need
to
get
data
for
the
container
images
and
right
now
it's
it's
really
complex,
and
so
I
don't
want
members
to
have
this
false
feeling
that
yeah,
we
can
put
everything
in
the
container
registry
and
everything
will
works
as
it
is.
D
Currently,
the
api
of
the
container
registry
is
really
not
in
a
great
shape
and
as
a
very
small
example,
there
is
an
endpoint
that
will
list
a
well
give
you
a
list
of
objects
and
that
endpoint
is
not
paginated
at
all.
So
if
you
have
thousands
of
objects,
you
receive
thousands
of
objects,
and-
and
so
it's
not
impossible
to
improve
the
link
between
rails
and
the
and
the
container
registry,
but
it
needs
a
lot
of
work.
C
So
I
think
that
everyone
is
aware
of
these
problems.
At
least
I'm
aware,
I've
been
involved
in
implementing
container
registry,
evaluating
the
notifications,
api
and
stuff
like
that.
So
it's
it's
clear
that
it's
not
a
simple
problem
to
solve
and
there
are
probably
solutions
to
that.
We
can
probably
treat
of
a
container
registry
as
a
secondary
storage
like
we
still
might
need
to
store
data
in
postgresql
metadata
right
and
then
we
can
actually
store
blobs
for
the
container
registry.
C
It
might
be
possible,
but
I'm
I'm
not
entirely
convinced,
yet
that
this
solution
would
be
aligned
with
the
problems
we
are
trying
to
solve
like
it
might
actually
solve
something.
It's
not
really
clear
if
there's
something
that
this
would
solve
would
be
the
problems
we
have
right
now
so
yeah.
That's
why
I'm
thinking
about
actually
scoring
the
solution
against
the
the
the
problems
we.
B
Want
to
solve,
we
should
also
keep
in
mind,
and
that
goes
back
to
a
comment
I
left
early
on
on
this
whole
requirements
document.
Is
that
so
far
what
I
can
tell
we've
been
looking
at
the
requirements
from
a
very
technical
lens
like
we
would
try
to
identify
what
what
is
kind
of
the
cross-section
of
all
of
the
stuff.
That
involves
object,
storage
and
what
are
the
requirements
kind
of
coming
out
of
that,
but
that
completely
ignores
the
feature
level
requirements
for
the
actual
products
that
are
built.
B
B
I
is
that
something
that,
like
a
container
registry,
would
support
as
well,
so
because
I
think
that's
why
they
use
git
right
now
right
and
get
lfs,
so
so
so
maybe
it
does
I'm
just
saying
that
was
not
part
of
this
table
right,
because
it's
specific
to
design
management.
It's
not
in
this
cross
section
of
requirements,
so
we
need
to
be
really
careful
that
we
don't
like
look
at
this
only
through
a
technical
lens
and
completely
ignore,
what's
happening
on
the
product
level.
C
So
I
think
that
that's
interesting,
because
it
makes
me
wonder
if
we
are
talking
about
the
solution
on
the
right
abstraction
level,
because
the
container
registry
might
actually
be
a
viable
solution
at
a
different
abstraction
level.
If
we
hide
this
behind
everything,
it's
just
a
storage
bucket
and
we
still
do
have
postgresql
metadata
in
between.
We
still
do
have
workhorse
and
everything
else
in
between
right.
So
it
feels
like.
C
Should
we
think
more
about
on
which
abstraction
level
we
want
to
place
the
new
solution?
Does
it
need
to
be
in
front
or
or
on
the
back
end,
because
it
like
ultimately,
is
going
to
be
a
different
solution
right?
If
you
want
to
have
this
getaway
with
some
business
rules
around
how
we
store
data
along
with
metadata,
it
will
be
placed
in
at
the
front
of
the
entire
stack.
If
we
want
to
actually
use
the
container
registry
or
any
kind
of
other
artifacts
registry,
it
might
be
at
the
back.
C
But
then
the
problems
at
the
front
will
remain
unsolved,
still
right,
so
it's
like
which
abstraction
with
which
level
of
abstraction
which
layer
we
want
to
actually
inject
the
solution
in
or
move
into.
So
that's
something
that
we
need
to
somehow
capture,
I
believe
or
describe,
so
that
it's
made
a
bit
more
explicit.
What
we
want
to
solve,
how
we
want
to
do
that,
and
it
kind
of
depends
on
where
the
problems
are
right,
because
artifact
registry
might
be
a
viable
solution,
but
the
problems
are
on
a
different
level.
C
A
Yeah,
these
are
all
good
and
valid
point.
Thank
you
all
of
you
for
expressing
those,
so
I
want
to
quickly
chime.
In
yesterday
I
had
a
coffee
challenge-
a
coffee
shop
with
marshall,
just
to
figure
out
where
he
is.
Where
is
he
with
this
thing
with
his
thinking
on
this?
So
we
kind
of
agreed
that
the
the
thing
he
was
proposing
is
not
at
the
right
level
for
what
we
are
trying
to
do
here.
So
he
will
probably
join
the
the
working
group
next
week
because
he
lives
in
the
u.s.
A
So
this
this
time
zone
doesn't
help
here,
so
maybe
next
week
he
will
join.
So
what
he
told
me
is
that
basically,
it
will
probably
will
try
to
to
focus
more
on
packages
so
that
the
the
registry
can
be
say
we
can
try
to
iron
out
the
details
on
what
the
oci
artifact
registry
can
do
in
the
context
of
packages.
A
Storage
is
kind
of
by
some
degree
well
known
and
is
working
with
string
attached,
but
it's
working
while
we
have
problems
with
how
we
finalize
those
things
on
rails,
how
we
keep
metadata
about
where
things
are,
and
so
I
would
say
I
will
not
spend
one.
I
would
not
like
to
spend
one
year
of
engineering
time
working
on
something
that
is
replacing
the
the
only
part
of
the
only
part
is
a
bit
too
much.
Let's
say
the
biggest
part
of
object,
storage,
implementation
that
is
working
in
the
current
state.
A
C
That's
it
yeah,
I.
I
think
these
are
all
a
great
point,
but
I
also
think
we
should
somehow
capture
that
somewhere
in
the
google
doc
google
spreadsheet
blueprint,
because
for
for
after
talking
about
that,
it's
kind
of
clear
that
we
want
to
solve
problems
and
like
not
back
in
storage
per
se,
but
yeah
this.
We
should
somehow
implement
that,
and
I
document
that
and
I'm
not
sure
how
to
what
would
be
the
best
way
to
do
that.
So,
if
anyone
has
suggestions
like
please,
let
us
know.
A
A
A
C
A
A
C
So
gregor
is
back
to
you
yeah,
so
the
last
week.
I
think
it
was
last
week
or
the
week
before
we
had
this
incident
with
database
contention
coming
from
lox
that
were
caused
by
presumably
carrier
wave,
removing
data
from
packages
inside
the
transaction.
I
think
there
is
rca
completed.
I
have
not
yet
okay,
so
thanks
for
linking
it
there
is
this
rc
I
completed.
So
I
will
take
a
look,
but
it's.
A
C
That's
really
interesting,
so
this
probably
won't
work
but
back
to
the
point
that
that
we
don't
ask
if
we
can
actually
review
the
api
and
other
endpoints
and
check
if
these
are
not
vulnerable
to
this.
And
while
I
believe
that
removing
data
might
actually
not
be
a
problem
outside
of
package,
I
think
it's
possible
that
uploading
data
might
be
because
upload
still
happens
inside
the
transaction
and
when
a
file
is
large,
it
can
actually
cause
a
long
transaction
so
yeah.
C
A
C
A
A
I
can
point
to
a
couple
of
issues,
but
the
point
is
that
if
direct
upload
is
implemented,
this
happens
outside
of
database
transaction,
which
is
good.
The
point
is
that
the
finalization
call
which
you
are
aiming
to
remove
is
it's
within
the
transaction
and
depending
on
which
object,
storage,
implementation,
you're
using
may
be
faster
or
slower.
A
A
If
it's
a
big
file,
it's
because
I
mean
we
have
customer
reporting
that
they
were
uploading
up.
25
gigabyte,
lfs
object
and
add
timeouts
yeah,
so
I
mean,
but
I
think
it's
a
very
specific
use
case,
so
that
one
is
good,
but
it
may
change
from
object,
storage
implementation
to
object,
surge
implementation
because
it
really
depends
how
how
things
are
copied
over.
So
I.
C
Sure
good
point,
so
I
wonder
if
we
can
actually
open
an
issue
about
that
and
collaborate
there.
Of
course
it
should
be
a
confidential
issue
and
that's
kind
of
a
security
issue
as
well,
because
someone
who
knows
how
to
upload
a
very
large
file
and
work
workaround
limits
can
you
know,
cause
daniel
of
service
on
the
database
level.
C
A
Thank
you
gregor.
I
think
david.
This
is
what
we
were
discussing
a
couple
of
weeks
ago
in
the
the
work
encryption.
Where
me
you
and
sam.
We
were
trying
to
figure
out
what
what
happens
if
there
are
things
that
are
kind
of
required,
so
extra
storage.
So
I
think
if
we
go
back
searching
those
informa
those
messages
we
will
have
some
kind
because
stan
was
giving
us.
I
think,
a
direct
link
in
the
code
base
where
those
things
are
happening,
so
it
can
be
yeah.
C
D
D
A
Okay,
if
there
are
no
extra
discussion
on
this
topic,
the
next
item
is
mine.
This
is
just
a
very
instead
just
a
status
update.
So
I
open
up
a
separate
issue
to
understand
if
we
can
duplicate
and
remove
this
pseudonymizer,
which
no
one
seems
to
know
what
it's
doing
I
mean,
maybe
it
seems
to
be
something
related
to
the
old
mint
miltano
integration,
so
one
less
bucket,
if
we
can
remove
it
so
yeah.