►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Object Bucket Provisioning KEP Review - 30 July 2020
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
B
Okay,
so
so,
hopefully,
everyone's
had
a
time
to
switch
from
sig
storage
if
they
were
attending
that
this
is
part
two
of
like
the
final
stretch
on
this
cap.
A
week
ago,
we
we
went
over
the
apis.
We
captured
some
feedback.
We've
tried
to
incorporate
it
into
this.
There's
been
several
commits
into
this
version
of
the
kept
that
I'm
sharing.
Now
I'm
sharing
the
formatted
version
of
it
and
xing.
You
dropped
a
comment
where
you
sent
us
a
link
on
the
more
official
deprecation
for
phase.
B
B
The
two
required
fields
which
are
kind
in
status
or
type
and
status,
but
we'll
we'll
consider
others
as
well
like
reason
anyway.
So
this
version
of
the
kept
doesn't
have
that.
But
the
goal
of
this
meeting
is
to
go
through
the
rpc
mechanism,
which
we
skipped
last
time
and
workflows
and
then,
with
five
minutes
left,
I
am
going
to
try
to
stop
conversation
if
possible
and
get
a
straw
poll
vote.
Just
get
a
straw
man
vote
and
see
where
the
11
12.
Whoever.
B
B
If
the
vote
is
a
nay,
then
you
know
because
of
outstanding
issues
to
resolve,
then
my
focus,
our
focus
will
be
on
those.
So
that's
that's
my
plan
and
so
the
so
the
parts
of
the
kepler
covering
here
are,
oh,
I
think
maybe
sid
would
like
to
go
through
the
diagram.
So
if
I
click
on
the
topology
link,
he's
got
oh,
and
just
above
that
I
put
a
pod
manifest.
E
D
B
B
We've
said
this
before
and
and
sid,
and
I
were
looking
at
it
and
we
were
thinking
that
we
do
not
need
a
bucket
request
for
any
brownfield
use
case.
We
just
need
the
bucket
access
request,
because,
after
all,
that's
all
we're
doing
is
asking
for
access
to
a
bucket.
That
already
exists,
we're
not
creating
one,
and
so
why
should
I
have
to?
Why?
Should
a
user
have
to
create
a
bucket
request
and
a
bucket
access
request
just
to
get
access
to
an
existing
bucket
and
the
bucket
classes
being
ignored
in
that
scenario
etc?
F
So
the
question
is,
then,
how
do
I,
as
a
kubernetes
administrator,
regardless
of
of
setting
up
the
read,
write
or
whatever
kind
of
access?
How
do
I
say
that
only
these
name
spaces
are
allowed
to
access
this
bucket
so
that
that
in
the
bucket,
are
you
saying
that
would
be
a
read
through
on
the
bucket
access
request.
B
When
those
resources
are
immutable
and
we
concluded,
we
did
not.
We
are
aware
of
the
use
case
or
the
the
request
that
you're
making
or
the
or
the
concern
you
have,
but
we
we
don't
think
that's
a
good
way
of
doing
it
right
now,
but
sid
you
had
a
reason
for
that.
Do
you
want
to
elaborate
on
the
current
elimination
of
name
spaces
in
bucket
bucket
class.
D
Yeah,
so
there
was
a
field
called
permitted
name
spaces
in
bucket
class.
What
it
essentially
did
was
to
say
up
front
that
these
are
the
namespaces
in
which
this
bucket
could
possibly
be
provisioned
for
workloads
and
what
we
realized
was
say.
I
have.
I
have
a
bucket
that
I've
I've
given
a
set
of
pro.
You
know,
permitted
namespaces,
and
we
were
talking
about
it.
Jeff
and
I
were
talking
about
in
terms
of
an
organization
which
has
a
bunch
of
teams.
D
D
Given
the
given
the
given
the
restriction
based
on
name
spaces,
is
we
have
to
create
a
new
bucket
class
or
delete
the
existing
one
and
create
a
new
one
and
then
have
this
new
namespace
be
added
to
that
the
the
whole
reason
being
bucket
classes,
just
like
storage
classes
are
immutable,
so
we
wouldn't
be
able
to
just
add
another
permitted.
Namespace.
C
C
C
B
C
In
this
case,
what
I'm
imagining
is,
you
would
have
a
set
of
white
listed
name
spaces
as
part
of
the
bucket
object.
So
if,
if
you
wanted
to
extend
the
set
of
namespaces
that
a
specific
bucket
was
allowed
access
to,
instead
of
having
to
delete
and
recreate
the
storage
class
object,
you
can
just
update
the
bucket
object,
which
would
be
fairly
straightforward.
Would
that
work,
but
I'm
going.
B
F
F
D
F
D
F
I
I
don't.
I
don't
know
how
you
can
do
that
if
part
of
bucket
access
provisioning
could
be
minting
credentials
and
minting
the
actual
account
that
accesses
those
credentials
right,
you
you've
effectively
got
no
mechanism
to
be
able
to
apply
that
policy
unless
you
assume
that
you've
already
worked
out,
who
has
access
to
what
and
then
you're
going
to
rely
on
some
sort
of
you
know:
drill
through
access,
where
user
you
know,
service
account
x,
means
cloud
account.
Why,
which
certainly,
I
won't
support
that
mechanism,
but
I
think
you've
written
off
the
other
one.
F
Right,
so
the
purpose
of
bucket
access
request
was
primarily
to
deal
with
single.
The
the
access
to
this
bucket
by
this
particular
account
right
like
like
what
what
you
know
at
the
protocol
level.
You
know
here's
who
you
have
to
authenticate
as
and
by
the
way,
here's
the
what
I'm
going
to
automate
the
setup
of
on
the
back
end
in
terms
of
access
credentials.
So
if
we're
saying
that
bucket
access
request
is
how
you
provision
that
I'm
asking,
where
do
you
control
it?
F
B
Right
because
what
you're
saying
is
anyone
could
create
anyone
grant
you
know
many
users
would
have
the
ability
to
create
a
bucket
access
request
and
and
and
they
can
reference
their
own
secret
or
a
service
account.
But
I
mean
the
two
fields:
the
two
top
fields
on
your
spec
is
the
service
account
name
or
your
secret
name.
The
operation.
F
Oh
wait
a
minute,
so
maybe
maybe
you've
done
something
else
here
too,
so
it
might
be
that
I'm
missing
something.
If
we
go
back
to
the
very
original
proposal
here
and
certainly
the
way
that
that
we
ended
up
implementing
our
version
of
this
is
the
driver
would
actually
mint
a
service
account
on
the
cloud
side
and
meant
access
to
that
service
account
for
so
mint
mint
access.
F
So
add
a
at
a
roll
binding
for
accessing
that
that
that
that
to
to
that
bucket
and
then
download
a
key
that
then
got
stored
in
a
secret,
which
then
was
was
passed
to
the
application.
So
there
the
entire
flow
there
was
automated,
and
I
thought
we
were
preserving
that
as
one
option,
which
would
go
all
the
way
down
to
minting
an
access
key
and
then
making
it
available.
F
F
F
D
D
C
C
A
C
F
So
so
I
want
to
say
is
a
I
think,
you're
both
expressing
that
we
should
be
able
to
have
consume
control.
Then
the
secondary
question
is:
should
we
that
control
that
by
namespace
or
should
we
control
that
by
service
account
is
one
of
those
preferable
to
the
other
and
then
finally
the
third
thing
is
yeah?
Okay,
so
if
it
does
go
in
the
class,
it
should
also
be
copied
into
the
bucket
so
that
when
you're,
looking
at
substrate,
you're
actually
referencing
the
bucket,
not
the
class.
When,
when
trying.
B
To
do
and
and
andrew
you
you've
made
a
compelling
point,
you
saw
and
aaron
chiming
in
as
well.
I
I
don't
see
the
number
of
participants,
but
does
anyone
else
wanna
and
there
was
a
plus
one
on
the
automatic
minting
workflow
that
andrew
described
and
and
and
you've
made
good
arguments.
I
want
to
know
what
some
other
people
on
the
call
think.
G
G
F
F
G
B
B
B
D
F
Yeah,
that's
security
through
obscurity.
That
just
says
the
person
can
see
this
or
or
or
are
you
suggesting
that,
through
our
back,
you
can
make
that
bucket
only
visible
to
be
because
the
controller
is
not
running
it's
doing.
The
binding
is
not
running
in
that
client
side
right.
So
I
don't
think
normal.
Our
back
works
for
this,
or
am
I
wrong.
F
Right
so
I
I
don't
think
you
can
just
craft
a
rule
that
says
this:
namespace
can
access
this
or
this
namespace
can
access
this
because
that's
it,
it
doesn't
work
that
way.
It
would
be.
This
user
can
access
this
and
so
sure
you
could
make
it
so
some
users
wouldn't
be
able
to
see
all
of
the
buckets,
but
that's
security
through
obscurity.
G
B
B
K
B
H
K
K
We
even
started
the
cap
discussions
suggesting
it
and
then
having
same
discussion
about
you,
know
the
one
of
the
community
meetings.
There
was
a
request
to
by
andrew
that
was
echoed
by
some
other
folks
saying
that
you
know
without
without
the
minting
of
credentials,
and
you
know
the
automation
of
creation,
creating
the
buckets
without
having
the
the
full
life
cycle.
K
F
The
class
and
inside
provide
an
alternative
to
that
which
says
you
shouldn't
look
at
the
class
anyway
you're
looking
at
the
actual
underlying
bucket,
you
should
only
be
looking
at
the
class
when
minting
the
bucket,
so
that
particular
resistance,
and
so
the
question
is
okay.
With
that
twist,
could
this
be
added
back
in.
B
Yeah,
yes
or
it
could
be
a
list
of
service
accounts
andrew
you
said
you
weren't,
you
know
it
wasn't
just
yeah
yeah,
but
to
and-
and
we
already
do,
that
we
we-
we
basically
copy
the
fields
from
the
bucket
class
into
the
bucket
resource
object.
So
we
we
instance,
we
are
doing
that
so
that
we
do
not.
So
no
part
like
the
sidecar
controller
doesn't
ever
need
to
get
a
bunker
class.
They
have
the
information
they
need.
F
Let
me
let
me
first
address
the
the
his
his
point,
because
I'm
not
sure
that
I
completely
buy
into
it.
So
I
think
you're
positing
a
situation
where,
in
the
class
I
know
a
priori
the
full
set
of
namespaces
that
are
ever
going
to
utilize
the
class,
but
the
class
is
primarily
utilized
for
greenfield
right,
yes
and
so
sure,
but
we
have
to
ask
for
greenfield:
is
it
really
likely
that
you're
going
to
be
minting
a
bucket
that
then
this
set
of
of
namespaces
is
going
to
use?
F
I
mean
if
you're
going
to
be
sharing
the
bucket,
they
all
have
to
kind
of
know
what
the
bucket
is.
So
that's
going
to
be
a
brownfield
anyway
and
you're
going
to
be
provisioning.
The
bucket
you
know
either
separately
or
independently
or
with
the
full
name
or
something,
and
so
in
that
case
I
think
what
you're
really
managing
then
is
access
on
the
bucket,
not
access
on
the
bucket
class.
B
B
Name
spaces
in
the
bucket
access
class
because
that
that's
it's
a
brownfield
use
case
right
so
this
class
here,
but
I
don't
know
if
my
screen
still
being
shared
but
the
bucket
access
class.
So
andrew
you're
right
just
a
few
revisions
ago
in
this
cap
we
had
a
list
of
additional
permitted
name
spaces
or
allowed
namespaces
in
the
bucket
class,
but
that
was
only
a
very
narrow
use
case.
That
was
that
green
to
brown
use
case
and
to
try
to
generalize
it
that
list
of
name
spaces.
B
That's
allowed
should
be
in
the
bucket
access
class
because
that's
used
for
all
brownfield,
and
so
that's
where
we
moved
it
and
then,
as
we
thought
more
about
it,
then
we
removed
it.
So
I
think,
if
we're
going
to
put
a
list
of
something
that
is
allowed,
that,
whether
it's
namespaces
or
service
accounts
that
list
ought
to
live
in
the
bucket
access
class.
D
F
Class
knows
the
bucket,
I
don't
think
it
could
right,
and
so
it
wouldn't
make
any
sense
to
put
restrictions
on
the
access
class
in
that
because
it,
the
fundamentally
those
restrictions,
are
I
mean
you
could?
If
you
you
know,
the
the
restrictions
could
absolutely
be
applied.
If
you
chose
at
the
time
that
you
create
the
bucket
access
request,
I
get
it
that
in
the
process
of
satisfying
that
binding,
you
want
to
be
able
to
check
aloudness
and
and
that
that's
a
reasonable
place.
F
K
I
I
find
it
okay,
I
mean
to
recreate
a
class
if,
if
the
meaning
of
a
class
was
as
a
share
sharing
group
right-
and
this
is
what
we're
describing
here-
it's
it's
more
of
a
you
know,
group
descriptor
in
this
case,
unless
about
or
maybe
on
top
of
the
other
properties
of
that
class,
I
don't
know
the
storage
layer
and
the
storage
tier
or
whatever
other
properties,
which
are
very
different.
That
gives.
G
Noise,
I
was
thinking
that
gives
it
the
property
of
being
traceable
over
the
lifetime
of
accesses.
If
you
want
to
change
the
scope
of
which
a
bucket
can
be
accessed,
you
have
to
create
an
update
or
a
new
bucket
access
class
and
then
reference
it
through
your
bucket
access
request.
You'll
be
able
to
see
that
over
time,
guys.
F
No,
no
market
access
classes
are
there
to
handle
the
different
kinds
of
access
minting
that
you
need
to
do
yes,
like,
oh,
I
need
to
actually
create
a
new
account
and
create
bindings
and
download
a
credential.
That's
one
kind
of
bucket
access
or
oh
I'm
going
to
rely
on
service
account
to
service
count
binding
and
all
we
need
to
do
is
add
the
role
binding
on
the
server,
and
nothing
else
needs
to
happen
because
I
already
implicitly
am
who
I
am
so
that's
the
access
david.
K
But
david
so
correct
me
if
I'm
wrong,
but
I
think
you
are
suggesting
that
the
bucket
will
refer
to
the
bucket
access
classes.
That
will,
you
know,
be
allowed
essentially
and
it
might
be
copied
from
the
bucket
class
itself.
I
mean
essentially
a
bucket
would
say
these
are
the
bucket
classes,
the
bucket
access
classes
that
I
allowed,
so
you
were
was
that
you
were
thinking.
G
Well,
if
we,
if
we
look
at
the
diagram,
currently
there's
no
references
from
the
bucket
access
class,
but
a
bucket
access
request
does
reference
the
bucket
access
class.
So
I
had
thought
and
probably
incorrectly
earlier
that
that,
because
that
information
was
being
inherited
in
when
you
created
a
bucket
access
request
that
that's
where
that
had
been
proposed
in
a
previous
revision.
F
A
Right
and
if
we
take
a
step
back
to
how
we
do
that
in
brownfield
for
traditional
storage,
we
just
don't
add
the
provisioning
piece
we're
still
providing
in
a
storage
class.
The
what,
like
you
said,
andrew
we're
just
not
necessarily
providing
the
how
and
if
we
do,
provide
the
how
it's
generally
through
a
secret.
F
A
No
and
that's
what
I'm
getting
at
like
it's,
it's
the
generalized
group
of
what
you're
getting
and
even
if
it's
pre-provisioned
storage
like
I
could
do
that
today,
within
a
storage
class
and
instead
of
the
provisioner,
I
would
just
say
no
provision,
that's
an
actual
option
and
I'm
giving
you
you
know
access
to
this
ceph
cluster,
not
volume,
xyz,
right
and
so
bucket
class.
I
assume
the
axis
we'd
still
want
to
follow
the
same
pattern.
A
G
B
And
and
to
this
point
about
specific
volumes,
I've
highlighted
the
bucket
instance
name
and
scroll
down.
This
is
a
bucket
access
request
if
my
screen's
still
being
shared-
and
you
can
see
in
there
that
there
is
a
connection
to
a
bucket
instance
and
at
the
bottom
of
the
screen,
if
that's
visible,
that
describes
that
that
that
that
that's
a
that's
all
this
is
again
a
brownfield
sharing
use
case
and
the
bucket
instance
exists.
F
B
F
C
B
So
I
mean
that's,
that's
true,
and
it's
something
we
wrestled
with
like
how
are
people
supposed
to
so,
even
if
you
howard
yeah,
how
would
you
how
do
you
know
that
name
and
going
up
to
brown
field
with
a
bucket
request?
I'm
scrolling
up
here
to
the
vr.
We
have
the
same
problem,
so
a
brown
field
bucket
request,
we've
we've
got
this
instance
name
same
thing
number
six.
How
do
you
know.
B
F
B
B
D
B
Decision
to
move
away
from
what
is
it
I
can
go
back
to
earlier
commits
and
look
at
and
and
look
at
the
bucket
access
request
and
see
and
try
to
refresh
my
memory
on
what
happened
to
that
field.
It
could
be
a
typo
or
a
mistake
or
yeah.
Just
you
know
general
confusion
trying
to
make
a
lot
of
changes
simultaneously
to
the
cap.
I
might
have
just.
D
Done
something
wrong
with
this
field:
to
elaborate
what
andrew
was
trying
to
say
if
you're,
creating
a
new
bucket-
and
you
don't
know
the
name
of
the
bucket
instance,
yet
all
you
can
do
is
refer
to
the
bucket
request
and
have
this
bucket
access
request.
You
know
point
to
that.
Bucket
request,
yes
and
now
you'd
be
able
to
utilize
that
bucket
when
it
gets
provisioned.
D
F
Yeah
good,
so
what
I
would
so
so
this
is
what
the
model
I
think
was
before
and
and
again
this
isn't.
You
know
I
thought
it
was
workable.
I'm
not
necessarily
saying
it
has
to
be
this
one
is
that
you
have
two
different
binding
problems.
You
have
a
problem
of
binding
a
bucket
request
to
a
bucket,
and
then
you
have
a
different
problem
of
binding,
a
bucket
access
request
through
which
means
at
the
end
of
this
it
means
you've
got
access
to
the
bank.
You
meaning
you,
the
application
have
gotten
access.
F
So
the
thought
was
that
that
first
one
binding
bucket
request
to
bucket
solves
a
you
know
a
couple
of
problems.
One
is
the
brownfield
versus
greenfield,
and
so
you
would
have
a
different
kind
of
mechanism.
You
would
say.
Basically
I
want
to
provision
a
new
bucket
or
you
would
say,
here's
an
existing
bucket,
but
in
your
case,
right
off
the
bat
you
could
shut
that
down
and
say
whether
or
not
that
binding
is
allowed
so-
and
you
could
do
that,
based
on
policy
statements
about
namespaces
that
are
allowed
to
access
it.
F
I
don't
know
if
buckets
are
under
service
accounts,
so
maybe
that
doesn't
work
but
but
certainly
namespaces
was
a
mechanism
for
doing
that.
So
then,
you
could
still
turn
around
create
a
bucket
access
request
that
referenced
that
bucket
request.
But
if
the
bucket
request
wasn't
bound
that
bucket
access
binding
would
also
fail
because
the
underlying
bucket
wasn't
bound,
and
so
it
creates
the
circumstance
where
you
can
always
create
both
of
those
objects.
D
So
the
main
issue
we
have
the
namespaces
was
was
the
level
of
granularity
where
we
got
that
resolved
earlier
now
today.
In
order
to
add
that
back
in
is,
is
almost
no
work.
We
would
just
have
to
have
that
feel
in
both
the
bucket
class
and
the
bucket
object
as
well.
That's
it
and
we
could
make
you
know
and
we'd,
have
everything
needed
to
do
that.
F
Right
so
to
be
clear,
putting
it
in
the
bucket
class
fundamentally
means
something
different
than
putting
it
in
the
bucket,
and
I
get
why
we
want
that.
But
putting
in
the
bucket
class
would
presumably
say:
hey
you,
mr
namespace
aren't
even
allowed
to
create
greenfield
buckets,
because
this
is
the
bucket
class
for
creating
green
field
buckets,
so
you
can
only
refer
to
bucket
classes.
F
B
It
should
andrew
it
should
you
know
it
will.
That
was
a
point
of
of
debate
and
it
it's
gone,
is
sort
of
tilted,
both
directions
and,
and
the
current
tilt
is
that
brownfield
would
not
need
a
bucket
class.
But
if
you
put
allowed
namespaces
in
the
bucket
class,
it
seems
to
me
brownfield
would
still
be
required
to
reference
a
bucket
class
so
that
we
can
do
the
check.
C
No,
no,
let's
be
clear
about
this,
so
what's
being
proposed
now
is
you
have
the
bucket
class
and
the
bucket
instance?
Both
of
them
would
have
an
allowed
namespaces
field
in
bucket
class.
It
represents
the
set
of
namespaces
that
are
allowed
to
provision,
as
well
as
the
initial
set
of
namespaces
allowed
to
access
that
provisioned
bucket
instance,
but
by
copying
that
into
the
bucket
instance,
we
allow
that
to
be
to
mutate
and
so
for
brownfield.
You
do
not
need
a
class
object.
C
K
K
B
I
didn't
even
say
good,
you
were
just
saying
said:
I
mean
so
what
you
could
start
off.
Is
you
have
a
list
of
name
spaces
in
a
bucket
class
that
can
basically
create
buckets
okay,
so
once
I
create
a
bucket,
the
bucket
instance
just
has
my
own
name
space
in
it.
It
doesn't
have
a
list
and
then
are
we
saying
you
need
to
patch
the
bucket.
B
F
Yes,
that's
right
so,
but
but
if
you,
if
you
make
the
br,
if
you
make
the
decision
on
when
the
br
is
bound
or
not
right,
that
is
an
option
to
handle
a
number
of
things
it.
It
can
handle
problems
when
provisioning
greenfield
it
can
handle
access
rights
like
hey.
You
know
you,
your
class,
you
don't
have
access
to
this
class
or,
if
alternative
to
specifying
class,
you
instead
specify
an
actual
bucket.
It
can
say
no,
you
don't
have
access
to
that
bucket,
because
your
namespace
isn't
the
namespace
that's
allowed
on
that
bucket.
F
So
the
br
is
going
to
have
some
status,
some
condition
that
says
whether
or
not
it
can
accept
access
requests
right
and
then
so
when
trying
to
satisfy
bucket
access.
The
first
thing
you
have
to
do
is
dereference
the
bucket
request
and
if
that
is
not
bound,
if
it
isn't
actually
point
to
an
underlying
bucket,
then
yeah,
the
bucket
access
request,
just
stops
right.
There
yeah
we
got
it.
Look
at.
B
F
B
B
B
D
Minutes
or
55
minutes-
oh
my
god,
so
quick
thing,
though
no
jeff
so
based
on
the
entire
discussion
we
had
today.
Yeah
we
didn't
cover
everything,
but
but
in
terms
of
what
needs
to
change
or
fundamentally
there
isn't
a
much
of
a
change
as
such
in
the
cap,
because
all
we'd
have
to
do
is
add
those
two
fields
right
and-
and
if
you
all
understand
that,
I
think
I
think
it
you
know,
assuming
there
are
no
other
concerns.
We
didn't
go
through.
B
F
Yeah,
so
let
me
tell
you
what
my
my
concern
is:
is
that
we've
had
a
little
bit
of
a
there's
kind
of
a
recurring
thing
that
happens
is
that
somebody
finds
what
they
believe
to
be
an
issue
and
it
might
be
legit
or
not.
But
what
ends
up
happening
is
a
design.
Change
goes
in
to
reflect
that,
and
so
then
the
cap
veers
off
from
what
we
kind
of
thought.
F
It
was,
and
sometimes
it's
that
that
sneaks
in
and
and
so
I
am
certainly
comfortable
if
we
say
okay,
we're
just
going
to
put
this
back
to
the
way
we
thought
it
was
yeah.
But
what
I'm
worried
about
is
in
the
process
of
putting
it
back
to
the
way
we
thought
it
was
you'll
think
that
there
are
other
issues
and
it
won't
be
exactly
the
way
it
was
it'll,
be
some
other
thing
and
that's
why
I'm
a
little
bit
concerned
with.
D
This
happened
is
because
there
was
this
whole
change
from
john
to
us.
I
don't
think
it's
going
to
happen
again.
We
are
getting
clearer
and
we'll
go.
We
can
go
through
the
cap
again
and
again
again
as
much
as
needed.
I
don't
think
that
should
be
a
concern
where
you
know
we
will
go
off
on
our
own.
Think
to
you
know
without
without
going
through
a
review
with
everyone,
the
larger
community,
it's
not
going
to
be
a
new
design
decision
and
there's
not
going
to
be
a
new
designation
in
there.
F
D
B
D
Yeah,
I
think
one
change
we
made
was
going
from
phases
to
conditions
and
the
other
one
is
this
additional
name
spaces
and
the
other
one
based
on
last
week's
discussion
was
with
supported
protocols
that
kind
of
didn't
make
any
sense
in
bucket
access
classes.
That's
about
it!
That's
the
list
of
changes.
We've
made.
B
B
Share
it,
I
think
there
was
a
comment
on
the
kepa
written
comment
about
default
bucket
class
with
a
list
of
protocols
and
that
being
confusing,
and
I
think
the
suggestion
there
was
made.
Why
not
have
a
bucket
class
just
list
one
protocol
and
if
you're,
google
and
you
support
s3
and
something
else,
then
you
have
two
bucket
classes
same
with
azure,
it's
not
a
big
imposition
and
it
makes
it
clearer.