►
From YouTube: SIG - Storage 2022-12-19
Description
Meeting Notes:
https://docs.google.com/document/d/1mqJMjzT1biCpImEvi76DCMZxv-DwxGYLiPRLcR6CWpE/edit#
A
A
B
A
B
Yeah,
this
is
an
issue.
That's
been
floating
around
quite
a
bit
as
GitHub
issues
come
up
on.
You
know,
slack
it's
and
even
I
noticed
last
week.
That
project
like
hypershift
is,
is
kind
of
coding
around
this
issue
by
doing
some
questionable
stuff.
Basically,
the
issue
is
that
importing
a
Cuca
to
file
via
HTTP
may
be
slow,
and
the
reason
for
that
is
that
we
are
converting
from
qcout,
so
convert
obviously
uses
raw
images
and
when
we
convert
from
HTTP
we
are
doing
that.
B
So
if
latency
is
high
to
the
server-
or
this
is
like
some
mirror
thing-
and
there
are,
is
you
know
throttling
going
on
on
the
server
side,
it
can
be
quite
slow
because
we
just
do
a
number
of
HTTP
requests
and
the
alternative
is
and
the
so.
The
nice
thing
about
doing
the
conversion
in
line
is
that
it
doesn't
require
scratch
space.
You
can
just
create
the
target
PVC
and
write
directly
to
it.
B
The
alternative
is
to
download
the
qcat
2
file
to
scratch
space
and
then
can
then
do
the
conversion
from
there
and
in
a
lot
of
cases
that
is
faster
to
just
stream
down
the
image
to
the
to
a
local
scratch
PBC
and
convert
from
there.
So
the
question
is:
how
do
we
want
to
deal
with
this?
It
seems
like
do
we
make
it
configurable
to
allow
this?
B
C
A
A
D
A
E
D
The
nice
thing
about
qco
is
that
you
should
have
less
I
mean
it
should
be
smaller
than
raw.
So,
in
my
opinion
it
would
be
nice
to
do
it.
I
mean
if
we
can
configure
it
and
add
the
scratch
space,
but
the
scratch
face
doesn't
need
to
be
the
original
size
of
the
raw
image.
It
needs
to
be
the
cube
cow
virtual
side.
Now,
I
always
forget
anyway,
in
usually
QC
how
images
are
smaller,
yeah.
B
E
A
D
A
E
A
I
mean
in
the
in
the
earliest
of
days.
We
never
even
had
scratch
space
like
so.
The
only
way
we
could
import
was
like
in
the
very
beginning,
was
finding
a
way
to
use
the
the
I
o.
The
readers,
like
the
reader
stack
in
golang
to
basically
build
a
reader
that
could
read
directly
into
the
PVC.
That
was
the
original
design
and
then
I
think
we
ran
into
cases
where
you
you
just
frankly,
could
not
do
that.
So
then
we
had
to
introduce
scratch
space,
but
we
never
Revisited
whether
we
should
use
that
everywhere.
A
And
I
would
say
like
just
adding
a
bit
of
information
here.
I
have
not
noticed
really
any
complaints
with
the
scratch
space.
Implementation,
like
I,
haven't
seen
any
kind
of
issues
coming
across
where
people
would
say
you
know.
I
don't
have
enough
space
in
my
cluster
to
import
this
because
it
needs
scratch
space,
but
I
would
have
been
okay
if
you
could
do
it
directly
like
that,
just
doesn't
seem
to
be
a
commonly
encountered
issue,
so
it
seems
like
if
scratch
space
is
working
well
and
people
aren't
bothered
by
the
temporary
increased
storage
requirements.
A
Yeah
I
mean
I,
definitely
have
an
opinion
here.
Maybe
it's
not.
The
only
one
I
would
say
that
more
options
equals
harder
to
use
the
the
software.
So
in
general
we
should
just
pick
what
we
consider
to
be
the
right
approach.
I
would
say
that
if
you
need
a
workaround
like
if
scratch
Space
is
really
an
issue
for
you,
you
could,
if
you're
in
control
of
the
the
file
or
you
have
a
place
to
host
it.
A
You
could
host
it
in
compressed
raw
format,
which
could
still
be
direct
to
PVC
without
a
performance
penalty,
or
you
could
create
a
container
disk
and
use
a
registry
import
or
something
else.
If
you
really
were
in
a
bind
with
this,
but
otherwise
it
seems
like
it
shouldn't
affect
people
to
too
badly.
C
B
Yeah
I
mean
they
use
data
volumes
and
you
know
for
for
their
they're,
currently
importing
them
via
HTTP
because
they
don't
have.
You
know
this
is
probably
it
a
temporary
thing
for
now,
but
they
don't
have
whatever
images
they're
hosting.
They
need
like
some
Rel
image
or
Centos
I
mean
don't
forget,
which.
B
E
B
B
A
A
C
A
D
You
hear
me
yep,
so
I
would
like
to
make
you
aware
about
the
design
proposal
I
open
on
Friday,
so
this
is
basically
describes
the
integration
of
a
new
project
that
rely
on
second,
especially
second
notifiers,
and
as
far
as
regards
storage,
that
could
help
solving
to
issues.
So
one
is
the
scalpy
Precision
reservation.
D
This
is
the
topic
I'm
working
since
the
wire,
and
it
doesn't
really
have
a
nice
solution.
So
for
those
of
you
are
not
aware
about
gazipers
reservation,
I
link
some
some
smooth
reference,
so,
but
basically
they
issue
go
Downs
to
let
qrimu
talking
to
a
privileged
demon
through
a
uni
socket,
and
this
is
really
not
nice
supported
in
a
kubernetes
environment.
D
D
So,
at
the
end
we
would
like
to
avoid
buy
mounts
because
several
issues
clean
up
issues
so
yeah.
Basically,
this
proposal
could
fit
nicely
in
these
two
use
cases.
So
it's
pretty
lengthy.
We
try
to
write
down
a
lot
of
security,
implication
so
yeah.
If
you
have
some
time
and
you
have
time
to
review
it.
A
D
D
We
actually
have
talked
about
this
in
the
document,
but
there
is
this
latency
some
additional
latency.
However,
we
have
tried
to
minimize
this
by
building
a
smart
filter
and
the
latency
is
logarithmic
proportional
to
the
number
of
the
filters
c-score,
but
we
considered
that
these
numbers
should
be
pretty
low.
D
D
A
D
A
A
All
right,
thanks
for
raising
that
and
I
guess
the
next.
What
kind
of
what
is
the
next
step?
I
guess?
The
next
step
would
be
to
close
on
the
design
proposal,
and
you
said
that
you
were
working
on
the
the
sort
of
the
the
base
implementation,
so
you'd
be
able
to
show
like
a
proof
of
concept
of
this
at
some
point
as
well.
Yeah.
D
A
A
B
So
basically,
he
recommended
to
take
that
topic
to
the
Seth
mailing
list
or
something
well.
I
talked
to
Niels
about
it
and
yeah.
He
he
he
did
not
know
the
status
of
deduplication
and
serve.
He
seems
to
think
that
we
don't
support
it
in
Downstream
like
OCS.
Yet
so,
okay,
I,
don't
think
I,
don't
think
Andre
is
using
OCS
or
but
yeah.
He
recommended
just
taking
it
to
the
except
mailing
list.
So
I
don't
know.
A
C
C
A
D
E
D
A
Yeah
there
had
been
some
discussion
about
that,
because
we're
definitely
trying
to
do
some
refactoring
of
code.
There's
there's
been
an
effort
over
the
long
term
to
yeah
to
try
to
organize
the
code
in
such
a
way
that
it's
sort
of
clear
which
maintainers
or
which
folks
should
review
certain
or
be
kind
of
in
charge
of
certain
bits
of
the
code
base.
A
That's
an
ongoing
thing
at
one
point:
when
we
had
some
plans
to
try
to
automate
that
you
know
Cube
vert
wide
we're
looking
for
ways
to
continue
to
scale
the
development
process,
to
make
it
easier
and
quicker
for
people
to
get
the
reviews
they
need.
So
yeah
I'm,
not
sure
what
the
latest
and
greatest
is
on
any
of
those
processes
or
automation,
but
at
least
for
now
I
guess
it
can
be
used
manually
and
it
looks
like
at
least
Alicia
is
looking
for
that
label
and
I
guess
the
rest
of
us.
A
D
A
Yeah
and
I,
could
you
know
that's
a
it's
a
good
point,
because
this
could
be
another
another
way
for
us
to
call
attention
to
certain
things
in
this
meeting
as
well.
I
know
at
the
first
the
first
meeting
we
we
tried
to
take
a
look
at
some
of
the
outstanding
GitHub
issues
and
things,
and
so,
if
we
could
do
that
across
repos
within
the
cube
vert
org
by
use
of
the
Sig
storage
label,
that
might
be
a
great
way
to
yeah
to
keep
a
hold
on
that.
A
Great
okay,
so,
while
other
folks
are
pondering
any
other
last
minute
additions,
they
want
to
bring
up.
I
wanted
to
propose
that
we
cancel
the
next
instance
of
this
meeting,
which
would
occur
on
the
2nd
of
January
I.
Think
a
lot
of
folks
are
going
to
be
out
still
from
from
the
end
of
year,
holidays
and
stuff,
and
and
even
if
they're,
not
I,
don't
expect
there
to
be
a
ton
of
topics
as
folks
are
getting
back
from
that.
So
it
seems
to
make
sense.
A
C
A
All
right
so
with
that
I
guess
we
can
give
folks
a
few
extra
minutes
back
on
their
schedule
today
and
I.
Just
wanted
to
thank
everybody
for
joining
I
really
enjoy
the
discussions
that
we're
having
here
so
I
hope
everyone
has
a
good
holiday
season
and
we'll
catch
you
guys
back
in
about
a
month's
time,
foreign.