►
From YouTube: CNCF SIG Storage 2020-12-09 (1 of 2)
Description
CNCF SIG Storage 2020-12-09 (1 of 2)
A
A
A
A
A
B
A
A
A
All
right,
let's
get
going,
we
can
catch
up
people
from
the
recording
later
on.
So
before
we
before
we
start
on
the
first
item
in
on
the
agenda,
I
wanted
to
share
an
idea
that
that
luis
and
I
had
well
actually-
it
was
mostly
luiz's
idea,
but
I
wanted
to
share
an
idea
that
or
a
proposal
even
about
some
of
the
formats
of
the
sick,
calls
going
forward.
So
we
wanted
to.
We
wanted
to
change
around
some
of
the
topics.
A
Today
we
have
two
meetings
a
month
and
and
often
we've
we've
ended
up
having
just
a
single
meeting
a
month,
because
project
activity
or
or
project
reviews
have
been
have
been
slower
than
what's
needed
for
two
meetings.
So
what
we?
What
we
were
thinking
was
one
way
of
revitalizing
the
sick
and
and
making
it
more
productive
for
the
community
is
to
have
a
session
a
month.
So
maybe
the
the
first
first
meeting
every
month
could
be
focused
on
an
information
session.
A
C
B
A
A
So
the
the
other
agenda
item
we
had
we
had
today
was
something
that
was
proposed
by
rafaela,
who
is
who
is
on
the
scroll
and
he
was
interested
in
discussing
aspects
of
disaster
recovery
and
how
they
relate
to
cloud
native
environments
and
cloud
native
storage
and
potentially
with
a
proposal
to
to
either
create
a
working
group
to
create
some
content
around
this
or
or
perhaps
to
to
you
know.
Perhaps
we
could.
A
A
D
Now
I
think
you
summarized
it
well.
My
my
question
to
this
forum
is,
if
you
guys,
are
interested
in
discussing
dr
and
creating
guidance
for
storage.
You
know
storage,
software
and
stateful
in
general,
also
stateful
middleware,
since
I
think
there
is
a
lot
of
you
know:
common
concerns
between
storage
and
and
and
state
for
middleware.
D
In
a
container
native
world,
so
in
a
kubernetes
world,
probably
more
specifically-
and
I'm
proposing
this-
because
what
I
see
with
my
customers-
which
you
know
I
I
work
for
a
dad-
I
am
a
consultant-
I'm
an
architect,
but
I
work
in
consulting.
I
work
with
anything
between
three
and
five
customers
at
having
given
time.
So
I
don't
have
a
big
you
know
sample,
but
but
my
sample
is
constantly
varying
and
I
see
always
the
same
thing,
which
is
people
are
trying
to
design
disaster
recovery.
D
People
are
getting
to
the
point
where
they
don't
on
board
status
applications
only
anymore,
and
we
are
getting
to
the
point
where
there
is
interest
for
stateful.
So
there
is
interest
for
databases
and
message
queue
systems,
but
they
are
designing
and,
of
course,
the
disaster
recovery
conversation
comes
up
immediately.
Once
you
have
state
once
you
have
a
state
to
manage,
but
but
what
people
tend
to
do
is
to
design
disaster
recovery
strategy,
as
you
would
design
it.
For
you
know
the
traditional
traditional
data
centers
or
traditional
I.t
with
essentially
active
passive.
D
You
know
deployments
and
human
decision
to
decide.
Okay,
there
is
a
disaster.
We
have
to
flip
the
traffic
we
have
to
flip
the
whoever
is
the
master
and
this
kind
of
thing,
whereas
I
think
the
the
technology
now
allows
to
do
much
more
and
allows
to
create
autonomous
systems
which
can
detect
disaster
and
treat
disaster.
Essentially,
like
an
aha
event,
where
you
know
the
the
event
is
autonomously
managed
traffic
is
is
is
moved
where,
where
there
is
an
active,
you
know
there
is
a
working
side.
D
D
There
is
not
a
lot
of
knowledge
about
the
cap
theorem,
which,
which
is
what
ma
you
know,
essentially
drives
all
of
these
conversations,
and-
and
there
is
not
a
lot
of
knowledge
about
the
middleware
that
are
designed
around
the
cap,
theorem
versus
middle
products
that
are
of
a
previous
generation,
and
you
really
cannot
be
used
to
build
this
kind
of
systems.
So
people
does
not
do
not
even
make
this;
they
are
not
capable
of
making
this
discussion
distinction
that
it's
very
difficult
for
them
to.
D
I
have
this
conversation,
and
I
you
know
I
have,
as
you
can
see
right
there
when
I
went
to
school
when
I
went
to
the
university,
the
cap
theorem
was
not
had
not
been
discovered.
We
didn't
learn
these
things
there,
so
unless
you,
unless
you
actually
proactively,
try
to
study
these
things,
it's
difficult
to
to
understand
the
big
change
that
has
happened
in
the
meantime
and
and
the
new
options.
So
I
think
if,
if
all
of
this
information
was
to
come
from
a
community
like
this,
you
know
a
committee
like
like
this.
D
B
D
I'm
obviously
I'm
pushing
this
in
my
in
my
own
day
by
day
work
and
I
can
already
share
what
is
the
what
is
hard
about
adopting
this.
There
are
two
things
that
are
hard.
Besides
having
the
conversation
in
the
right
way
with
people.
You
know
you
have
to
do
a
lot
of
education,
but
there
are
two
things
that
are
hard
one
is
you
cannot
build
these
architectures
with
two
data
centers,
you
need
three
data
centers
and
most
of
the
customers
have
only
two
data
centers.
D
We
need
three
because
of
the
leader
election.
You
know
quorum
issue,
but
so
so
there
needs
to
be
guidance
on
how
to
build
a
third
data
center,
possibly
in
the
cloud.
So
so
that's
a
probably
one
of
the
highest
expression
of
hybrid
cloud
that
we
always
hear
about
right.
Maybe
you
have
two
data
centers
on
prem
and
then
the
third
is
is
on
the
cloud
and
that's
how
you
you
do
zero
downtime,
dr.
D
D
C
C
I
think
if
you
took
dr
and
described
what
it
is
and
describe
what
it
entails
and
describes
the
benefits
of
dr
as
a
whole
right
that
I
feel
fits
the
cncf,
the
storage
landscape
document,
better
the
actual
instruction
of
how
to
set
up
dr
and
how
to
do
things.
That
sounds
more
to
me
like
a
kubernetes,
sig
storage
thing
or
a
or
something
that
is
part
of
the
kubernetes
group
right,
because
again,
this
is
just
my
opinion,
but
the
cncf
is
it's
separated
from
kubernetes
right
now,.
B
C
More
about
concepts
and
instruction
and
more
about
so,
if
you
want
to
bring
one
of
the
things
I've
been
thinking
about,
is
creating
a
multi-cluster
ins
definition
of
what
it
means
to
have
multi-cluster
right
now
that
we
have
a
lot
of
multi-cluster
kubernetes
systems
out
there
like
anthos
tanzu,
the
one
from
amazon
arc
and
so
on.
They
require
dr
as
for
example.
So
if
there
was
a
multi-cluster
paper
that
this
graduate
wanted
cluster
means
and
what
it
means
to
have.
Dr
in
that
concept,
then
that's
definitely.
C
D
Okay,
thanks.
Thank
you
for
this.
Maybe
I
didn't
use
the
rewards
we
can.
We
can
actually
remove
kubernetes
completely
from
the
conversation,
because
this
is
really
an
intrinsic
property
of
stateful
workloads.
It
doesn't
have
it
does
all
the
consideration
apply,
whether
you
deploy
it
in
kubernetes
or
or
in,
but
all
the
configuration
all
the
considerations
apply.
With
regard
to
the
what
I
said,
the
quorum,
the
data
centers.
All
of
that
perfect,
so
yeah
we
can
keep
it
absolutely
general
if.
B
C
B
I
think
it's
a
fantastic
topic.
I
think
it's
arguably
the
general
topic,
because
this
is
not
actually
specifically
about
disaster
recovery.
It's
more
about
handling
handling
failures
in
in
storage
scenarios
and
disaster
recovery
is
kind
of
one
one
flavor
of
failure.
I
guess
I
think
this
absolutely
gets
to
the
heart
of
cloud
native
storage.
B
I
mean
there
are
other
aspects
as
well
like
scalability,
but
but
I
think
this
is
a
great
topic
and
I
think
it's,
as
you
pointed
out
a
very
misunderstood
topic
and
I
think
it'd
be
a
fantastic
topic
discussion.
Were
you
proposing
to
do
that
today
or
were
you
proposing
to
have
a
separate
discussion
or
presentation
or
a
working
group?
Or
what
was
your
thing.
D
D
D
It
could
be
an
extension
of
the
current
paper
or
it
could
be
a
separate
paper,
but
something
like
that
because
I
don't
think
this
lends
itself
to
a
video
or
something
short
this
this
it's
a
complex,
it's
a
complex
topic
and
we
need,
I
think
we
need
to
have
the
right
medium
is
to
start
with
a
document.
In
my
opinion,
then
we
can
simplify
and
we
can
extract.
D
You
know,
maybe
shorter
in
immediate
messages,
but
to
begin
with,
we
should
we,
I
I
suggest
a
paper.
So
maybe
then,
if,
if
we
agree,
you
know,
if
we
agree,
then
maybe
the
next
step
is
to
create
a
working
group
to
start
drafting
this
paper.
I
have,
I
have
already
written
a
lot
in
this
space,
so
there
are
some
things
that
we
can
probably
reuse,
but
my
my
articles
are
about
doing
these
things
in
upshift,
so
we
can.
D
B
I
think
using
what
you
have
as
a
starting
point
would
be
great,
maybe
maybe
reviewing
that
one
yeah
either
either
do
a
sort
of
a
presentation
to
the
group
to
just
give
them
an
overview
of
what
you've
already
done
and
then
use
that
as
context
for
starting
the
paper
would
be
one
approach.
Yeah,
I'm
very
supportive
of
this,
as
you
can
probably
hear.
A
A
C
C
Because
again,
I
just
feel
that
we
are
in
this
point
in
the
market,
where
there's
a
lot
of
a
methods
of
how
to
do
and
expand
your
specific
kubernetes,
but
your
clusters
across
regions
right
and
very
easily
and
how
that
deals
with
data
movement.
If
one
of
those
clusters
die
and
you
have
to
move
to
another-
which
is
dr
right
and
what
that
means
to
application
data
right-
and
I
think
that's
something
if
we
attack
multi-cluster
and
bring
dr
as
part
of
it.
C
D
D
Luis
that
that
we
should
focus
on
storage
and
not
assume
that
we
are
even
running
in
a
cluster,
because
these
are
really
is
a
is
a
topic
of
is
an
intrinsic
property
of
stateful,
whether
it's
stateful
store
and
statement
middleware,
and
so
we
can
say
instead
of
talking
about
multi-class,
that
we
can
say
we
can
talk
about
a
failure
domain
and
you
know
so
that
could
map
to
a
data
center,
it
could
map
to
a
cluster.
It
doesn't
matter
at
that
point.
We
are
much
more
abstract
around
the
underlying
implementation.
D
What
matters
is
the
behavior
of
this
of
the
state
for
middleware
relative
to
the
failure
domains
or
what
the
failure
domain
does
yeah,
and
so
I
would
focus
on
that
and
then
I
would
and
then
we
can
have
some
pointers
to
work
that
other,
maybe
other
sticks
are
doing
on
multi-cluster
and
say
for
for
this
to
work
in
a
kubernetes,
multi-cluster
environment.
This
is
these
are
the
capabilities
that
we
need
right
and
I
in
my
documents
I
have
a
good.
I
think,
identification
of
what
these
capabilities
are,
but
we
don't.
D
B
I
totally
agree
I
would.
I
would
caution
against
us
creating
the
wrong
impression
that
we're
somehow
doing
multi-cluster
stuff,
because
there
is
already
a
bunch
of
multi-cluster
efforts
and
much
broaderness.
So
so
what
I
do
think
we
will
need
to
do
is
is
definitely
speak
to
the
multicustom
people.
I
know
there's
a
sig
in
sick
in
the
kubernetes
world
that
I
used
to
run
for
a
long
time
long
ago,
and
I
wouldn't
be
surprised
if
there's
something
similar
in
the
cncf
sig
yeah.
B
B
The
other
one
is
this
term
disaster
recovery.
I
I'm
a
bit
of
a
stickler
for
names,
because
sometimes
they
kind
of
stick
and
then
they
get
they
take
on
a
life
of
their
own.
I'm
not
sure
that
what
you're
proposing
is
actually
what
people
understand
by
disaster
recovery.
I
think
disaster
recovery
and
correct
me
if
I'm
wrong.
You
probably
know
a
lot
more
than
this
about
this
than
I
do,
but
but
disaster
recovery
tends
to
be
associated
with
the
old-school
way
of
doing
this
stuff.
D
That's
fine
yeah.
I
have
my
definition
of
disaster
recovery,
but
I
don't
know
if
it's
a
shared
definition
or
not.
For
me
it's
what
you
do
when
you
lose
a
data
center
right
and
so
what
you
what
you
said.
Those
are
disaster,
recovery
strategies
and
order
are
those
are
the
traditional
ones
and
there
are
the
ones,
and
those
are
the
kind
of
thinking
that
we
need
to
change,
but
yeah
you
can
still
lose
it
at
the
center
today,
so
that
event
can
still
happen.