►
From YouTube: SIG - Storage 2023-02-13
Description
Meeting Notes:
https://docs.google.com/document/d/1mqJMjzT1biCpImEvi76DCMZxv-DwxGYLiPRLcR6CWpE/edit#
B
C
C
Basically
yeah,
so
cubert
explicitly
supports
a
field
on
there
resource
for
image,
pull
Secrets
or
you
know
where
you
can
set
references,
a
reference
to
image
a
list
of
secrets
right,
so
you
know
we
can
do
something
similar
and
but
there
are
a
couple,
different
considerations
that
I
put
in
there.
Basically,
first
of
all,
it's
pretty
you
know
you
could
read
the
comment
there,
but
basically
it's
you
know
pretty
very
straightforward.
To
add.
C
If
someone
sets
image
pull
Secrets,
they
add
basically
some
sidecar
containers
to
that
demon
set
that
just
pulls
down
the
image
to
every
node
and
and
then,
as
long
as
you
don't
use.
The
pull
policy-
always
it
should
work
you
know,
so
we
could
do
something
similar
it's
a
little
happier
because
we
don't
have
a
demon
set
already.
So
we
would
have
to
create
something
new,
but
it's
a.
C
C
C
E
C
A
F
Topic,
I
think
there's
an
open
shift
operator
that
basically
like
lets.
You
manage
option
C
and
Michael's
comment
something
like
option
C
but
like
with
wrapping
over
it,
but
I
have
to
dig
it
out.
I,
remember
it
from
from
where
we
had
a
problem
with
with
the
proxy
config
map,
so
I'll
have
to
dig
out
the
name
but
I
think
there's
an
operator
that
makes
this
like
a
nicer
experience.
Option
C
here.
A
A
H
A
C
Yeah,
this
is
actually
new
topic.
Well,
something
we've
been
looking
into.
Basically,
you
know,
convert
is
maturing
and
people
are
starting
to
use
it
in
some
pretty
more
complicated
environments
and
we're
starting
now
to
see
support
or
people
want
support
for
Disaster
Recovery
Solutions
we've
been
looking
into
one
specific
case,
pretty
deeply,
which
is
a
what
we
call
a
Metro
Dr,
which
is
like
you
know,
primary
and
secondary
sites
very
close
to
each
other
synchronous,
replication.
C
C
Came
up
with
a
couple
potential
issues
with
the
with
the
current
implementation
of
data
volumes.
So
the
way
this
specific
case
works
is
that
when
you're,
a
primary
you're
setting
up
the
application,
initially
you
apply.
Some
manifests
in
the
git
Ops
in
the
GitHub.
Repo
I
will
create
a
data
volume
populate
the
data
volume
and
then
that
volume
becomes
replicated
between
a
primary
and
a
secondary
site.
C
When
the
when
you
fail
over,
there
is
going
to
be
a
PV
on
that
secondary
site
that
exists.
That
is
waiting
for
a
new
PVC
to
be
created
for
a
specific
name
that
basically
the
PVCs
from
your
application,
and
what
was
happening
is
that
when
we
failed
over
our
data
volume
controller
was
essentially
binding
to
that
PV
and
rewriting
over
the
data.
C
C
So
what
I'm
proposing,
if
you
go
back
I,
have
an
in-process
PR
to
address
this
data
corruption
issue
and
it's
basically
we're
adding
an
annotation
to
the
data
volume
that
will
well
it's
pretty
much
described
here
that
we'll
basically
check
if
there's
a
statically
provisioned
PV
for
that
data
volume
before
we
before
we
create
the
PVC
and
if
so,
and
we
bind
to
that
PV,
you
know.
That's
it.
C
We
don't
do
any
population,
so
I've
started
it
and
I've
done
it
implemented
it
fully
for
import
the
rest
of
our
sources.
Are
there
so
yeah?
The
idea
is
that
if
you
have
a
data
volume
and
it's
going
to
be
in
one
of
these
replicated
Dr
situations,
you
add
the
sanitation
and
we'll
make
sure
it's
not
stomp
over
your
data.
When
it's
reimported
so
reviews
comments,
there
would
be
great.
A
Yeah
and
I
think
ideally
so.
We've
done
some
deep
diving
into
one
particular
implementation
of
disaster
recovery,
but
I
think
where
we
can
definitely
benefit
as
if
there's
others
who
have
experience
with
other
Disaster
Recovery
Solutions.
It
would
be
interesting
to
to
understand
if
similar
issues
exist
there.
If
different
issues
exist.
A
This
seems
to
be
I
think
the
standard
way
that
you
sort
of
prepare
a
PV
behind
the
scenes
in
a
sort
of
replica
or
a
failover
type
of
situation.
So
hopefully
this
is
the
canonical
way
to
achieve
this,
and
therefore
responding
in
this
way
should
be
a
universal
solution,
but
it
never
is
right.
So
yeah.
C
Yeah
and
to
be
clear,
yeah
I
think
we
definitely
want
to
make
data
volumes
work
in
this
scenario,
but
you
know
we're
going
to
start
working
on
Implement.
You
know
having
PVC
based
Solutions,
you
know
PVCs
with
populators
that
do
the
equivalent
of
our
data
volumes
and,
if
you're,
and
if
your
user,
if
your
application
is
just
dealing
with
ppcs,
there's
nothing
special
you'd
have
to
do
so.
That's
kind
of
the
longer
term
solution
is
to
support
populators
with
data
volumes
populators
and
use
PVCs
directly.
B
I
have
a
question
like
again,
like
very
hundred
thousand
foot
view
question.
So
what
exactly
do
we
hear
like
in
terms
of
disaster
recovery?
So,
let's
say
I
have
a
cluster,
so
we
just
create
a
copy
of
data
somewhere
else
in
a
different
cluster
on
a
different
stories
and
just
restore
from
that.
If
this
primary
storage
in
this
cluster
dies.
C
A
couple
different
types
of
replicated
volume
types-
one
is
actually
they
call
it
a
replicated
volume,
and
this
is
like
synchronous,
replication
for
Metro
Dr.
They
also
support
asynchronous
replication
via
a
project
called
valsync,
which
is
another
red
hat
project
that
asynchronously
syncs
volumes
between
clusters,
but
basically
so
that
keeps
the
ramen
Dr
is
responsible
for
basically
prepping
the
volumes
or
preparing
them
to
be
replicated
setting
up
kind
of
the
lower
either
RAM
and
Dr
the
lower
level
resources
that
allow
for
synchronous
array,
synchronous,
replication
and
on
a
failover.
C
You
kind
of
make
sure
that,
like
the
network,
fencing
is
done
and
then
you
promote
the
secondary
to
primary
in
the
process
of
doing
that.
The
RAM
and
Dr
will
create
any
PVS
statically
and
then
ACM
will
apply
the
manifests
and
any
PVCs
or
data
volumes
in
our
case
should
bind
to
those
PVS
that
RAM
and
Dr
set
up.
E
C
C
We
want
to
disable
garbage
collection
because
that
so,
if,
if
other
people
don't
know
the
most
recent
version
of
I,
guess,
openshift
and
CDI
makes
data
volume,
garbage
collection,
the
default,
and
that
is
not
really
good,
Ops
friendly,
because
if
you
have
a
manifest
that
defines
a
data
volume
explicitly
when
you
go
to
delete
that
manifest,
which
happens
when
you
make
like
a
cluster
not
primary
anymore,
it
will
not
clean
up
everything.
It
will
leave
like
a
data
volume,
PVC
straggling.
A
Yeah,
it
seems
that
Dr
is
really
tied
heavily
to
the
underlying
storage
provider,
because
that's
the
you
know
the
ultimate
place
where
their
replication
is
happening.
So
we
expect
that
there'll
be.
You
know
with,
for
example,
with
like
NetApp
Trident
storage.
They
would
have
presumably
a
way
to
implement
this
with
their
storage.
D
I
have
some
experience
on
that,
for
you
know,
years
and
they're
from
the
desk,
we
are
across
30
data
centers
and
all
the
users
has
a
roaming
profile
across
all
these
180
countries.
We
serve
and
we
have
a
way
to
sync:
the
files
across
all
data
centers
regarding
his
profiles
and
files,
my
documents,
my
video
and
so
far,
but
there
is
no
disaster
recovery
for
the
desktop
itself
when
the
the
the
the
user
go
down,
because
the
entire
region
is
down
he's
able
to
log
into
another
region
with
his
files.
D
A
Yeah,
so
that
sort
of
feels
yeah,
that's.
That
seems
like
a
nice
kind
of
cloud
native
approach
where
you're
able
to
instead
of
relying
on
as
much
saved
State,
you
have
a
small
amount
of
state.
That's
like
configuration
that's
replicated,
but
the
the
data
heavy
portion
can
be
dynamically
recreated
on
demand,
which
seems
like
a
nice
model
as
well.
A
D
D
D
This
was
done
very
well
on
memory,
even
if
he
he
opens
the
file
and
write
something
he's
pushing
back
almost
in
real
time
in
less
than
milliseconds
he
pushing
back
to
the
profile.
He
always
he
can
lose
an
open
file,
but
not
the
content
of
the
openness
file
because
he
saved
in
a
different
state
in
the
S3
storage.
For
you
understand,
let
me
see
if
I
remember
hear
that
the
name
of
the
the
song.
A
C
C
C
No
that
that's
pretty
much
it
so
yeah
those
for
now.
Those
are
the
solutions
that,
for
the
specific
case
that
I've
discussed,
you
know
using
a
couple
annotations
and
yeah
Mark.
If,
like
you
know,
this
is
something
a
topic
we're
all
learning
on.
So
hopefully
I'd
love
to
hear
more
from
the
community
about
other
VR
work.
That's
going
on.
A
D
D
D
They
could
convert
on
top
of
a
lean
store
for
us
and
also
there
is
the
lean
store
CSI
for
you,
efforts
that
use
it
behind
the
scenes
to
to
make
the
the
glue
for
convert
use
this
daily
in
store
these
very
stable
and
in
less
than
in
a
couple
of
milliseconds
I'm
able
to
do
the
clone
of
the
disc,
because
we
do
copy
and
write
and
the
correct
solution
from
from
convert.
It
doesn't
fit
our
needs
for
you
understand,
and
also
the
iops
for
the
storage
for
the
solution.
D
D
D
A
I
I
I
D
A
I
think
an
easy,
short-term
solution,
for
that,
too,
is
probably
something
you're
already
doing,
which
is
well,
maybe
not
quite
but
you're
you're
running
an
environment
with
all
these
components
together
that
you
care
strongly
about.
So
when
you
find
issues
there,
and
hopefully
there's
not
too
much
too
many
unique
issues
related
to
your
storage
config
that
come
up
since
we're
trying
to
be
pretty
storage
agnostic
with
these
components.
But
when
you
do
find
those,
obviously
it's
important
that
this
stuff
works
everywhere.
C
D
A
So
Alex
posted
a
link
here
underneath
the
on
the
agenda
under
your
under
this
copy
and
write
topic
regarding
something
that
he's
working
on
so
for
Seth,
it's
able
to
clone
pretty
much
instantly
from
a
snapshot,
but
the
current
implementation,
that's
already
up
Upstream,
creates
a
snapshot.
Then
clones
from
the
snapshot
then
removes
the
temporary
snapshot.
It's
those
snapshot
operations
that
are
time
consuming.
A
So
if
you
have
a
model
where
you
have
sort
of
a
one-to-many
relationship,
which
sometimes
we
call
a
golden
image,
it
might
be
a
base
operating
system
image
that
you
want
to
create
a
thousand
clones
of
as
you're
spinning
up
new
desktops,
for
example.
In
this
case,
if
you
make
the
Clone
Source
a
snapshot
instead
of
a
PVC,
then
the
Clones
that
happen
from
that
snapshot
on
a
set
system
are
basically
instantaneous.
Yes,
so
we're
having
some
really
good
luck
with
with
that.
D
The
missing
part
there
is
that
the
the
duplication,
only
okay,
because
we
don't
have
a
lot
of
ram
disk
on
each
server.
That's
why
the
duplication
is
also
must
have
we
achieved
that
with
ZFS
on
top
of
of
lean
store
for
you
understand,
okay,
is
there
a
way
to
do
it
over
a
rook
concept
that
the
publication,
because
I
was
aware
only
they
are
on
Alpha
stage
only.
C
H
D
D
C
C
A
Yep,
that's
an
interesting
feature
for
sure.
So
for
those
who
who
do
want
to
use
the
platform
I
think
yeah
anytime.
That,
especially
when
you
have
these
models,
where
you
have
a
lot
of
derivative
volumes
that
come
from
the
same,
you
know
based
operating
system,
there's
a
lot
of
a
lot
of
opportunity.
There
yeah.
D
D
The
latest
is
greatest
and
we
create
an
ISO
file
and
we
we
start
VM,
install
everything
and
now
then,
after
that,
create
the
golden
image,
for
you
understand
completely
automated,
but
this
is
something
that
the
missing
part
in
a
proper
way
is
how
to
after
I
create
the
golden
image,
how
to
replicate
across
all
the
the
Clusters
I.
Have
you
understand
today's?
This
is
a
sink
of
file
and
I.
Think
the
best
way
is
to
have
this
over
the
convert.
Api.
A
Import
cron
API
objects
that
that
we
have
are
not
was
the
principal
developer
in
that
area
and
I
think.
What's
a
natural
choice
is
to
push
the
disk
images
into
a
container
registry,
and
if
you
do
this,
the
data
import,
cron
logic
allows
us
to
check
that
registry
for
updates
periodically
and
then
the
the
updated
image
is
pulled
down
and
we
have
something
called
a
data
source
that
can
be
updated
dynamically.
A
To
then
point
to
the
updated
image
we
can
maintain
a
list
of
a
certain
number
of
previous
images.
Garbage
collect
the
old
ones,
and
so
this
feature
is
really
nice,
because
when
you
set
up
your
virtual
machines
to
clone
from
the
data
volume,
that's
managed
by
a
data.
Import.
Cron
object,
then,
essentially
your
automation
that
updates
the
VM
disk
images.
A
So
then,
that,
essentially
you
have
a
a
private
registry
or
a
registry,
that's
accessible
to
all
your
clusters
that
you
push
your
your
base,
images
into
from
CI
CD
and
then
what
ends
up
happening
is
each
of
these
clusters
will
recognize
the
updated
image,
pull
the
image
down
to
the
cluster
locally
and
store
it
into
a
PVC
where
it
can
be
instantly
cloned
in
the
future.
So.
A
Yeah
so
I
would
I
would
definitely
encourage
you
to
take
a
look
at
the
at
the
documentation
inside
of
the
CDI
repo
and
our
non.
Maybe
could
dig
up
the
link
or
something
to
help
out,
maybe
popping
that
into
this
agenda
for
people
who
might
be
viewing
the
recording
and
then
I
would
just
take
a
look
at
that
stuff.
D
A
All
right,
so
if
there
are
not
any
other
additional
topics,
I
think
it
was
suggested
last
time
that
we
just
take
a
look
at
the
the
issue
list.
I'm,
not
exactly
sure
you
know
what
order
to
go
in,
but
just
kind
of
trying
to
make
sure
that
we
don't
let
any
of
these
issues
Wither
on
the
vine,
so
I
don't
know.
Is
there
a
suggestion?
Do
we
want
to
start
with
the
oldest
ones.
C
A
A
A
I
C
C
C
C
Step,
oh,
if
you
go
back
up
actually
there's
an
interesting
thing
there.
So
it
looks
like
Ingress
engine
X
log.
If
you
scroll
up
so
it
looks
like
so.
It
looks
like
the
upload
proxy
is
being
exported
via
Ingress,
an
Ingress
controller,
and
you
know
there
can
be
all
sorts
of
connection
handling
issues.
So
I
wonder
the
proxy
could
be
like
detecting
an
idle
connection
and
closing
it
something
like
that,
because
once
the
image
is
uploaded,
then
we
do
the
conversion
phase
and
the
client
is
still
connected.
A
I
C
I
I
C
F
E
E
A
E
B
E
A
A
G
E
A
A
G
Yeah
I
mean
that's.
This
is
very
true,
so
it
is
very
hard
to
resize
a
a
disk
image
reliably
and
the
way
that
resize
works.
Is
it
literally
won't?
Let
you
sort
of
in
place
resize,
partly
to
force
you
to
keep
a
backup
and
just
partly
because
of
the
way
it
works.
You
can't,
for
example,
move
partitions
around
safely,
so
it
always
copies
into
a
new
PB
and
that's
probably
the
reason
why
it
was
suggested.
But
then
the
leache
says
it's
probably
the
reason
why
it
was
suggested,
but
then
rejected.
C
C
I
think
I
opened
an
issue
in
library
go
anyway.
Basically
there
are
some
functions
of
using
Library
go
but
they're,
not
public
and
I
just
made
them
public.
In
my
Fork,
that's
really
the
only
difference.
I
think
I
submitted
an
important
issue
or
or
click
on
that
open
shift.
Library
go
540,
nope
right,
yeah,
see.
What's
going
on
there.
C
A
A
I
G
A
Okay:
let's
try
that
all
right,
so
I
think
that
is
good.
What
I'm
going
to
do
is
I'm
going
to
make
a
placeholder,
so
I
think
we
would
be
on
this
issue
next,
so
I'm
just
going
to
make
a
note
of
that,
and
we
can
just
continue
to
work
our
way
up.
Luckily,
we
we
aren't
super
unhygienic
with
respect
to
issues,
as
we
only
have
these
two
pages,
but
it'd
be
nice
to
get
through
them.