►
From YouTube: WG Data Protection Meeting 20200826
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
today
is
august
26
2020.
This
is
the
kubernetes
data
protection
working
group
meeting.
So
today
we
have
mainly
one
item
on
the
agenda,
which
is
to
continue
our
discussion
on
the
data
protection
workflows.
A
I
think,
went
through
this
last
term.
I
think
for
the
use
case
section.
I
hope
that
we
have
made
some
good
progress,
so
shan
chen
tom
stephen.
You
guys
want
to
talk
about
this.
A
Okay,
so
should
we
okay,
let
me
you
want
to.
Should
I
make
you
a
composer,
you
can
share
your
screen.
Should
we
go
review
this
the
stock
or
what
is
the
thing.
B
I
think
we
haven't
really
synced
up
on
this
dock
again,
since
we
did
do
one
meeting
on
the
dock.
Add
some
more
definition
added
more
sections.
We
haven't
really
fully
flushed
it
out
completely
okay,
but
we
can.
We
can
maybe
go
through
some
of
this
if
we
want
yeah.
B
Yeah
that'd
be
great.
Let
me
make
sure
my
screen.
A
Okay,
let
me
stop
sharing.
B
Perfect,
you
see
my
notepad,
yes,
okay,
so
I
think
we
collected
the
feedback
from
the
last
meeting,
which
was
that
I
think
we
were.
We
added
a
lot
more
scope
than
what
we
had
taught
than
I
think
what
the
section
kind
of
required
and
we
did
a
bunch
of
work
on
defining
some
personas.
B
I
think
krishna
and
steven
added
some
of
this
as
well
right.
So
maybe
I
can
just
share
my
screen
if
you
guys
want
to
walk
through
some
of
the
things
you
added
and
we
can
that
doesn't
get
feedback
on
that
stephen.
I
think
you
added
this
section
correct.
D
I
I
did
so
having
minor
technical
difficulty,
giving
me
one
minute
because
everything's
all
work
on
my
end
just
one
second.
B
D
All
right,
my
laptop,
is
no
longer
screaming
at
me.
Sorry
about
that
yeah
yeah.
So,
basically,
what
we
did
is
we
put
together.
You
know
sort
of
the
top
part.
Here
you
see
the
personas
right.
We
basically
said
there's
three
people
that
are
going
to
care
in
these
use
cases.
Now
not
everybody's
going
to
care
about
every
use
case.
You've
got
the
app
owner,
you've
got
a
cluster
admin
and
then
you
usually
have
some
sort
of
central
backup
and
then
what
we
try
to
do
and
we
won't
necessarily
go
through
all
these
use
cases.
D
But
if
we,
if
we
scroll
down,
we
basically
said
look
when
you
do
a
backup,
you
might
just
be
backing
up
an
application
right,
and
so,
if
you
back
up
the
application,
obviously
you
know
there's
there's
a
certain
set
of
steps
in
the
process.
So
the
person
who
cares
about
backing
up
an
application
will
either
be
your
app
owner
or
the
central
admin,
basically
in
our
world
right.
If
the
app
owner
cares
enough,
they'll
take
an
active
role.
D
If
they
don't,
then
the
central
admin
is
sort
of
responsible
and
and
basically
to
back
up
an
application.
You
can
have
some
mechanism
to
specify
the
components
we
sort
of
have
an
open,
open
question.
I
think
on
all
right,
so
you
have
to
be
able
to
specify
what
components
make
up
your
app
do.
We
want
a
mechanism,
a
standard
way
to
specify
components
that
are
external
for
the
cluster,
or
is
that
sort
of
an
exercise
left
to
each
of
the
implementers
each
of
the
readers
each
of
the
users?
D
You
know,
for
example,
aws
just
sort
of
triggered
their
ack
stuff.
You
know
casting
if
you
guys
have
a
mechanism
to
specify
external
resources,
that
sort
of
thing
you've
got
to
have
a
way
to
specify
your
custom
operations.
Your
clients,
log
truncation,
your
korean
postscripts,
basically
you're
going
to
select
what
kind
of
backup
and
a
couple
of
the
most
common
types
are.
Are
you
going
to
want
it
to
be
app
consistent?
Are
you
going
to
want
to
do
sort
of
all
those
pre
and
post
scripts?
D
Are
you
going
to
be
happy
with
crash
consistent
and
one
of
the
things
we
talked
about
is
frankly
throughout
the
course
of
the
day
you
may
choose
to
do
one
app,
consistent
and
five
crash
consistent,
because
that
consistency,
obviously
a
lot
bigger
impact
on
the
application
running
you'll,
also
have
a
choice
of.
Do
you
just
want
to
do
snapshots,
or
do
you
also
want
to
do
data
copy?
D
I
know
most
backup
apps
at
this
point,
offer
both
mechanisms
and
then-
and
then
you
know
the
last
is
just
you've
got
to
specify
where
you
want
the
backups
to
go
right
and
things
like
failure,
handling.
How
long
till
you
time
out
how
many
resources
could
you
fail
backing
up
before
you
fail
it
so
so
this
is
kind
of
the
process
when
you
specify
what
needs
to
be
done
and
then
this
is
then
the
exercise
again
enough
to
you
know
I'm
on
the
backup
vendor
which
is
go.
Take
care
of
it
go
go!
D
Do
it,
however,
you
want
to
do
it
right.
Some
of
the
requirements
we
talked
about
in
terms
of
making
this
happen
again,
encryption
is
going
to
be
important
again.
Some
mechanism
to
identify
what
makes
up
your
application
again,
some
mechanism
for
the
app
intelligence
to
be
able
to
inject
scripts
and
operations,
define
the
dependencies,
all
those
sorts
of
things,
a
mechanism
to
be
able
to
do
crash
consistent.
This
is
where
we
figure
there's
a
dependency
on
consistency,
groups
which
we
know
the
storage
team
is
working
on
again
snapshot
on
the
snapshot,
backup.
D
I
know
one
of
the
things
that
comes
up
a
lot
and
when
we
talk
to
customers
is
snapshots
disappear
when
objects
disappear
depending
on
the
type
of
retention
policy
you
put.
If
it's.
If
it's
delete
an
object,
gets
deleted,
then
that's
pretty
sad.
If
you
have
a
retention
period
for
a
snapshot
that
needs
to
maybe
governance
requirement
and
then
obviously
some
requirement
to
be
able
to
reasonably
easily
do
data
level
backups
again.
This
is
where
you
know:
valero
uses,
rustic
and
he's
able
to
hook
into
containers.
D
Obviously
again
casting
has
tools
like
administer
and
then
and
then
we
you
know,
are
we
going
to
have
some
sort
of
standard
mechanism
to
specify
external
resources,
so
this
is
kind
of
how
we
view
sort
of
this
is
how
you
do
an
app
backup.
These
are
some
of
the
things
you
need
to
have
there
not
trying
to
prescribe
how
to
do
it.
Just
this
is
what
needs
to
be
done.
B
Yeah
really
really
good.
Thanks.
Do
you
just
want
to
go
through
the
rest
of
the
types
of
backups
we
discussed
as
well?
Let's
go
faster.
D
The
other,
which
is
probably
more
common
and
something
we've
learned
from
the
vmware,
is:
if
someone
doesn't
specify
everything
you
want
a
default
policy,
it
just
says
grab
all
the
other
stuff
because
you
might
need
it
later
and
it
sort
of
equals
one
of
the
default
policies
in
the
backup
vms,
and
so
so
you
may
have
again
it's
probably
more.
The
central
admin
that'll
trigger
the
namespace
backup
that
they
just
say
just
in
case
grab
it
all,
but
otherwise
it's
it's
pretty
much
the
same
as
in
that
backup,
just
a
lot
less.
D
And
then
the
cluster
backup
again
is
basically
get
me
all
the
namespaces
plus
any
other
stuff.
I've
made
a
week
from
the
question,
which
I
think
is
the
pretty
most
people
I
didn't
actually
start,
and
I
think
the
only
questions
that
come
up
here
when
we
talk
to
people
are
just
the
permissions
of.
What
do
you
need
to
be
able
to
access?
D
B
Yeah,
I'm
curious
what
people's
opinion
are
on
cluster
backups.
You
know,
I
think,
there's
there's
kind
of
this,
maybe
not
flame
word,
but
there's
contention
around
is
is
backing
up
like
doing
an
suv
backup
sufficient
here.
B
You
know
my
my
kind
of
opinion
here
is
that
it's
not
you
know,
you
should
really
focus
on
going
through
the
queries.
Api
to
grab
objects,
including
cluster
level
resources.
Do
people
have
an
opinion
here.
Do
people?
Does
anyone
want
you
to
counter
counter
stance
and
we
can
discuss
it.
G
I
was
just
saying
you
know:
can
you
elaborate
more
as
to
why
you
think
lcd
backups
are
not
good
again,
I
don't
have
a
view
on
this,
but
just
trying
to
understand
more.
B
I
I
think,
there's
a
lot
of
components
that,
if
I'm,
if
I'm
doing
like
disaster
recovery
of
a
cluster,
a
lot
of
things
that
I
see
don't
no
longer
make
sense
right
nodes.
For
example,
it's
likely
that
you're
going
to
be
using
new
nodes
and
your
restore
of
sdgs-
and
I
think,
is
you
know
these-
will
cause
more
issues
than
me
right.
A
So
you
are
saying:
actually
you
don't
really
use
that
at
all
you
just
to
completely
control
the
backup
yourselves,
that's
sort
of
yes,
you're
not
really
build
other
things
on
top
of
it,
but
you
don't
want
to
use
the
cd
backup
at
all.
It's
your
suggestion.
F
Yeah,
I
can
add
on
to
that,
may
I
yeah
so
I
will
refrain
from
my
point
of
view
on
whether
we
need
cluster
as
a
whole
as
an
entity
to
be
backed
up
or
not.
But
if
you
are
doing
it,
I
will
tell
why
xcd
may
not
be
a
right
candidate
right.
There
are
with
with
cloud.
There
are
a
lot
of
managed
kubernetes
services
coming
into
picture,
and
none
of
these
managed
kubernetes
services
may
have
an
option
to
directly
take
a
backup
pocket
series.
F
F
Xtd
at
all,
in
that
case,
if
you
are
a
backup
vendor
supporting
that
particular
clouds,
cloud
providers
managed
kubernetes
service.
Then
you
need
to
do
it
through
api
model.
Kubernetes
api
model.
That's
one
point
of
view.
J
I
think
the
other
argument
against
doing
it,
cd,
that
I've
seen
is
that
the
resource
ids,
for
example,
we
have
volume
ids,
it
might
be
an
ebs
volume
or
you
know,
a
vsphere
volume
id
or
whatever.
If
you
cop,
if
you
back
up
at
cd,
those
volume
ids
are
baked
into
the
ncd
backup.
So
if
you
try
to
restore
it
as
a
duplicate,
it
winds
up
pointing
back
to
the
original
objects
and
that's
not
a
great
thing.
F
B
F
I
Because
you
can
install
kubernetes
anywhere
across
on-prem
on
edge
and
even
on
cloud,
and
the
infrastructure
really
is
widely.
A
F
Think
I
think
one
from
from
our
previous
discussions,
I'm
not
sure
if
I'm
remembering
this
correctly,
I
don't
know
if
we
called
out
backing
up
infrastructure
as
out
of
scope
for
this
effort.
A
Yeah,
I
think
it's
right
now
it
is
out
of
scope
and
we
can
talk
about
it.
I'm
just
saying
that,
for
if
you
look
at
our
charter,
some
of
those
are
right
now
out
of
scope.
G
So
one
more
thing
around
the
lcd
backup-
you
know
most
of
these
container
distributions,
rancher
and
so
on
are
providing
some
backups
based
on
hcd.
Are
we
saying
that
those
backups
are
not
good
enough.
G
You
know
they
provide
cluster
level
backups
just
directly
backing
up
ncd
and
they
provide
some
different
levels.
I
believe
you
know
backing
up
just
versions
or
configurations
and
I'm
not
sure
if
it's
cluster
resources
as
well,
but
just
trying
to
understand
that
if
there
are
distributions
that
are
suggesting
htd
kind
of
backups,
are
we
saying
that
those
backups
won't
be
enough
from
what
we
are
kind
of
looking
at
the
landscape
and
figuring
out?
What
needs
to
be
protected
from
a
protection
point
of
view.
K
G
Cluster,
well,
I
think
I
think
what
would
be
useful
is
you
know,
kind
of
you
know
if
we
document
you
know
what
does
an
lcd
backup
include?
You
know
and
then
kind
of
look
at
it
from
the
other
angle.
What
would
a
user
want
to
restore
to
get
his
applications
back
up
again.
B
You
know
so,
for
example,
I
think
let's
say
that
an
spd
backup
would
just
be
you
know,
treat
it
like
an
application
and
just
have
an
exact
copy
of
the
same
std
cluster
store
your
app.
Then
the
question
for
me
is:
what
are
the
deficiencies
with
that?
B
I
will
say
that
it
does
work
well,
there
are
cases
where
it
works
well
and
my
my
question
with
with
asking
this
was
kind
of.
Do
we
want
to?
Is
that
worth
bringing
up
in
this
in
this
context
of
cluster
backups
right
there?
B
There
are
use
cases
where,
if
you
do
a
store
in
place,
if
you
want
to
roll
back
or
something
perhaps
the
sd
can
and
work
well,
and
it
is,
it
is
that
you
say
supported
by
different
distributions,
and
I
wonder
if
that's
worth
worth
discussing
in
this
in
this
section
as
well.
A
I
think
we
can
add
that
just
for
the
completeness,
but
we
just
call
out
that.
That's
not
our
focus.
F
Yeah,
the
the
scenarios
in
which
I
think
taking
a
backup
of
hcd
would
actually
help
is
like
scenarios
where
you
are
actually
upgrading
at
cd.
Let's
say
where
you
are
running
your
own
hcd,
not
a
managed
kubernetes
service.
You
are
running
your
own,
then,
in
that
case,
and
you
are
managing
the
life
cycle
of
xcd
cluster
itself.
So
in
that
scenario,
when
you
are
when
you
are
the
lcd
operator
yourself
and
you
are
performing
upgrades
in
such
scenarios,
you
are
better
off
taking
a
backup
of
its
cd
before
you
actually
upgrade
it.
F
So
those
those
are
scenarios
where
taking
an
xcd
backup
would
be
useful,
but
for
a
more
sophisticated
like
high
level
construct
understanding,
kubernetes
applications,
you
would
want
to
go
through
the
kubernetes
api
server
to
backup
your
resources.
G
D
F
B
A
What
is
your
definition
of
infrastructure
here?
You
think
that
would
include
what
it
basically
meaning
the
entire
cluster,
including
the
nodes.
F
So
the
way
I
would
look
at
it
is
you're
taking
resources
from
one
kubernetes
cluster
and
you're
trying
to
move
it
to
another
kubernetes
cluster.
So
at
which
point
you
already
have
the
infrastructure
set
up
in
your
destination.
Cluster,
that's
correct,
so
moving
recreating
nodes
would
not
be
useful
because
there
is
no.
There
is
no
controller
that
is
watching
for
node
objects
to
be
created
to
go
provisional.
J
We've
had
people
looking
at
doing
like
array-based
copies.
You
know
just
basically
copying
all
the
storage
and
like
for
easter.
That
also
means
you
copied
all
the
vms,
but
we
run
into
a
lot
of
issues
there
with
object
identity,
but
maybe
the
thing
to
do
like
for
utcd
backups
is
define
the
scenarios
where
it's
actually
viable
so
like,
for
example,
like
etcd
loss.
J
D
L
Over
here,
the
whole
point
of
conducting
cluster
backup
or
with
the
final
way
here
is
given,
and
the
theme
is
that
think
about
the
from
the
personnel's
perspective
that
comes
introduced
before
right
as
a
cluster
admin.
If
your
cluster
is
big,
there's
no
easy
way
for
the
class
admin
to
understand
every
single
application.
L
However,
they
might
need
to
comply
with
org
policies,
saying
that
you
need
to
back
up
your
production
system
in
a
periodic
way,
so
in
in
this
case,
the
easiest
approach
for
them
is
to
take
a
backup
of
the
whole
cluster.
Yes,
there
will
be
situations
where
objects
are
not
portable
in
different
environments
like
nodes
events,
etc,
etc.
L
But
I
think
this
can
be
another
problem
solved
in
the
restore
process
where
you
take
a
complete
backup
of
the
cluster.
However,
during
the
restoration
you
have
some
kind
of
sophistic
selection
mechanism
or
whatever
your
ui
to
pick
and
select,
so
I
think
we
can
treat
these
two
problems
slightly
differently.
L
D
B
There
are
definitely
questionable
assets
so,
for
example,
crds
storage
classes.
You
know
we
we
found
that
backing
those
up
and
restoring
those
is
pretty
useful
yeah.
B
You
know,
I
guess
the
question
is:
if
I'm,
if
I'm
doing
like
a
cross
cluster
migration,
so
let's
say
I
have
a
backup
one
cluster
and
I
will
restore
it
somewhere.
What
can
we
assume
is
in
the
new
cluster?
Can
we
assume
that
it's
a
completely
empty
cluster
without
any
industrialization?
B
Should
we
assume
that
they're,
the
storage
classes
and
things
have
already
been
created?
Can
we
assume
that
the
crds,
and
maybe
even
operators
and
those
kind
of
things
have
been
created
as
well?
B
I
you
know,
I
think,
it's
more
conservative
to
say
that
we
we
wouldn't,
but
there
there's
a
line
there
too
right,
because
you
want
to
assume
something
that
you
know
you
have
to
have
storage
allocated
in
some
way
and
whether
or
not
that
means
you
create,
the
storage
classes
is
kind
of,
is,
I
think,
an
option
right.
Customers
have.
A
B
Yeah,
you
know
I'm
very
biased
here.
That
is
what
we
do
back
those
up.
That's,
I
think
it's
kind
of
optional,
because
it
depends
on
what
the
target
cluster
has
allocated
already
right.
Yeah.
M
I
have
a
question.
It
seems
sorry,
it
seems
like
the
definition
of
cluster
back
up
here
kind
of
matches,
what
whatever
it
does
right,
that
we
are
copying,
kubernetes
ap
objects.
We
don't
necessarily
need
everything
in
that
cd,
but
some
some
of
the
some
of
the
state
net
cd
and
the
question
I
have
is
even
is
that
sufficient,
like
what
valero
does
or
does
it
have
gaps
like
the
one
we
discussed
regarding
backing
up
the
whole
at
city,
state.
I
M
M
So
then,
why
are
we
talking
about
backing
up
at
cd,
given
all
these
problems
like
why
the
valor
way
of
doing
things
using
api
objects
is
the
way,
but
I
think
we
should
talk
about
that
in
the
context
of
cluster
backup.
B
Yeah,
I
mean,
I
think
it's
still
useful
to
talk
about.
I
mean
I
don't
want
to
push
this
being
the
right
way
to
do
things,
but
I
do
think
it's
worth
talking
about
it,
even
if
we
decide
that
we
prefer
to
go
at
the
api
level
just
because
people
are
doing
this,
I
mean,
as
I
think
preshanto
pointed
out,
was
prashanta
right.
Who
pointed
out
that
there
are
many
distributions
that
that
recommend
using
std
backups
for
that
cluster
backup
and
disaster
recovery.
You
know
so
as
a
working
group.
B
A
B
Cases
and
then
what
what
things
do
we
want
to?
What
primitives
do
we
want
to
move
forward
in
the
community
that
that
would
support
those
use
cases?
And
so
it's
worth
discussing
it's
easy
in
these
use
case
discussion,
because
people
are
using
it.
I
think,
but
I
agree
you
know
my.
My
preference
is
that
we
use
the
api
level
because
we
have
a
lot
more
control
over
there.
We
can
do
things
that
are
just
not
possible
with
that
cd
right.
L
Here
we're
not
for
solutions
right.
We
are
listing
scenarios
in
this
stock,
whether
or
not
a
cluster
backup
is
something
this
community
or
this
working
group
is
going
to
pursue
or
not
it's
a
different
story.
M
Good
yeah
that
makes
sense,
and
I'm
on
board
one
follow-up
question
so
does
the
lyric
or
how
it
works
today?
Is
that
sufficient,
for
example,
like
we
just
discussed
service
accounts,
may
not
match
from
one
cluster
to
another,
or
you
know,
let's
say
if
an
app
uses
some
secrets,
you
know
they
may
change
when
we
go
from
one
cluster
to
another.
How
does
valero
take
care
of
those
problems
or
does
it.
F
Yeah,
I
am
my
memory-
is
kind
of
failing
me
at
this
point,
because
I
was
trying
to
do
multiple
things,
but
we
don't.
If
I
remember
correctly,
we
do
back
up
those
resources,
but
we
don't
just
store
them.
F
F
So
that's.
That's
that's
been
a
general
principle
that
we
tried
to
follow.
A
F
Yeah,
so
even
on
both
backup
and
restore
users
are
free
to
choose
what
they
want
to
backup
at
a
granularity
of
resource
level,
and
they
can
also
choose
what
they
want
to
back
up
and
what
resources
they
want
to
back
up
and
what
resources
that
they
want
to
restore.
F
So
if
we
are
backing
up
see
a
custom
resource
yeah,
but
the
user
did
not
specifically
ask
for
crds
to
be
backed
up,
we
make
we
do
the
web,
the
link
from
cr
to
crd
and
back
up
the
crd
also
and
under
stored.
We
do
restore
the
crd
search
value.
J
I
think
there
were
some
things
that
you
know
it's
it's
useful
to
like
remap,
so
like
valeria
will
remap
storage
classes,
for
example.
We
were
looking
at
that
the
other
day
and
using
that
and
there's
also
there's
like
things
that
get
mixed
into
the
cluster
resources,
so
like
pvs
or
cluster
level
resources.
J
So
you
know
if
you're
only
backing
up
a
name
space.
Do
you
back
up
all
the
pvs
if
you're
doing
the
cluster
level
resources,
so
I
think,
there's
a
bunch
of
stuff
there
to
figure
out
like
how
you
know.
How
do
you
filter
those
out?
How
do
you
have
ways
to
change
them
on
restore
and
probably
in
a
more
generic
fashion,.
B
I
think
changing
things
without
restore
is
a
general
problem,
not
specific
to
cluster
level
resources.
You
know
we
found
this
for
many
different
types
of
resources,
not
just
crds
and
other
cluster
level
resources,
but.
K
A
L
G
L
Heavy
logic
needs
to
happen
during
the
restore
time,
and
it
needs
guidance
from
the
users,
for
example
the
world's
snapshot.
It
is
not
easy
to
restore
because
you
need
to
literally
transform
whatever
dynamically
created
ones.
Natural
objects
in
the
api
server
into
a
pre-progression
snapshot.
Otherwise
it
just
won't
work
so
that
my
point
in
the
beginning
is
that
I
think
the
these
two
provide
a
more
or
less
complete
backup,
so
that
a
restore
can
happen
in
case
it
needs
something
from
backup,
but
how
to
conduct.
That
is
the
big
question.
A
C
L
They
only
support
community
maintained.
Yes,
that's
right.
A
B
A
A
B
G
Yeah
we've
also
kind
of
seen
similar
things
in
our
end.
You
know
backing
up
the
crs,
especially
you
know
you
know
giving
the
example
of
etc.
Again,
cd
has
a
custom
resource
to
do,
backups
and
restore
which
it
puts
in
a
target
s3
repository.
G
A
B
A
B
Does
that
does
that
make
sense,
or
is
that
I
don't
want
to
pose
that
opinion.
L
G
B
Okay,
cool
steven,
I
I
apologize
for
hijacking
your.
D
A
And
so
they
can
keep
going.
We,
the
next
agenda,
can
go
very
quick,
so
yeah,
that's
just
to
keep
this.
D
So
so
the
next
part.
Actually,
I
think
I
can't
remember
who
said
it,
but
I
prefer
the
term
resource
backup
is
actually
better
than
sub
application,
backup
but
yeah
this.
This
is
basically
just
the
the
resource
backup.
So
you
know
hey,
I
just
wanna.
I
just
wanna
do
one
little
thing
right
and
it
could
be.
You
know
from
our
point
of
view.
It
could
be
a
customer
says.
D
So
they
may
just
want
to
say
hi
yeah,
just
back
up
this,
my
sequel
or
back
up
just
this
volume
or
something
something
limited
like
that,
so
that
that's
really
sort
of
the
intent
here.
So
it's
it's
got
a
lot
of
the
same
characteristics
as
an
application
backup,
but
just
obviously
a
much
smaller
granularity
and
generally.
This
is
something
only
the
app
owner
is
really
going
to
care
about,
because
it
does
tend
to
be
something
where
they're
about
to
again
do
probably
some
sort
of
upgrade
or
some
sort
of
test
that
they
want.
D
So
the
application
was
literally
so
at
least
the
way
we
were
thinking
of
it
is
take.
Take
customer
x,
they've
got
a
billing
application
or
actually
probably
a
better
billings
complicated,
take
a
discussion
with
a
guitar
company
that
basically
wanted
to
it
had
a
kubernetes
application
that
allowed
you
to
design
a
custom
guitar,
and
so
basically
there
was
a
database.
There
was
an
external
database
where,
where
they
keep
a
certain
amount
of
information
in
rds,
they
had
a
couple
of
databases
in
kubernetes
as
well.
D
D
But
then
they
said
there
are
points,
let's
say
so
they
were
using.
In
this
case.
I
think
they
were
using
a
or
for
some
for
some
of
it
and
they
said,
but
if
I'm
gonna
upgrade
I'd
like
to
be
able
sometimes
just
to
be
able
to
say,
take
a
backup
of
the
right,
I
don't
need
to
back
up
the
whole
app
right
now.
A
D
C
B
Stephen,
do
you
see
it
being
something
similar
to
this?
Where
the
there
is
some
kind
of
input
required,
because
in
that
case
you
could
back
up
the
entire
instance
of
you
know
the
entire
mongol
instance
or
you
could
back
up.
You
know
individual
collections,
for
example,.
D
Right
and
and
so,
and
so
that
was,
that
was
where
we
got
into
the
discussion
with
them.
Where
again
this
comes
to,
they
wanted
to
be
able
to
label
the
apple,
the
guitar
application,
as
this
is
the
guitar
application,
and
then
they
almost
wanted
like
a
sub
label
where
they'd
say
this
is
guitar,
so
they
could
say,
I
just
want
to
back
up
guitar,
as
opposed
to
all
of
guitar.
D
D
E
Us
hi
in
this
example,
even
the
can
also
have
sub
components
right
in
so
in
some
sense,
this
is
becoming
a
composite
application
kind
of
a
scenario
where
we
have
applications
and
there
are
kind
of
a
composite
applications
which
are
made
up
of
multiple
couple
applications
and
the
backups
can
be
dealing
with
a
single
application
or
a
composite
application
kind
of
a
scenario
yeah
and.
D
That's
why,
under
the
requirements
I
did
and
they
they
wanted
some
way
to
to
specify
like
a
hierarchy
in
the
application
so
that
they
could.
They
could
build
up
that
composite.
That
way
and
again
I
I
don't
have
any
religion
on
how
you
do
it,
but
that
was
that
was
the
customer's
ask,
and
we've
had
that
from
quite
a
few
customers,
whether
it's
the
guitar
or
a
building
or
any
sort
of
application.
L
D
That
was,
that
was
certainly
what
we
told
them,
and
I
think,
as
long
as
the
group
is
okay
with
that
being
the
implementation,
I'm
fine.
I
just
wanted
to
put
the
use
case
down,
and
this
is
something
people
want
to
do.
That
was
where
we
were
guiding
them
was
you're
probably
going
to
do
this
with
labels,
but
you
know
from,
but
from
a
use
case
perspective.
We
just
need
to
solve
it.
If
the
group
all
agrees
that
labels
is
a
way
to
solve
it,
we'll
put
that
in
there.
J
J
Longer
term,
because
we're
at
at
some
point
you
know
all
we
see
is
kubernetes
labels
at
this
point
of
things
like
pvs
and
stuff,
and
so,
if
we
want
to
do
application,
specific
backup
like
actually
use
the
mongodb
backup,
we
need
to
be
able
to
trigger
that
as
well.
But
that's
a
that's
outside
of
this
this
as
a
use
case.
This
is
something
we
really
need
to
support.
A
A
A
So
so
you
mean
that
if
we
want
to
do
that,
you
cannot
use
labels
too,
but
the
label
can
still
help
to
pick
the
pick
up
the
risk
correct
resources
right
now.
This
is
like
we
probably
need
some
other
configuration
to
some
flag
to
say.
Okay,
we
want
to
go
this
way
to
back
up
this
way,
not
using
this
other.
J
F
I
think
thinking
it
from
a
perspective
of
like
backing
up
mongodb
as
kind
of
is,
is
a
very
narrow.
It
seems
like
a
very
narrow.
F
Scenario,
what
I
would
I
would
suggest
is
there
are
think
think
of
people
are
labeling
their
applications
and
saying
they
want
to
back
up
all
resources
associated
with
this
application.
That
is
when
you
would
use
a
label
selector
to
find
out
all
resources
that
are
associated
with
an
application
and
back
them
up.
So
I
I
would,
I
would
kind
of
try
to
think
of
using
label
selectors
in
that
way,
and
I
feel
that
that
is
a
scenario
we
should.
We
should
kind
of
think
about.
B
D
Yeah
yeah,
we
we
had
the
both,
I
think
the
and
the
requirements
ability
to
identify
what
comprises
an
application
and
then
to
dave's
point
gap,
intelligence
as
well
and
so
yeah.
So
the
assumption
I
I
didn't
want
to
copy
the
requirements
for
each
each
one.
You
know
because
it
would
just
make
the
document
redundant.
So
that's
why
the
requirements
most
of
them
say
all
of
the
things
in
the
application
plus
right.
It's
just
there's
always
more
requirements,
especially
for
less.
B
D
D
D
So
so,
let's
start
with
the
application
one.
So
so
again
I
mean
this
this
you
know
many
of
the
recoveries
mirror.
The
the
backups,
though
I
I
think
is,
might
have
been
it
was
it
wasn't
dave,
but
it
was.
It
was
anyway
ishish,
maybe
that
it
was
a
sheath
that
brought
up
that
an
application
recovery
could
be
a
recovery
of
an
application
backup,
but
it
could
also
be
that
I
did
a
namespace
or
a
cluster
backup
and
then
on
the
restore
specified
the
components
of
the
application.
D
D
That
allows
me
to
select
the
components
that
comprise
the
application
during
the
restore,
since
I
didn't
do
it
during
the
backup,
obviously
they're
going
to
pick
a
place
to
restore
it
too
and
then
and
then
and
then
hand
wave
hand,
wave
magically
the
backup
thing
sort
of
recreates
all
the
stuff.
That
was
there
right.
The
kubernetes.
D
The
volumes
all
of
that
stuff
that
makes
my
application
come
back
and
again
didn't
want
to
get
super
prescriptive
on
which
objects
and
how
we
deal
with
it,
but
some
of
the
requirements
here
again
you're
going
to
need
a
mechanism
to
specify
the
components
again.
That
may
be
a
backup
application
thing,
but
obviously
you're
going
to
need
that
some,
some
of
the
ones
that
do
come
up,
though,
is
some
sort
of
guidance
or
or
standard
order
of
operations.
I
think,
is
useful
as
people
build
backup
applications.
D
That
becomes
a
a
big
deal.
Another
one
is
if
we
did
allow
them
to
specify
dependencies
on
external
objects
again
an
rds
database,
for
example.
We
probably
need
a
standard
mechanism
to
allow
them
to
trigger
the
recovery.
If
we
decide
that's
out
of
scope,
then
again
that
becomes
sort
of
a
one-off
per
vendor
per
per
external
resource
kind
of
thing.
Either
one
is
oh
okay
there,
but
I
think
we
do
need
to
decide
on
on
whether
we're
going
to
bring
that
into
scope
or
not.
D
I
left
off
here,
and
I
probably
put
it
in
a
different
part,
all
right.
The
assumption
here
was
that
it
was
you
restoring
to
a
totally
alternate
location
so
tom
to
your
point
before
I'm
not
worrying
about
any
conflicts
and
he
overwrites
any
hey,
I'm
hitting
an
object
or
something
of
the
same
name.
D
D
Are
there
standard
ways
to
sort
of
cope
with?
I'm
encountering
an
object
and
I
need
to
know
what
to
do
or
again
is
that
something
we
leave
up
to
the
backup
vendors
to
sort
of
sort
out
on
their
own,
but
that
will
be,
I
think,
a
concern,
certainly
for
all
users
of
you
know
how
do
you?
How
do
you
take
this
back
to
the
last
backup
and
not
leave
cruft
around
or
or
create
make
things
worse
than
when
we
started.
A
The
question
using
the
ability
to
special
order
of
backing
up
resources
such
as
backup
application,
nodes
ports-
you
mean
the
resources
on
those
nodes
plus
not
backing
up
the
nodes
themselves.
Right
is
that
yeah.
B
Okay,
stephen,
you
kind
of
mentioned
something
interesting
there,
the
when
you
say
application,
rollback,
you're
talking
about
overwriting
existing
things
and
then
for
recovery.
You're
talking
about
new
net.
D
New
is
that
what
you
mean
yeah,
that
was,
that
was
the
distinction,
because,
as
we've
met
with
customers,
there's
always
those
two
sorts
of
flows.
One
says:
look,
I'm
always
going
to
restore
it
either
maybe
same
name
space,
but
I
want
to
prefix
the
restored
objects
with
a
different
prefix
and
then
there's
the
other
of
no.
We
want
to
you
know,
especially
you
know,
frankly,
with
people
who
have
like
a
netapp
background.
D
Yeah
so,
and
that's
why
we
say
it
doesn't
mean
what
you
think
it
means
in
a
netapp
world,
when
I
snap
restored
a
volume,
it
was
a
you
know,
sort
of
a
single
point
in
time,
roll
back
and
it
destroyed
data.
But
you
know
all
it
said:
was
your
storage
goes
back
to
the
point
in
time.
They
want
to
apply
that
to
the
whole.
D
D
B
That's
true
yeah,
I
think
we're
out
of
time
thanks
a
lot
to
see
this
thing.
That
was
really
useful.
We
can
maybe
continue
there's
more
stuff,
so
maybe
we
can
do
that
next
time.
So.
A
D
L
Appreciate
it
and
this
kind
of
effort
is
going
to
definitely
guide
us
in
the
future,
what
components
we
needed
again,
I
want
to
clarify
this
is
the
use
case,
collection
phrase
we
are
not
targeting
at
designing
or
deciding
the
direction
directly.
At
this
moment,
I
I
actually
encourage
everybody
to
take
a
look
at
this
stock
is
really
well
written
and
put
you
on
your
comments
over
there
thanks
tom
thanks
for
stephen
and
all
others,
working
on
this,
it's
initiative,
yeah.
Thank
you.
A
So
I'm
just
wrapping
up,
so
there
are
so
yeah
we
do
have
other
sections.
I
think
some
we,
I
think
we
schedule
time
to
to
discuss,
and
so
I
think
actually
I
should
probably
go
to
this
other
doc.
So
if
you
have
a
sign
up
for
this,
please
reach
out
to
each
other.
A
That
are,
you
know
in
the
same
group
with
you,
and
maybe
we
can
make
some
progress
there
for
those
other
sections
as
well,
and
then
just
just
a
quick
update
about
our
our
talk,
so
I
think
it
went
well.
It's
just
the
time.
Tell
me
why
it's
very
early
in
the
morning,
like
five
o'clock,
5
30
specific
time,
but
I
think
it
went
well.
So
I
think
we
got
some
questions.
Some
very
good
questions.
A
One
question
we
got
is
actually
actually
we
got
several
questions
about
the
valara
like
how.
How
is
this
different
from
valara?
What
do
you
guys
think
a
different
part
of
her
so
basically
was
saying
we
are
not
really
it's.
We
are
just
providing
some
some
tools
that
balara
can
use
we're.
You
know
trying
to
work
on
those
missing
missing
pieces
in
kubernetes
and
velar
is
actually
part
of
this
working
group.
A
I
think
there
is
another
question
which
is
about
the
whether
when
we
are
going
to
support
change
block
tracking,
so
I
think
that
was
actually
our
charter.
So
probably
I
think
I'm
going
to
add
that,
as
in
this
talk
as
well,
because
that's
maybe
something
that
we
could
also
think
about
a
little
bit-
awesome
yeah,
that's
great
yeah
and
then.
A
Like
a
brand
new
topic,
so
but
it's
we
just
have
not
got
a
chance
to
talk
about
that.
So
probably
we
should
at
least
talk
about
what.
That
is
why
we
need
it
in
our
white
paper.
You
know
it's
not
like
we're,
not
starting
the
design
yet,
but
at
least
talk
about
why
we
need
it
things
like
that.
Okay,
I
think
I
think
we
are
running
our
time.
So
thank
you,
everyone
and
talk
to
you
next
time.