►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Standup Meeting - 08 July 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
Clearly,
some
I'm
gonna
paste
the
link
in
the
chat
here
good
morning.
Everyone
I've
just
pasted
a
link
to
the
updated
cap.
There
are
a
few
pieces
of
information
missing.
However,
it's
something
I'll
add
very
quickly
now,
but
but
this
is
the
so.
A
I
think
so
too,
all
right
so
just
simplified
all
the
information,
that's
there
for
someone
who's
reading
it
for
the
first
time,
and
if
anyone
wants
to
get
deeper
into
any
of
this
there's
links
to
the
code.
This
links
to
the
spec
people
should
be
able
to
do
it,
and
I
don't
think
at
the
alpha
level.
You'll
need
any
deeper
of
a
review,
but
but
just
take
a
look,
I
think
I
think
it's
very
easy
to
read.
A
That
was
one
of
the
you
know.
Main
intentions
I
had
for,
for
you
know,
rewriting
the
skip.
Tim
kind
of
you
know
openly
just
said
that
that's
what
he
wants.
Let
me
let
me
share
my
screen
and
show
you
what
I'm
talking
about
yeah.
So
here's
the
here's,
the
new
cap
yeah,
even
even
these
fields,
have
been
like
dramatically
reduced
simplified,
and
you
know
this
is
all
stuff
that
we
all
know
I've.
You
know
laid
out
the
goals
I
called
bucket
sharing
as
bucket
reuse.
A
This
is
something
I
wanted
your
input
on
it
just
it
is
much
easier
to
understand
what
you're
talking
about.
When
you
say,
the
use,
and
also
it
by
default,
applies
to
both
the
name,
space
sharing
and
cluster.
You
know
cross
clusters
sharing
and.
E
My
chrome
just
crashed,
I
see,
reuse
to
me,
means
taking
an
existing
bucket
saving
its
name
and
then
reusing
it.
It
means
like
an
erase
operation.
F
A
A
Yeah
so
in
general,
in
computer
science,
when
we
say
the
use
we
like
in
in
code,
we
we're
really
talking
about
you
know
using
that
code
again,
but
I
guess
I
guess:
storage
is
different
from
compute
and
you
could
say,
code
is
a
form
of
compute.
A
To
me,
ryu
seems
much
more
accurate
than
saying
bucket
sharing,
and
this
seems
to
be
the
best
term
that
we've
got
as
of
now
to
to
clearly
convey
what
we're
trying
to
do.
Do
you
think
it
causes
more
ambiguity
than
like?
Do
you
think
it
causes
a
lot
of
ambiguity
to
call
to
the
use.
B
Go
ahead,
man
I
was
gonna,
say
I
I
can
see
that
interpretation,
but
I
don't
know
I
mean
you
always
have
to
define
words
when
you
use
them.
Yeah.
B
E
What's
the
issue
with
the
word
sharing,
I
know
that
that's
a
common
description,
for
I
think
it's
miles.
A
Yeah,
I
think
yeah
fair
point,
so
I
I
think
sharing
makes
sense
in
the
context
of
someone
who
understands
the
cosy
system,
but
but
for
someone
who's
just
reading
the
cap.
A
For
the
first
time,
I
think
it's
harder
to
understand
what
we're
talking
about
when
you
say,
sharing
like
why
even
worry
about
sharing
the
whole
reason
is
because
we
we
constrain
a
bucket
to
a
namespace
by
or
you
know,
not
a
bucket
to
a
namespace,
not
the
actual
bucket
resource
or
namespace,
but
but
in
concept
we
do
constrain
the
bucket
to
be
accessed
by
the
namespace
that
created
it
or
the
namespaces
in
the.
B
Loudness
list,
so
so
you
raise
an
excellent
question
when
you
ask
it
that
way,
which
is
like
we're,
we're
fundamentally
doing
two
different
things
like
for
for
people
who
have
a
lot
of
existing
buckets,
they
could
be
completely
uninterested
in
our
create
delete,
type
workflows
and
they
might
be
specifically
interested
in
just
the
access
granting
and
the
automatic
plumbing
of
credentials
into
the
into
the
pods,
and
that
could
be
all
they
really
care
about.
In
which
case
you
know,
the
talking
about,
sharing
or
reuse
will
seem
bizarre
to
that
user.
B
B
I
don't
know
how
to
describe
it
very
specific
to
workloads
where
you
want
to
automate
bucket
life
cycles,
and
you
know
within
kubernetes,
and
they
are,
you
know,
kind
of
different
use
cases
that
were
both
they
were
and
we're
trying
to
tackle
them,
both
so,
okay.
I
I
think
we
need
to.
E
E
B
I'm
envisioning
two
specific
kinds
of
users:
there's
there's
the
user,
who
already
has
his
buckets
and
he
just
wants
to
use
them
in
kubernetes
in
as
convenient
a
fashion
as
possible,
and
so
for
that
guy,
you
know
the
the
the
representation
of
the
bucket
in
kubernetes
a
way
to
bind
a
pod
to
it,
with
potentially
its
own
specific
access
credentials
that
can
be
revoked
independently
of
anything
else
are
all
very
valuable
to
that
to
that
user
and
they're
and
they're
when
they
want
to
go,
create
a
new
bucket
they're
just
going
to
go.
B
B
B
Yeah
but,
but
specifically
I'm
referring
to
like
defining
your
application
as
a
bunch
of
yaml
that
represents
like
all
the
pieces,
so
you
can,
you
can
deploy
it
in
a
place
and
then
you
can
pick
it
up
and
deploy
it
in
another
place
and
you
can
infrastructure
yeah.
So
maybe
something
like
that
so
yeah
the
infrastructure
is
as
code.
B
People
are
gonna
say
well,
I
need
a
way
to
create
a
bucket,
because
my
application
needs
a
bucket
to
do
whatever,
and
so
of
course
I
need
to
be
able
to
create
a
bucket
and
have
a
provisioner
that
can
go
satisfy
that,
just
like
the
pvcs
and
and
and
for
that
type
of
user,
then
you
know
the
creation
and
deletion
is
is
integral
because
they
want
it
to
all
be
inside
kubernetes.
They
don't
want
to
ever
have
to
go
out
and
talk
to
something
else.
B
They
just
want
to
say
if
there's
a
cozy
driver-
and
I
make
a
bucket
request,
of
course,
I'm
going
to
get
a
bucket
and
then
I
can
use
it
and
I
can
wire
it
up
to
my
pods
by
defining
the
appropriate
things.
But
but
I
I
I
guess
the
question
is:
will
these
ever
two
users
ever
meet
each
other
or
overlap
in
their
interests?
A
I
don't
think
we
can
make
that
assumption,
but
yeah
we
will
come
back
to
this
reuse
question
later
and
yeah.
We
can
go
back
to
calling
it
sharing
and
you
know
define
it
or
it
doesn't
matter
to
me
yeah,
let's,
let's
move
forward,
but
what
ben
did
we
answer?
The
question
that
you
just
had
about.
B
I
it's
not
a
question,
I
guess
it's
just
a
framing,
a
framing
of
who
the
who
the
personas
are
for
this
api.
B
You
could
dream
up,
but
but
those
it's
that
second
one.
That
really
highlights
the
fact
that,
like
we,
you
know
we
we
seem
to
be
prioritizing
the
first
one
and
the
second
one
who
already
has
a
bunch
of
buckets
and
he
doesn't
want
to
share
them
or
reuse
them.
He
just
wants
to
use
them
in
his
mind.
He
has
buckets
and
he
wants
to
use
them.
And
how
do
you
do
that
with
cozy
and
we've?
We've
never
really
focused.
We've
never
made
that
our
top
priority.
We've
always
made
it
like
an
afterthought.
A
A
I
mean-
I
guess
we,
you
know
like
one
of
the
reasons
for
that
is,
is
probably
subconsciously.
We're
trying
to
you
know
we're
thinking
in
the
kubernetes
way
we're
pushing
the
world
forward
and
focusing
on
the
new
way.
We
want
people
to
do
things
which
is
just
to
create
on
the
fly,
perhaps
yes,
yeah.
So
another
thing
that
I
wanted
to
go
over
on
the
cap
itself
was
the
changes
that
we
actually
brought
into
via
each
of
the
resources
we
drastically
simplified,
pretty
much
all
of
them.
A
So
here
I'm
talking
about
bucket
okay,
I
need
to
put
the
picture
here
so
so
you
know
so
we
said
the
bucket
request
is
just
going
to
have
a
protocol
field
by
name,
because
you
know
the
application
is
expected
to
know
the
protocol.
The
protocol
field
stopped
being
a
full
fledged
structure.
It
went
back
to
being
what
it
was
probably
a
year
ago,
where
it's
just
an
identifier
for
that
actual
protocol
and
in
the
bucket
class
as
well.
A
That
protocol
field
became
pretty
much
nothing
and
anything
that's
protocol
specific
was
decided
to
be
represented
using
parameters.
Do
you
all
remember
that
discussion?
A
A
Then
that
translates
to
the
grpc
api,
which
pretty
much
puts
in
the
bucket,
so
the
grpc
api.
We
didn't
really
discuss
it,
but
it's
kind
of
implied
that
the
protocol
structure
changes
to
what
we've
now
defined
and
also
everything
goes
into
the
parameters.
We
drive
driver,
specific
parameters
going
through
parameters.
A
A
Then,
using
this
we
infer
the
bucket
name
and
we
set
parameters
copied
from
the
bucket
class
and
bucket
acts,
work
at
access
class
and
then
set
the
bucket
access
class
name.
Provisional
name
should
be
here,
that's
missing,
but
I'll
add
it.
We
renamed
the
minted
secrets
to
credential
secret.
C
And
yeah
wait
wait
a
minute.
The
parameters
are
copied
here
from
market
access
class.
C
B
A
How
else
would
you
know
how
else
would
you
know
what
are
the
policies
that
have
been
applied
to
this
access
like
like
it's
gonna,
be
you
know
unknown
to
you?
You
won't
be
able
to
figure
out
what
was
applied
on
this,
like
what
policy
applies
to
this,
this
access
credential,
if
you
don't
copy
those
values
here,.
B
G
B
B
But
I
mean
nowhere
else
in
kubernetes:
do
we
keep
values
around
just
for
the
user's
own
interest,
like
the
idea
is?
If,
if
you
cared
about
that,
you
could
put
annotations
on,
you
could
put
labels
on
it.
You
could
do
whatever,
like
you
know,
kubernetes
isn't
around
to
do
a
bunch
of
bookkeeping
for
you.
We
don't
have
superfluous
fields.
B
C
B
A
I
don't
think
this
so
yeah.
I
don't
think
this
affects
the
architecture
or
you
know
functioning
very
much
because
you
can
still
achieve
everything
without
having
parameters
here.
Yeah.
The
only
thing
that
changes.
F
F
No,
but
I
think
it
does,
we
did
this,
we
did
think
about
having
you
know
these
parameters
in
the
in
the
bucket
and
in
the
bracket
access,
because
we
wanted
so
we
wanted.
G
F
Control
and
updating
that
those
right.
F
But
then
we're
saying
that
a
bucket
has
opaque
parameters
on
creation
time.
That
implies
that
these
parameters,
also
you
know
some
of
them
at
least-
can
be
affected
after
creation
as
well.
Let's
say
you
have
some
type
of
policy.
Some
type
of
you
know,
information
that
affects
how
the
driver
should.
B
B
Kubernetes
is
never
going
to.
You
know,
call
like
a
mutate
bucket
with
here's,
some
new
opaque
parameters
right
so
at
least
we've
chosen
not
to
do
that
on
the
volume
side
right.
We
have
a
couple
of
big
parameters
in
the
storage
class
that
get
passed
down
at
create
time,
but
they're
persistent
nowhere
and
if
you
ever
cared
about
what
those
things
were,
you
either
have
to
keep
track
of
them
some
other
way
or
go.
Look
at
the
actual
storage
and
figure
it
out.
We
don't
do
a
lot.
B
Well,
I
mean
it's,
it's
it's
opaque,
so
so
it's
like
there's
no
standard
way
to
do
this
so
you're.
You
know
if
you
have
a
netapp
device
and
you
have
a
netapp
storage
class
and
you
have
a
bunch
of
opaque
parameters
that
are
nav
specific.
If
you
care
about
them,
you
just
go.
Look
at
your
netapp
device
and
see
what
the
what
the
settings
are
on
the
actual.
B
You
know,
flex
files
that
got
created
or
whatever
you
know,
but
there's,
but
that's
all
proprietary
and
kubernetes
doesn't
care.
So
kubernetes
is
just
saying:
okay,
when
you
create
a
volume,
we're
going
to
shove,
a
bunch
of
big
parameters
in
so
that
you
can
do
a
couple
of
things
at
creation
time
we're
not
going
to
help
you
after.
F
This
kubernetes
is
a
set
of
controllers
right,
and
one
of
these
controllers
is
going
to
be
the
netapp
driver
for
that
matter,
for
cozy
and
and
net.
The
netapp
driver
cares
right.
It
like
it
wants
to
provide
a
crd
based
api
for
its
administrators
running
on
kubernetes
right.
The.
B
G
C
C
F
Implies
that
every
any
administration
of
of
you
know
any
any
modification
would
have
to
would
have
to
bypass
kubernetes
right.
B
B
F
But
every
controller
like
every
reconcile
is
a
mess
to
to
that
extent
right,
because
if
you
have
changes
and
you
want
to
reconcile
them
to
some
other,
you
know
api
right,
but
I
think
the
value
here
is
that
we
would
keep
the
administration
within
kubernetes.
I'm
not
I'm
seeing
that
pvs.
Don't
have
that
as
well,
which
which
makes
a
good
argument
for
why
this
doesn't
belong,
but
but
then
I'm.
I
just
wonder
how
does
like
with
pvs.
If
I
ever
want
to
do
anything
with
that
pv,
I
I
would.
B
B
F
F
B
For
access
that,
that's
that's
an
accurate
statement
but
like
for
bucket
creation
or
anything
other
than
access
policy
is,
I
don't
think.
F
There's
a
bunch
right,
there's
a
replication
policy
access
polls
like
fine,
fine
grain
access
policies
and
versioning,
whatever
there's
a
really
in
s3.
There's,
I
don't
know,
maybe
20
different
policies
you
can
set
on
a
on
an
existing
bucket
right
and
mutate.
It.
A
F
I'm
not
talking
about
creating
something
new
really
really
talking
about.
How
do
I
manage
and-
and
sometimes
I
think,
managing
here
would
be
an
administrator-
you
know
manual
management,
and
sometimes
it
will
be
another
controller
trying
to
do
having.
F
A
Yeah
haven't
we
haven't?
We
always
said
that
you
know
when,
in
that
brownfield
use
case,
you
know
it
does
have
the
bucket
class
field
and
the
whole
point
of
that
is
to
apply
new
parameters
on
the
bucket.
A
B
So
so
again
like
like
the
model
in
the
storage
world
or
the
model
in
the
volumes
world
was
pvs.
Remember
the
name
of
the
storage
class
they
were
created
from,
but
you
can
delete
the
storage
class
after
the
pv
is
created
and
nothing
will
happen.
You
can
change
it.
Nothing
will
happen.
It's
just.
It's.
C
A
B
A
That's
a
that's
a
fine
argument.
I
mean
to
what
guy
is
saying
he's
saying
that
we
should
be
able
to
mutate
bucket-related
properties.
I
mean.
B
G
B
F
B
F
B
F
B
F
B
A
F
Let's
say
that
I
also
want
well
just
one
second,
let's
say
that
I
also
want
to
keep
the
parameters
from
the
class.
I
would
be
able
to
transform
them
into
my
proprietary
annotations
for,
for
example,
and
then
watch
these
right
and
be
able
to
mutate
things
based
on
those.
F
So
we're
saying
that
I
I
can
have
this
solution
in
a
recommend
like
not
recommended,
but
no,
I
can
have
a
proprietary
way
for
any
vendor
to
to
implement
such
a
thing,
but
you
you,
don't
think
that
this
should
be
just
a
copy
of
the
parameters.
That's
from
that
perspective,
right.
G
Hey
see,
I
have
a
general
question:
do
you
have
the
type
of
the
parameters
specified
anywhere.
F
G
This
team
is
going
to
ask
for
that,
because
he's
going
to
do
an
api
review
if.
G
A
It's
fine,
no,
it's
not
too
much
and
yeah
I'll
definitely
add
a
link
to
the
code
as
well
that
that
is
no
brainer
yeah.
Both
both
will
help.
A
Yeah,
I
can
add
those
okay,
so
taking
our
parameters.
A
G
A
F
Do
you
have
any
any
comment
here
about
what
the
discussion
we
had
about
the
protocol
versions
like
yeah
in
the
future?
Is
it
described
somewhere.
A
Yeah,
so
so
what
we
said
about
protocol
versions
or
or
just
everything
to
do
with
protocols
is
the
they're
all
going
to
be
specified,
they're
all
going
to
be
a
contract
between
the
the
driver
and
and
and
the
workload.
So
so
it
is
expected
that
whenever
a
workload
or
a
workload
in
a
particular
environment,
if
it
expects
the
protocol
version
to
be
a
specific
one,
then
then
it
is
expected
that
only
drivers
that
support
that
protocol
version
are
are
used.
F
F
Is
not
coded
into
the
yamls.
A
Right
right,
any
protocol
specific
field
is
not
is
not
encoded
into
the
into
into
the
structures
itself.
So.
F
You're
saying
it's
just
like
we
say
in
many
cases
for
any
rest:
api,
it's
http
and
we
don't
say
what
type
of
rest
api
it
is
specifically,
and
we
assume
that
somebody's
like
has
set
this
environment
to
support
the
workloads,
and
you
know
the
bucket
types
that
that
support
them
right.
Something
like
that.
F
H
F
A
So
you
can
still
configure
the
class
to
allow
certain
apis.
Assuming
the
driver
understands
such
parameters.
You
could
still
say
support,
s3,
v4
and
v5,
assuming
v5
is
something
that
happens
in
the
future
through
the
opaque
parameters.
I.
F
Think,
though
I
I
would,
I
would
if
it's
not
here
somewhere,
I
would.
I
would
just
include
this.
You
know
snippet
of
explanation
how
protocol
version
might
at
least
fit
into
this
okay.
I
think
because
I
think
we
discussed
it
quite
a
lot
and
I
think
it
will
it
might
be
yeah.
Somebody
might
question
if
this
is
enough
to
identify
the
protocol.
A
Yeah
there's
a
bunch
of
things
I
have
for
the
appendix
one
is
bucket
ownership
other
than
the
few
things
that
we
talked
about.
Mutation
is
another
one
bucket
ownership
is
who
owns
the
bucket
that
cosy
creates.
You
know
we
have
some
guidelines
on
how
it
should
be
done,
but
really
we
don't.
We
don't
care,
we
don't
control
it.
A
Yeah
stuff,
like
that.
We'll
put
everything
in
the
appendix
does
that
make
sense,
yeah
sure,
okay,
all
right!
So
please
take
a
look
like
I
said
there
are
some
parts
that
are
not
linked
yet
but
they're
coming
up
soon
and
and
please
take
a
look
and-
and
you
know
we'll
go
from
there.
A
Yeah
the
grpc
aps
I
just
have
to
copy
them
over,
got
them
ready,
so
yeah.
Please
take
a
look
and,
and
we'll
go
from
there,
that
that's
all
I've
got
about
the
cap
itself.
H
F
C
A
All
right,
so,
okay,
so
the
other
thing
that
I
wanted
to
bring
up
was
shing.
When
was
the
deadline
for
the
blog
that
you
were
talking
about.
G
G
Usually,
no,
I
thought
you
really.
If
you
are
you
sign
up
for
to
write
a
blog
they
have,
then
they
have
your
name
there
right.
So
they
should.
You
repeat
you
directly,
but
I.
G
G
H
G
Think
your
name,
I
think
c,
do
you
want,
I,
I
think,
probably
only
your
name
there.
Normally
they
just
ask
one
name
there.
I
probably
put
down
your
name,
so
they
should.
A
G
G
A
Okay,
yeah
we'll
start
writing
it
then
yeah.
I,
if
yeah
we
can
start
writing
it
again,
I'll
bring
it
up
in
front
of
the
whole
group,
and
you
know
we'll
do
we'll,
do
it
together.
So,
okay,
what's
the
deadline
for
the
cap
preview?
Would
you
know
that.
G
So
well,
well,
the
thing
is:
this
is
auto
tree
right,
it's
getting
a
little
weird
so,
but
if
you
think
about
it
right,
the
the
block
has
to
be
out
on
august
4th
so
and
then
you
need
to
have
the
block
ready
for
review
on
july
27th.
I
think
before
that
you
you
need
to
have
the
cabin
in
a
shape
that
it
has
to
be
merged,
because
otherwise
we
don't.
G
G
G
G
I
actually
I
don't
know
if
we
can
make
it,
but
if
you
can
get
the
if
you
can
get
the
cap
merged,
I
also
if
you
can
get
cat
emoji
before
the
july
27th,
then
we
consider
this
one
to
be
122,
because
otherwise
I
think
it's
too
late
and
if
cap
is
not
even
merged,
I
mean.
How
can
we
write
a
blog
right?
That's
just.
B
B
G
G
Yeah,
yes,
it's
a
little
weird
because
this
one
we
don't
have
to
because
we
don't
have
any
code
entry
right.
The
reason
they
have
all
of
those
other
deadlines
is
because
you
know
we
have
this.
We
have.
We
have
to
merge
by
the
merge
deadline,
which
is
what
which
is
today
actually
right.
So
we
don't
have
that
ally
code.
Merge
deadline
today
for
entry
right,
this
one
we
don't
have,
but
we
still,
I
think
I
think
some
other
sick.
They
maybe
just
completely
don't
follow
at
all.
They
complete.
G
They
don't
follow,
don't
be
blocked.
They
don't
do
anything.
They
just
do
something.
You
don't
care
when
it's
out,
but
because
the
sixth
story
we
still
try
to
align
with
the
you
know
with
the
kubernetes
release
right,
even
though
it's
it
is
async,
it's
a
little
later.
When
that
I
was
still
trying
to
align
with
that.
So
that's
why
it's
a
little
weird
yeah,
but
I
would
say
you
know
july.
20
27
is
the
the
day
when
the
blog
is
ready
for
review.
You
should,
should
you
have
the
cab
merge.
A
All
right
good
to
know
yeah
we
can.
We
can
get
everything
ready
before
that
and
and
and
in
terms
of
cap
review.
A
Let's,
let's
assume
that
you
know
this
thing
is
complete
by
tomorrow,
the
end
of
this
week,
the
cap
itself,
in
that
case,
like
do
you
think
tim
would
be
very
busy
now
or
do
you
know
when
when
I
I.
G
H
G
Maybe
you
can
ping
him
tomorrow.
He
may
want
to
take
a
break.
Then
monday.
Definitely
try
to
get
him
start
review
this
next
week.
I
would
say
otherwise.
We
are
we're
running
out
of
time
again
right
because
he's
in
july
27,
it's
not
that
far
away.
Actually
yeah,
I
mean
still
just
try
to
get
him
to
review
as
soon
as
possible.
I
mean
if,
if
we
can't
make
it
in
one
or
ten
two,
then
we're
not
23.
A
Makes
sense
yeah,
I
I
think
I
think
yeah
I
will.
I
will
highlight
highlighted
to
him
that
this
is
this.
Is
you
know,
we've
addressed
some
of
the
things
that
he's
he's
asked
for
and
also
highlight
that
it
should
be
easier
to
read
this
time
and
hopefully
he
reviews
it
right
away.
Okay,
so
that's
that's
all
I've
got
for
today
unless
anyone
wants
to
bring
anything
up.
F
On
the
cap,
the
the
problem,
I
mean
the
missing
thing
for
me
and
you
probably
wanted
to
do
that,
but
the
the
is
the
api.
It's
for
the
application
side
like
how
the
mount
works
and.
F
Like
the
adapter
csi
yeah
all
these
details,
I
don't
know
if
they
really
matter
yeah
if
it
matters
that
much
to
the
api
review
technically
speaking,
because
this
is
a
mechanism
which
is
already
in
csi
right.
So
it's
not.
A
A
But
but
yeah
yeah
it
should
be
done.
Quick
shouldn't
be
a
problem,
I'm
going
to
add
that
for
sure
and
the
appendix,
with
those
three
things
I
have
to
write
it
down
and
the.
F
A
A
Yeah
yeah,
that's
that's
the
main
reason.
I
directly
link
it
right
now:
yeah
and
bucket
ownership
and
yeah.
I
think
those
are
the
three
line
items
yeah.
Okay.
F
But
I
don't
know,
I
don't
understand
the
process.
Maybe,
but
do
you
know
what
what's
what's
going
to
be
needed
formally
to
get
approval
for
the
api
review?
Is
that
so.
A
G
Can
be
so
we
we
just
need
to
cut
a
release
before
1.23,
then
we
can
still
say
it
is
part
of
another
2.
I
guess
so
so
we
still
have
more
time
and
also
since
we
already
have
a
lot
of
code.
It's
not
like
we're
starting
from
scratch
right,
so
I
think
once
the
cap
is
merged,
then
we
can.
I
think
we
should
have
enough
time
to
make
the
necessary
changes
right.
G
A
G
So
but
I
mean
I
don't
know
if
tim
wants,
you.
G
G
He
may
look
at
the
api,
I
don't
know
I
don't
remember.
If
you
look
at
the
snapshot
api
code
entry
code,
he
will
definitely
review.
Actually
this
is
out
of
2.
I
don't
know
he
may
still
review
the
the
api
part
but
yeah.
I
think
he
doesn't
have
to
review
everything.
This
is
you
know
we
also
have
all
the
other
repos,
probably
just
like
the
api
part.
G
A
G
A
Yeah,
that
should
that,
should
that
should
address
that,
I
think
I
think
I
think
we're
in
a
decent
shape,
then
that
that's
all
that's
all
yeah
I'll,
also
write
down
this
other
thing.
So
another
thing
was
how
much
of
our
design
that
contributes
to
things
like
and-
and
you
know,
how
is
that
design,
secure
and
system
properties
like
that,
like
like
how
how
much
of
this
is
explained
in
the
cap
and
how
much
of
this
is
assumed
to
be
just
inferred
from
the
design.
A
A
G
A
Yeah,
fair
enough,
that's
that's
how
I
went.
I
think
I
think
that's
the
best
answer
here,
yeah,
because
if
we
start
diving
into
those
things
it
gets,
it
gets
tricky
there's
a
lot
we
can
add
and
then
it
cuts
across
all
the
different
parts
of
the
system,
like
all
the
different
apis,
all
the
different
components.
So
so
it's
probably
harder
to
explain.
F
I
think
I
think
maybe
it
will
be
useful
if
we,
if,
in
that
review
process,
there's
a
chance
to
explain
the
you
know
the
things
that
we
understood,
that
we
didn't
highlight,
or
we
didn't
go
into
details
in
the
cap
actually
right,
so
that.
A
Yeah,
we
have
a
section
for
that
things
that
we
won't
address
now
and
things
that
yeah
we
considered
and
said
no.
F
C
G
A
So
were
there
questions
raised
on
that,
for
you
know,
how
will
this
be
performant
or
how
will
this
be
secure,
or
how
will
this
allow
portability
stuff
like
that,
or
was
that
just
assumed
somehow.
G
G
A
Okay,
I
think
I
think
I
have
all
the
information
that
I
need.
Is
there
anything
else
anyone
wanted
to
bring
up
again.
A
Okay,
we
can
end
for
now
and
we
can.
We
can
reconvene
on
monday
as
usual,
so
I've
been
thinking.
I
think
our
discussions
are
more
more
or
less.
You
know
we
have
a
decent
grasp
on
on
how
we're
designing
the
api.
Would
it
make
sense
now
to
reduce
the
frequency
of
meetings
to
just
one
a
week
or
does?
Does
it
still
make
sense
to
have
two?
Every
week.
G
G
Probably
yeah
that
probably
better
right,
let's
just
follow
just
right
after
the
six
story,
meeting
right,
yeah.
A
Okay,
everyone,
everyone,
okay
with
that.
A
C
A
Sweet,
okay,
all
right,
so
I
will.
I
will
update
the
calendar
and
yeah,
let's
let's
meet
again
next
thursday,
so.
G
Okay,
so
you
can
just
because
I
think
you
set
this
monday
meeting
right.
So
if
you
cancel
it,
I
would
just
review.
I
would
just
remove
that
from
the
six
stage
calendar,
then
that
should
be
it.
I
think
the
other
meeting
is
set
by
saad
so
that
one
just
we
just
keep
that
one.
F
F
A
You
for
that
sure
that'll
help.
Okay,
all
right!
I'm
canceling
monday
meetings
going
forward
from
july
12th
onwards.
All
right
you
should
you
should
you
should
get
a
you
should
get
a
cancelled.
You
know
update
and
then
for
notification
all
right.
So
that's
good!
I
think.
That's
all
and
let's,
let's
meet
again
on
thursday
and
and
a
guy
I'll
helping
you
shortly
sure
bye,
bye,.