►
From YouTube: SIG - Storage 2023-03-27
Description
Meeting Notes:
https://docs.google.com/document/d/1mqJMjzT1biCpImEvi76DCMZxv-DwxGYLiPRLcR6CWpE/edit#
A
Okay,
all
right,
so
the
first
agenda
item
that
I
added
here
is
I
just
wanted
to
throw
out
a
quick
reminder
that
we
have
cubert
Summit
this
week,
Wednesday
and
Thursday.
If
you
click
that
link
it'll,
take
you
to
the
events
page.
It
is
a
free
registration,
but
you
do
need
to
register
for
the
event
in
order
to
receive
the
link
to
the
actual
sessions,
and
you
can
see
the
schedule
and
everything
there.
So
all
virtual
highly
encourage
you
guys
to
attend.
A
There
should
be
some
pretty
cool
talks
there
from
a
diverse
array
of
presenters,
so
definitely
had
to
mention
that
one
and
then
hey
Michael,
I,
see
that
you're
here,
I
can't
recall
if
you
had
a
topic,
I
feel
like
yes.
Last
week
we
were
discussing
something
that
you
thought
about.
Bringing
here,
I,
don't
know
if
you,
if
you
had
that
or
otherwise
pretty
much
all
I
have
on
the
agenda
for
today
is
to
go
to
the
CDI
issues.
C
B
Talk
about
Hubert,
rendering
in
CDI
and
how
things
have
changed.
Given
the
our
decreased
release,
Cadence.
B
So
it
used
to
be
that
you
know
CDI
would
release
every
three
weeks
if
we
were
making
a
change
in
CDI
like
say
we're,
adding
or
you
know,
adding
a
field
to
an
API
that
we
wanted
Cuba
to
use.
We
would
basically
just
you
know,
do
it
in
release
and
and
and
then
wait
for
a
release.
B
You
know
it
was
going
to
happen
soon
enough
and
then
vendor
it
in
to
keep
vert,
and
that
was
fine
because
we
were
releasing
pretty
frequently
and
but
now
with
these
very
infrequent
releases,
where
we're
releasing
what
three
times
a
year
or
at
least
having
make.
You
know
more
major
releases
three
times
a
year.
C
B
We
do
it
would
seem
that,
given
our
current,
you
know
the
comp
where
we're
doing
things
would
be
to
essentially
so
we
don't
have
so
okay.
So,
given
the
way
we
release
things,
we
basically
create
a
release.
Branch
right
before
we
do
a
release,
tag
it
and
yeah
build
the
release,
so
we
basically
make
these
release
branches
at
the
end
like
right
before
we're
going
to
release.
B
So
if
we
wanted
to,
if
we
were
working
on
something
now
an
API
change
that
we
wanted
to
vendor
into
cubert,
you
know
we
we
kind
of
have
a
couple
options.
We
could
either
vendor
in
to
keep
commits
from
Maine
on
CDI,
which.
B
Is
possible
but
I
think
we've
kind
of
decided
that
that
that's
got
a
sense
of
trouble
before
in
the
past.
I
believe
the
second
option
is
we
can
create
release
branches
kind
of
earlier
on
in
our
release,
progress
in
our
release
in
our
development
process
and
basically
always
do
our
work
in
Maine
and
always
merge
down
into
release
Branch.
B
So
it's
basically
more
work
as
we
go,
but
at
least
the
nice
thing
about
that
is
when
we
vendor
into
convert
we're
at
least
vendoring
in
from
a
release
branch
and
not
Main,
and
that
second
strategy
is
what
like
say
a
project
like
openshift
does
when
they're
you
know,
openshift
has
a
bunch
of
projects
with
different
dependency
relationships
and
they'll.
They
basically
Branch
very
early
on
and
I,
think
kind
of
bulk
merge
things
down
into
release
branches.
So
that's.
B
Think
you
know
we
we
used
to
be
able
to
be
kind
of
lazy.
Oh
we'll
just
wait
for
the
release.
That's
going
to
happen
only
in
a
couple
weeks
now
that
releases
are
less
frequently.
What
should
we
do.
C
And
so
do
we
have
any
metric
metrics
release
for
keyword
and
CDI
I
mean
there
is
some
relationship
between
keyword
and
CDI?
So
do
we
do
we
have
already
something
like
Hubert,
I,
don't
know
zero
point.
50
59
works
with
those
cdis
version.
B
I,
don't
think
we
do
for
Upstream.
Now
we
do
I
think
maintain
mappings
of
what
Downstream
versions
match
to
Downstream,
but
I.
Don't
think
we
have
I
mean
maintain
any
sort
of
Matrix
for
Upstream.
A
Yeah
I
think
in
general
we're
just
expecting
that
that
you
would
use
the
latest
latest
releases
together.
B
Yeah,
any
any
yeah
yeah
pretty
much
that
that's
what
we
expect.
Upstream
I
guess.
D
So
I
have
a
comment.
The
branching,
early
and
mirroring
commits
is
going
to
be
a
lot
of
work.
How
big
of
an
issue?
Is
it
because
we're
supposed
to
build
cubert
and
CDI
so
that
they
can
like
you're
supposed
to
be
able
to
run
it
with
the
code
with
an
older
CDI?
And
you
can
test
it
locally
with
the
newer
CDR.
D
So
we
can
just
pretend
just
wait
longer
and
test
ourselves
that
it
does
the
right
thing
or
maybe
we
can
have
a
branch,
optional
branch
which
tests
the
latest
CDI
and
cubert,
and
then
we
can
know
make
it
easy
for
people
to
see.
Yes,
those
changes
work
with
the
latest
Cydia.
A
Yeah,
like
I
was
wondering:
is
there
a
way
that
we
can
have
Cube
vert
updating,
like
actually
Cube
vert
main
is
tracking
CDI
main
for
vendoring,
like
on
a
fairly
regular
basis,
and
then,
when
cube
vert
would
switch
to
a
stable
Branch?
Then
they
would
expect
to
switch
to
a
CDI,
stable
Branch
for
vendoring?
Is
that
I
don't
know
if
that's
a
model,
that's
sustainable
as
well.
B
You
know
I,
think
I,
think
the
reason
that
I
think
that
that
is
probably
fine,
given
the
way
that
we're
doing
things
now
I
think
where,
because
we're
never
really
working
kind
of
two
releases
in
the
future,
so
say
we
had
some
super
long-term
initiative
that
we
wanted
to
make
progress
on
and
Maine,
while
some
shorter
term
stuff
we
wanted
for
the
next
release.
That's
where
I
think
things
get
complicated.
If
you
don't
Branch
early.
A
But
really
we
should
be
introducing
new
apis
in
a
compatible
way
as
a
best
practice
such
that,
if
you
adopt
newer,
you
know
newer
vendored
code.
It
shouldn't
affect
it.
Shouldn't
provide
like
unwanted
side
effects,
I
guess,
I,
don't
know.
Yeah.
B
I
mean
that
that
is
true,
I
think
again,
a
lot
of
this
is
getting
into
like
the
could
haves
and
what
haves
and
being
pedantic
about
things
like,
for
example,
CDI
is
technically
still
beta.
You
know
we're
not
a
V1
API
yet,
but
yeah.
A
B
We
don't
have
to
be
total
hardcore
purist
about
this.
You
know,
I
think
they
can
do
something.
That's
pragmatic,
given
our
history
and
everything
but
I'm
just.
A
A
Even
if
somebody
forgets
after
Cube
vert
stabilizes
to
update
the
vendoring
I
mean
we
really
should
do
that
right
before
we
Branch
Cube
vert
is
at
least
go
to
the
latest
CDI
main,
because
then,
if
we
did
need
fixes
on
a
cube,
vert,
stable
Branch,
we
would
just
do
those
fixes
in
the
CDI
release
branch
and
then
update
the
commit
to
to
that
and
then
that
avoids
bringing
in
The
Unwanted
additional
development
from
the
main
branch.
A
So
long
as
at
the
time
of
cube,
vert
branching,
we
make
sure
I
guess
we
do
have
to
make
make
sure
to
update
the
the
vendoring
at
that
time
and
not
forget
that.
Otherwise
there
could
be
a
bit
of
a
fast
forward
involved
there
that
that's
not
planned.
A
E
Think
we're
we're
getting
one
sort
of
thing
here
is
that
Cooper
adventures
in
mainly
the
CDI
API,
which
is
a
separate
Repository
Michael.
Do
you
know
off
the
top
of
your
head
if
the
CDI
API
is
generated
on
every
commit,
or
only
on
like
brows
branches,.
B
It's
it's
well.
I
can
check
right
now,
I
think
that
it
I
think
that
it
maintains
the
branches.
E
Every
commit,
then,
we
can't
really
vendor
in
Maine,
because
we're
not
generating
main
properly
ever
commit
so.
B
E
A
E
My
main
thought
is
like
in
CDI
we
introduced
a
new
API
and
we
haven't
done
a
branch
and
made
a
you
know
proper
release
for
it.
Yeah
and
I
want
to
use
it
in
Cube
verbs.
E
E
Even
though
the
API
may
exist
in
the
actual
CDI
repo,
actually
I
I
think
it
just
answered
my
own
question
because
it
can
exist
in
CDI
itself.
It
doesn't
exist
in
CDI
API.
So
but
it's
sort
of
like
that
staging
thing
so
yeah.
A
E
If
you
want
to
use
the
API,
it
needs
to
exist
right.
That's.
F
E
B
Getting
the
the
GitHub
unicorn
when
I
try
to
access
our
container,
our
API
repo
did.
E
You
see
the
GitHub
accidentally
released
their
private
SSH
key,
so
they
have
to
like
regenerate
and
replace
all
the
GitHub
host.
Ssh
keys,
yeah.
Okay,
if
you
actually
let
me
let
me
go
find
the
link
to
this
blog.
A
Okay,
so
I
don't
know:
do
we
have
any
other
other
thoughts
on
this
I'm
trying
to
it
feels
to
me
like
if
we
try
to
allow
Cube
vert
to
track
commits
in
the
main
branches
of
CDI
that
this
could
be
okay,
I'm
trying
to
remember,
we
did
have
a
reason
for
not
doing
it
in
the
past
and
I
think
that
may
have
been,
because
it's
possible
to
choose
a
commit
that
you
know
we
don't
regard
as
like,
fully
fleshed
out,
but
I
think
it's
up
to
the
people
who
submit
the
PRS
to
cube
vert
to
choose,
commits
that
are
known.
B
Yeah
I
mean
I
think
it
may
be
fine,
given
our
current
priorities
and
the
way
we've
been
doing
things
for
a
while.
You
know
maybe
something
we'll
revisit
later
and.
A
I
mean
CDI
and
Cube
vert
are
you
know,
sibling
projects
with
crossover
from
developers?
It's
not
like
we're
vendoring,
some
some
random
library
on
GitHub,
where
we
don't
even
know
the
developers
so
I
mean.
In
that
case
you
have
to
be
careful
and
choose
stable
releases,
but
here
there's
a
lot
of
synchronization
in
at
play.
So
we
understand
the
risks
and-
and
we
understand
the
projects
well
enough
to
do
that-
to
track
Maine
I.
Think.
A
A
Yeah
I
mean
I've,
been
I've,
been
personally
thinking
about
this,
for
quite
some
time,
I've
been
kind
of
wanting
to
delay
any
of
those
until
we
adopt
the
populators
concept
within
kubernetes
and
also
when
we
potentially
have
workflows
that
don't
require
the
use
of
data
volumes
and
I
think
you
know,
because
some
of
those
there
could
be
some.
A
You
know
gymnastics
that
we
need
to
do
that.
You
wouldn't
want
to
do
with
the
V1
API.
Obviously
we
maintain
compatibility,
but
if
things
things
are
going
to
be
probably
moving
a
little
bit
more
than
you
would
expect
for
a
V1
API.
With
some
of
these
changes,
so
I
feel
like
after
we
complete
that
work,
we
would
be
in
a
good
position
to
be
branding
V1
right.
E
But
you
know,
being
beta
gives
us
a
little
flexibility
to
be
more
breaking
if
we
have
to,
for
whatever
reason
we
try
not
to,
but
if
there's
a
really
good
reason,
much
harder,
wouldn't
be
one
than
a
bigger
one.
A
All
right,
okay,
any
other
thoughts
on
this
one
before
we
move
on,
hopefully
that
I
think
we
got
to
a
resolution
on
that.
A
All
right,
any
other
topics
before
we
start
in
with
the
issue
triage,
just
throwing
it
out
for
a
quick,
open
floor.
A
Okay,
all
right,
so
let
me
go
and
open
up
this
tab,
so
we
ended
last
time
on
the
expected
hash
to
data
volumes
issue.
So
let's
go
up
to
the
next
issue
here.
C
E
No
I
think
that
just
really
really
slow.
A
A
Okay,
so
we
got
all
of
these
all
right,
you're
right.
Okay,
so
is
this
the
one
we
need
to
do
or
did
we
cover
this
one
I
forget
now
it
says
life
cycle
rotten,
so
I
guess
maybe
this.
A
Thanks
all
right
all
right
when
importing
a
containerized
disk
via
data
volume,
definition
to
block
CSI
driver,
the
disk
is
the
wrong
permissions
when
importing
to
a
file
driver,
it
Imports
it
the
correct
permissions,
all
right,
I'm,
a
little
confused
by
that,
because
a
block
device
wouldn't
have
permissions,
but
maybe
they
mean
a
file
system
built
on
top.
Let's
see.
E
Remember
so
the
the
problem
is
for
actual
volume
of
block
FS
group
doesn't
apply
so
since
155
we're
running
routes,
so
the
permissions
on
the
Block
device
are
essentially
wrong,
and
this
is
known
in
kubernetes,
I
I
linked
the
article
that
sort
of
explains
why?
But
the
issue
is
on
the
runtime.
F
E
Think
mainly
container
DSS
issue.
Since
you
know
all
our
testing
is
on
cryo
cryo
doesn't
automatically
already
okay.
Well,
basically,
what
that
flag
enabled,
it
will
sort
of
follow,
says
so.
Do
I
think
this
actually
got
resolved
because
there
hasn't
been
any
activity
after
I've,
you
know
explained
all
of
it
so
I
either
they
completely
gave
up
or
it
worked
for
them
now.
So
do.
G
G
D
B
A
So
I'm
gonna
say
since
the
proposed
solution
should
resolve
the
problem,
and
we
have
documented
this.
C
A
A
Okay,
I'm
just
gonna,
scan
this
here.
Private
registries.
B
B
Pr
I'm
surprised
it
didn't
close
this
one
automatically.
B
It,
oh
it
does
oh
okay
yeah,
he
he
didn't
use
the
fixes
he
macro
or
whatever
in
the
description.
Okay,
but
yeah.
B
A
Can
try
it
every
time
I
go
to
these
top
tabs
I'm
getting
this
pop
over
from
from
Zoom
okay,
so
this
is
23.95,
so
I'm
gonna
write
fixes
I.
B
A
All
right,
all
right,
so
we
are
next
to
CDI,
with
restricted
policy,
fails
to
import
on
volume.
That
is
ext4
because
it
cannot
remove
lost
sound
I.
Think
we
talked
I
feel
like
we
talked
about.
This
I
have
a
Deja
Vu
of
a
conversation
about
really
only
trying
to
remove
the
disk,
dot,
IMG
file
and
not
other
stuff.
That's
on
the
PVC.
E
Yes,
we
had.
We
had
this,
what
I
I
want
to
say,
NetApp
back
end
where
they
had
some
read-only
snapshot
directory
in
in
the
and
the
volume
itself,
and
that
was
causing
a
CDI
to
fail.
Okay,.
G
E
No
that
was
me
to
open
this.
So,
oh
it
hasn't
been
then,
okay,
so
I
I,
actually
don't
remember
the
circumstances
why
I
opened
it
I
believe
Michael
did
some
testing
and
he
said
a
word
for
him.
I
think
I
thought
it
would
have
said.
I
might
be
completely
wrong
here.
So.
A
Okay,
let's
look
and
see
if
we
can
find
it
further
up
in
the
list
here
and
then
we
can
yeah.
G
A
Right,
okay,
so,
let's
mark
the
do
we
wanna,
which
one
should
be
become
the
I
mean
the
older
one,
has
the
more
context.
E
B
A
Okay,
cool
all
right:
let's
go
back
so
data
volume
resource
disappeared,
I'm
guessing
this
is
maybe
a
garbage
collection.
A
A
A
Okay
is
this:
is
this
publicly
visible?
It
should
be
because
we're
yeah,
okay,
all
right,
so,
let's
keep
it
open
until
the
pr
gets
merged.
A
G
Yeah
I
was
just
suspecting
that
the
volume
snapshot
itself
was
having
issues
oh
yeah
yeah.
That's
that
that
CSI
driver
won't
populate,
restore
size
and
I
think
we
kind
of
rely
on
it.
I
think
in
rightly
so,
I
mean
that's
the
right
thing
to
do,
and
that
provisioner
has
an
open
PR
to
populate
the
restore
size
on
the
snapshot,
but
I
don't
think
it's
accepted.
Yet,
let's
take.
A
So
I
guess
the
question
is:
do
we
feel
that
I
mean
I,
don't
want
to
have
workarounds
in
our
code
for
every
deficiency
and
random
provisioners?
So
do
we
think
that
what
we're
doing
is
the
like?
Do
we
expect
resource
size
restore
size
to
be
populated
correctly,
and
therefore
it's
okay
for
us
to
rely
on
it.
G
A
Okay,
so
yeah,
we
could
just
say
that's
this
is
being
addressed,
or
this
is
a
bug
in
in
this
other
provisioner
and
not
a
CDI
bug
so
closing
the
issue.
We
could
say
it
that
way.
C
E
D
E
A
G
Yeah
I
opened
it
a
while
ago.
Well
doing
the
volume
snapshot,
cloning
and
I
just
hit
it
when
I
was
doing
concurrent
clones.
It's
what
happens.
Is
you
get
a
couple
of
restarts
on
the
Clone
Source
pods
I?
Think
I
I
even
took
the
logs
I
managed
to
grab
some
logs.
It
says
something
like
permission
denied
back
back
at
that
time.
It
couldn't
make
much
sense
of
it,
but
the
issue
still
stands.
A
Okay,
yeah:
it's
because
we
yeah,
we
can't
really
attach
multiple
sources.
Source
pods
to
the
same
PVC.
Is
that
basically,
the
issue.
G
I,
don't
think
so,
I,
don't
think,
there's
a
problem
doing
that
I'm
also
hitting
this
on
one
node
cluster,
so
okay,
so
that
it
should
work
it's
the
scheduling.
Business
is
out
of
scope
for
this
card.
I
put
it
in
another
issue:
okay,.
A
All
right,
so
this
one's
a
real
thing:
it's
gonna
need
some
attention,
so
I
I,
don't
think,
there's
anything
that
we
can
do
in
this
meeting
to
further
Advance
it,
except
for
you
know,
calling
attention
to
it
and
if
somebody
wants
to
look
at
it.
B
So
Alex
the
pr
I
linked
in
the
chat
you
know
I
think
is-
is
related
to
this
at
all.
B
B
Issue
with
single
node,
so
it
probably
doesn't
matter
yeah.
A
Okay,
all
right
so
that
one's
gonna
need
some
more
attention.
Let's
go
to
the
next
one
unify
off
in
a
single
authorized
data
volume.
G
G
C
A
B
Can
you
go
scroll
that
top
box
sideways
a
bit
I
think
so
you
can
see
the
problem
doing
head
request,
URL
unable.
D
D
E
A
I
mean
I
thought
we
were.
Are
we
not
testing
with
fips
enabled
yet.
G
We
do
that
Downstream
and
openshift
virtualization.
This
thing:
okay,.
A
A
It
have
to
do
what
does
it
have
to
do
with
the
the
server
that
we're
going
to
this.
B
E
A
C
G
Isn't
it
weird
that
they
get
an
out
of
memory,
though
not
just.
A
Yeah
I
mean
it's
certainly
possible.
There's
an
NBD
kit
issue
here
to
look
further
into.
Is
there
a
way
that
we
can
what's
what
would
be
the
way
to
to
get
them
to
like
I
forget
if
we
do
like
pre-allocation
equals
true
that
disable
NBD
kid,
because
that
would
be
another
way
to
test.
You
know
if
it's
an
NBD
kit
right
is
there
something
that
they
could
change
their
data
volumes
back
to
specifically
get
rid
of
the
built-in
conversion.
E
B
A
So
that's
part
of
the
direct
like
import
with
with
streaming
conversion
right.
D
B
D
I
think,
if
we
did
no,
it
would
have
to
be
like
gzip
or
rxc
or
XC,
or
something
like
that
would
or
scratch
space.
A
E
D
A
All
right
so
some
follow-up
there
just
to
move
forward
with
it
all
right
and
then,
let's
go
to
looks
like
we
may
have
time
for
one
more
High
availability.
B
Yeah
there's
a
PR
on
this
I
think
it's
still
that's
a
merged.
Yet,
though,
I
think.
D
E
So
I
think
that
distracted
or
something
and
now
it
needs
a
rebase,
so
that'll
be
more
fun.
A
Okay,
all
right,
so
it
seems
that
nothing
specific
we
want
to
do
with
this
yet
I
mean
at
some
point.
We
could
decide
if,
if
it's
a
stale
request
or
something
but
for
now,
I
think
it's
not
that
old.
So
all
right,
let's
jump
into
one
more
CDI
download,
fails
due
to
NBD
kit.
Curl
error,
it's
another
from
the
same
reporter.
A
A
A
Okay,
so
this
is
potential
to
add
some
filters.
A
F
E
There's
a
pi
open
for
154,
but
there's
something
wrong
with
the
build
the
I
haven't
figured
out
yet.
A
A
Okay,
here
we
go
all
right,
and
that
brings
us
to
10
minutes
to
the
top
of
the
hour,
which
is
our
scheduled
end
time.
So
one
last
call
for
any
other
small
things.
If
anybody
wants
to
have
any
topics,
otherwise
we
can
call
it
a
call.