►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 07 January 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
Thank
you,
okay.
So
before
we
go
into
this
topic,
let's
get
an
update
on
the
project.
So,
let's
start
with
the
nicholas
actually
so
yesterday
in
nicholas
I
was
I
was
trying
to
utilize.
B
The
customization
template
to
you
know,
deploy
so
first
thing
that
I
did
was
we
don't?
Have
the
images
actually
deployed
anywhere?
So
we,
you
know,
I
got
access
to
key
dot,
io.
B
Where
we
have
our
images
by
the
same
name,
that
was
specified
in
in
the
template,
so
we
have
object,
storage
controller.
Let
me
also
bring
the
template
up.
B
B
Yeah
contain
object,
storage,
object,
storage
controller,
so
we
created
that
repository
pushed
the
latest
version
of
the
code.
B
Oh,
we
brought.
D
D
B
E
B
Okay,
if
it's
possible
to
get
official
reports,
we
would
like
to
get
started
on
that.
To
be
honest,.
E
F
A
I
think
the
only
problem
is
it's
only.
You
can
only
upload
the
one
that
is
formally
released.
You
can't
do
like
later,
so
those
images
cannot
be
there.
So
that's
the
problem
if
you
want
yeah,
so
maybe
yeah.
If
you
want
to
just
to
go
ahead
with
this
one
for
now,
maybe
try
to
use
that
later.
That's
I'm
fine!
I
just
I'll
just.
F
F
A
Your
you
have
a
pr.
I
also
have
the
same
question
there:
okay,
it's
fine
yeah.
B
Yeah,
I
think
we
should
add
an
issue
here,
though
we
shouldn't
forget.
F
Yeah
I'll
do
that
I'll,
take
care
of
that
and
yeah
you're
right
I
mean
you,
you
asked
the
same
question
on
my
pr.
Probably
you
know
the
reason
we
need
the
product
is
edge
to
be
in
because
some
of
the
posts
submit
jobs
so
depend
on
that.
So.
E
F
Now
I
think
we
will
have
to
merge
that
pr
as
soon
as
possible
and
then
iterate
on
that
as
we
decide
these
things.
B
Okay,
so
I
try
to
deploy
using
the
customization
template
here,
so
just
cube
ctl
create
dash
k,
okay
for
customize
and
in
this
directory.
So
this
specification
of
the
crd.
I
understand
why
it
has
been
put
this
way,
but
this
doesn't
work.
B
So
I
I
understand
that
we're
trying
to
specify
the
directory
where
all
the
cids
are
in
the
api
repo,
but
it
doesn't
work.
It's
it's
actually
invalid
syntax.
I
mean
it's:
it's
not
able
to
retrieve
that
path.
G
I
literally
tried
doing
that
before
doing
the
pr.
So
let
me
it's
an
interface
controller.
B
Yeah,
it's
possible
that
you
know
I
don't
have
a
config
set
or
something
like
that
or
maybe.
G
I
G
I
don't
know
what
using
customized
version.
G
G
B
Yeah
or
I,
what
I
did
was
I
copied
over
the
crds
to
a
local
directory
and
then
pointed
to
the
local
directory
just
for
testing.
G
H
Okay,
so
nicolas
as
a
follow-up,
could
you
add
an
issue.
E
B
Yeah
I'll
have
to
fill
this
up
later,
but
I'm
gonna
assign
it
to
you
nicholas,
since
you
know
the
best
about
qcpl
customize.
What
is
your,
what
is
your.
B
It's
okay,
so
I'll
just
assign
it
to
myself,
but
you
know
so
that
others
don't
take
up
the
issue,
but
yeah
we'll
have
the
understanding
that
that
you'll
take
your
you
know.
You
look
into
this
issue.
E
B
Okay,
so
okay,
so
that
was.
That
was
the
first
issue
that
I
faced
once
we
got
over,
that
it
deploys
just
fine.
It
works
just
fine.
Once
we
went
through
that
there
was
some
issue
with
installing
the
provisioner.
B
Okay,
I'm
getting
it
wrong,
but
regardless
I
won't
go
into
the
details
right
now.
The
the
reason
I
brought
this
up
is
because,
as
as
things
are
right
now,
we
have
all
the
code.
We
have
all
the
logic
built
in
for
the
demo.
For
the
first
demo,
however,
the
one
final
step
which
is
integration
is
not
is
not
yet
in
place,
even
though
we
can
technically
do
the
demo
already.
B
The
the
goal
we
set
for
the
demo
was
that
whatever
we
show
in
the
demo
is
not
smoke
and
mirrors
or
is
not
something
that's
ahead
of,
what's
already
checked
in
so
before
we
do
the
demo.
I
want
to
make
sure
that
integration
is
done
to
such
an
extent
where
users
can
just
fork
the
controller
repository
and
should
just
be
able
to
do
cubesat
applied
hk
and
the
full
stack
should
get
deployed.
B
I
don't
think
we're
very
far
from
it.
We've
come
a
long
way.
We
just
need
to
iron
out
the
customized
issues.
B
Okay,
so
that's
one
thing
that's
left
for
before
the
demo.
The
other
question
that
I
want
to
ask
all
of
you,
so
we
need
help
with
with
documentation.
E
So
in
the
pull
request,
yeah
here.
E
If
samus
is
here,
we
could
we
can
discuss
this.
However,
the
issue
was,
let
me
see.
B
B
Someone
just
tried
to
have
tab
like
headers
here,
however,
markdown
does
not
render
html
and
anything
that's
rendered
is
because
of
the
browser.
It's
generally
not
a
good
idea
to
go
to
go
down
this
route
so.
B
If
someone
else
is
available
to
help
with
this
documentation,
if
one
of
you
could
guide
summers
and
work
with
them
to
get
this
documentation
done,
that
would
be
great.
It
is
actually
quite
important
that
we
get
it
done,
because
we
have
more
and
more
people
interested
in
understanding
where
we
are
at
and
how
we
work
cozy
the
project.
B
So
we
created
this
project
board,
which
is
definitely
useful.
However,
we
don't
have
documentation
that
describes
how
quasi
works,
for
instance,
yesterday
or
day
before
yesterday,
someone
from
rook
io
reached
out
wondering
what
the
state
of
the
project
is
and
basically
how
things
work
and-
and
I
was
able
to
respond
to
them
on
slack
and
and
I
would
also
encourage
participation
there.
B
However,
I
think
it
is
much
more
efficient
to
have
a
documentation
in
place.
Are
you
thinking
along
the
lines
of
a
design,
doc
or
something
else?
So
I
think
just
to
begin
with.
We
should.
We
should
start
out
with
the
spec
doc
like
csi
has,
and
a
small
readme
csa
has
a
beautiful
documentation,
container
storage
interface.
B
B
I
think
this
would
be
the
first
priority,
because
the
first
point
of
integration
that
that
we
want
people
that
we
expect
people
to
do
is
by
writing
a
driver,
and
if
we
start
the
process
now
we
will
have
something
that
is
more
or
less
usable.
In
a
few
weeks.
B
B
Okay,
so
again,
I'm
reaching
out
to
all
of
you
there
are.
There
are
tasks
open
for
documentation,
I'm
going
to
add
yeah,
I'm
going
to
add
some
more
information
about
what
kind
of
docs
we
want
and
and
a
basic
style
guideline
into
these
issues.
B
So
it's
clearer,
but
you
know
this
is
going
to
be
a
team
effort
and
and
people
are
going
to
start
using
cozy
more
and
more
and
and
it
is
our
responsibility
to
make
sure
that
they
have
all
the
information
that
they
need.
So
so
anyone
who
is
available
to
contribute
please
reach
out
to
me
or
start
making
prs
for
these
open
issues.
It
will
be
much
appreciated.
B
The
next
thing
is
okay,
so
those
are
the
two
main
things:
integration
and
documentation-
that
that
is
a
big
focus
for
this
week
and
probably
next
week
as
well,
documentation
is
going
to
be
a
continuous
effort,
but
integration.
We
should
have
a
basic
grasp
on
it
by
next
week,
so
before
next
thursday.
B
Okay,
so
that
is
in
terms
of
progress.
Now
I
want
to
get
into
how
we've
designed
deletion
and
finalizers.
B
So
in
order
to
move
forward-
and
you
know
we-
we've
been
discussing
quite
a
bit
technically
and
I
don't
believe
I've
had
a
chance
to
explain
some
of
the
technical
decisions
that
we
made
with
the
community,
and
I
think
it's
very
important
that
that
this,
this
architectural
design
decision
is
done
together.
E
B
B
So
I
want
to
talk
about
deletion
and
finalizers,
so
we
have
buckets
which
follow
this
basic
workflow.
A
bucket
request
is
created
which
leads
to
a
bucket
being
created
and
which
utilizes
a
bucket
class.
But
for
this
discussion
by
class
is
not
relevant
and
then
a
bunch
of
bucket
accesses
refer
to
this
bucket.
B
Now,
a
basic
expectation
is
that,
while
a
board
is
using
a
bucket,
the
bucket
should
not
be
deleted
from
underneath,
and
something
like
this
can
be
easily
achieved
by
using
finalizers
we've
discussed
and
we've
even
written
in
the
cap
that
we'll
use
finalizers
to
make
sure
that
buckets
are
not
deleted,
while
pods
are
using
it.
But
this
discussion
goes
into
how
exactly
we'll
do
that
so
into
a
bucket
object,
I'll
I'll
get
to
how
bucket
request.
Finally
is
also
work,
but
let's
start
with
this.
B
B
B
E
B
B
Should
the
I
mean
one
of
the
ideas
is
we
should
allow
the
user
to
also
delete
the
bucket.
So
in
that
case,
if
a
bucket
request
is
deleted,
we
will
trigger
the
deletion
of
the
bucket
as
well.
Now
there
is
an
other.
B
Question
here,
which
is
we
shouldn't
the
admin
shouldn't
delete
the
bucket,
while
a
bucket
request
is
referring
to
it
now.
My
question
is:
is
that
even
a
concern,
should
we
even
be
designing
for
that.
B
I
don't
think
it
was
clear,
so
let
me
let
me
reiterate
this,
so
there
are
two
scenarios
one
is
and-
and
you
know
we
can
enable
either
of
them,
and
this
is
the
question
of
usability
if
a
user
creates
a
bucket
request
and
that
leads
to
the
creation
of
the
bucket,
should
the
user
be
able
to
delete
the
bucket
by
deleting
the
bucket
request.
J
Sid,
what
doesn't
the
workload
come
into
play
in
that
question?
Because
if,
if
I
create
a
br-
and
I
have
a
pod
consuming
the
bucket-
also-
which
is
the
most
common
case-
and
then
I
delete
my
br,
but
the
pod
is
still
running.
J
I
assume
the
previous
scenario
means
that
the
things
won't
get
cleaned
up
on
the
on
the
k8
side.
That
will
keep
will
ignore
that
delete
on
the
br
for
a
while.
You
know
due
to
a
finalizer
until
the
pod
is
done
right.
So
if
a.
B
B
Then
you
know
the
bucket
cannot
be
deleted,
and
so,
since
the
bucket
is
still
alive,
bucket
request
is
not
is
not
deleted.
Right.
J
J
And
so
the
the
bucket
instance
won't
be
deleted
until
all
workloads
are
done
with
the
bucket
right.
J
B
By
itself,
no,
but
if
the
user
decides
to
delete
the
bucket
request
on
the
bucket
access
a
bucket
access
request,
then
the
bucket
access
request
deletion
will
trigger
the
deletion
of
the
bucket
access.
J
B
B
B
J
J
B
J
Go
away
at
that
point,
how
do
we,
the
cozy,
draw
the
csi
driver
or
a
cozy
driver
the
the
interface
with
the
cube
when
the
when
the
pod
finishes
we
get
a
node,
unpublished,
volume
call
and,
and
what
we'll
essentially
do
is
remove
one
of
the
finalizers
on
the
ba
and
then
when
they're
all
gone,
then
the
ba
naturally
is
deleted.
B
J
Well
right,
and
so
that
that's
in
part
why
I
asked
the
question,
because
a
philosophy
could
be
that
cozy
never
deletes
a
user-created
resource.
So,
as
a
user
I
create
the
br
or
I
create
the
bar
closing
won't
delete
them.
I
have
to
do
it.
It's
my
I
so
in
that
case,
if
that's
the
philosophy
we
adopt,
cozy
will
never
delete
the
bar.
B
A
B
B
A
A
Because
what
if
ba
is
not
removed,
then
how
are
you
going
to
link
this
together?
Again,
I
mean
so
the
ba.
If
ba
is
not
deleted
and
then
the
finalizer
is
removed,
then
what
was
the
point
of
having
the
finalized
in
the
first
place
absolutely
want
to
avoid
it.
B
Yeah
I'll
explain
that,
so
we
don't
wait
for
the
ba
to
be
removed.
That
just
means
we
call
delete
on
the
ba
and
if
the
finalizers
are
gone
from
the
ba,
the
ba
goes
away.
A
A
C
A
B
Well,
it
will
be
a
terminating
resource.
I
don't
you
know,
I'm
looking
for
input
here.
Let
me
put
it
that
way.
So
is
it
technically
speaking
if
we've
started
the
deletion
of
the
ba,
then
as
long
as
you
know,
it
doesn't
get
deleted
until
all
the
finalizers
are
removed,
but
you
know
it
actually
represents
that
that
token
is
still
alive
so
or
it
is
still
in
use.
B
J
Yeah,
but
we
don't
want
what
we
there's
a
one-to-one
mapping
between
a
b-a-r
and
a
b-a
right.
That's
correct!
Isn't
it
so
so
if
I
delete
the
b-a-r
and
that
and
there's
a
finalizer
on
the
bar
and
that
causes
cosy
to
do
to
to
attempt
to
delete
the
ba.
But
the
ba
has
finalizers
because
there's
an
app
pod
right,
okay,
so
deletion
timestamp
is
set,
but
but
now
we're
we're
just
stuck.
J
I
mean
the
api
is
not
stuck
it
will
it
will
return,
but
but
we
haven't
really
done
a
deletion
and
so
now,
let's
say
the
application
pod
is
done.
The
node
adapter
deletes
the
finalizer
on
the
ba.
Let's
just
say:
there's
one:
the
ba
goes
away.
We
need
to
know
that
the
ba
went
away
so
that
we
can
remove
the
finalizer
on
the
bar
and
clean
that
up
and
there's
but
shane.
There
could
be
windows
and
time
where
we
have
a
bar,
but
no
ba
or
you
know,
because
we're
just.
B
Right
that
part
is
okay.
I
think
what
shrink
is
bringing
up,
I
think,
is
valid.
I
I
just
don't
know
if
it's
okay
to
leave
it.
That
way,
though
it's
it's
basically.
A
That's
what
we
so
that's
what
we
have
done
for,
like
one
snapshot
of
one
snapshot
content.
We
have
the
same
type
of
thing,
finalizers
right,
so
we
to
avoid
leaking.
We
always
want
to
make
sure.
First,
you
want
to
make
sure
the
physical
volume
is
for
the
physical
snapshots
deleted
before
we
remove
the
finalizer
on
the
the
content
and
then
making
sure
that
the
content
is
removed
before
we
remove
the
finalizer
on
the
snapshot
itself.
So
it's
similar
to
this,
but
we
make
sure
there
are
no
resource
leaking.
B
I
see
so
I
mean,
let
me
ask
this
way
if
we
start
the
deletion
of
the
bar,
that
is
also
going
to
remain
stuck
until
all
the
parts
are
done
with
it.
So
is
that
okay,
yeah.
A
That's
that
that
is
yeah.
That's
what
finalizes
that
for
right!
That's
that's
why
we
have
finalizers,
because
otherwise
your
finalizer
is
not
really
doing
much.
If
you
remove
that
so
early,
then,
if
you
don't
have
finalizer,
it's
going
to
be
the
same
like
what's
the
point
of
even
have
the
finalizer,
if
you're
not
preventing
it.
B
So
the
only
reason
is
there
is
a
design
challenge
with
this
and
it's
a
solvable
problem
and
we
already
know
the
solution.
So
the
challenge
is:
if
we
are
going
to
have
that
bar
remaining,
then
we
need
to
somehow
know
that
the
ba
is
has
been
deleted.
The
ba
is
gone
when.
A
B
The
ba
controller,
the
if
it's
listening
on
delete
events,
the
v8
controller,
can
go
down
just
on
the
delete
event
comes
in
and
when
it
comes
back
up,
it
won't
get
the
delete
event.
So
we
could
miss
that
event.
However,
it's
there's
a
solution
around
it,
which
is
on
the
bar
controller
during
a
sync
call.
B
So
every
resync
period,
all
the
resources
are
basically
added
back
and
during
that
call
we,
you
know
you
get
an
update
request
in
the
controller,
so
we
should
just
check
if
division
timestamp
is
set,
we
should
also
set.
We
should
also
check
if
the
ba
corresponding
to
this
bar
is
still
alive,
and
if
that's
the
case,
if
you
know,
if
it's
not
alive,
then
you
know
we
can
go
and
remove
the
finalizer
from
the
br.
I
Well
but
but
he
didn't
didn't
say
that
exactly
by.
A
The
way
you
have
to
have
like
two
separate
controller,
like
one,
cannot
check
the
other
resource
at
this
audio.
Not
I'm
not
familiar
with
your
controller,
I'm
not
sure.
How
are
you
saying
you
have
one
controller
for
baa,
one
kind
of
br
they're
completely
separate.
I
think
you
should
have
like
a
central
control
that
education.
B
They're
not
completely
separate.
My
my
concern
is
the
the
controller
loop.
That's
listening
to
ba
events
could
potentially
miss
the
delete
event.
A
I
A
B
A
B
Yeah
yeah,
that's
the
solution.
I
just
suggested
yes,
okay,
yeah,
so
so
this
this
works
then
so
is
rob
here.
Rob
was
working
on
this.
Oh
sorry,
sreeniva
was
working
on
this
correct.
B
B
So
is
this
what
we
decided
that
hey
is
this,
what
we
decided
that
we
will
wait
for
the
ba
to
be
deleted
before
removing
the
bar,
the
finalize
on
the
br?
That's
true,
yeah,
okay,
okay!
For
some
reason,
I
remember
it
the
other
way
where
we
said
we'll
trigger
the
deletion
of
ba
and
then
we'll
just
go
ahead
and
remove
the
finalizer.
J
B
Timestamp
is
set
and
if
there's
only
one
finalizer
left
and
it's
time
to
remove
this
finalizer,
then
at
that
point
you
go
ahead
and
delete
the
token
right,
because.
J
Okay-
and
I
know
in
general-
probably
revoke
is
fast,
but
if
you
think
about
but
but
but
potentially,
let's
just
say,
theoretically
what,
if
revoke,
is
very
slow
at
the
driver's
side?
Do
we
do
does
cozy
do
anything
like
the
physical
delete
of
a
bucket
could
be
very
slow,
but
but
we're
talking
about
bars
instead
here,
but
still
the
do.
We
does
it
matter
to
us
if
the
driver
is
very
slow
to
respond
to
a
revoke
request.
B
We
we
could
design
for
a
long
revoke
operation.
However,
I
think
that
concern
is
more
applicable
in
case
of
buckets
agree.
I
agree,
so
I
wouldn't
worry
about
you
know
long-running
revoke
operations.
B
We
could
go
with
what
we
have
and
let's
say
we
go
out
there
and
and
we
find
that
to
be
a
valid
concern.
We
can
always
you
know
come
come
back
and
fix
it,
but
I
don't
believe
your
work
should
take
long
in
any
scenario.
J
J
Do
we
need
it?
I'm
just
saying
I'm
not
sure
we
do
either,
but,
let's
just
say
the
in
the
in
the
in
the
diagram
you
have
all
three
pods
are
done,
and
so
therefore,
the
finalizers
that
you
show
on
the
va
are
gone
well.
That
ba
could
be
deleted
any
time,
but
there's
still
a
b.a.r
pointing
to
it
and
we
need
any
protection
in
that
system.
I.
B
Well,
I
don't
know
if
you
if
it
has
to
point
back
to
the
bar,
but
you
need
one
to
make
sure
that
the
token
isn't
just
removed
because
or
you
need
a
finalizer
to
make
sure
that
ba
doesn't
go
away
until
the
token
is
removed.
B
No,
no,
we
need
a
fourth
one,
which
is,
which
will
be
one
for
the
actual
physical
token.
So.
B
That's
not
the
br,
that's
just.
I
don't
think
we
need
one
for
the
bar,
I'm
saying.
Instead
of
that,
we
need
one
finalizer
which
is
present
and
that
finalizer
we
can
call
it
token
protection,
finalizer
or
access
protection
finalizer,
where,
if
the
application
parts,
when
they
go
down,
the
csi
adapter
will
go
ahead
and
remove
the
finalizers
one
by
one
and
if
it
removes
the
last
finalizer,
the
ba
could
go
away
before
we
call
revoke.
B
A
F
The
bs
can
only
be
deleted
by
admin
right.
If
that
is
the
case,
then
it's
admin
knows
what
he
is
doing,
at
least,
if
you
can
assume
that
I
thought.
C
B
I
think
I
think
we
have
a
valid
use
case
for
leaving
that
deletion
open.
Actually,
if
the
admin
wants
to
forcibly
if
adam.
B
So
so,
what's
the
what's
the
solution
here,
I
think
this
is
a
valid
concern.
So
the
first
question
is.
B
J
Let
me
see
who's
here
yeah.
I
just
think
you
we
want
to
think
about
said.
I
think
we
want
to
consider
use
cases
where
we
do
automatic
clean
up
of
finalizers
on
the
ba,
because
all
the
app
pods
are
done
and
the
ba
is
out
there
now
and
there's
a
bar,
but
the
user
forgets
to
delete
the
bar
right.
I
mean
they
that
can
happen
so
now
we
have
a
bar
and
a
ba.
J
B
Unless
unless
a
rogue
admin
comes
in
and
takes
the
bar
out,
so
the
ba
out
the
bar
is
pointing
to
a
ba
that
doesn't
exist.
Well,
that's
okay,
because
if
the
ba
now
gets
deleted,
it
just
gets
deleted.
J
B
No,
no,
no
worries.
This
is
a
complicated
discussion,
so
so
what
jeff
is
saying
is
also
correct.
So
for
mvp
you
know
this
is
kind
of
an
edge
case
scenario
where
the
ba
gets
deleted
out
of
band
rather
than
going
through
the
cozy
line
of
chain
of
operations.
A
I
think
actually,
this
is
something
that
could
happen.
I
think
it's
going
to
be
coming
for
the
sun
to
happen,
because
if
alvin
does
not
know
they're
not
supposed
to
delete
this
one
first,
he
could
just
leave
this
one
by
accident.
So.
A
Yeah,
it's
not
too
much!
You
add
that
right
so
also
for
this
to
be
consistent
with
all
the
other
existing
this
you
know,
there's
a
pairing,
two
object:
kind
of
a
binding
type
of
resources,
so.
B
A
B
A
B
A
So
yeah
should
not
be
a
problem,
I
mean
if,
of
course,
you
have
to
handle
those
in
the
controller.
B
Yeah
makes
sense.
I
can't
quite
remember
why
we
didn't
go
that
approach
earlier,
but
yeah.
If
we
remember
it,
we
can.
We
can
bring
it
back
up
next
week.
B
All
right
so
jeff
and
srini.
What
are
your
thoughts
on
that
about?
Adding
adding
a
for
you
know
bi-directional
finalizer.
F
The
the
original
discussion
I
remember
like
jeff,
I
I'm
going
to
echo
what
jeff
said
it's
more
like
a
admin
object
and
admin
is
doing
what
he
knows.
He
thinks
that
he
is
doing
so.
That's
the
reason
why
we
did
not
adopt
this
and
the
second
thing
is
the
complexity
around
bi-directional
finalizers.
F
So
if
we
agree,
we
can
just
do
exactly
what
snapchatter
or
you
know
pvpcs
are
doing.
So
I
just
wanted
to
know.
If
there
are,
there
are
any
known
problems
in
those
areas.
If
there
are
none,
those
are
well
tested.
So
actually,
no
that's.
B
D
B
Where
you
might
end
up
having
dangling
pvs,
I
believe
it's
a
rare
scenario,
but
it's
possible.
B
I
think
even
saad
mentioned
it
at
one
point
having
cyclic
dependencies
like
that
could
be
troublesome,
so
we
designed
such
that
there
won't
be
cycles.
I
don't
know
if
everyone
remembers.
J
You're
right,
there's
there's
numerous
issues
in
prs
related
to
pvc,
pv
protection,
yeah
and
and
the
orchestration
of
like
pods
restarting
but
the
pv's
in
a
and
not
in
a
state
to
be
remounted.
I
mean
there's
lots
of
it's
a
complex
area
and
it
has
had
a
lot
of
issues
related
to
it.
I
see
yeah,
okay,
so.
B
Let's
do
this,
then,
let's,
let's
go,
try
and
understand
those
issues
well,
but
for
now
I
think
it
makes
sense
to
just
have
one
more
finalizer
for
the
token
and
for
the
br
finalizer,
let's
get
more
info
before
we
proceed
on
that.
B
Okay,
yeah
yeah
just
have
to
deal
with
that
complexity,
question
and,
and
if
that
looks
good,
we
can,
we
can
definitely
add
it.
B
Yeah
but
we'll
bring
it
up
next
week
again
with
more
knowledge
wishing.
This
is
not
I'm
not
going
to
you
know,
I'm
making
I'm
going
to
make
sure
we
follow
up
on
this,
and
then
we
make
a
decision
together.
B
Okay,
so
actually
we're
out
of
time.
Let
us
discuss
this
this
bucket
finalizer
design
monday
and
by
that
point,
we'll
also
have
some
clarity.
On
the
other,
the
complexity
related
to
the
bi-directional
bindings.
We
can
yeah
so
so
we'll
we'll
discuss
that
on
monday
and
yeah
we
have
about
seven
minutes.
So
I
want
to
open
up
the
floor
to
anyone
who
has
any
questions.
J
Yeah,
I
can,
I
can
try
I've
been
very
busy
since
the
start
of
the
year,
but
I
would
like
to
be
able
to
contribute
something.
J
I
I
know
that
I
I
think
our
kepp
is
getting
slightly
out
of
date
with
the
code
and
that's
expected,
but
I'm
I'm
I'm
worried
about
that,
and
I
I
think
we
have
to
figure
out.
What
is
the
role
of
the
cap?
Is
it
done?
Is
it
a
static,
a
static
document?
That's
done.
It
served
its
purpose
and
we
no
longer
reference
it
or
do
we
want
to
keep
it
current
or
do
we
want
to
replace
it
with
a
document
that
tracks
the
code
coding
decisions
so
in
case.
B
Of
say,
csi:
the
cap
was
there
to
discuss
the
original
proposal,
but
then,
once
the
original
proposal
was
accepted,
I
think
all
the
future
documentation
or
all
the
changes
that
were
made
from
that
point
onwards
were
put
into
the
documentation
rather
than
keeping
the
kept
current.
J
F
Yeah
yeah,
actually
at
some
point
in
time
about
three
or
two
months
ago,
I
created
a
spec.md
out
of
the
spec.
F
I
might
dig
that
up
and
we
can
discuss
on
that.
That
would
be
a
good,
probably
a
reasonable
start.
Could
you
share
that
with
jeff,
and
I
think
that
pr
is
on
the
old
repo?
I
can
dig
it
up
and
then
share
it.
Yeah.
B
Yeah
please
share
with
jeff
and
also
put
it
on
the
common
slack
channel.
That
way,
others
also
can
take
a
look
and
start
contributing
commenting.
That's
good,
yeah,
yeah,
okay,
that
sounds
good.
The
other
question
is
srini
and-
and
you
know
others
who
are
writing
code
right
now,
is
there
any
reasonable
expectation
on
the
timeline
for
the
demo?
So
do
you
think
we
can
get
it
done
before
next
thursday,
or
do
you
think
it'll
take
more
time?
B
F
Think
we
next
thursday
will
be
very
aggressive,
but
it
depends
upon
one
or
two
common
sessions
we
have
to
have
within
the
team.
So
maybe
monday,
we'll
have
a
better
picture
on
that.
As
far
as
I
think
yeah,
but
I
would
say
january,
we
should
dedicate
to
get
the
first
demo
out
and
then
some
work
towards
the
api
review
so
that
we
don't
miss
the
121.
F
B
Yep,
we
have
to
you,
know,
hit
that
milestone
so,
okay,
this
sounds
good.
So,
on
monday,
I'll
ask
this
question
again
and
on
monday
we'll
also
talk
about
finalizes.
Again,
that's
it
for
today.
Thank
you.
Everyone.