►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 24 February 2022
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Sidhartha Mani (Minio)
B
B
This
is
six
storage,
cosy
the
container
object,
storage
interface
meeting
for
bringing
object,
storage
standardization
to
kubernetes.
So
I
want
to
start
off
today
by
addressing
a
pr
that
jiffin
raised
to
update
the
code
base
to
have
all
the
latest
specifications
that
we've
discussed
over
the
months
so
different.
Did
you
want
to
go
over
the
pr
and
talk
about?
What's
on
it.
C
So,
based
on
last
week
meeting,
I
guess
I
pushed
the
changes
to
update
the
apa,
but
I
am
not
quite
sure
with
that.
Do
I
need
to
update
the
spec
with
this
so
like
I
need
to
update
the
spec
first,
then
apa,
so
the
first
p
commit
like
it's
not
complete,
like
I
need
to
update
the
so
this
one
just
removes
the
bucket
access
starts
from
the
bucket
access
request,
details
from
the
apa
and
the
first
commit
like
when
I
did
the
codes
and
it
created
some
modification
to
the
existing
code
base.
C
That's
why
the
first
commit
does
something
which
it
was
a
part
of
the
codes
and
generation.
That's
it.
The
second
one
is
the
actual,
so
yeah.
This
is
the
first
step
I
guess
like
after
the
next
round.
I
will
try
to
update
the
renaming
the
bucket
request
to
bucket
claim
and
other
stuff
like
updating
the
stats.
C
B
A
it's
a
pretty
straightforward
update
and
this
is
a
work
in
progress
right.
That's
what
he
said.
C
Sit
like
should,
I
need
to
update
the
spec
faster.
I
can
update
the
speculator
after
after
having
these
changes.
B
So
spec
is,
is
just
the
grpc
specification
for
cozy
to
talk
to
the
driver
that
should
be
orthogonal
to
this.
That
should
be
independent
of
the
changes
here.
So
it
doesn't
matter.
B
You
can
start
with
the
api,
though
we
generally
try
to
take
the
spec
changes
very
carefully,
because
any
existing
drivers
that
are
using
the
spec
can
get
affected.
So
so,
let's
keep
the
spec
update
for
last
and
we
can
start.
B
Yeah
thanks
yeah,
that's
good!
I'm
glad
you
got
a
chance
to
make
this
pr
and
and
grant
also
said
he
might.
He
might
get
some
time
to
work
on
it,
but
I
haven't
seen
the
pr
from
him.
I'm
he's
probably
is
just
busy
or
he'll
make
the
platform,
but
but
it's
good,
I'm
glad
we
got
to
start
on
this
note,
so
so
so
I
think
so
far.
B
We've
we've
discussed
pretty
much
all
aspects
of
our
initial
design
as
in
what
we
aim
for
alpha
and
I
think
it's
time
given
the
positive
feedback
from
michelle,
even
though
it's
not
merged
yet
I
think
I
think,
with
where
we
are
today.
B
I
think
it's
okay
to
start
working
on
the
next
aspects
of
it
specifically.
So
there
are
two
unanswered
questions.
One
is
regarding
bucket
properties,
so
we
have
kind
of
a
vague
answer
around
how
we're
going
to
support
things
like
bucket
versioning,
bucket,
locking
object,
locking
or
it's
called
worm
right
on
right
once
read
many
or
policies
around
a
bucket.
B
So
say
you
want
to
set
up
a
replication
configuration
or
a
bucket
or
choose
the
storage
class
for
a
bucket
stuff,
like
that,
so
the
storage
class
for
a
bucket
there's
a
there's,
a
there's,
a
distinction
between
the
regular
storage
class
that
we
use
with
file
and
block
stores
and
the
storage
classes,
buckets
they're
called
storage
classes.
But
you
know
we
can
come
with
a
new
term
too.
The
the
storage
class
with
buckets
is
what
kind
of
redundancy
is
is
applied
to
the
objects
that
get
stored
in
the
bucket.
B
So,
for
instance,
you
can
you
can
choose
to
have
enhanced
irrelevancy
or
reduced
redundancy
reduced
redundancy,
I
think,
does
a
eventually
consistent,
replication
and
and
has
you
know,
can
can
lose
up
to.
Let's
say
it's.
You
know
the
object
is
on
is
on
10
different
servers.
I
think
you
can
lose
up
to
n
by
two
servers
or
something
enhanced
redundancy
is
where
you
know
the
the
the
chance
of
failure
is
much
lower
or
even
when
things
go
wrong.
B
Chance
of
losing
data
is
much
lower,
but
when
it
comes
to
the
cost
of
performance
so
stuff,
like
that,
the
question
one
is:
how
do
we
model
it
in
the
cosy,
workflow
and,
and
the
second
question
is
yeah?
Actually
so
do
we
even
model
it
as
typed
objects?
That's
the
question
one
I
would
say
question
two
is
how
because
there
is
a
simple
approach
here,
where
we
could
just
say
put
it
all
in
the
in
the
bucket
class.
B
That's
that's
a
pretty
simple
answer
and
it
would
work
for
alpha
and
in
a
sense,
that's
that's
okay,
but
but
I
want
to
kind
of
open
up
the
flow
to
everyone,
hear
their
thoughts
or
even
any
use
cases
they
have
around
these.
These
concerns.
B
So
so
at
netapp,
then
I'm
sure
netapp
buckets
have
bucket
policies
right
like
what
would
they
be.
B
B
I
see
all
right
so
and
cozy
needs
to
be
able
to
configure
that
at
the
least
right.
Is
there
any
orchestration
involved
depending
on
these
policies
from
you
know,
that
would
be
expected
from
the
cozy
side.
A
I
I
think,
the
the
stuff-
that's
on
the
the
bucket
class,
the
opaque
params,
and
this
is
how
we
do
with
csi
right.
You
have
a
bunch
of
opaque
params
that
just
get
passed
down
by
the
side
car
and
then
our
driver
knows
what
to
do
with
them
and
as
we
as
we
want
to
add
more
features
to
our
driver.
We
just
add
more
opaque
brands
and
we
document
them
and
cozy
doesn't
need
to
understand
how
they
work.
B
I
see
all
right
so
actually,
let's
start
with
the
example
of
encryption,
as
you
mentioned,
I
just
thought
of
one
of
the
requirements
for
encryption,
so
so
this
there's
like
three
different
styles
of
encryption,
that
s3
supports
oneness
prescriptions
where
the
client
clips
so.
A
B
All
right:
okay,
sorry
about
that
unreliable,
wi-fi
here,
anyways
all
right!
So
we
were
talking
about
encryption,
yeah.
A
A
B
Yeah
there's
three
kinds:
this
client
side
there's
server
side
and
then
the
server
side,
then
with
an
external
key
server,
so
like
vault,
so
client
side
is
where
the
client
encrypts
the
object
and
puts
it
into
the
data
store.
The
client
knows
the
decryption
keys,
the
encryption,
keys
and-
and
you
know,
gets
the
encrypted
object
back
and
knows
how
to
get
the
real
object
out
of
that
server
side
is
where
the
server
holds
one
key
across
the
board
for
all
the
buckets
and
it
chooses
it.
Encrypts
all
the
objects
with
that.
B
So
if
that
key
is
lost,
all
is
lost,
but
it's
still
encrypted.
B
That's
that's
server-side
encryption
and
there's
the
last
one,
which
is
with
an
external
key
server
and
that's
where
each
object
gets
its
own
encryption
key
and,
and
it
needs
some
sort
of
orchestration
with
vault
with
an
integration
of
an
external
key
server,
and
I
believe
that
that
standard
is,
I
mean
the
the
way
to
talk
to
an
external
key
server
is
standardized,
at
least
at
least
for
s3
encryption
options.
B
So
assuming
we
were
doing,
you
know
the
third
kind
of
encryption,
the
second
kind
of
encryption,
where
it's
a
server
side
or
or
it
was
with
the
key
server.
We
would
need
some
some
amount
of
orchestration
from
cosy
at
the
minimum,
a
secret
having
an
encryption
key,
that's
one
or
some
form
of
configuration
to
point
to
the
awards.
Server.
B
Oh,
no,
so
so
so
there
are
admins
in
the
team
that
might
want
to
make
sure
all
data
that's
stored
in
a
particular
cluster
is
encrypted.
B
A
It's
just
a
client-side
feature
that
they
implement
in
their
s3,
client
or
or
on
top
of
that
so
like
those
are
the
things
that
we
should
do
first
and
then
I
think
you're
right
that
that
third
option
sounds
like
there's
some
role
for
something
in
the
middle
to
orchestrate
it,
and
we
would
obviously
want
that
to
work
the
same
across
every
implementation
so
like
that.
Would
that
would
be
like
a
cozy
extension
that
we
would
want
to
specifically
design
and
implement.
A
On
top
of
you
know,
cozy,
once
it's
approved
and
stable,
we
would
want
to
like
specifically
design
that
extension,
but
I
I
wouldn't
want
to
spend
time
on
it
before
we
get
to
that
point
right.
You
know,
there's
so
many
other
things
that
are
higher
priority
than
sorting
out
that
specific
feature,
but
but
yes,
something
like
that
would
would
make
sense
to
specifically
design
into
cozy.
At
some
point.
D
C
Yeah:
okay,
what
my
understanding
is
like
the
s3
client
will
specify
like
the
headlights
will
specify
sse
kms
or
something
like
that.
Then
the
key
name.
A
C
B
No,
no,
no,
that's
not
right!
So
so
when
you're
providing
a
client
based
key
and
the
server
encrypts
it
that's.
When
the
header
is
different,
when
it's
when
it's
kms
based
the
the
way
the
keys
are
managed,
is
completely
on
the
server
side,
so
the
client
doesn't
know
anything
about
it.
B
So
we
need
a
way
to
configure
that
through
the
cozy
workflow
saying
that
enable
encryption,
maybe
it's
the
the
the
the
field
or
we
just
add
a
field
that
says
encryption
and
type.
Maybe
that's
all
it
is,
but
at
least
that
much
needs
to
be
there.
A
A
A
B
Cozy,
I
don't
think
that's
true.
Actually
so
one
one
big
problem
with
so
much
data,
is
you
can't
you
can't
rebalance
it
or
go
and
change.
A
B
So
that
that
requires
some
orchestration
right,
because,
right
now
you
can't
change
anything
in
the
bucket
class
in
cozy.
B
Right
right,
I
see
where
you're
coming
from
yeah
that
too,
that
also
needs
to
be
discussed.
So
that's
where
I
was
coming
from
the
the
larger
the
bigger
picture
here
is:
we
need
a
way
to
specify
bucket
policy,
that's
more
than
just
a
bunch
of
opaque
fields,
because
there
are
quite
a
few
policy
related
things
that
are
common
across.
B
I
would
say
all
the
cloud
implementations,
and
also
many
of
I
can't
speak
for
self,
but
we
have
a
representative
from
seth
who
can
who
can
vouch
for
that,
but.
A
But
we
should
we
should
go
through
those
on
a
case-by-case
basis
and
and
see
how
we
would
design
them
and
if,
if,
if
the,
if
the
obvious
answer
is
like
oh,
it
would
make
sense
to
wrap
these
in
a
policy
so
that
they're
more
reusable
like
we
can
do
that.
But
but
again
I
would
say,
like
that's
all
lower
priority
stuff,
because
it's
so
easy
to
get
wrapped
up
in
the
details
of
exactly
how
those
features
work
and
we
could
spend
hours
and
hours.
You
know
bike
shedding
on
exactly
how
to
do
it.
A
The
process
for
granting
access
to
a
principal
was
very
awkward,
and
I
I
think
it's
better
because
we
spent
a
lot
of
time
on
it.
But
I
mean
just
having
an
implementation
that
we
can
code
against
and
try
it
out
and
say
like
yeah.
I
like
this
or
no,
I
don't
like
this,
but
that
that's
where
we
need
to
be
is
you
know
the
the
real
bread
and
butter
of
cozy,
which
is
creating
buckets
and
granting
access
to
pods
and
then
getting
the
pods
to
actually
use
the
buckets.
B
Yeah
yeah,
I
agree
so
so.
We've
already
started
focusing
on
development
a
little
bit.
Here's
the
tough
balance
that
we
have
to
strike
it's
between
writing
code
and
making
sure
our
design
is
accepted
because
we
don't
want
to
write
code.
That's
going
to
that's
that!
That's
not
going
to
be
a
part
of
the
final
design.
B
I
agree,
I
think
that's
that's
completely
fair,
all
right,
so
so
in
terms
of
what
we
can
discuss
today,
I
still
think
bucket
policy
at
least
should
be
in
the
back
of
our
minds.
It's
just
one
of
the
concerns
that
needs
to
be
addressed
after
we
have
alpha.
You
know,
after
after
we
reach
alpha
status,
but
but
I
agree
there
should
be
a
focus
on
making
sure
whatever
we've
done
so
far
like
getting
feedback
on
what
we've
done
so
far
and
and
knowing.
C
B
That
that
actually
works
for
people
who
are
using
it
so
along
those
lines.
Let
me
ask
this:
how
many
of
you,
you
know,
represent
vendors
and
have
you
started
working
on
drivers.
B
I
know
jiffin
is
working
on
something
I
know
ben
you
worked
on
something
early
on,
but
after
that
has
there
been
any
progress.
A
Yeah,
it
says
speaking
for
netapp,
we
did
the
we
did
the
poc
with
the
ontap
s3
driver.
That
was,
I
think,
close
to
a
year
ago
or
maybe
10
months.
I
forget
exactly
how
long
it's
been,
and
we
haven't
done
more
of
that,
since
we've
been
waiting
for
the
next
iteration
of
the
sidecars
to
to
be
usable
and
then
we'll
update
that
poc.
B
Got
it
and
and
the
main
feedback
was,
it
was
hard
to
configure
user
access
type
right
like
it
was
hard
to
say
what
kind
of
access
would
be
provided
for
a
particular.
A
Yeah,
the
the
the
mec
the
the
process
of
this
just
defining
a
bucket
access
class
and
its
contents
were
made
made
no
sense
at
the
time
and
of
course,
we've
been
through
all
this.
You
know
and
we
redesigned
that
and
then
the
specific
fields
that
were
provided
to
the
grand
access,
rpc
and
the
return
values
also
didn't
didn't.
They
didn't
comport
with
like
what
we
actually
needed
to
do
right
because,
like
we
needed
to
get
like
a
I'm
forgetting
how
this.
B
Oh,
I
I
can
remind
you
so
in
the
bucket
access
class,
there's,
an
opaque
map,
string,
string
field
and
somehow
you'll
have
to
pass
a
provider
specific
access
definition
through
that.
So,
for
instance,
in
amazon,
the
provider
specific
way
to
define
access
is
through
im
policy
and
you
will
have
to
somehow
get
an
iem
policy
into
that
map.
String,
string
field
and.
A
No,
this
was
this
was
about
the
like
the
minting
of
a
of
a
access
key
and
a
secret
key,
and
then
how
we
return
those
back
to
cozy,
so
that
cozy
can
can
persist
them
in
a
place
where
the
pod
will
be
able
to
use
them
like
that.
I
think
that
it
was
the
basic
plumbing
of
you
know:
how
do
you
get
a
secret
key
and
an
access
key
out
of
the
driver
into
cozy?
You
know
through
that
grpc
interface.
A
Yeah
so
that
that
was
where
all
the
rough
edges
were
as
far
as
we
concerned
like
creating
buckets
and
deleting
buckets
like
that,
all
worked:
fine,
because
it's
pretty
straightforward
how
you
do
that,
but
granting
the
access
and
then
revoking
the
access.
The
grpc
felt
very
awkward
and
that's,
of
course,
the
other
half
of
what
a
driver
has
to
do
so
so
the
create
delete
part
was
was
easy
and
that
grant
and
deny
was
was
hard
and
hopefully
the
next
iteration
will
go,
go
more
smoothly
there.
B
Yeah
so
so
the
changes
that
have
come
in
there
around
grant.
B
Are
we
we
just
provide
a
policy
now
we
earlier
we
had
the
support
of.
We
had
the
support
for
choosing
an
existing
user,
and
I
think
that
made
the
design
unnecessarily
complex.
Now
we
we
just
provide
a
policy,
and
we
said
for
for
each
bucket
access.
We
create
a
new
service
cloud
service,
account
not
a
service
around
kubernetes
but
but
the
equivalent
of
a
user
for
applications
in
the
cloud
in
the
providers
and
the
object
storage
providers.
B
So
once
we
went
to
that
model,
we
didn't
have
to
have
references
to
the
user
in
the
way
we
were
doing
it,
the
more
complex
way,
which
was,
which
is,
I
think,
I
think
we
had
a
way
to
specify
who
the
user
was
going
to
be
and
what
policy
they
get
up
front.
And
now
it's
just
the
policy
a
new
user
gets
created
and
and
how
the
user
gets,
how
the
user
id
is
used
and
how
the
user
is.
B
The
life
cycle
of
that
user
itself
is
completely
opaque
to
the
user
to
someone
who's
using
cosy,
wow.
There's
too
many
user
words
here.
I
think
it's
gotten
simpler,
even
though
it's
kind
of
complicated
to
explain.
A
B
Right
right,
I
think
I
think
you
should.
I
think
it's
better
to
wait
until
you
know
it's
a
little
more
solid.
We
we
have
a
little
more.
I
mean
we
have
the
design
acceptance
and
we
have
code
in
a
much
better
shape,
but
but
I
would
still
like
to
know
where
you
know,
if
you
from
your
poc,
what
was
the
state
of
things,
because
it
is
important
to
address
these
concerns,
especially
around
passing
in
access
policy
through
the
bucket
access
class.
B
I
don't
think
that
that
part
just
the
way
in
which
we
pass
the
access
policy
hasn't
changed.
Fundamentally,
I
think
I
think
how
we
did.
User
management
has
changed,
but
but
how
we
passed
in
access
policy
just
has
not
changed.
So
if,
if
you
wanted
to
say,
give
access
through
this
bucket
access
class,
where
people
can
only
write
a
thousand
objects
or
if
you
wanted
to
have
a
specific
access
policy,
you
you'll
have
to
somehow
encode
that
entire
policy
inside
inside
inside
the
bhc.
A
B
Right,
but
there
are,
there
are
some
concerns
around
it.
Like
I
I'll
tell
you
the
one
thing
I
don't
like
about
that
approach.
You're
gonna
have
to
base
64
encoded
or
some
form
of
encoding,
at
least
at
least
escape
spaces,
or
something
while
putting
into
the
map
string
string
and
it's
not
readable.
A
I'm
saying
that
that
we
can
decide
this
to
have
very,
very
simple
predefined
policies.
Like
read
only
read
write,
you
know:
yadda
yadda,
you
know
just
simple
strings
that
demean
things
that
we
know
or
document
on
on
the
back
end,
and
then
you
can
have
some
other
mechanism
of
plugging
in
those
those
policies
on
the
back
end
so
that
they
don't
have
to
be
passed
through.
Cozy
cozy
can
just
select
from
a
menu
that
the
driver
knows
about.
B
You
can't
do
that
because
of
portability,
so
if
a
driver
was
able
to
define.
A
B
What
fields
they
were,
which
is
what
I'm
assuming
you're
saying
then
then
each
like,
even
if
it's
just
for
s3
going
from.
A
B
A
And
you
can
design
you
can
design
keys
and
values
that
make
sense
for
your
driver
and
then
you
right
put
them
in
your
documentation
and
we
put
them
in
our
documentation.
The
whole
point
is
this:
is
it's
a
it's
a
class
right?
It's
something
the
admin
creates
for
the
end
users
to
select
from,
and
users
don't
create
these
things.
So
there's
no
portability
concern
at
the
class
layer.
A
It's
it's
a
something
you
select
from
and
then
now
now
I
I
do
take
your
point
that,
like
to
the
extent
that
these
things
can
be
made
common
and
portable,
they
should
be.
But
I'm
saying
it
that's
a
very
hard
thing
to
get
right
from
the
beginning
and
a
simple
just
you
know
an
opaque
string
map
that
cozy
doesn't
do
anything
with
is
way
easier
to
deal
with
for
version
0.1
and
then,
if
we
want
to
design
something
that
actually
isn't
opaque
but
is
widely
supported,
then
we
can
do
that.
B
Yeah
yeah,
that's
yeah
yeah.
If
we
were
to
try
to
do
the
other
thing
where
we
we
try
to
find
that
balance
between
what
what
cozy
defines
and
what
what
should
be
just
an
opaque
string.
I
think,
like
you,
said
it's
very
hard
upfront.
At
least
I
mean,
even
even
in
the
long
run,
it's
very
hard,
even
with
all
the
feedback
that
you
get
from
users,
the
hardest
thing
is
is
trying
to
maintain
compatibility
between
multiple
vendors
or
multiple
different
providers.
A
Yeah
yeah,
I
I
think
the
starting
places
you
just
make
it
opaque
you
leave
it
up
to
the
vendors,
we'll
go,
do
our
things
and
then
we'll
come
back
together
after
we
all
have
working
implementations
and
we'll
figure
out
what
we
have
in
common.
It's
just
so
hard
to
talk
about
what
we
have
in
common
before
we
have
working
implementations.
B
Right
right:
okay,
okay,
it's
good!
It's
good
to
hear
that,
because
now
we
can,
we
can
redefine
our
goals
and,
I
think,
not
really
defined
but
but
kind
of
focus
on
on
other
aspects
of
of
cozy.
You
know
the
life
cycle,
which
is
which
is
development
again
about
10
months
ago,
that
that
was
our
focus
when
where
we
we
were
pushing
hard
to
get
a
working
implementation
and
then
we
had
one,
but
we've
had
significant
changes
in
design.
So
so
we
had
to
stop
that.
B
I
think
so.
Last
time
we
had
help
from
a
lot
of
volunteers,
and
this
time
I
think
people
start
signing
up
as
we
go
along,
but
but
even
otherwise
you
know
I
can
help
and-
and
we
have
jiffin
and
grant
last
time,
so
he
can
help
out
and
anyone
else
who
can
find
time
should
should
be
able
to
help
out.
You
know
we
know
who's
here
and
and
if
you
just
have
some
time
to
write
code,
you
know
I
I
humbly
request.
B
You
to
help
out
with
cozy,
but
but
I
think
we
should
be
good
on
the
development
front,
at
least
in
terms
of
the
the
effort
we
can
put
in.
I
think
we
have
enough
to
start
off
so
so
we
can
start
defining
development
goals,
then
so
so
I'm
looking
at
this
more
of
as
a
planning
meeting
trying
to
figure
out,
you
know
what
we
all
need
to
land
on.
B
What's
the
next
big
thing
that
we
need
to
focus
on,
because
our
current
thing,
which
is
which
is
you
know,
getting
the
kept
merged
or
getting
the
design
right,
getting
the
kept
merged,
we're
just
we
just
which
is
gated
on
on
our
reviewers
availability,
and
we
can't
do
anything
about
that,
but
what
we
can
control.
This
is
our
next
priority,
which
is
actually
getting
a
working
solution
in
place.
B
So
unless
anyone
has
any
objections,
I
would
like
to
start
focusing
on,
or
anyone
thinks
there's
some
other
some
other
higher
priority
thing.
I
think
I
think
it's.
I
think
I
would
like
to
focus
on
development
actually,
so
that
people
can
try
it
out
any
thoughts
on
that
like
ben.
A
B
Enough
yeah,
all
right,
so
that's
what
that's
kind
of
where
we
started
last
week,
but
it's
good
to
kind
of
just
say
it
explicitly
that
that
this
is
our
goal.
So
we
can
start,
we
can
start
working
on
it.
So
so
things
like
policy,
there's
there's
a
lot
of
bucket
policy
related
things
and-
and
I
I
I'm
pretty
sure
we'll
have
to
discuss
it.
I
don't
think
it
will
be
opaque
for
the
entirety
of
all
the
policies.
That's
that
bucket
support.
B
B
I
think
we've
made
progress
halfway
and
I
think
we
had
a
decent
design
to
start
out
with,
but
but
that's
the
other
priority.
I
it's
okay
to
not
start
a
discussion
on
that
right
now.
But
but
that's
that's
another
thing
that
we
need
to
focus
on
at
some
point.
B
Right
right,
but
I
don't
think
it's
fully
flushed
out,
so
the
reason
I
want
to
start
right
away
is:
I
wanted
to
go
back
and
visit
where
we
were
and
that
document
that
we
had
kind
of.
Where
is
this
storage
yeah?
This
one.
B
Yeah,
so
this
one,
this
one
has
info
about
what
those
what
the
last
last
agreement
was
yes
from
anyway,
but
it
was
from
earlier
this
year,
so
we
should
be
able
to
revisit
and
and
remember
what
exactly
that
was,
but
but
before
before,
getting
it
all
back
into
context.
I
don't
want
to
get
into
the
discussion
of
that.
Okay.
B
From
from
where
we
from
what
I
remember
best,
I
don't
think
we
fully
fleshed
out.
I
think
we
found
an
approach
that
worked
for
most
cases
and
or
yeah,
which
seemed
very
promising,
and
then
we
kind
of
left
it
at
that.
A
But
my
bias
is
towards
like
having
the
code
first
and
then,
once
you
have
the
code,
then
you
write
the
design
because
a
lot
of
it's
very
easy
to
write
a
design
that
doesn't
make
any
sense
right
and
then,
when
you
start
coding,
you're
like
wait
a
minute.
This
is
this
is
weird
like
once
you
have
code.
That
actually
does
the
thing
that
says
that
you
want
to
do.
Then
you
can
just
write
down
what
you
did
and
call
that
the
design
and
then
maybe
it
needs
to
be
tweaked.
A
If
there's
you
know
specific
specific
corner
cases
you
didn't
think
about,
but
I
don't
know
I
I
would
say:
there's
no
reason
not
to
just
take
us
take
a
swing
at
that
and
implement
what
we
wrote
down
and
then
you
know
if
if
people
can
point
out
reasons
why
it
has
problems,
then
then
we'll
go
fix
them.
B
I
think
I
think
the
reason
we
have
design
meetings
is
so
that
we
get
everyone's.
You
know
requirements
or
concerns
captured
just
so
that,
because
we
have
different
vendors
represented.
A
Yeah
yeah,
I
mean
I'm
not
saying
like
don't,
have
the
meetings
and
don't
gather
all
the
requirements
and
think
it
through
I'm
just
saying
at
a
certain
point,
it's
just
time
to
start
coding
yeah.
I.
B
Think
we're
there
yeah
yeah
all
right,
so
so,
let's
yeah,
let's,
let's
start
focusing
on
coding
again.
This
is
this-
is
the
yeah.
This
part
is
going
to
be
a
little
bit
easier
because
you
know
code
is
like
like
math.
We
already
know
what
the
right
answer
is
as
and
there's
a
right
answer,
at
least
so.
B
So
we
given
the
design
that
we
have
now
we
can
write
code
to
get
it
to
the
point
where,
where
we
match
what
we
have
now
and
as
things
change,
we
can
adapt
it
so
yeah.
So
it's
good
that
jiffin
has
started
on
on
api
and
he's
gonna
look
at
the
spec.
I
can
actually
start
looking
at
the
controllers
and
and
all
of
us
together.
I
think
we
should
be
able
to
get
something
working
fairly
soon
within
within
a
month
or
two
months
time.
A
B
All
right,
okay,
so
that's
all
I
have
from
my
site.
Unless
anyone
wants
to
bring
something
up,
you
can
have
14
or
13
minutes
of
your
time
back.