►
From YouTube: WG Data Protection Bi-Weekly Meeting 20200715
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
All
right,
good
morning
again
today
is
july
15th.
This
is
the
kubernetes
data
protection
working
group
meeting
today
we're
going
to
go
through
actually
three
topics.
A
One
is
shin
and
I
had
another
round
of
discussion
between
sign
note
leadership
as
well
as
team
on
the
container
notifier
design
doc.
We
collect
some
feedback
and
then
I
think
two
weeks
back
tom
from
casting
has
good
another
person.
It
is
a
that
gives
us
some
updates
on
from
castings
perspective,
how
they
are
looking
at
the
notifier
and
whether
they
prefer
crd
or
notify
approach
and
today-
and
I
want
to
give
you
guys
more
updates
on
that-
I
I
think
that
person
was
kirushana
right.
A
Okay,
I
was
like
yeah.
Another
thing
is
that
we
have
been
discussing
the
data
protection
workflow
in
the
beginning
of
this
working
group,
but
unfortunately,
the
we
haven't
made
too
many
too
much
progress.
A
So
far
today
we're
going
to
be
reading
some
of
the
thoughts
shin
has
put
up
a
talk
about
that
we'll
go
through
the
doc
and
the
last
minor
thing
is
that
there's
a
kubernetes
annually
reporting
newly
added
there's
a
poor
request
that
listing
an
agenda
so
far,
there's
no
action
item
for
the
working
group
per
se,
but
if
you
guys
are
interested,
feel
free
to
take
a
look
all
right.
Seeing
that,
can
you
present
your
dog?
Please,
yes,
or
should
you.
B
B
One
part
we'll
have
the
action
defined
there
and
in
action
we
could
have
the
command
d
run
in
the
container
or
some
signal,
and
then
we
have
a
probe
kubelet
can,
after
sending
the
action,
it
can
use
the
probe
to
check
whether
the
action
has
has
get
the
desired
results
and
the
so
the
discussion
we
have
so
the
we
got
some
comments
from
them,
mainly
the
signal
they
are
still
very
concerned
about
adding
all
of
those
complicated
logic
into
signal
into
kublet,
so
they
so.
I
added
some
notes
here.
B
Mainly
there
are
a
couple
of
action
items.
The
first
thing
is
they
want
us
to
summarize
the
crd
approach
so
that
I
did
so.
We
already
talked
about
the
extrusion
hooks
here,
the
approach
several
times,
so
I'm
not
going
to
repeat
that
and
the
second
one.
Why
is
the
because
we
did
put
down
the
workflow
for
a
choir
as
an
enquires,
but
they
want
us
to
also
do
the
same
thing
for
some
other
workflows,
so
so
I've
added
a
two
short
one
well
for
one
is.
B
This
is
like
a
signal
if
you
want
to
send
a
sick
hub
signal
to
your
part,
what
do
you
do
and
then
the
other
one
is
the
send
signal
to
change
log
level
so
yeah,
so
this
one
so
just
to
simplify
things,
just
assume
that
we're
only
sending
those
to
one
container
in
the
pod,
and
in
this
case,
so
the
signal
is
defined
in
the
container,
notify
action
inside
the
container
and
then
the
we
have
an
external
controller
which
will
create
a
notification
object.
B
You
request
this
signal,
cumulate,
watches
the
notification,
object
and
get
notified,
and
then
it
will
send
this
signal
to
the
container.
So
this
is
like
a
docker
kill
with
a
c-hub
signal,
and
then
the
probe
in
this
case,
we'll
just
be
checking
to
see
the
container,
is
whether
the
container
is
still
running.
B
If
the
probe
detects
that
the
container
is
no
longer
running,
that
means
the
signal
is
sent
and
it's
successful.
So
then
google
sets
the
succeeded,
fielding
container
notification
status
to
true.
If
the
content
is
still
running,
then
people
will
just
retry
and
probe
the
container
again
until
it
times
out
yeah.
So
this
is
a
very
simple
one.
B
Any
questions
on
this
this
is,
I
know
this
is
not
really
the
use
case
that
this
one
group
is
interested
in,
but
then,
since
now
we
are
trying
to
have
designed
this
api
as
a
more
general
api.
So
so
we
need
to
at
least
describe
how
this
would
work
as
well.
B
Yeah,
okay
and
similarly
there's
a
so
for
change.
Log
operating
is
very
similar
to
that
one.
Basically
user
want
to
change
log
level.
Then
the
external
controller
will
create
a
notification
object,
request
this
changelog
level
and
then
couplet
system
watches
it
and
gets
this
request.
It
sends
the
changelog
level
signal
that
is
defined
in
the
container
notification
to
the
container.
B
You
could
also
send
a
probe
to
check
the
existing
log
level
in
container
to
see
if
the
change
then
it's
changing,
then
it
sets
the
status
succeeded
to
two
so
very
similar
things.
One
thing
that
they,
they
were
actually
talking
about,
something
like
an
internal
signal
which
so
I'm
really
not
that
familiar
with
cubelet.
So
I'm
actually
not
sure
how
to
do
this
internal
signal.
So
I
don't
know
if
you
have
some
any
thoughts
about
that
the
internal
one.
They
also
ask
you.
B
She
was
talking
about
some
internships,
but
I'm
not
actually
not
quite
sure
how
to
do
so.
I
know
they
have
so
they
also
asked
about
using
this
for
a
node
shutdown
like
avid
node
right,
so
that
so
I
thought
about
that,
but
that
is
different
so
for
for
for
a
node
shutdown,
the
command
that
should
actually
be
run
on
the
node
itself,
not
really
inside
a
container.
B
So
oh.
A
No,
no,
no!
No,
it
is
the
same
yeah.
What
the
use
case
is
that
couplet
is
trying
to
solve,
is
when
a
node
is
marked
as
a
tent
pin
or
it
is
getting
shut
down.
It
would
like
kubulate
some
applications
that
would
like
couplets
to
send
graceful,
gracefully
exiting
signals
to
the
container
instead
of
just
erect
them
or
before
evict
them.
That's
one.
The
other
one
is
that
couplet
realize
there's
not
enough
resource
on
a
specific
node,
and
they
try
to
do
some
eviction
on
some
existing
containers
or
parts.
A
They
would
like
a
mechanism
to
let
the
containers
or
parts
know
that
I
am
running
out
of
resources,
I'm
going
to
give
it
to
so
that
in
space
this
is.
This
is
especially
interesting
and
important
for
some
stateful
workload
so
that
they
can
basically
have
time
and
their
chance
to
flush
whatever
the
stats
from
the
ram
into
the
disk.
B
But
is
that
comment
so
see?
That's
the
part
that
I
was
actually
checking
this
this
dot.
Okay,
I
actually
have
a
doc
here.
I
was
just
trying
to
check
like
what
they
are
sending.
I
think
it's
not
really
like
sending
like
a
sick
hopping
container.
I
believe
it's
something
else,
because
I
was
checking
well.
I
could
be
wrong,
but
I
was
really
I'm
not
really
familiar
with
this.
Maybe
there's
something
that
we
need
to
ask
them
about,
so
I'm
looking
at
the
stock.
So
this
is
a
sig
note.
B
Has
this:
they
have
this
working
group,
so
I
attended
once
they
have
the
stock
talk
about.
You
know
what
is
a
no
shutdown
like
how
to
detect
it?
They
talked
about
what
are
the
commands
that
will
be
considered
a
shutdown,
so
they
have
something
like
you
know,
you'd
be
running
something
like
this.
A
This
this
is
probably
not
very
related,
but
the
in
the
third
point
over
there
system
d.
Actually,
since
yeah
that
might
be
related,
I
think
it's
more
related
to
the
third
one
again,
please!
No!
No,
I
mean
I
mean
the
signals,
the
signals,
the
nodes
when
the
node
shuts
down
it,
motivates
to
kubernetes
being
able
sorry
the
cooperative
been
able
to
notify
stateful
workloads
hosted.
On
that
note,.
B
Oh
you're
saying
that
they
actually
you're
saying
they
they're
not
really
talking
about
shouting
down
the
note
about
talking
about
inform
the
parts
something
exactly
yeah
like
so
so.
Basically,
you
are
saying
this
use
case
that
we
have
this
workflow.
What
we
have
here,
maybe
it
is
what
they
want
like
sending
this.
It.
A
B
Can
we
ask
them
then
yeah?
I
was
not
quite
sure,
yeah,
because
they
so
I
they
because
they
asked
about
the
no
shout
out
thing.
I
know
they
have.
They
have
been.
They
have
a
dedicated
group
working
on
this
one.
So
this
is
a
very
complicated
thing.
I
really
hoping
that
we
don't.
We
don't
have
to
use
our
akh
to
solve
this
case.
It's
a
complicated
problem.
It
will
be
a
very
wide
scope,
so
I
I
I.
C
I
have
two
questions
like
why
sig
hub,
instead
of
sig
term.
B
Sig
transfer
two
abs
are
just.
This
is
just
one
example
that
I
found
okay,
because.
C
B
But
this
is
but
if
you
search,
but
if
I
search
for
like
a
docker,
kill
command,
I
see
this
this
example
so.
C
B
So
I
think
it
also
depends
how
how
we
are
passing
this
in
right.
So
I
think
if,
if
it's
sick,
so
if
we
okay
so
this,
I
think
this
is
something
that
I
actually
got
some
comments
from
inju
and
you
can.
I
was
asking,
I
think,
he's
probably
also
working
with
notes,
so
so
he
was
saying
he
was
actually
having
a
suggestion
to
ins
other
than
this
action,
which
is
the
you
know,
sending
a
comment
he
was
saying.
B
C
But
I
mean,
but
sig
term
is
the
default
like
if
you
don't
specify
a
signal
and
you
can
kill
something
you
get
sig
term
and
and
forever
for
the
vast
majority
of
things.
That
should
be
okay.
Typically,
when
you
want
to
send
something
other
than
sig
term,
it's
because
you
don't
actually
want
to
kill
it.
You
just
want
to
interrupt
it
or
wake
it
up
or
tell
it
something's
happening,
but
you
want
it
to
live
on
or
there's
the
kill,
dash
9.
B
I
yeah,
I
think,
probably
I
use
this
thing
also
because
of
this
issue.
I
believe
tim
mentioned
this
one
like
yeah,
fine.
We
can
change
that,
but
I'm
so
like
I
think
he
talked
about.
I
think
he
talked
about
cucado
signal,
dr
q,
or
something
yeah
so
and
he
talked
about.
I
think
I
think
that's
probably
why
I
use
this.
He
talked
about
c
cub,
so
I
think
yeah,
I'm
fine
I'll.
B
D
B
So
right,
so
you,
you
know
well
so
actually
ben!
Actually,
you
should
be
familiar
with
this.
You
have,
you
have
been
participating
in
maybe
all
the
meetings
right.
So
in
the
beginning,
you
know
we
have
the
execution
hook.
Crd
approach
right
and
also
tom
also
went
through
that
last
time
right.
So
that's
very
specific
only
for
this
acquiring
use
case
that
we
want
we
are
interested
in,
but
then
we
got
pushback
from
the
api
reviewer
saying
that's,
not
secure.
B
So
then
we
are
going
through
this
approach,
which
is
to
define
this
inside
the
container.
But
then,
since
we
were
doing
inside
the
container,
so
team
has
this.
You
know
request
long
time
ago.
He
always
wanted
to
do
this
so
since
we
are
going
to
define
this
in
as
a
container
in
aspect
anyway,
so
why
don't
we
make
this
more
general
right?
So
so
this
way
this
is
not
only
for
choice
anymore.
This
is
for
many
other
use
cases
as
well.
B
So
basically,
this
will
be
no.
This
will
be
this
so
like
this
use
case.
Actually
let
me
actually
go
back
to
my.
D
A
Yeah,
just
summarize
that
yeah
add
on
top
of
what
it
would
assume,
was
the
scorpion
ban
and
the
the
evolution
evolution
of
this
whole
proposal.
As
gene
stated
initially
with
the
crv
approach,
then
the
two
main
reasons
why
this
one,
which
is
sitting
in
kublets
and
introduced
quite
some,
actually
core
type
api
api
types.
A
A
That's
one,
the
other
one
is
that
they
traditionally
there's
no
good
way
to
express
imperative
signals
in
in
kubernetes
in
kubernetes,
and
then
team
got
this
request,
and
I
totally
think
that
request
is
legit,
especially
for
a
lot
of
existing
applications,
debuggers
or
programmers
engineers
using
signals
to
communicate
with
the
application
either
to
adjust
local
levels
or
dump
something.
It's
very
typical
and
very
noble
in
today's
commercial
software.
A
So
the
proposal
was
oh
yeah,
since
we
haven't
even
modeled
the
imperative
signals
in
kubernetes.
Why
don't
we
just
utilize
this
opportunity
to
add
more
use
cases
and
take
the
hard
route
and
the
height
route
now
becomes
defined?
Limited
number
of
or
supported
signals
in
kubernetes
in
kubernetes
also
offer
application
owners
the
ability
to
basically
define
the
corresponding
comments
they
want
commands.
They
want
to
run
as
execution
hook
via
the
notification
mechanism
in
this
state.
A
The
kubelet
will
be
the
executor
of
this
command
and
since
kubernetes
already
has
this,
you
know
super
sodu
or
whatever
privilege.
It
needs
to
run
any
comments
on
a
node.
So
we
thought.
E
C
E
C
A
Back,
that's
a
great
point
as
a
matter
of
fact,
there's
the
heated
discussion
over
that
and
does
the
compromise
the
prop.
You
see
the
prop
definition
over
there.
That's
exactly
to
get
what
you
were
describing
ben.
A
So
after
you
execute
a
command
against
a
container,
you
also
want
to
supply
a
prop
which
let
the
cube,
look
periodically
query
the
container
for
the
status
and
the
status
will
be
fit
into
a
vector
right.
I
think
a
condition
vector
that
tells
you
exactly
which
status
it
is.
It
has
been.
A
B
C
Because
I
think
what
we
have
to
be
thinking
about
is
like,
if
I'm
trying
to
build
like
a
backup
app
that
takes
a
backup
of
of
some
some
workload
every
15
minutes
like
then
every
15
minutes
it's
going
to
deliver
a
signal
that
says
you
know.
Do
your
question
things
I'm
going
to
take
a
snapshot
soon
and
you're
going
to
have
to
wait
for
some
signal
to
come
back
that
says
yep.
I
am
ready
for
you
to
take
that
snapshot.
Then
you're
going
to
have
to
take
the
snapshot.
C
Signal
that
says:
okay,
now
you
can
go
back
to
doing
what
you're
doing
and
if
that
whole
thing
takes
more
than
like
a
few
seconds
and
you're
doing
it
every
15
minutes
people
are
going
to
notice
right
because
your
your
app
is
always
going
to
be
going
up
and
down
and
up
and
down.
So
you
really
want
to
minimize
the
latency
in
any
one
of
these
steps.
A
Great
point
ben,
but
they
I
I
treat
this
problem
into
two
aspects,
reprop
is
probably
itself
is
not
gonna,
be
sufficient
to
cover
the
use
cases
we
were
talking
about,
especially
when
we
talk
about
queers
hooks
with,
as,
as
you
said,
we
don't
want
the
quiz
for
50
minutes
right,
the
first
time
you
might.
C
Quiet
for
for
10
seconds
out
of
every
15
minutes
to
take
your
snapshot,
but
if
it
takes
like
10
seconds
just
to
find
out
that
you've
successfully
quest,
you
could
easily
double
the
amount
of
time
that
you
are
quiet
because
you
don't
even
start
taking
the
snapshot
until
after
you
get
the
answer
back.
Yes,
I'm
quiet.
B
C
F
A
Should
we
discuss
this
in
the
meeting
right?
We
discussed
this
in
a
meeting
too
to
address
exactly
the
problem
right.
The
problem
is
that
you
don't
want
to
wait
too
long
for
choirs,
especially
and
this
feedback
loop,
that
there
are
actually
two
things
right.
We
can
do
one
is
to
define
the
contract,
so
one
could
execute
the
action
item
against
a
specific
container.
A
They're
gonna
be
some
as
stand
out
or
stand
arrows,
something
like
that
right
and
that
one
we
want
to
carefully
define
for
queers
and
queers,
so
that
application
owners
who
actually
implement
those
execution
hooks.
Those
hooks
need
to
return
a
special.
How
do
I
a
fixed
format
of
the
standard
out
or
standard
arrow
so
that
kubelet
can
translate
that
information
into
the
corresponding
response?
A
As
not
the
response,
the
stakes
of
the
notification
notify
action
item,
and
that
happens
in
the
first
round
when,
after
it
runs
the
commands,
it
gets
the
output
and
it
feels
in
the
output
into
the
stat
as
the
the
status
of
the
container
notification
notify
action,
and
the
prop
is
just
what
shin
was
trying
to
say.
Well,
what
she
was
saying
is
more
of
for
situations
like
if
you
send
the
signal
to
a
container.
A
You
don't
get
anything
back,
so
I
think
we
we
we
can
still
use
props
to
just
to
for
to
you
know,
avoid
not
receiving
anything
or
timeout
or
something
like
that
could
be
called
causing
an
exit
exit
against
the
container
it
times
out.
But
the
main
purpose
of
probe
is
not
really
for
the
choirs
and
anchors
hooks
case.
Okay,.
C
A
C
Object
that
you
could
establish
like
an
api
watch
on,
so
that,
as
soon
as
the
the
status
update
goes
to
the
api
server,
it
will
tell
anyone
who's
watching
it
that
there's
something
that
there's
been
a
state
change.
So
they
can
move
forward
like
that.
That
would
be
an
acceptable
amount
of
delay
to
do
it
through
an
api
watch
just
just
something
that
so
that
you
can
trigger
on
completion.
G
C
G
A
Requirement
sure
I
think
ben
was
trying
to
say
is
that
we
should
minimize
the
latency
introduced
by
the
execution
hook.
If
the
application
itself
needs
certain
time
to
to
quiz
or
unquest
the
application,
then
I
I
don't
think
we
can
effectively
solve
the
problem
here.
C
A
A
By
any
way,
I
I
don't
know
if
the
for
the
controller
for
the
crda
approach,
we
might
have
the
same
thing
right.
You
cannot
get
away
from
it.
A
C
C
A
B
I'm
not
sure
how
flexible
that
part
is
so
like
for,
for
example,
for
I
just
checked
like
the
the
probe
thing
live
list
probe
thing
they
basically
just
return
either
zero
or
some
some
number
positive
number.
I
think
zero,
meaning
success
or
anything
else
is
not
success.
Something
like
that
yeah.
So
I
don't
know
if
we
can
have
two
a
lot
of
choice
on
what
he
returned
there,
but
we
can
take
a
look.
B
So
I
want
to
just
refresh-
because
I
was
I've
been
talking
about
those
workflows
for
signals,
but
we
actually
had
this
workflow
before,
which
is
really
for
our
clients
use
case
right,
so
you
you
know
you,
let's
say
suppose
you
have
several
commands.
You
need
to
run
before
taking
snapshot
mysql,
you
need
to
log
table
flush,
disk
and
then
do
ifs,
freeze
so
and
then
take
snapshot
through
fsl
phrases,
unlock
tables.
B
So
we
had
this
one
before
but
sig
node
they
want
to.
They
want
us
to
provide
workflows
for
other
use
cases,
they're
saying
oh
you're,
only
providing
only
one
use
case.
B
So
that's
why
we
added
those
those
short
workflows
that
we
just
talked
about
earlier,
so
that
we
covered
everything
right
so
otherwise,
if
it's
just
for
our
working
group,
of
course
we
this
is
what
we
are
interested
in,
will
only
be
showing
this,
but
they
want
to
make
sure
this
api
designed
also
works
for
other
use
cases
that
we
are
trying
to
cover
here.
So
that's
why
we
only
talked
about
this
here.
B
Let's
see
anything
else
for
for
this.
Oh
shanghai,
remember
there's
a
they
are
saying
there
are
some
limitations
with
the
probe
like
how
many
probes
you
can
do.
Do
you
remember,
I
didn't
write
it
down.
I
forgot
that
what
is
the
they
think
this?
They
have
some
example.
How
many
probes
you
can
do.
Do
you
remember
that
part.
A
It's
not
about
how
many
quotes
is
about
cooper's
performance
concern.
There
are
two
concerns.
Basically
one
is
that
how
frequently
should
cupid
be
running
those
problems
and
and
when
you
should
be
triggered-
and
one
idea
is,
of
course
you
could,
regardless
whether
there's
any
action,
another
is
going
to
continuously
call
the
prop
code,
regardless
and
after
the
status.
A
Now,
since
the
note
object-
or
the
container
object
already
has
where
we
reach
information
already,
so
they
want
to
limit
the
number
of
status
that
sits
in
every
single
prop
code.
So
I
I
think
team
put
some
fake
number
over
there
as
a
first
sort,
some
eight
per
eight
props
max
or
something
like
that.
A
That
needs
to
be
re-evaluated
and
being
reviewed
by
a
signal
team.
If
this
is
the
pro,
if
the
proposal
gets
through.
A
B
A
B
B
Yeah,
but
he
said,
he's
okay
with
either
way,
but
if
separate
then
yeah,
I
guess
it's
okay,
but
I
don't
know.
I
thought
this.
This
is
not
clear
for
me
to
to
put
them
together
to
think
about
them
together,
otherwise,
otherwise
they
can.
I
think
they
can
have
the
same
name
to
correlate.
I
guess
yeah.
I
just
feel
this
is
more
clear.
A
Yeah,
just
just
to
just
to
communicate
back
to
the
group,
one
of
the
biggest
concerns
that
signal
has
is:
this
is
a
such
powerful
thing
and
they
literally
introduce
imperative
where
you
can
execute
any
command
against
any
container.
We
are
calculate
at
any
given
time
as
long
as
it's
defining
a
power
definition.
Yes,
the
part
owners
still
owns
the
definition
of
the
command
and
still
owns
the.
How
how
to
write
up
all
these
comments.
A
However,
anyone
who
has
accessibility
to
create
those
notifiers
will
be
able
to
trick
those
comments,
so
they
are
afraid
the
concerned
of
those
notifiers
get
abused
and
even
get
attacked.
So
honestly,
I
don't
have
a
good
answer
for
that.
I
think
cooperate
already
have
this
problem,
because
this
coupe
exit
itself,
it
is
doing
this
thing
exactly
and
it's
less
controlled.
B
A
I
think
the
key
is
that
we
need
to
have
some
limitations
to
start
with
and
some
reasonable
limitations
to
start
with,
and
then
we
can
evaluate
that.
B
Yeah,
so
if
you
even
just
look
at
the
existing
probes,
those
are
very
powerful.
It's
very
tricky
on
how
to
set
it
correctly,
like
the
liveness
probe,
you
know,
because
it's
going
to
restart
container
if
detected
not
live
anymore
right,
so
that's
very
could
be
dangerous.
If
it's
not
done
right
could
cause
hands,
sometimes
so
that's
already
very
tricky
for
the
for
those
existing
ones
like
they.
Have.
I
see
that.
C
I
can
see
the
argument
why
this
is
a
little
bit
more
scary
than
than
cube
control
exact,
because
I
mean
you,
don't
you
never
really
need
to
use
the
exact
command
to
do
most
things
and
and
a
kubernetes
administrator
could
take
the
stance
that
look
no
one's
going
to
exec.
Anything
in
my
in
my
cloud
and
you
can
still
all
get
your
work
done
and
that's
fine.
C
I
think
the
the
problem
with
the
notifiers
is
is
what's
going
to
happen
is
once
once
they
get
introduced
once
we
start
using
them
like
you're,
not
gonna,
be
able
to
realistically
turn
them
off
and
still
expect
things
to
work.
Well,
because
things
are
going
to
start
to
depend
on
them.
So
they're
going
to
become
the
kind
of
thing
where
everyone's
going
to
have
to
have
them
enabled
and
our
back
is
going
to
have
to
be
enabled,
and
so,
if
it's
as
bad
as
exec.
C
A
B
C
A
Thing,
I
think,
there's
a
there's
a
distinction
over
here:
the
application
owners
they
don't
necessarily
need
to
have
access
to
container
notify
action
creation.
They
need
to
define
those
things
in
the
pot.
That's
all,
but
they
don't.
They
are
not
necessarily
the
executor,
the
executor.
The
controllers
application
controllers
will
take
case,
take
care
of
the
snapshot
in
the
backup
right
and
you
need
back
all
battery
rules
for
those
you
don't
necessarily
need
our
back
rules
for
application
owners.
Of
course,
maybe
you're,
not
testing
phrase.
C
A
C
C
B
Yeah,
so
we
need
to
so
right
now
they
didn't
say
100.
No,
they
are
still
saying
hey.
Can
you
show
us
this?
Can
you
show
us
that,
so
that's
what
we're
trying
to
do.
We
show
them
this
and
then
see
what
is
their
next
requirement
right?
If
they
just
completely
say:
oh
no
100.
No,
then
we're
going
to
go
talk
to
tim.
Who
is
the
kerry,
will
say?
Okay,
then?
What
should
we
do,
then?
Maybe
we
need
to
narrow
down
the
scope
or
something
right.
So
I
think.
C
C
B
So
to
make
this
the
scope
smaller,
what
I'm
saying
is,
I
think,
even
tin
mentioned
that
or
maybe
we
need
to
do
something
more
specific
just
for
this.
I
think
he
would
like
to
do
this
for
a
more
general
purpose,
but
maybe
then
we
just
do
this
for
choice.
I
think
he
did
mention
something
like
that.
We
haven't
got
that
point.
Go
to
that
point
yet
right.
So
that's
all
right.
A
All
right
in
a
smaller
scope,
xin
and
I
are
actually
on
the
same
page
as
word
ben
you
were
describing
both
of
both
both
of
us
actually
wants
to
move
forward
with
certain
decision
as
soon
as
possible,
and
that
this
has
been
couple
months
already
back
and
forth
for
the
design.
They
are
concerns
around
the
container
notifier
approach.
A
We
took
this
hot
road,
we
know
it
is
hard
and
we
know
it
is
going
to
be
challenging
to
introduce
new
core
types
as
well
as
introduce
complexities
into
kubernetes
in
the
beginning,
so
anticipate
that,
but
we
also
see
the
value
of
it
to
be
to
be
fair
right.
Team
is
behind
all
this
to
push
the
effort
forward
and
he's
been
very
helpful
by
helping
us
convincing
signal
people,
but
he
also
acknowledged
that
this
is
something
that
was
a
very
thorough
thinking
and
a
design
around
how
we
do
that.
A
He
is
not
against
the
idea
of
taking
the
crd
approach
as
well,
but
what
one
thing
I
think
she-
and
I
we
need
to
do-
is
to
follow
up
with
the
security
team
to
figure
out
what
exactly
are
the
concerns
around
control?
Grant
controllers
super
privilege
so
that
it
can
run
x,
exit
against
any
containers.
B
B
C
I
was
just
going
to
mention
that
there's
the
kubernetes
are
back
type
access,
control,
questions
that
are
important,
but
we
can't
lose
sight
of
the
other
access
control
questions
which
are
the
level
of
privilege
on
the
node
that
required
to
do
the
things
that
we
want.
Like
you
mentioned
with
mysql,
you
want
to
do
an
fs
freeze,
like
you,
can't
do
an
fs
freeze
from
inside
a
container
unless
the
container
is
running
with
just
this
happening.
G
C
A
A
A
So,
in
order
to
speed
the
process
a
little
bit
more,
two
things
will
definitely
help
that
I
can
tell
one
thing
is
that
we
have
more
concrete
use
cases
of
using
those
container
modifiers,
especially
the
cases
where
we
need
to
somehow
signal
a
certain
part
of
a
container
to
support
the
point
that
a
container
notifies
actually
a
thing
that
everybody
wants
in
kubernetes
work.
That's
that
that
would
definitely
help.
If
anyone
has
those
use
cases,
please
please
let
us
know,
I
mean.
A
Yeah
they're,
not
okay,
they're
interested
in
more
generic
signal,
usages
or
similar
use
cases
that
can
you
utilize
this
nullifier
and
that's
one
and
the
other
one.
Is
this?
The
you
know
both
proposals
faces
a
serious
challenge
in
in
terms
of
security
concerns.
A
C
C
G
A
Yes,
yes,
dave.
I
have
to
agree
with
you
that
this
is
way
beyond
our
scope,
but
again
we
took
the
hot
route
not
because
not
because
it
is
only
gonna.
It
is
only
gonna
just
overall
problem,
but
we
took
it
because
it's
gonna
just
solve
a
broader
problem
which
is
not
bp
related,
but
some
a
lot
of
people
actually
likes
it
in
kubernetes.
A
All
right,
since
you
want
to
move
on
to
the
next
one,
we
have
10
minutes
left
with
this
session
and
we
won't
see
any
questions
open
questions.
B
Okay,
yeah
sure
yeah
we
can.
We
can
just
talk
about
next
one
quickly
and
then
we
can
maybe
taco
or
that
more
next
time.
So
so
the
next
one
is
the
data
okay.
So
we
have
the
data
protection
workflows.
So
we
need
to
start
a
discussion
on
this
early
on,
but
we
didn't
continue
so
we
just
put
together.
This
is
a
more
simple,
simplified
version
of
how
to
what
other
workflows
in
data
protection,
so
you
know,
have
a
table
of
content
just
getting
started.
B
So
I'd
like
to
get
people
in
this
one
group
who
are
interested
in
contributing
to
work
on
the
stock
together.
So
this
is
a
you
know.
More
is
simpler
than
what
we
had
discussed
earlier.
So
this
one
would
be
I'll
just
go
through
the
table
of
contents
right,
so
why
we
need
to
have
data
protection
kubernetes.
What
is
currently
there
and
what
is
missing,
and
we
want
to
figure
out
how
to
identify
resources
and
the
backup
and
store
workflow
and
then
the
last
one
is
application
snapshot
by
governance
or
fill.
B
So
we
can
come
back
and
go
over
this
in
the
next
meeting
and.
A
Yeah
I
yeah
on
top
of
what
she
was
describing,
I
think.
Initially
we
had
this
initiative
to
kind
of
come
up
with
a
white
paper
of
this
whole
working
group
and
what
are
the
items?
What
are
the
workflows
we
want
to
achieve
right
and
from
there
we
identify
different
components
like
in
different
systems,
either
foreign
storage
or
now
sig
note
to
support
those
workflows
and
think
it
actually
was
my
it
was
on
me
and
in
the
middle
we
dropped
the
ball
a
little
bit,
and
now
I
discussed
with
the
shin.
A
A
We
are
expecting
the
anyone
in
the
working
group
who
are
interested
to
give
us
input
in
this
doc
by
either
editing
the
content
or
comment
on
this
or
giving
feedback
on
the
items
et
cetera,
et
cetera,
so
that
we
can
create
a
have,
a
clear
kind
of
roadmap
concept
of
this
working
group.
We
can
then
move
on
different
components.
B
Yeah,
so
if
you
are
searching
so
if
you're
interested
just
you
know,
let
us
know
and
or
you
can
also
add
comments
on
stock
as
well.
So
so
just.
H
To
because
there
were
multiple
ways
to
help,
so
can
we
go
through
this
because
comments
is
easy,
but
what
would
be
the
preferred
way
to
help
like
what?
Because
27
people
whacking
at
a
document
is
fun
but
not
productive
right?
What
what
would
you
prefer
that
we
do.
B
Why
don't
you
just
I
like
to
see
who
are
interested
in
first,
and
maybe
you
can
see
how
we
can
maybe
divide
the
dock
into
several
pieces
and
then
maybe
some
a
few
people
can
work
on
one
section:
the
other
people
can
work
on
the
other
section.
We
can
do
that
way
or
you
can
also
yeah.
You
can
also
add
comments
here
as
well.
So
why
don't
you
just
you
know
whoever
are
interested
in
contributing,
please
email
me
and
sean
chen.
B
Then
we
can
figure
out
how
to
move
over
yeah.
Let's
think
if
there
are
too
many
people
modifying
the
same
personality,
so
probably
one
need.
B
We'd
like
so
you
remember
that
this
is
actually
in
our
charter.
We
actually
have
one
that
is
yeah,
but
I
think
initially
we
had
some
meetings.
I
think
they've
also
put
together
a
like
outline,
but
that
has
a
very
wide
scope,
so
this
is
a
much
smaller
scope.
I
think
it's
more
achievable,
so
I
would
like
to
see
what
we
can
come
up
with
and
then
we
can
actually
eventually
upload
this
one
to
the
community
repo
under
our
working
group.
B
B
Yeah
we,
I
think
we
should
start
with
the
you
know
from
the
beginning
right
and
then,
of
course,
that
you
know
the
last
one
is
more
complicated.
We
haven't
really
spent
much
time
talking
about
that.
Yet
so
probably
we
need
to
put
those
section
on
hold.
First,
maybe
we
need
to
start
with
the
the
easier
or
more
well-known
sections.
First.
A
I
think
stephen
has
a
very
good
question
with
regarding
how
we
can
collaborate
on
this
effort.
Xin
and
I
shouldn't
I
will
take
an
action
on
item
on
that
at
this
stage.
I
think
yeah.
If
you
are
interested,
please
shoot
us
an
email.
Then
we
can,
you
know,
have
a
smaller
discussion
around.
How
do
we
work
together
on
this
talk
exactly.
A
A
B
Yeah
we
have
this
just
want
to
show.
I
mean
we're
not
really
just
quickly.
This
is
just
we
got
pinned
down
this
one.
So
the
the
thing
the
steering
committee
just
started
this
one.
They
want
to
have
more
communication
with
the
working
groups
to
see
how
we
how
we
are
doing
so
they
just
pinned
us.
We
just
need
to
answer
a
few
questions
here.
I
think
I
think,
should
be
straightforward.
I
don't
see
shouldn't
be
too
difficult
right.
So
basically
there's
a
section.
I
think
it's
for
the
okay
yeah.
B
I
think
part
of
the
section
like
the
mission,
the
road
map
and
the
what
you
have
done-
and
you
know
things
like
that
so
yeah
so
society
and
is
going
to
just
going
to
answer
this
question,
and
maybe
you
guys
can
comment
on
that
and
then
we
can
send
it
out.
So
this
shouldn't
be
too
difficult,
but
it's
just
they
just
added
this
formal
thing
recently.
Actually
we
just
got
pinned
yesterday
on
this
one,
so
yeah.