►
From YouTube: CNCF SIG Storage 2021-02-10
Description
CNCF SIG Storage 2021-02-10
A
A
A
Okay,
I
think
we
should
we
should
start.
Today
we
have
two
main
items
on
the
agenda.
A
The
project
fine
yards
team
are
going
to
follow
up
from
the
presentation
that
they
that
they
gave
us
at
the
last
meeting
with
with
a
quick
demo
and
then
we'll
move
on
to
to
further
technical
discussion
of
rafaeles.
A
Dr
document,
which
has
been
coming
along
nicely
so
with
that
I'll
hand
over
to
the
alibaba
team
for
project
vineyard
demo,.
B
Thank
you
alex
hello,
everyone.
My
name
is
leon
yoo
and
I'm
from
alibaba
dharma
academy,
and
today
my
colleague,
andy
and
tao,
and
I
are
going
to
demonstrate
our
system
as
a
follow-up
of
last
presentation.
B
And
it
has
a
shared
screen.
Yeah,
why
are
linearly?
Is
a
in-memory,
multiple
data
manager
that
provide
out-of-the-box,
high-level
abstraction
and
zero
copy,
in-memory
sharing
for
distributed
data
in
big
data
tasks,
and
if,
if
you
I
want
to
know
more
technical
details,
you
can
refer
to
our
rapport.
Also,
you
can
look
at
the
dax
of
the
last
since
last
thing
meeting
and
I
will
first
introduce
a
big
data
task.
B
We
are
going
to
demo
and
then
I
will
hand
hand
the
microphone
to
my
colleague
andy,
and
he
will
then
go
through
the
other
running
back
on
combinations
and
as
well.
Okay,
the
task
we
focus
on
it's
like
it's
a
simplified
version
of
what
we
do
in
alibaba
is
for
fraud
detection.
B
Currently
a
fraud
transaction
indicates
a
customer
deceptively
purchased.
An
item
hoped
hoping
for
to
inflate
the
rating
of
the
item
and
in
the
demo
example,
we
used
pandas
and
mars
for
distributed
processing
to
prepare
the
dataset
and
then
use
python
to
trim
from
translating
classifier,
and
we
integrate
one
out
of
its
these
two
systems.
B
The
data
we
used
actually
from
a
few
series
base,
typically
one
on
an
application
built
on
top
designed
for
handle
large
data,
but
today,
for
demo
purposes,
we
will
just
always
use
the
small
data
just
to
speed
up
the
the
process,
but
you
can
imagine
those
kind
of
data
can
live
in
hdfs
or
something
the
schema
of
the
data
is
like.
The
follows:
like
item
is
something
like
items
listed
in
e-commerce
websites
like
amazon
or
alibaba.
B
B
The
first
two
columns
are
the
user
ids
and
item
ids
and
the
third
column
is
a
label
like
used
to
indicate
whether
this
transaction
we
have
labeled
as
a
fraud
or
not.
We
use
this
label
for
training
and
followed
up
by
a
few
like
transaction
features
like
for
the
actual
classification
we
we
actually,
we
we
joined
those
two
two
to
three
tables
together
to
to
have
a
very
wide
lots
of
attribute
lots
of
features
table
for
transactions.
B
Let's
look
at
the
data.
Sorry,
the
code
like
a
a
simple
like
one
single
machine
version
is
using
behind
us.
We
use
banners
to
load
data
from
sas
waste
and
load
them
as
a
data
frame
as
appendix
data
frames,
and
we
do
us
using
a
join
like
to
to
expand
to
get
a
new
data
frame
and
it's
called
data
set,
and
then
they
like
yeah
combine
features
is
to
do
this
and
then
we
can
go.
Can
you
can
you
scroll
down?
Please.
B
Yeah
and
then
we
we
sorry,
oh
okay,
we
use
the
make
data
sets
to
to
the
function,
to
like
to
convert
those
pandas
data
frame
to
num
high
and
to
be
a
a
a
high
torch
tensor
data
set,
and
then
we
import
pi
torch
and
it's
a
just,
a
simple
like
one
layer
in
for
classification:
okay,
it's
to
taking
taking
input
and
taking
the
data
as
input,
but
what,
if
those
data
sets,
are
large
like?
Let's
just
imagine
those
sets-
these
are
too
large
to
be
handled
on
a
single
machine.
B
We
need
to
do
the
distributed
processing.
In
this
case
we
use
mars.
It's
also
a
project
from
alibaba.
It's
you
can
think
it
has
a
parallel
or
distributed
numpy
appenders
and
the
scikit
cycle
learn
package.
Okay,
let's
go
back
to
the
code,
it's
the
code
itself.
It
looks
pretty
like
similar
to
the
version
in
pandas.
You
see,
but
there
are
a
few
notable
differences.
B
First,
like
the
data
frame.
Here
is
a
mars
data
frame.
Here
it
is
different
from
the
pandas
data
frame
here.
B
Tmrs
will
slice
the
the
extra
data
frame
into
multiple
chunks
and
this
distributed
results
into
material
nodes
and
machines,
and
you
can
see
why
yard
provides
the
I
o
ability
for
mars
because
like
for
for
iron-
and
it
not
only
supports
the
local
data
I
o,
but
also
supports,
like
I
o
from
remote
hdfs
and
various
like
data
sources
and
the
forty
those
that
come
the
actual
drawings
like,
let's
see
the
the
like
andy,
can
you
select
the
yeah
for
the
acne
joints,
it's
quite
similar
to
the
pandas,
and
I
accept
that
for
mars.
B
It's
actually
like
the
job
actually.
B
Frame
download
the
joints
of
those
chunks
and
reshuffle
the
data
if
necessary,
and
for
for
this
part
we
we
only
like
taking
care
of
the
precision
and,
in
this
script,
we're
only
taking
part
taking
care
of
the
preset
pre-processing
part.
We
we
just
output
a
one-yard
object
as
a
global
data
frame.
We
will
like
go
back
to
the
python
part
later.
C
Thank
you,
william,
and
thanks
tau
for
for
the
code
demo.
Okay,
now,
let's
first
check
the
our
environment.
Here
we
have
a
kubernetes
cluster
with
eight
nodes
and
there
is
no
pods
running
now
we
install
wired
with
helm.
C
Then
we
run
mars.
Now,
oh
okay,
while
it's
now
running
as
a
demon
set
on
the
kubernetes
cluster
okay,
now
we
can
run
mass
now.
C
C
C
193
now
we
check
the
the
parts
we
can
see
that
the
the
wired
port
on
node
192
is.
Is
this
one,
so
we
log
in
this
one
other
part
to
to
to
get
a
chunk
to
to
see
how
exactly
the
chunk
looks
like
we
first
import
the
wire,
then
we
establish
a
client
client
connecting
to
the
ipc
socket
of
wyatt.
C
Then
we
can
get
the
chunk.
We
will
choose
a
chunk
lying
on
the
two
note:
okay,
now
we
get
the
chunk.
Actually,
the
chunk
data
is
mapped
from
the
one
of
the
process
to
the
python
process,
with
shared
memory
in
a
zero
copy
fashion
and
the
chunk
data
is
automatically
resolved
into
a
pandas
data
frame,
since
we
already
registered
the
pandas
data
frame
reservoir
to
myart
for
the
detail
about
memory,
mapping
and
the
resolver
registration
mechanism.
C
Please
refer
to
the
one
document,
and
now
we
try
to
get
another
chunk
that
is
not
located
on
1i2,
for
example,
this
one
okay.
C
Now
we
find
that
we
we
can't
get
get
that
chunk.
This
means
that
when
we
try
to
get
the
chunks
from
one
other,
we
we
can
only
get
the
local
chunks.
C
Now,
let's
look
at
the
pie
touch
code.
That
will
be
the
next
step.
We
are
going
to
run
okay
compared
with
the
single
machine
version.
The
make
data
set
from
wired
is
a
is
a
different
here.
Okay,
here
we
we
have
to
first
connect
to
the
wi-fi
ipc
socket
and
get
all
the
local
chunks,
and
we
can
concatenate
these
chunks
into
a
merged
data
frame.
Then
then,
the
rest
part
are
just
the
same
as
the
single
machine
version.
Okay.
C
So
when
we
deploy
the
python
port
on
kubernetes,
what
if
the
ports
are
scheduled
to
the
nodes
that
doesn't
have
any
chunk
chunk
of
data,
then
then
the
python
can't
get
any
data
from
wired.
So
let's
look
at
the
stateful
set
yamo
of
of
our
pod
job
of
our
python's.
C
C
Okay,
let
me
find
it:
okay,.
F
G
Minutes,
can
I
ask
a
question
while
we're
waiting?
Okay,
andy,
can
you
can
you
describe
the
the
your
memory
allocation,
how
that's
going
on
and
you
know
what
what
kind
of
rules
you're
using
and
and
how
the
the
memory
that
global
memory
is
getting
allocated
and
and
decided.
If
there's
enough
to
do
the
application
and
things
like
that.
C
Okay,
here
and
currently,
we
didn't
have
very
specific,
sophisticated
strategy
in
and
now,
if
the,
if
the
memory
is
not
enough,
when
we
create
the
the
object
we
will,
we
will
return
the
the
the
message
to
the
client
to
tell
them
that
the
memory
is
not
enough.
G
G
B
Yeah,
let
me
like
share
a
bit
more
on
this.
Actually,
we
with
the
helm
like
we
need
to
specific
specify
how
much
memory
can
we
are
used
like
in
the
helm,
the
command
and
after
layout
is
deployed
and
the
the
memory
like
consumed
by
wire
is
fixed.
It's
not
no
larger
than
eight
gigabytes
in
our
demo
case,
but
you
can
specify
the
launcher
demon
set
of
wire
like
how
much
memory
you
want
montmartre.
B
B
Yeah
yeah,
you
can,
you
can
show
us
the
the
spec,
the
the
the
stateful
set
yamo.
B
C
Okay,
so
so
I
I
just
described
the
the
case
that,
when,
when
the
pod
is,
is
not
scheduled
to
the
to
the
place,
the
that
the
the
chunks
are
located.
In
this
case
we
will
add
the
the
wired
migration
to
the
init
container,
and
this
is
a
a
function
provided
by
wired
to
to
migrate
the
data
chunks
when,
when
the
chunks
are
not
located
at
the
same
node
as
the
pod,
okay.
So
now
now,
let's
run
the
pythos.
C
C
Id
okay:
now
we
check
the
pod.
C
We
can
see
that
these
two
pi
touch
pods
are
scheduled
to
node
one
eight,
eight
and
one
eight
seven.
They
are
not
the
same
node
as
the
chunks
are
located.
They
are
192
and
193.
So,
let's
check
the
logs
of
the
worker
0.
C
C
G
A
Just
just
a
quick
question
there
so
so
effectively
you
have
a
set
of
source
data
which
then
gets
sharded
across.
You
know
a
number
of
nodes,
and
then
you
can
start
your
your
workload
that
consumes
that
data
on
any
node
within
the
cluster,
and
it
will
pull
the
relevant
segments
to
the
node
where
the,
where
the,
where
the
job
is
running
right.
H
I
have
a
question
about
the
design.
Why
did
you
decide
to
have
an
explicit
step
to
pull
the
relevant
shards
as
opposed
to
maybe
just
let
the
client
in
this
case
the
python
application
say
I
want
this
global
shard
and
have
the
in
the
vineyard
locate
the
the
you
know
they
needed
and
do
the
migration
on
demand
instead,
you're
doing
an
explicit,
you
know
any
container
step
to
do
the
shard
migration
or
replication.
B
I
I
can't
explain,
because,
like
those
kind
of
cancer
needs
to
be
like
in
our
case,
that
cancer
need
to
be
like
used
immediately
after
the
the
this
process
was
launched,
just
just
because
the
case
we
first,
we
need
to
convert
those
like
data
frames
to
tensors
and
we
need
to
get
all
the
data
frames.
At
least
a
chunk.
The
whole
chunk
to
get
the
job
started.
B
We
have
a
mechanism
for
pipelining
like
using
streams
like
environment.
We
didn't
demo
today.
In
that
way,
we
can
do
some
pipelining,
like
the
streams,
are
just
chunk
streams
you
can
like
consume
chunk
after
chunk
chunk
and
a
sequence
of
chunks,
you
can
consume
a
chunk
at
a
time
and
we
can
organize
that
as
extreme,
so
we
can
only
migrate
one
chunk
at
a
time,
and
in
that
case,
so
yeah
yeah,
just
just
the
data.
B
E
Just
a
quick
question-
and
I'm
learning
from
this
is
that
would
it
be
the
data
frames
are
on
certain
nodes?
Is
that
correct?
Yes,
okay
and
then,
as
the
application
consumes
them
the
python
application,
would
it
be
a
beneficiary
to
have
the
python
application
hint
in
the
pod
specification?
C
Okay:
okay,
thanks,
okay,
so
this
new
global
data
frame
it
it
has
chunks
located
as
at
192
and
103
as
well.
Okay,
now
this
time
before
we
run
pi
touch,
we
first
installed
the
scheduled
plug-in
to
to
kubernetes
okay,
yeah.
C
Okay
later
we
will
inspect
the
logs
from
this
scheduled
product
in
to
to
see
how
we
schedule
the
part.
Okay.
Now,
let's
go
back
to
the
state
state
force,
34
set
yamo.
C
C
So
actually,
when,
when
the
scheduler
is,
is
trying
to
schedule
the
port,
it
will
first
get
get
the
one
object,
id
form
from
the
that
that
spec
and
then
it
since
we
are
using
stateful
set
each
pod-
will
has
a
rank
based
on
the
rank
and
the
object
id
the
scheduler
can
understand
which
chunks
are
required
by
that
port.
Then
it
will
inspect
the
location
info
from
the
crds
to
know
which
node
has
that
chunks.
C
C
C
Objects
and-
and
there
is
no
replicated
local
objects,
because
there
is
no
data.
Migration
happens.
So
here
the
here,
the
the
data
migration
and
the
schedule
plug-in
is
just
one
of
the
functionalities
provided
by
wyatt
in
kubernetes,
and
we
want
to
integrate
the
ability
of
kubernetes
in
to
achieve
advanced
functions
like
check,
pointing
photo
recovery
and
so
on.
We
hope
we
can
build
a
new
cloud-native
way
of
building
and
running
big
data
applications
on
kubernetes
thanks.
A
This
this
was
this
was
really
this
was
really
informative.
It
really
helped
me
visualize
a
bit
more
how
how
fine
art
works
and
some
of
the
architecture,
because
I
think
it's
it's
a
complicated
concept.
J
B
You
mean
about
this
box,
oh
yeah,
oh,
it's,
it's
quite
different.
Actually,
the
one
wireless
like
interface
is
very
low
level.
B
It's
actually
the
shared
memory
it
you
can
use
all
kinds
of
like
the
language
of
your
choice
and
the
the
runtime,
the
the
execution
model,
your
choice
to
like
build
applica
big
data
applications
on
top
of
ir,
like
you
can
use
a
data
flow
like
spark
or
you
can
use
mpi
jobs
or
you
can
openmp
parallel
computation
or
you
can
even
use
some
single
machine
algorithms
like
so
you
can
choose
everything,
but
the
fourth
spark
is
actually
it
has
a
fixed
like
a
a
fixed
programming
model
and
a
fixed,
like
communication
model,
a
fixed
running
mode.
B
A
Just
to
summarize
that,
therefore,
am
I
getting
this
right.
Would
it
be
fair
to
say
that
that
fine
yard
is
is
almost
like
an
in-memory
kind
of
mapreduce
capability
which
can
plug
into
multiple
so
multiple
apps?
Can
it
be
accessing
that
same
those
same
shared
memory,
chunks
in
in
in
parallel,
when
you
have
a
multi-step
pipeline
for
your
for
your
analytics,
for
example,.
B
Yeah
yeah
that's
correct,
but
basically.
J
B
J
B
Yeah,
the
flexibility
is
what
we
aim
for
like,
for
example,
there
are
some
hpc
tasks
using
mpi
like
you
built.
The
application
itself
is
an
mpi
job.
That's
like
you,
it's
very
hard
to
like
migrate
that
job
into
like
the
a
spark
pipeline
like
but
get
rid
of
dvm
completely.
It's
it's
very
hard,
so
the
wire
basically
doesn't
provide
any
computation
support.
You
choose
your
way
of
communication.
You
can
use
rdma,
you
can
use
some
magical
tunnel.
You
can
use
your
the
common
tcp
socket.
B
It's
your
call.
You
doesn't
enforce
any
like
execution
model,
for
example.
If
you
want
to
run
on
tpu,
it's
fine,
it's
your
call,
it's
it!
So
basically,
why
are
just
memory?
Storage
engine
like
can
provide
a
cross
process
like
memory
sharing.
A
Did
anybody
else
have
any
other
questions
for
the
team.
D
B
Okay,
thank
you.
Thank
you
eric
we.
We
would
like
to
submit
our
project
as
sandbox
as
we
mentioned
in
the
last
meeting,
and
we
are
wondering,
if
is
there
any
way
we
can
like
have
feedback
from
the
the
sig
storage
community
in
some
form,
I'm
not
sure
whether
that's
unnecessary
but
yeah.
We
really
want
some
feedback
here.
A
So
it's
I
think,
amy's
on
the
or
I'm
not
sure
if
amy's
still
here,
actually
she
might
have
dropped
off.
So
so,
strictly
speaking,
a
sig
recommendation
isn't
needed
for
the
for
the
for
sandbox
submission.
But
what
what
we
can
do
is
we
can
provide.
A
You
know
a
little
a
little
snippet
of
of
of
a
comment
to
kind
of
say
that
you
have
presented
and-
and
we
think
it's
interesting
and
it's
worth
going
into
sandbox
and
also
provides
a
recording
of
the
of
the
sig
meeting,
which
you
can
use
in
your
in
your
sandbox
submission,
because
the
sandbox
submission
is
just
it's
just
effectively
a
a
form
that
you
fill
in
and
then
the
toc
review
it
at
the
their
next
meeting.
A
The
the
next
thing
we
had
for
on
the
agenda
was
to
follow
up
the
discussion
around
the
the
disaster
recovery
document
that
that
rafaela
has
been
focusing
on
and
contributing
just
so
that
everybody
is
on
the
same
page.
I
will.
A
So
we
we
could,
we
could
definitely
do
with
more
feedback
and-
and
you
know,
comments
as
we
as
we
continue
to
refine
and
and
and
bring
more
ideas
into
the
documents.
A
A
We
had
a
discussion
about
documenting
more
clearly,
some
of
the
you
know
some
of
the
advantages
of
of
cloud-native
disaster
recovery
as
a
as
a
as
a
general
concept,
in
terms
of,
for
example,
having
standardized
versions
of
all
of
the
software
in
the
kubernetes
clusters,
by
virtue
of
the
fact
that
you
know
everything's,
containerized
and
standardized
versions
of
deployments
and
configuration
through
the
use
of
you
know,
yaml
and
being
able
to
have
declarative
and
composable
application,
deployment
and
storage.
A
And
you
know
that's
that
kind
of
leads
to
a
number
of
advantages
that
we
saw.
So,
for
example,
you
know
it
dramatically
simplifies
testing,
failover
and
dr
processes.
It
it
dramatically
simplifies
keeping
multiple
clusters
in
sync,
because
you
know
they're
all
built
on
the
same
config,
so
rafael
did
have.
I
captured
that
thought
process.
Was
there
anything
else
that
we
in
relation
to
that.
A
A
D
A
D
A
With
perhaps
their
customers
or
or
anything
like
that,
whether
whether
you
know
there
were
any
other
things
that
that
maybe
we
can,
we
can
focus
on
in
terms
of
the
advantages
of
of
the
r
and
cloud
native.
J
I
can't
talk
about
a
little
bit,
so
it's
quite
challenging
to
say
you
know
what
considers
an
outage,
especially
in
cloud
environments,
especially
because
in
clouds
you
know
there
are
different
services
like
load,
balancers,
compute
and
outage
means
different
things
in
each
context,
especially
like
a
zonal
outage.
You
know,
or
things
like
that,
and
there
is
really
no
good
way
of
defining
or
detecting
outages
like
so
most
like
what
we
usually
end
up
with
is
some
arbitrary
thresholds.
J
As
far
as
if
x
percentage
of
nodes
are
down,
we
would
consider
like
a
zonal
outage,
and
obviously
semantics
about
is
also
mean
different
things,
for,
if
you
look
if
you're
looking
at
it
from
the
from
the
perspective
of
infrastructure
versus
application,
but
from
applications
point
of
view
looks
applications
like
scd
or
distributed
data
stores.
They
do
replication
and
they
obviously
have
you
know
different
view
of
what
outage
means
versus
if
you're,
trying
to
just
look
at
it
from
the
infrastructure's
point
of
view.
J
H
I
think
what
we're
trying
to
do
with
this
document
is
to
provide
guidance
that
abstracts
from
the
underlying
root
cause
or
possible
root
cause
of
an
outage,
and
just
give
you
a
guidance
on
how
you
organize
your
stateful
workloads
to
survive
an
outage
whatever
that,
whatever
the
root
cause
is
right,
we
want
to
be
able
to
do
it
without
having
human
intervention,
like
I
was
saying
without
losing
state,
or
you
know,
having
zero
rpo
and
having
the
lowest
rto
as
possible.
H
A
I
I
think,
I
think
it's
still
useful,
though
too
to
capture
you
know
the
things
that
are
that
are
hard
to
do
as
well
right,
because,
on
the
one
hand,
you
know
having
having
a
coordinated
plus
recovery
pattern,
the
find
is
important
and
there
are
a
lot
of
pros,
but
obviously,
from
an
operational
point
of
view,
things
like
defining
what
constitutes
an
outage
and
what
are
the
thresholds
for
for
failover
and,
for
you
know,
the
differences
between
degraded
service
versus
an
outright
failure
of
his
own
are
are
probably
worth
worth
articulating.
J
J
I
mean
it
all
depends
on
like
how
abstract
we
want
to
keep
the
document
or
how
generate
you
want
to
keep
it.
I
haven't
had
a
chance
to
read
the
whole
thing
in
detail,
so
I
don't
know
exactly
what
what
your
goal
is
larger
goals
if
it's
just
providing
some
basically
some
level
selling
for
people
to
order
to
be
familiar
with
the
concepts
or
we're
actually
trying
to
come
up
with
a
set
of
guidelines,
so
people
can
build
solutions
on
top
of
them.
H
It's
the
latter
that
you
said:
let's
do
this,
if
you're
willing
to
contribute
we're
going
to
take
your
time
to
read
it
and
and
maybe
drop
comments,
and
maybe
we
can
also
collaborate.
H
A
Well,
a
deck
to
to
summarize
would
would
always
be,
will
always
be
extremely
valuable,
and
we
can
also
you
know,
use
that
content,
perhaps
to
to
you
know,
create
a
blog
in
future
or
a
webinar
or
or
or
something
like
that,
because
you
know
the
we
we
have
done
webinars
on
the
on
on
the
through
the
cncf
as
well
in
the
past,
so
that
that
sort
of
thing
would
definitely
be
useful.
I'm
sure.
H
D
Raphael,
it's
aaron.
I
think
it's
good
to
give
a
little
bit
of
history.
Is
this
the
same
doc
that
has
kind
of
been
in
progress
for
a
while,
when
I
was
still
there
in
that?
I
think
it's
really
hard
for
people
who
are
adopting
kubernetes
in
a
not
completely
cloud
deployment
to
understand
the
complexities
of
running
it
on-prem
and
on
cloud
and
taking
our
traditional
storage
concepts
and
trying
to
apply
them
to
cloud
native,
and
I
think
that's.
D
Maybe
the
goal
of
this
is
to
take
what
people
are
normally
used
to
as
far
as
their
rto
and
rpo
in
terms
of
storage
and
what
that
looks
like
if
we
run
that
in
cloud
and
how
we
can
achieve
that
capability
into
artelon's
point
like
we
have
to
have
replication.
I
think
just
some
perspective
is
also
about
what
are
the
costs
associated
with
that,
because
that
seems
to
be
a
concern
when
I
talk
to
a
lot
of
different
people
about
deploying
things
this
way,
you
know
that
are
at
huge
scale.
D
What
are
the
the
benefits
and
possible
drawbacks
so
that
that
would
be
helpful
if
we
also
outline
those
for
people-
and
I
would
arlan
what
do
you
mean
by,
like
you
know,
being
specific?
Are
you
talking
about
creating
use
cases
for
each
one
of
the
clouds
and
how
we
know
that
they
work
or
trying
not
to
be
specific?
J
J
So
I
think
I
mean
it
kind
of
depends
on
how
we
look
at
it.
So,
for
example,
like
you
know,
I
work
at
netapp
and
in
the
storage
people
usually
talk
about
like
five
nines
six
nines,
you
know
of
availability,
like
rto
of
you
know
a
few
seconds
or
you
know
it's
a
very
the
way
we
talk
about
our
real
high
availability
is
somewhat
different
than
the
cloud
world.
J
You
know
where
you
know,
for
example,
if
you
look
at
the
slas
of
aws
or
gcp,
you
know
they
usually
talk
about
like
99.5
or
9.5
availability,
you
know
and
if
you're
building
a
cloud
native
solution,
unlike
on-prem
storage
solutions,
where
you
can
control
the
whole
stack
networking,
it's
it's
a
different
kind
of
beast
in
the
cloud
world
right.
So
I
think
some
of
it
is
a
cultural
look.
J
D
J
H
You
know
let's
work
together
on
that,
because
sure
I
think
you
will
find
it.
It
was
an
interesting
insight
for
me,
as
I
was
doing
this
research
in
in
in
what
I
call
the
cl
cloud
native
dr,
which
is
defined
in
this
document
right
and
you
don't
have
to
agree,
but
what
I
call
cloud
native
dr
disaster
recovery,
the
features,
the
capabilities
that
enable
disaster
recovery
don't
come
from
storage.
H
H
Storage
has
to
be
there
still
as
an
important
role.
We
still
need
backups
for
logical
failures,
but
not
for
dr.
We
still,
we
probably
don't
need
volume
replication
in
this
new
world,
because
the
responsibility
of
keep
the
state
in
sync
is
to
the
application.
A
J
H
H
J
E
H
H
A
I
just
want
to
make
I
I
just
want
to
make
an
important
point,
because,
because
I
I
feel
we're
we're
in
danger
of
going
off
in
a
dangerous
tangent.
The
the
point
that
we're
trying
to
talk
about
here
is
not
about
the
capabilities
of
individual
platforms,
it's
more
about
the
architectural
patterns
that
would
be
implemented
and.
A
You
know
the
the
the
architectural
patterns
that
we're
discussing
in
this
document
are
not
linked
to
you
know
any
specific
cloud
provider,
or
you
know
on-prem
provider
or
or
anything
like
that.
In
fact,
it's
it's
it's
more
about.
This
is
how
you
would
engineer
this
is
about
how
you
would
engineer
a
system
and
cater
for
consistency
and
make
sure
that
data
is
available
in
multiple
places
and
then
allow,
for
you
know
the
the
the
failovers
across
you
know,
different
kubernetes
clusters,
etc.
That's
kind
of
the
concept
of
what
we're
talking
about
here.
A
We're
not
we're
not
specifically
saying
at
any
point
that
you
know
you
would
do
volume
replication
in
a
certain
way
or
database
replication
in
a
certain
way.
But
but
more
around
the
point
of
saying
you
know
we,
you
need
load
balancing
capability
and
you
need
you
know
a
middleware
or
or
a
database
layer
that
that
can
do
the
replication
or
you
can
have
replication
happening
as
a
volume
layer.
A
H
H
Right,
thank
you
alex.
Yes,
in
fact,
we
from
the
internal
documents
that
aaron
was
referring
to
before
we
I
stripped
away
everything
that
was
kubernetes
related
or
openshift
related.
It's
all,
it's
very,
very
generic,
now
that
the
pattern
should
work
anywhere,
whether
you
use
machine
with,
or
machines,
in
the
cloud
whether
you
use
containers
on
prime,
wherever
you
are
the
pattern,
this
pattern
that
we
are
presenting
should
work.
H
Actually,
I
think
it
will
work
and
that
not
to
say
in
this
document
we
are
not
saying
that's
the
only
way
to
do
it.
D
I
think
it's
right
for
discussion.
To
be
perfectly
honest,
I'm
part
of
the
the
end
user
group
now
as
well
in
the
cncs,
and
there
is
a
lot
of
discussion
around
storage
and
durability
and
availability
and
the
the
consensus
for
most
users
of
kubernetes
is
that
they
can't
the
storage
is
not.
I
don't
think
they
use
the
word
dependable,
but
they
haven't
had
good
success.
D
So
I
think
it's
also
one
of
the
topics
I
brought
up
on
the
the
toc
yesterday
is
I'd
like
to
have
a
little
more
focus
from
them
as
well
as
projects
and
ideas
and
and
how
we
take
these
things
and
socialize
them
a
little
bit
better,
so
that
people
can
achieve
the
same
things.
Hopefully
they
can
do
on-prem
or
in
private
cloud
that
they
they
can
do
in
in
cloud.
So
they
have
a
consistent
way
of
doing
things.
I
think
that's
what
we're
trying
to
achieve
is.
D
D
Love
to
talk
about
these
things,
because
I
I
think
I
have
definitely
my
old
red
hat
perspective
and
now
apple's
perspective,
and
I
think
it's
interesting
to
see
the
two
meld
together.
So
I'd
love
to
hear
the
diversity
of
thought
around
this
and
what
people
are
doing
and
customers
are
expecting
so.
Okay,.
A
A
No,
no,
no
so
look
I
I
we're
coming
up
we're
coming
up
the
time.
I
I
just
wanted
to
say
look.
These
are
all
good
points,
but
we
we
should
make
sure
that
we
that
we
contribute
to
the
documents-
and
you
know,
if
need
be,
add
paragraphs,
add
comments
and
we
can.
We
can.
You
know
then
further
discuss
and
merge
them
together
and
we
can
have
separate
follow-up
goals
if
we
want
to
discuss
any
particular
points
in
in
a
bit
more
detail.
H
No,
I'm
okay,
erin
I'll
contact
you
privately
just
we
couldn't
continue
that
that's
good.