►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review - 20 August 2020
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
I
I
wanted
to
start
the
meeting
just
quickly
and-
and
I
I
think
we're
all
on
the
same
page
of
wanting
to
keep
the
kept
moving
forward
and
not
introduce
any
unnecessary
delays,
but
feel
confident
that
it's
going
to
work
and
so
there's
probably
more
urgency
with
some
people
than
others.
But
this
is
what
sid
and
sereni
and
myself
are
striving
to
achieve
to
to
build
up
confidence
among
this
team
that
that
we
have
a
working,
a
workable
architecture
at
api
and
grpc
specs
that
we
can
move
this
forward.
A
Not
every
detail
is
ironed
out
and
there
will
obviously,
as
we
get
to
coding,
there
will
be
changes
that
likely
will
occur,
that
we
will.
We
will
expose
and
get
feedback
on.
So
the
cap
doesn't
have
to
be
perfect.
It
has
to
be
good
enough
that
that
you
guys
have
confidence
and
that
that's
that's
the
litmus
test
I
believe
sid
will
be
presenting
some
things.
B
Now
all
the
bucket
access
all
the
users
that
have
access
to
this
bucket
are
captured
in
this
bindings
field
of
a
bucket,
which
has
a
list
of
bucket
accesses
that
have
access
to
this
bucket.
So
this
is
the
architecture
as
we
left
off
last
week,
and
some
questions
came
up
about
how
to
do
deletion,
and
for
that
I
have
the
same
diagram.
However,
I've
added
a
bunch
of
new
bucket
access
requests.
B
B
B
C
So
this
is,
this
has
been
sorry.
I
was
on
vacation
last
week,
and
so
I
had
to
how
did
david
bring
me
back
up
to
speed.
Why
I
don't
understand
why
we
don't
follow
the
model
we
followed
for
snapshots,
where,
like
we,
don't
actually
have
multiple
things
pointing
to
the
same
object,
but
instead
we
just
have
multiple
unnamed
spaced
objects,
each
with
a
one-to-one
relationship
because
it
solves
so
many.
C
Yeah
yeah,
just
and
you'll
end
up
with
multiple
buckets
objects
pointing
to
the
same
actual
bucket,
but
then
deletion
becomes
simple
because
you
have
one-to-one
relationship
between
your
bucket
requests
and
your
buckets
and
they
all
have
deletion
policies
and
whatever
one
says
to
actually
delete.
It
causes
the
deletion
to
occur
and
all
the
other
ones
don't
yeah.
So.
B
Let
me
take
a
crack,
so
if
we
did
that,
if
we
did
that,
we
would
end
up
with
with
multiple
bucket
objects
pointing
to
the
same
back
in
bucket,
then
the
problem
becomes
deletion
of
the
back
end
bucket
where
multiple
bucket
objects.
We
will
still
have
this
problem.
I
think
there's
a
there's
a
better
solution
for
this,
so
what
we
explored.
We
had
a
conversation
about
this
earlier
this
week
in
the
engineering
meeting.
Was
this
idea
of
a
single
ownership?
B
C
B
C
Right
right,
the
the
key
would
be
that
when
you
set
up
the
the
new
bucket
request
to
bucket
binding,
you
would
decide
whether
that
one
had
the
capability
to
delete
it
or
not
and
and
in
theory
either.
The
administrator
who
did
that
or
the
controller
that
did
that
on
the
user's
behalf,
would
would
know
whether
that
was
the
right
thing
to
do
in
that
situation.
G
C
It
it
puts
the
problem
in
the
hands
of
of
that
entity,
not
not
at
the
kubernetes
api
level,
because
then
the
kubernetes
api
becomes
simple.
You
just
say
well,
if
yeah.
If,
if
this
bucket
is
marked
as
delete
on,
you
know,
actual
the
deletion
policy
of
delete
will
do
it
and
if
it's
not,
we
won't-
and
it's
someone
else's
job
to
set
that
correctly.
So
they
get
the
behavior
they
want.
C
A
A
B
So
so
he
doesn't
mean
retain
policy.
The
retain
policy
is
a
release.
Policy
is
for
the
contents
of
the
bucket.
He
means
the
bucket
itself.
That
is,
should
the
so
it
won't
have
this.
This
second
option
of
retain
it'll
it'll,
be
a
boolean,
but
which
will
say
either
this
one
deletes
the
bucket
or
it
doesn't,
and
because.
C
B
C
C
I
I
I
think
I
think,
when
it's
with
volume
and
snapshots,
maybe
it's
a
little
bit
different
because
of
volume
and
snapshot.
This
situation
is
kind
of
it's
very
rare.
When
you
have
that
situation,
I
I
would
say
from
my
experience
like
why
would
you
have
this
like
same
volume,
pointing
to
the
same
under
like
multiple
volumes
pointed
to
the
same
underlying
volume?
C
C
I
E
A
Box
I
wanted
to
bring
up
andrews
two
things:
what
you,
what
you
and
ben
are
that's
a
great
question
ben,
because
that
that
is
the
nature
of
this
design
and
architecture.
So
that's
a
fair
discussion
to
resolve
and
make
sure
that
we
have
a
good
solution
and
second
point
is:
we
have
a
one-to-one
mapping
between
a
bucket
access
request
and
the
bucket
access
cluster
scoped
object,
and
that
shows
the
access
to
a
bucket.
A
E
A
A
E
The
many-to-one
has
had
a
number
of
issues
that
we've
talked
about
reference
counting.
How
do
you
know
when
to
delete
everything
else,
and
I
think
what's
happened
is
not
that
we
can't
come
up
with
a
technical,
workable
approach.
It's
just
that
people
are
uncomfortable
for
a
variety
of
reasons,
with
the
different
approaches,
because
they
don't
reflect.
E
F
B
E
B
B
C
You're
presuming
that
no
one's
going
to
write
controllers
to
help
with
these
things-
I
I
mean
I,
I
don't
think
anyone
you
know
is
manually
twiddling
with
yaml
most
of
the
time
when
they're,
when
they're
interacting
with
kubernetes.
Usually
you
you
build
higher
level
abstractions
on
top
of
these
low-level
abstractions,
to
make
these
kinds
of
things
less
painful.
I.
B
I
I
have
to
respectfully
disagree
with
that.
One
point:
maybe
even
the
bigger
point
that
we're
trying
to
make
is
a
different,
but
but
just
that
one
thing
where
most
people
are
still
struggling
with
the
animal
having
worked
with
customers.
I
unfortunately
know
this
part
and
it's
always
like
a
simple
stupid
mistake:
that's
bringing
down
the
whole
cluster
like
they
get
a
spelling
wrong
or
something
like
that.
B
I
think
there
is
a
lot
of
uncertainty
around
how
this
is
going
to
be
used,
and
I
think
I
think
it's
worth
actually
putting
it
out
there
and
testing
how
it
goes
and-
and
that
would
mean
we-
we
go
ahead
with
the
approach
we
flushed
out
the
most
right
now,
while
keeping
in
mind
that
there's
a
better
approach
and
then
we
will
treat
this
like
a
testing
exercise
and
and
based
on
what
we
learn
we
can.
We
can
go
back
and
try
the
other.
I
I'll
guess
correctly,
if
I'm
wrong,
we
are
the
main
problem
comes
with
use
case
when
we
go
from
green
field
to
brownfield,
because
it
looks
like
for
pure
green
field,
like
it's
obvious
that
the
guy
who
created
bucket
can
delete
bucket
for
brownfield.
It
looks
like
admin
creates
bucket,
and
I
think
retention
policy,
if
it
has
a
retention
policy,
should
be
always
like
retain
right.
So
nobody
deletes
it
because
it
just
should
be
there
and
we
are
talking.
The
main
problem
is
when
it
goes
from
green
field
to
brown
field.
E
Two
different
bucket
classes,
one
that
was
used
to
provision
a
green
field
and
has
in
it
that
you
have
delete
and
the
other,
which
is
for
all
of
the
other
brown
fields
and
you
have
in
it
retaining.
So
I
don't
think
that
if
you,
if
you
do
the
multiple
bucket
approach,
there's
any
question
about
who
deletes
or
anything
else,
it's.
B
That
the
admin
won't
make
mistakes
at
that
point,
we're
saying
they
they'll
do
it
perfectly
where,
where
they
will
not
end
up
with
unintended
buckets
with
with
deletion
policy.
There's
also,
this
other
confusion
there
of.
If
I
have
the
the
first,
I
I
create
two
bucket
objects,
let's
say
the
first,
both
of
them
point
to
the
same
backing
bucket
and
the
first
one
says:
retain
the
data
after
you
delete
this
object.
The
other
one
says:
delete
the
data
after
you
delete
this
object.
How
do
you
resolve
that
right?.
J
Things
like
that
who
who,
who
is
the
bucket
to
be
representing
the
actual
thing
outside.
Of
course,
there
is
sharing
with
the
ot
with
the
rest
of
the
world,
but
in
this
case,
what
we're
saying
is
that
we're
not
even
giving
a
single
view
for
all
the
namespaces
right?
We
have
this
like
disconnected
views
of
the
bucket
between
them.
So
I
think
it's
it's
fine,
but
then
I
think
what
we're
saying
is
that
we
don't
want
to
automate
bucket
life
cycle
things
we
just
want
to
allow
provisioning
and
deletion.
E
I
I
don't
think,
that's
true,
because
there's
a
difference
between
brownfield
and
greenfield
so
for
greenfield.
We
absolutely
completely
automate
bucket
provisioning
and
life
cycle,
but
what
what
we're
just
saying
is
that
for
the
brownfield
case
there
are
a
number
of
sticky
edges
and
one
possible
approach
for
brownfield
is
to
just
say:
look.
You
got
to
directly
deal
with
all
those
sticky
edges,
we're
not
going
to
try
to
be
magic
and
and
and
oh
and
intuit,
some
sort
of
policy
out
of
this
by
convincing
everybody.
J
E
The
api
objects
in
the
name
space
is
because
they're
dealing
with
two
different
problems,
so
one
of
them
is
whether
you
are
pointing
at
an
existing
bucket
underlying
bucket
or
whether
you're
minting
an
underlying
bracket.
That
problem
is
completely
distinct
from
providing
access
to
your
user
or
your
application
to
access
that
bucket.
There
are
two
different
questions:
one
is
bucket
provisioning
and
life
cycle.
The
other
is
bucket
access,
provisioning
and
life
cycle
and
both
are
reasonable
problems.
E
The
first
has
a
share
brownfield
kind
of
mode.
The
second
has
a
indirect
mode
where
you've
sort
of
handled
it
out
of
band,
so
they
they
both
have
modes
to
allow
for
management
outside
the
kubernetes
space,
but
they
are
different
problems.
I
mean
you're
you're,
managing
different
things,
which
is
why
there's
two
namespace
objects
right
right.
B
A
E
Where
is
the
problem
with
multiple
bucket
requests
pointing
to
the
single
bucket?
The
problem
is,
it
is
not
easy
to
express
how
you
should
manage
life
cycle
in
that
case,
that
problem
exists
in
two
ways:
it
exists
with
bucket
requests,
multiple
bucket
requests
tied
to
the
same
bucket,
and
it
exists
with
multiple
bucket
accesses
tied
to
the
same
bucket.
E
So
you
have
effectively
kind
of
two
sets
of
references
that
that
you
have
to
figure
out
when,
when
you
can
actually
take
action
on
the
underlying
bucket
is
problem,
one
and
problem
two
is
which
of
these
bucket
requests
kind
of
own,
the
management
of
that,
because
they
could
come
in
from
different
classes,
so
they
could
have
different
policies
at
their
level.
Yet
normally
we
reflect
that
policy
at
the
bucket
level,
not
in
the
bucket
request
level.
So
how
do
so?
This
now
gets
us
into
a
situation
where.
E
F
B
B
The
the
life
cycle
does
not
need
to
be
managed,
because
and
and
the
bucket
deletion
can
always
be
manual,
and-
and
you
know
we
can
go
back
to
one
of
the
suggestions
that
ben
made,
which
is
have
the
policy
on
the
bucket
request
which,
when,
when
provisioning
the
bucket
request
or
when
creating
that
you
could
say,
I
want
delete
permissions
on
this
bucket
request.
That
is,
if
I
delete
this
bucket
request,
the
underlying
bucket
should
be
deleted.
That's
that's
one
way
of
doing
it.
E
Yeah,
I
guess
my
point
is
that
that
I
don't
think
you've
actually
reduced
the
work
when
you
have
a
heterogeneous
set
of
delete
policies
among
the
clients
of
a
bucket
yeah
one
question:
you
have
to
create
multiple
buckets
in
the
other
case,
you
have
to
go
into
that
bucket
and
manage
per
bucket
request
policy
statements
about
who's
allowed
to
do
what.
So,
it's
still
a
cardinality.
B
E
Makes
sense
in
a
greenfield
case
right
for
brownfield,
there's
no
owner,
because
I
mean
you
have
a
weird
edge,
which
is
this
green
promoted
to
brown.
But
I
I
question
whether
that's
ever
actually
going
to
happen
likely
to
have
pure
brown
or
pure
green.
And
if
you
look
at
those
two
scenarios,
pure
brown
nobody's
going
to
be
deleting.
B
Nobody's
going
to
be
doing,
but
the
bucket
object
can
be
deleted.
You
see
that
that's
where
I
think
we
both
see
the
difference,
which
is
the
bucket
object.
Deletion
is
okay
and
that's
all
we're
going
to
be
doing
the
owner
still
makes
sense
when
that's
how
you
look
at
it
and
and
the
the
the
thing
is,
we've
thought
about
this,
and
we
also
have
an
alternative
approach
that
I
want
to
propose
that
just
just
so
we
have
more
information
about
where
this
is
going.
B
So
guy
and
jeff
also,
you
know,
brought
up
a
very
interesting
approach,
which
is
we
don't
have
multiple
requests
per
bucket.
Rather
it
might
make
more
sense
same
diagram
without
the
multiple
bucket
access
requests.
What
we're
seeing
is
have
the
bucket
access
request
directly
point
to
the
bucket
and
have
only
one
bucket
request.
B
A
Just
say
it's
green
field
sure!
Well,
it
is
what
ben
and
it
is
this
one-to-one
mapping
between
a
br
and
a
b,
but
there's
still
only
one
b,
but
you
get
a
multiple
accessors
to
the
b
and
that's
where
the
bar
to
ba
mapping
comes
in
and
that's
one
to
one
and
and
so
what
all
you're
saying
is
that
if
you,
if
you
look
at
brownfield,
why
should
I
have
to
create
a
br
and
a
bar
as
a
user?
E
E
B
So
so,
to
explain
that
a
little
bit
more,
if
you
have
brownfield
access,
you
know
the
name
of
the
bucket
name
name
of
the
bucket
up
front.
However,
if
it's
greenfield,
you
don't
know
the
name
of
the
bucket
up
front,
because
you,
you
only
have
the
bucket
request
and
you
have
the
bucket
access
request,
but
the
actual
bucket
hasn't
been
done
yet
absolutely
true
for
this,
we
so
so
the
two
approaches
we
have
to
to
and
which
is
where
we
need
your
help,
is
what
what
we're
thinking
is.
B
We
have
the
bucket
access
request
pointing
to
the
bucket
name
if
it's
brown
field
or
bucket
request
name,
if
it's
green
field,
this
introduces
a
difference
in
ux
user
experience
for
greenfield
versus
brownfield,
and
I
think,
maybe
guy
or
jeff,
who
came
up
with
this
idea.
If,
if
you'd
like
to
say
a
few
things
about
what
we
you
know
how
we
came
up
with
this,
please.
J
I
I
can
just
give
her
the
rationale
I
think,
compared
to
what
ben
suggested,
I
think
benches
suggest
that
we
sort
of
allow
every
namespace
to
be
a
manager
essentially
of
the
life
cycle
right.
So
we
we
extend
bucket
request
to
every
namespace,
basically
right,
so
it's
possible
we're
not
saying
it
has
to
be,
and
in
our
case,
what
we're
saying
is
we
actually
restrict
sort
of
restricted
it
to
only
the
cluster
scope.
E
So
I
would,
I
would
just
observe
that
this
achieves
the
same,
which
is
it
gives
us
one-to-one
binding
between
bucket
request
and
bucket.
So
it
actually
does
for
that
part
of
the
architecture,
more
aligned
with
the
the
sort
of
kubernetes
approach
bucket
access
has
also
one-to-one,
and
so
that
so
then,
the
only
thing
that's
left
is
this
weirdness
of
bucket
having
no
knowledge
of
bucket
access.
B
B
I
A
list
of
bindings,
I
have
to
say,
yeah
yeah,
I
think
I
think
we
were
talking
about
one
more
disadvantage
of
this
model
right
is
that
users
need
beforehand
know
if
it's
a
greenfield
or
brownfield
if
it's
an
existing
bucket
or
if
it's
auto,
created,
buckets
so
yeah
and
actually
application
deployment.
Yaml
should
actually
really
be
different
for
these
two
cases,
so
we
lose
some
portability
of
this.
In
this
case,.
A
G
A
K
E
I
agree
I
agree
I
mean
greenfield.
Is
I
don't
really
care,
I'm
not
going
to
be
sharing
this,
I'm
going
to
meant
a
magic
name
brownfield.
Is
I'm
going
to
be
coordinating
through
this
with
other
people,
or
else
I'm
starting
with
a
provision
set?
So
I
think,
by
the
time
you're
crafting
the
ammo
you're
usually
going
to
know.
A
E
Yeah,
I
I
think,
that's
you
know
if
you
just
think
about
as
an
application.
Why
would
I
want
greenfield?
I
mean
it.
It
causes
all
kinds
of
problems
right,
it's
like
it's
non-deterministic
bucket
name,
so
there
are
probably
a
class
of
things
where
hey
man,
I
just
need
storage
and
I'm
the
only
one
who's
ever
going
to
use
it
and
then
yeah.
E
It
is
kind
of
like
block,
except
that
it's
object
right,
you're,
the
one
who's
going
to
be
interacting
with
it,
but
I
think
it's
a
very
different
use
case
when
you're
using
object
for
the
purpose
of
interacting
with
other
applications,
for
you
know,
data
processing,
pipelines
or
anything
else
where
somebody's
going
to
be
consuming
it
yeah.
I
I.
B
I
So
yeah,
but
at
the
same
time
user
like
may
think
like
yeah
as
andrew
mentioned,
I
need
storage
and
basically
I
don't
care
if
it's
storage
like
existing
or
a
new
one.
I
just
need
some
storage
and
I'm
gonna
use
it
and
it
basically
it
was
up
to
admin
to
tell
you
which
storage
to
use-
and
now
it's
basically
it's
more
like
going
to
user,
so
user
needs
to
say.
Oh,
I
need
this
type
of
storage.
It's
not
it's!
Not
admin
decision
anymore!
It's
more
like
up
to
user,
too.
E
J
F
J
That's
that's
a
good
point,
because
in
in
many
cases
what
I
would
want
the
application
is
to
to
request
is.
I
would
like
to
request
a
let's
say
a
logs
bucket
right
and
I
would
like
the
admin
to
decide.
What
is
the
logging?
You
know,
operation
policy,
for
that?
How
do
I
provision
logs
buckets?
Do
I
provision
this
all
in
the
same
one
or
what
you
know.
G
Yeah
so
I
mean:
are
we
saying
that
minting
a
bucket
that
is
going
to
be
for
brownfield?
We
don't
have
a
case
for
that,
so
because,
if
you're
minting
a
green
field,
it's
going
to
be
a
a
non-deterministic
name
right,
so
you're
not
going
to
be
able
to
have
an
automated
way
of
making
that
brownfield
in
the
future.
E
Well,
it's
non-deterministic,
but
once
it
has
been
created
you
know
what
it
is.
So
if
you
so,
if
a
greenfield
app
has
written
into
a
bucket
and
created
a
bucket
and
then
at
a
later
point
in
time,
you
want
other
apps
to
be
able
to
access
it.
Then
you
would
just
provision
the
brownfield
pointing
at
that
specific
bucket.
E
Would
I
be
able
to
automate
that?
Well,
the
problem
with
automating
is
then
it's
an
order
of
operation
thing
which
guy
is
going
to
create
the
bucket.
If
you
bring
the
other
guys
up
that
that
want
access
to
it
before
the
bucket
is
cr
brownfield
before
the
greenfield
bucket
is
created,
then
you
kind
of
are
locking
yourself
into
a
deployment
model.
So
if
you,
if
you.
I
A
Well,
where
the
name
matters
the
most,
I
think
is
this
green
to
brown
like.
Why
did
I
provision
a
bucket
if
I'm
not
going
to
access
it
right,
so
I've
got
an
app.
It
needs
a
block,
block
mode
type
access
to
a
bucket
and
it
needs
to
it
needs
to
provision
the
bucket
and
then
use
the
bucket.
So
in
that
case
it
it
somehow
needs
to
know
the
name
of
the
bucket
instance
that
we've
created
for
and,
and
that
name
is,
has
randomness
in
it.
So
how
does
it
know?
A
It's
not
a
deterministic
name
like
it's
been
mentioned,
so
that
is
what
sid
mentioned
a
few
minutes
back.
Is
that
in
that
case
of
green
going
to
brown,
which
is
not
rare,
it's
every
greenfield
case
is
a
green
to
brown,
because
I
need
to
access
the
bucket
and
therefore
what
you
would
do
in
your
bar
is
you
would
reference
the
name
of
your
br
and
in
the
br
b,
so
you're
still
good,
you
don't
need
to
know
the
name
of
the
bucket
to
create
the
br
or
the
bar.
E
A
E
No,
I'm
not
I'm
actually
suggesting
it's
it's
it's
more
than
that
when
you're
doing
a
bucket
access
class,
you
know,
in
other
words,
instead
of
the
bucket
access
request,
having
to
know
that
it's
greenfield
or
brownfield.
We
make
the
bucket
access
class
know
what
greenfield
or
right,
and
so
it's
the
one
that
contains
the
reference
to
the
bucket
or
to
right.
Yeah.
J
D
J
The
other,
the
the
concept
that
ben
raised,
having
just
a
straight,
you
know
bucket
requests
in
the
bucket.
It
makes
a
little
bit
more
sense
actually,
because
you
know
if
what
we
are
saying
is
that
give
the
admin
to
just
control
sharing
and
not
only
control
but
be
responsible
to
do
everything
about
it
or
automate
it
on
its
own.
But
cozy
is
not
part
of
it.
Then
it
makes
more
sense
to
just
have
it.
B
Yeah,
it
is
weird
that
is
true,
so
I
think
I
think
what
I
want
to
do
now
is.
I
think
I
think
we
should.
I
I
think
we
should
test
it
out.
I
I
think
we
should
test
out
and
see
what
the
users
are
going
to
use,
how
the
users
are
going
to
use
this.
Basically,
I
want
to
know
out
of
these
two
approaches,
which
one
should
I
try.
First,
my
my
preference.
I
A
Yeah,
so
so
so
I
like
it
too,
I
like
it
from
the
point
of
view
of
you
unburdened
the
developer
from
the
the
brownfield
case
from
needing
to
know
at
the
in
the
user
space.
What
the
name
of
the
the
bucket
instances-
and
I
like
that
part,
the
the
a
downside
potentially,
is
that
you
need
a
right
now.
The
bac
is
an
abstraction
of
policy
right
to
well.
A
B
E
I
think
so
yeah
good.
Let
me
just
say
that
that
it
strikes
me.
The
difference
here
is
between
accepting
this
wart
of
having
to
provision
bucket
access
classes.
No
note
that
it's
one
per
bucket,
not
one
per
access
right,
correct.
So
so
it
you
know
it's
basically
one
per
brownfield
bucket
that
you're
trying
to
provision.
J
E
Right,
so
so
what
what
you
introduced
earlier,
that
I
was
arguing
with
you
with
I'm,
not
what
I
tend
to
do
this,
trying
to
explain
other
people's
ideas.
I
apologize
for
that,
but
what
I
understood
was
that
you
were
suggesting
that
look.
Let's
just
have
a
buck,
but
one
to
one
bucket
at
request,
a
bucket
whether
it's
greenfield
or
brownfield.
E
I'm
not
sure
that's
true
for
brownfield,
but
but
but
regardless
just
to
distinguish
between
the
two.
It
would
mean
that
effectively,
the
difference
is
a
bucket
per
user
of
the
bucket,
where
user
is
namespace
or
a
bucket
per
underlying
bucket,
but
still
being,
but
both
approaches
being
able
to
preserve
the
one
request
to
one
bucket.
E
E
I
E
E
H
B
I
mean
yeah,
I
I
think
I
think
what
we're
right
now
trying
to
discern
between
is
a
tiny
detail.
Whether
and
I
call
it
that
deliberately,
which
is
whether
the
bucket
access
request
directly
points
to
a
bucket
from
the
origin,
from
the
design
that
we
explained
or
if
it
points
the
bucket
through
the
bucket
access
class.
I
think
that
can
be
resolved,
so
we
only
have
very
little
time
left,
so
I
think
that
can
be
resolved
going
forward.
B
But
what
I
have
here
are
one
was
we
made
the
access
policy
opaque
instead
of
trying
to
model
a
love
and
deny
rules?
We
had
this
problem
come
up
with
service
accounts
where,
if
there
were,
if
there
was
a
conflict
of
access
for
the
same
service
account,
how
do
we
resolve
it?
We
resolved
it
by.
We
came
up
with
the
conclusion
that
it's
best
to
deny
any
new
access
requests
that
have
a
policy
that's
different
from
what
was
originally
given.
The
third
one
was
a
bucket
credentials
path
resolution.
B
We
weren't
entirely
sure
of
how,
where
we're
going
to
mount
or
provide
the
credentials
within
the
part
we
resolved
it
by
saying
there
should
be
some
sort
of
a
base
path
and
there
should
be
the
file
name
or
the
rest
of
the
path
of
where
the
credentials
should
be
given.
So,
for
instance,
if
you're
running
an
ubuntu
part,
the
home
directory
might
be
different
from
running
a
different
part
with
a
different
os,
and
so
so
that
should
be
left
to
the.
The
creator
of
the
part
is
what
we
decided.
B
B
We
should
talk
about
next
steps
in
terms
of
so,
like,
I
think,
after
today's
discussion,
I
think
the
decision
we're
going
to
end
up
with
is
is
some
form
of
this
design,
where
we
either
directly
point
to
a
bucket
from
bucket
access
request
or
point
to
the
bucket.
Through
the
bucket
access
class
and
in
green
field
cases,
we
have
the
bucket
access
request,
likely
point
to
the
bucket
request.
K
Son,
I
think
this
was
the
last
big
open
issue
in
terms
of
kind
of
data
flow.
Once
we
have
this
locked
down,
I
think
it
would
be
okay
to
sign
off
on
working
on
the
alpha
and
we
can
take
it
from
there.
So
maybe
let's
continue
this
discussion
next
week.
I
think
one
more
area-
and
it's
pretty
minor-
that
I
wanted
to
talk
about-
was
we
have
protocols
by
s3,
aws,
gcs
et
cetera,
small
minor
knit?
B
J
J
J
K
B
A
B
A
J
J
K
B
J
J
J
B
J
B
K
The
only
reason
that
we
care
about
this
is,
if
how
we
surface
the
information
bucket
information
into
the
container
changes
by
version
all
right,
otherwise,
for
us
it's
effectively
passed
through,
we
don't
really
care
what
the
version
is.
If
it's
s3,
depending
on
the
protocol,
we
change
how
we
surface
up
the
information
into
the
container
right.
B
K
K
C
B
B
A
Great
everyone's
invited
it's.
This
is
the
same
link.
Isn't
it
yeah?
It
would
be
great.
To
get
more,
I
mean,
I
think
I
see
the
finish
line
in
front
of
us,
so
we're
really
close.
If
we
can
just
keep
the
momentum
up
another
week,
I
think
we're
going
to
get
there.
Yeah
monday
meeting
will
be
good.
Did
you
say
it's
the
same
zoom?
It's
the
same.