►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 03 December 2020
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
A
So
again,
what
we're
doing
what
we
are
developing
towards
is
a
demo.
When
I
say
demo,
I
mean
that
that
will
be
building.
Co
will
be
writing
code
and
and
hitting
a
development
milestone
rather
than
a
demo
milestone.
That
is
the
code
that
we
write
will
will
not
be
prototype.
Quality
will
be
as
close
to
production
quality,
as
we
can
do
without
actually
going
to
production.
A
We'll
have
tests
in
place,
we'll
have
end-to-end
tests
in
place,
functional
tests
in
place
unit
tests,
and
when
we
show
a
feature
we
want
to
have
finished
it
thoroughly,
which
means
taking
care
of
edge
cases
and
and
just
overall
ensuring
that
quality
is
high
and
the
first
demo
is
going
to
be
a
simple
bucket
creation
and
a
bucket
provisioning
demo,
where
we
create
a
bucket
and
through
cosy
and
then
create
credentials
for
that
bucket
again
through
cosy
and
then
provide
the
bucket
information
and
the
credential
information
to
a
part
or
an
application
that
requests
it.
A
I
don't
say,
completed
I'd
rather
say
addressed
because,
as
we
discussed
more,
there
are
changes
that
are
being
brought
in
now.
During
this
week
we
focused
more
or
less
on
integration
efforts,
and
I
would
like
shrini
who's
been
working
on
a
part
of
the
integration
and
also,
if
tejas
is
on
the
call.
I
would
like
him
also
to
give
some
give
an
update
on
what
they've
been
working
on
so
srini.
B
For
now
I,
for
the
last
couple
of
weeks,
I've
been
working
on
getting
the
ci
up
and
running
and
then
some
unit
testing
for
the
bucket
request
and
bucket
access
request.
Basically,
mostly
on
the
create
calls.
I
will
I'm
ready
to
push
couple
of
pr's
in
that
area,
so
trying
to
move
as
much
of
code
as
possible
into
the
official
repo.
A
Yeah
for
those
of
you
who
knew
here,
I
noticed
a
few
new
names.
We've
been,
you
know.
Until
the
repositories
for
cosy
were
created
in
the
kubernetes
sigs
org,
we
created
a
you
know
an
org
ourselves
on
github,
just
to
start
writing
code
and
start
collaborating
right
now,
we're
in
the
process
of
moving
bits
and
pieces
of
that
code
into
the
official
repo,
so
srini
one
thing
is:
we
have
nicholas
here
who
is
interested
in
contributing.
A
You
know,
please
tag
him
or
please
tag
them
in
the
in
the
pr
as
well.
That
way
they
you
know
they
can
see
what
progress
is
being
made.
B
Absolutely
yeah:
we
we
definitely
need
reviews
on
the
pr's
that
are
coming
in
into
the
official
reverse,
so
that
would
be
awesome.
Awesome.
A
And
tedious,
are
you
here
yeah,
I'm
here.
C
A
C
Yeah
good
yeah,
I
I've
been
working
on
customized
template
to
set
up
cozy.
I
have
a
pr
open
there.
There's
some
feedback
from
you
said
on
that,
and
I'm
waiting
for
a
review
from
a
couple
other
folks
on
it
as
well.
D
A
All
right
sounds
good
and
sajin.
You've
been
working
on
the
sample,
provisional,
correct.
D
A
Okay
and
is,
is
christian
on
the
call.
A
Hey
chris,
did
you
get
a
chance
to
look
into
the
csi
driver.
E
Yeah,
just
yeah
yeah,
just
working
on
starting
to
move
stuff
over
I'll
have
some
prs
open
soon.
A
Okay
sounds
good,
so,
like
I
was
saying
earlier,
most
of
the
work
has
been
around
integration,
so
we've
got
customized
work
being
done,
we've
got
ci
setup,
the
pro
jobs
and
end-to-end
tests
being
worked
on,
and
and
we're
going
to
continue
this
until
we
have
the
boiler
plate
in
place.
A
That
is
stuff
like
the
ci,
the
set
of
tests
for
what
you
already
have
in
place,
so
that
so
we
can
speed
up
development
once
you
know
that
that
that
is
in
place
all
right
now,
I'm
going
to
get
going
to
the
next
part
of
the
meeting
which
is
discussing
what
was
what
we
were
discussing
last
week
before
I
get
started
so
so
nicholas.
A
A
I
think
that'll
be
an
easy
way
to
get
started
all
right
so
getting
into
this
so
so
andrew.
I
know
you
haven't
been
here
for
a
few.
You
know
a
few
weeks
so
I'll
give
you
a
quick
update
and
for
whoever
else
hasn't
been
here
for
the
last
few
weeks.
I'll
give
a
quick
update
on
the
on
the
last
conversation.
That's
been
going
on
for
the
last
few
weeks.
A
So
one
of
the
concerns
that
we
brought
up
a
few
weeks
ago
was
the
way
the
protocol
field
is
structured
inside
a
bucket
class
in
a
bucket
is
such
that
we
have
protocols
hard
coded
in
it.
So,
for
instance,
we
have
in
this
case
I'm
just
showing
the
name
and
version,
but
if
I
were
to
pull
up
the
cap,
which
I'll
do
right
now,
kubernetes
enhancements.
A
A
So
we
have
the
protocol
field
defined
like
this.
We
have
the
name
which
is
the
name
of
the
protocol
like
s3
or
gs
or
azure.
A
We
have
the
version
of
the
protocol,
so
this
would
be
in
case
of
s3.
The
version
looks
like
what
I
have
here.
So
you
know
each
each
protocol
follows
their
own
versioning
standard
and
then
we
have
the
individual
protocol
types,
so
we
have
a
substructure
for
s3
for
google
and
azure.
Now
the
the
first
question
you
might
ask
is,
you
know
we
have
a
predefined
set
of
protocols.
A
If,
within
a
protocol
we
might,
we
might
end
up
adding
new
fields,
new
features?
So
that's
where
the
discussion
has
been
for
the
last
few
weeks?
What
is
the
process
going
to
look
like
for
someone
who
wants
to
add
new
protocols
and
what
is
the
process
going
to
look
like
for
someone
who
wants
to
add
fields
into
a
particular
protocol
and
the
reason
this
is
an
important
question?
Is
because
we
have
multiple
vendors
that
support
single
protocols,
especially
s3.
A
There
are
a
lot
of
object,
storage,
vendors
that
support
s3,
and
we
need
to
have
a
clear
governance
model
such
that
such
that
you
know
we
we're
fair
and
just
and
and
and
clear
with
everyone
that
wants
to
contribute
for
their
particular
protocol.
A
So
the
first
question
that
we
were
dealing
with
was:
how
do
we?
How
do
we
allow
new
protocols
to
to
become
a
part
of
cozy
again?
The
reason
this
is
important.
A
The
new
protocol
is
important
is
because,
if
we
don't
address
this
now,
the
process
for
a
particular
provider
to
add
themselves
would
be
a
year
or
a
year
and
a
half
long
process
where
they'd
have
to
first
petition,
get
the
fields
into
protocol
and
then
go
through
the
api
review
and
then
wait
three
versions
of
kubernetes
for
it
to
become
stable,
so
yeah
go
ahead.
Yeah.
F
Yeah,
if
I
can
interrupt
you
here,
I
so
obviously
I
understand
the
concern
on
this
side.
Let
me
let
me
push
back
on
the
other
side
a
little
bit,
because
you
know
part
of
the
whole
reason
we're
doing
this
is
portability
right
is
to
basically
say
look.
I
can
write
to
an
s3
and
then
my
application
doesn't
in
any
way
have
to
change
whether
I'm
running
on
aws
or
whether
I'm
running
on
prem
and
I've
got
a
an
enterprise
object.
F
Storage
that
has
an
s3
interface
to
it
and
what
I
get
concerned
about
when
we
start
talking
about
adding
protocols
or
adding
additional
fields
is
breaking
that
contract
and
instead
it
becomes
more
of
a
hey.
I've
got
10
different
implementations
of
s3.
Each
of
them
have
a
slightly
different
set
of
parameters
or
something-
and
it
gets
to
the
point
where,
particularly
since
the
stuff
we're
talking
about
here
is
the
interface
with
the
application.
F
It's
not
it's,
not
the
interface
with
the
provision,
because
the
interface
with
the
provisioner
already
has
an
open,
flexible
thing
right.
What
you're
suggesting
is
that,
if
I
as
an
application,
am
writing
to
a
brand
new
object
storage,
then
then,
yes,
there
is
an
integration
to
get
that
brand
new
object.
Storage
protocol
into
here
we
can.
We
can
argue
about
how
onerous
that
should
be.
F
A
We're
on
the
same
page
with
that
I
mean
a
more
a
more
tangible
way.
Also
would
be
to
explain
that
would
be.
This
protocol
structure
is
what
is
going
in
inside
a
pod.
A
F
I
think
that's
a
fair
question:
let's
pause
it
that
maybe
at
some
point
in
the
future
we
have
a
vendor
neutral
object
protocol
that
we
we
decide
as
cncf
or
somebody
that
that
we
want
to
have
something
that
might
be
based
off
of
s3
or
something,
but
not
under
amazon
control
under
under
standard
control,
swift,
yeah,
whatever
it
might
be,
yeah
yeah.
I.
F
A
position
on
it
at
this
point
but
sure
in
that
case
there
would
be
a
strong
argument
for
adding
that
protocol
into
here
and
and
so
the
the
the
question
then
is
okay.
What
would
that
take?
Obviously
we'd
want
it
to
be
backward
compatible,
so
you
wouldn't
want
to
have
to
break
support
for
existing
protocols
to
add
a
new
one,
but
the
existing
mechanism
certainly
supports
that.
F
So
I
mean
you're
right
now
in
the
code.
That's
dealing
with
that.
Is
it
your
sense
that
that
is
going
to
be
a
terribly
onerous
thing
to
add
a
brand
new
product.
A
G
G
F
Right
but
but
I
guess
what
I'm
saying
is
you
don't
create
a
new
protocol
without
having
clients
that
are
already
writing
to
that
protocol
without
having
a
well
understood,
set
of
bootstrap
information,
you
need
endpoint,
information
or
or
whatever.
So
at
that
point
all
of
that
stuff
you
have
a
depending
on
how
new
the
protocol
is.
You
might
have
a
little
back
and
forth
on
what
is
the
actual
set
of
parameters
you
need,
but
it
strikes
me
at
the
end
of
the
day:
it's
pretty
straightforward
at
that
point,
you
just
say
boom.
F
Add
it
add
these
fields,
you
know,
have
a
new
thing.
You
learn
how
to
pass
through
and
that's
kind
of
it.
So
I
guess
I'm
not
really
sure
I
understand
from
what
the
argument
is.
What
what's
the
problem
with
this?
I
don't.
G
But
let
me
let
me
just
make
it
more
difficult
to
discuss.
Let's
say
that
the
new
protocol
has
its
own.
You
know
networking
high
performance
networking
to
set
up
for
for
the
pod
to
connect
right,
whether
it's
you
know
either
user
space
or
whatever
it
doesn't
matter
really
better,
but
imagine
that
a
protocol
really
comes
with
some
stack
under
it
and
not
just
you
know,
restful
http,
which
might
be
very
simple
right,
because
that's
how
all
these
protocols
today
are
built
right.
G
A
G
F
G
G
Anyway,
I
I
think
I
made
just
the
small
point.
I
mean
just
saying
that
the
protocol
might
be
different
than
what
we're
using
now
and
we
might
require
more
from
cozy
in
order
to
you
know
to
to
inject
it
into
a
pod
right.
F
I
completely,
I
completely
agree
that
that
is
a
possibility,
and
so
what
I
will
say
is
that
this
design
does
not
accommodate
that
and
so
to
accommodate
something
fundamental
like
a
completely
different
network,
or
you
know,
and
where
you
might
have
to
do
work
that
is
really
outside
of
what
these
components
are
doing
today.
H
F
I
I
think
it's
a
fair
question
and
what
what
I
would
say
is,
I
think,
at
this
point,
there's
kind
of
a
lot
of
experience
with
the
sort
of
block
and
file
and
the
tension
of
going
off
into
very
specific
stuff
versus
portable
stuff
and
so
yeah.
I
don't
have
the
answer
to
your
question,
but
what
I
would
say
is
I
I
just
have
a
gut
feeling
that
we've
probably
got
some
collective
wisdom
about
that
already
like.
Maybe
there
is
a
way
to
yeah.
F
The
problem
is
just
that
without
making
you
know
without
pulling
protocol
handling
completely
out
of
cozy,
I'm
not
sure
how
you
do
that
right,
like
I
want
to
try
something
brand
new,
I
mean
what
I
could
do
is
just
take
my
own
cozy
code,
maybe
and
provide
my
own
controllers
and
stuff
like
that.
But
but
in
terms
of
I
want
to
offer
a
prototype
of
my
brand
new
thing
that
isn't
supported.
Yet
by
cozy
we
could
have
a
generic
protocol.
A
Just
the
thought
out
there
I'm
not
advocating
for
it,
but
that
would
help
you.
You
know
incubate
and
and
try
out
cozy
without
having
to
adhere
to
any
of
these
azure
gcs
yeah.
F
What
I
do,
where
is
any
time
I've
seen
one
of
those
kinds
of
things
it
turns
into
a
vehicle
for
people
to
do
non-compliant
and
around
the
the
portability
right
I
mean
everything.
Yeah.
I
So
so
the
the
the
proposal
I
made
to
solve
this
problem
is:
if
I
want
to
develop
an
entirely
new
product
and
prototype
it
in
cozy.
What
you
do
is
you
implement
your
proprietary
protocol
and
s3
at
the
same
time,
and
then
you
implement
the
s3
part
in
cozy,
so
you
can
use
the
lifecycle
management
et
cetera,
et
cetera,
but
the
actual
pods
connect
with
a
different
protocol
that
you
just
happen
to
know
works
because
it's
your
prototype
right.
I
F
I
J
What's
the
advantage
of
keeping
that
thing,
if
it's
you
already
have
this
s3
compatible,
why
do
you
still
need
this
other
fancy
particle?
What's
the
advantage,
because.
I
A
The
main
reason
is,
you
know
we
most
most
most
vendors
want
to
pull
data
out
of
amazon
and
the
easiest
way
to
allow
workloads
to
move
between
clouds
is
for
the
new
cloud
or
the
new.
You
know
infrastructure
to
to
support
the
sd
protocols.
Applications
need
not
change
at
all.
I
mean
coming
from
min
io.
This
is
kind
of
how
we
bring
customers.
A
Where
the
you
know,
the
expenses
in
amazon
becomes
very
expensive
and
they
want
to
move
and
mineo
supports
s3
natively,
so
they
don't
have
to
change
the
applications
at
all.
They
just
have
to
move
their
data
and
and
they're
good
to
go.
K
K
K
F
I
I
that
that
that
has
always
been
my
concern
about
about
s3
being
an
amazon
or
standard,
because
they
can
advance
that
along
the
way
and
leave
all
the
compatible
quote
in
the
dust
we
want
to
a
little
bit,
though
bifurcate
between
cozy
and
this
question
of
s3
compatibility,
because
I
I
am
interested
in
once
we
get
cozy
down
talking
about
the
the
you
know,
a
standard
that
we
could
as
a
community
control
for
this
yeah.
I
only.
I
I
only
threw
out
s3
as
as
like.
If
you
want
to
develop
a
prototype,
cozy
driver,
you
don't
need
to
have
some
generic
protocol
type,
because
everyone
can
just
do
s3
and
it's
a
way
to
sort
of
get
your
foot
in
the
door
and
get
started
and
then
work
on
your
the
real
protocol.
You
want
to
support
in
parallel.
A
L
E
L
Of
cozy
as
a
prototype
and
when
you're
ready
to
go
further
beyond
a
prototype.
E
L
I
F
Right
makes
sense
yeah.
I
I
would
also,
though,
like
to
point
out
that,
where
we
draw
the
line
here
is
an
interesting
one.
We
are
intentionally
making
it
easy
for
different
implementations
to
come
in
and
integrate
in
a
csi
type
way.
But
that's
not
what
we're
talking
about
here
here,
we're
talking
about
the
equivalent
of
posix
file,
semantics
or
versus,
say
nt
file,
semantics,
or
something
like
that.
I
mean
it's
a
pretty
fundamental
difference.
It's.
G
F
F
G
Mode
right,
yeah,
yeah,
yeah,
yeah
and
the
and
the
one
that
you
noted
about
like
posix
things,
and
maybe
that's
flavors,
and
you
know
more
of
about
capabilities
of
file
protocols
right,
which
is
something.
Maybe
we
also
somehow
need
to
import
from
csi.
A
G
I
Object
protocols
are
analogous
to
volume
modes
in
that
there
is
a
small
fixed
number
of
them.
That
would
only
change.
You
know
under
very
significant
circumstances
and.
G
Locking
there's
there's
you
know
whatever,
like
file
system,
has
added
a
lot
of
optional
features
as
well.
K
G
So
how
does
csi
handle
that
differences
and
capabilities
of
the
volume
is
that
only.
I
Between
volume
modes,
so
so
you
can
get
a
block
volume,
you
can
get
a
file
system
volume
and
what
that
means
is
fairly
nebulous.
But
it's
kind
of
well
understood
that
you
know
block
volumes.
Have
you
can
read
and
write
blocks
to
them?
Maybe
you
can
do
scuzzy
iactals?
Maybe
you
can't,
but
you
know
the
basic
read.
Write.
Block
stuff
is
expected
to
work
everywhere
same
with
files.
You
know
you
can
create
and
delete
and
read
and
write
files,
but
like
whether
you
can
do
locking
or
whether
you
can
do
some
other
things.
G
So
you
can't
specify,
as
a
workload,
more
more
fine-grained
capabilities
of
a
block
volume
or
a
file
system
volume.
I.
I
The
way
you
would
do
it
would
be
out
of
band
the
administrator
you'd
go
to
your
minister
and
say
I
need
I
need
volumes
to
support
file,
locking
and
you'd
be
like
okay.
My
regular
storage
class
can't
do
that,
but
I'm
going
to
give
you
another
storage
class
that
I
promise
you
can
do
that
and
as
long
as
you
use
that
storage
class
you'll
be
fine
and
then,
with
that
out-of-band
agreement
between
you
and
the
administrator,
you
can
be
ensured
that
your
workload
will
always
get
volumes
that
support
lock-in.
But.
G
F
F
Okay,
so
once
we
get
this
cozy
here
right,
this
provides
immediate
value,
but
it
does
not
solve
truly
a
portable
object.
F
Right
I
mean
it
still
has
a
kind
of
a
an
implicit
contract
that
isn't
explicit
between
the
workload
and
the
underlying
storage
and,
for
example,
the
workload
tickles
some
brand
new
feature
of
s3
that
all
of
the
non-s3,
but
compliant
vendors,
don't
yet
support.
F
Then
that
doesn't
work
so
the
way
to
avoid
that
is
to
have
a
standard
protocol
that
is
evolved
alongside
this.
That
has
formal
compliance
and
everything
else
against
it,
and
you
know,
then
that
could
be
added
as
another
protocol
here
and
then
that
gives
you
a
much
stronger
portability
guarantee
at
the
application
layer,
but
I
just
didn't
want
to
conflate
that
activity
with
this,
because
I
see
this
control
plane
stuff
as
a
prerequisite
to
getting
data
plane
portability.
F
K
K
F
Yeah,
I'm
I'm
going
to
be
a
little,
maybe
heretical
here
and
suggest
that
you
you're
not
going
to
be
able
to
push
users
away
from
what
they're
probably
doing
and
that
what
you're,
probably
going
to
have
to
do
as
a
standard
is
in
fact
take
a
subset
of
s3.
F
That's
sufficiently
large
a
subset
that
it'll
match
a
large
num
percentage
of
the
applications
that
are
currently
out
there,
so
that
a
bunch
of
applications
can
just
switch
to
saying
they
depend
on
that,
and
then
they
have
a
more
stable
platform
against
changing
to
a
completely
different
object
protocol.
That
isn't
I
mean
I
think
that
is
also
of
value,
but
I
don't
know
what
the
actual
usage
of
those
protocols
is,
but
once
they
get
to
any
particular
level
of
usage,
then
I
absolutely
think
we
should
include
them.
I
A
Right,
great,
okay,
yeah:
how
do
we?
How
do
we
go
about
doing
this?
Do
we
do
we
first
release
what
we've
got
with
this
s3
and
then
how
do
we
go
about
standardizing
that
subset.
F
Yes,
I
that
is
my
proposal
is
that
we
move
forward
on
this,
because
this
this
framework
works,
whether
that
that
second
standard
protocol
exists
or
not
right,
and
it
provides
value
immediately,
especially
if
people
don't
depend
on
things
in
their
applications
that
differ
from
vendor
to
vendor
right
and
then
we
also
have
a
couple
of
protocols
here
that
have
sizable
usage
that
are
single
vendor,
so
so
that
this
has
value
right
off.
The
bat
can
be
baking.
F
It
can
be
a
completely
separate
effort
and
it
might
involve
different
people
and
and
likely
involves
some
corporate
level
activity
as
well,
because
you're
going
to
have
to
get
sign
up
to
things
like
that,
but
I
I
just
think
we
should
do
this
serially.
We
should
do
this
and
then
also
think
about
the
the
s3
standard
later.
That's
all
because
if
we
inspect,
we
could
totally
sidetrack
ourselves
off
and
argue
about
that
and
not
get
this
done.
A
Right
right,
yeah,
okay,
all
right,
I
think
I
think
we
have
a
good
path
ahead
with
this.
Does
anyone
have
any
questions,
so
I
someone
mentioned
swift
and
another
protocol
that
I
have
not
heard
of
from
from
what
I
understand
so
swift
is
currently
supported
by
sef,
but
sef
moved
forward
from
swift
and
moved
on
to
supporting
s3.
It
has
an
s3
gateway
which
came
after
support,
and
I
am
quite
sure,
on
this.
A
Openstack
deployments
are
definitely
being
out
completed
right
now
by
kubernetes.
In
terms
of
you
know,
growth
in
terms
of
new
deployments
and
I
think
ibm
has
it.
Oh.
K
A
From
what
I
understand
again,
I
might
be
wrong
about
this,
but
swift
is
a
part
of
openstack
right,
like
maybe
not
anymore,
but
isn't
that
how
it
came
about.
K
F
A
No,
I'm
even
constantly
I'm
questioning
if
that's
even
needed
or
not
swift
used
to
be
quite
popular
and-
and
I
don't
know
what
the
case
is
anymore.
So
that's
why
I'm
asking
so
I
I
think.
F
F
But
but
you
know
to
say
hey
you
know
once
you
have
a
certain
number
of
clients
and
you
want
to
propose
that
your
protocol
be
included,
then
you
know,
then
it's
worth
doing
that
right
as
opposed
to,
and
so
you
know
your
argument
that
well
maybe
swift
isn't
really
used
anymore.
F
We
should
just
get
some
kind
of
industry
information
on
that
and
then
set
kind
of
a
line
and
say
anything.
That's
above
that
line
is
a
candidate
all
right.
Let's
set
that
line,
then.
F
Yeah,
I'm
just
without
seeing
the
data
it's
going
to
be
difficult
to
draw
the
line
right,
because
what
what
I'm
going
to
guess
is
there's
a
clump
there's
well,
there's
s3,
which
is
going
to
be
a
huge
spike
and
then
there's
going
to
be
a
clump
behind
s3
and
then
there's
going
to
be
a
long
tail
and
so
seeing
the
data
we
can
figure
out
where
the
line
should
be
between
the
long
tail
and
the
clump.
That's
all.
A
That
makes
sense-
I
I
believe,
last
week
or
on
monday,
when
we
were
trying
to
figure
out
along,
I
mean
we
were
trying
to
find
out.
How
would
we
even
go
about
drawing
the
line?
I
mean
at
a
high
level?
What
you're
saying
makes
sense,
but
a
question
that
comes
up
is
again:
should
we
even
okay?
So
there
are
two
ways
we
can
approach
this.
A
We
can
consider
swift
as
a
brand
new
protocol
or
a
proposal
for
a
brand
new
protocol
understand
how
we,
you
know,
make
the
decision,
like
what
kind
of
information
that
we
use
and
just
get
a
sense
for
how
we
can
add
it
and
then
maybe,
based
on
that
we
can
start
drawing
that
line
for
for
other
new
protocols.
F
Right,
I
was
thinking
literally
some
numbers
on
market
share
or,
or
you
know,
number
of
applications
or
something
like
that.
I
did
a
quick
check
and
I
can't
find
anything
obvious,
but
I'm
sure
that
that
that
there
are
a
number
of
those
analysis,
organizations
that
have
gathered
this
information.
K
A
Don't
use
that
yeah?
Definitely
not.
I
agree.
I
don't
think
market
share
itself
is
a
good
enough
representation
to
be
honest
because
something
could
be
on
the
rise.
Something
could
be
you
know
just
early
on,
but
but
you
know
it
might
be
very
clear
that
it's
growing.
F
G
How
about
just
looking
also
on
available
open
source?
So
if
you
have
images
which
are
open
source
that
that
are
clients
of
of
of
the
protocol
right,
it
kind
of
give,
so
it
they,
they
might
get
stale
and
die
at
some
point,
but
they're
also
like
their
existence,
just
means
something
maybe
pools
of
these.
I
don't
know
but
yeah
you're,
just
talking
about
community
around.
G
I
mean,
maybe
we
just
need
to
collect
like
like
manually,
collect
by.
You,
know,
people
looking
up
what
what
kind
of
applications
used
swift
and
then
look
look
up
their
pulls.
Let
me
let
me
ask.
A
This
to
maybe
sad
sad,
I
know
there
are
a
lot
of
vendors
in
csi
and
I
know
some
of
them.
Some
of
them
even
entered
a
business.
How
did
you,
how
did
you
go
about
deciding
if
a
new
vendor
could
could
add
themselves
as
an
api
into
you
know,
kubernetes.
L
Yeah
for
the
entry
we
didn't
really
have
a
bar.
We
said
anybody
who
wanted
to
come
in
could
join
because
effectively
it
was.
We
were
trying
to
do
what
csi
did,
which
was
be
interoperable
with
as
many
different
third-party
block
and
file
storage
systems
as
possible,
and
so
there
was
no
bar
and
we
did
end
up
with.
You
know
a
set
of
abandoned
entry
plug-ins
which
we're
having
to
deal
with
now.
L
We
don't
have
to
be
as
permissive
and
we
can
be
a
little
bit
more
strict,
and
I
like
this
idea
of
kind
of
having
a
bar
that
you
have
to
meet
before
we
add
a
new
data
path.
It
has
to
have
a
certain
amount
of
kind
of
usage
before
before
it
before.
We
consider
adding
it,
because
there
is
overhead
in
maintaining
it.
A
Now
we
could
even
say
it's
going
to
be
decided
on
a
case-by-case
basis
by
a
committee
I
mean
us
everyone
here.
I
think
that's
fair
to.
A
Because,
right
now
I
I
I
don't
know
if
there's
a
single
measure
or
a
set
of
measures
that
that
would
be.
That
would
be.
You
know
good
enough
for
figuring
this
out.
F
Right
so
I
think
that's
heuristic
right,
so
the
heuristic
is
obviously
based
on
amount
of
usage,
but
heuristic
doesn't
have
to
be
the
sole
arbiter.
You
could
also
overweight
something
by
saying
look.
This
is
an
open
standard
as
opposed
to
a
vendor,
lock
standard,
hey.
This
has
open
source
clients
against
it.
Hey
there
are
network
effects,
it's
maybe
it's
got
other
hooks
into
kubernetes.
F
A
Use
so
so
here's
the
thing
you
know,
let's
say
let's
say
a
new
standard
comes
up
and
we
let
it
in
that
could
be
the
you
know
we
would
be
providing
the
platform
for
it
to.
You
know,
get
the
high
market
share
now.
A
What
I'm
trying
to
say
is:
maybe
they
didn't
already
have
it,
but
by
becoming
a
part
of
cozy
they
finally
got
the
you
know.
Finally,
get
the
visibility
and
reach
to
to
succeed
in
the
industry.
A
No
you'd
be
surprised,
like
with
the
cloud
provider
stuff.
There
were
a
lot
of
cloud
producers
that
wanted
to
add
themselves
into
into
into
kubernetes,
and
they
were
all
small
hosting
providers.
They're
trying
to
become
legit
by
you
know
becoming
a
part
of
kubernetes.
So.
F
Right
but
I
guess
I
would
just
point
out
that
cozy
doesn't
exist
yet
so
the
fact
that
people
aren't
aren't
being
aren't
using
those
providers,
it
isn't
isn't
because
of
lack
of
support
and
cozy.
K
If
I
may,
one
thing
you
could
consider,
although
it
comes
with
its
own
complications,
is
what
the
sender
project
does
before
did
with
an
openstack,
where
every
vendor
needs
to
actually
commit
and
not
commit
as
in
code,
but
commit
to
support
its
plugin
and
have
ci
available
ci
reporting,
backup
stream
and
whatnot
such
that
you,
you
rule
out
vendors,
who
are
only
in
it
to
to
get
their
names
somewhere
in
the
kubernetes
code
base
and
move
on.
F
Yeah,
I
would
just
point
out
that
this
is
the
whole
point
about
cozy
and
even
csi
is
to
vendor
stuff,
isn't
really
in
cozy
right.
We
have
a
couple
of
protocols,
but
the
actual
drivers
themselves
are
intentionally
outside
the
code
base
and
separately
distributed
by
vendors,
so
that
that
process
should
already
unlock
that.
So
getting
a
protocol
head
in
here
might
be
a
vendor
thing,
but
I,
I
suspect,
it's
far
more
likely
that
it
would
be
an
open
standard
thing
than
a
vendor
thing.
Moving
forward.
A
G
Okay,
I
have
a
question
yeah,
maybe
it's
maybe
it's.
Maybe
we
really
don't
need
it,
but
I
wanted
to
raise
it
just
because
so
now
we're
saying
that
adding
protocol
is
not
something
we
desire
right.
We
want
less
protocols
eventually,
but
to
begin
with,
do
we
so?
Are
we
saying
that
these
are
the
only
options
for
object,
because
there's
also
an
option
just
to
use
http
to
get
access
to
object
stores?
So
my
question
is:
do
we
want
to
provide
like
a
very
bare
minimum?
A
G
G
Mean
this
is
a
an
extension
of
you
mean
the
sage
s3
and
then
specify
that
it's
not
really
s3.
I
mean.
A
This
would
this
would
work
technically,
but
then
in
practice
and
I've
seen
this
too
we'll
end
up
using
this
to
you
know
we
lose
the
portability
that
that
we've
been
working
towards
all
along
because
because
people
start
using
this
in
in
ways
to
escape
the
standard
and
in
the
long
run
you
have
too
many
different
implementations
that
use
generic
and
and
lose
out
on
the
on
the
standardization
that
we
provide.
This
is
still
possible.
It's
just
should
we
do
it.
F
Yeah
yeah,
I
I
guess
I
was
going
to
say
two
things.
One
is
exactly
that
point
which
is
now
saying
that
you
rely
on
generic
doesn't
actually
mean
that
a
particular
driver
will
satisfy
that,
because
you've
got
no
idea.
You
know
whether
it
would
satisfy
or
not
so
you
kill
portability.
But
the
second
thing
I
would
say
is
I
just
don't
think
in
general:
it's
a
good
idea
to
try
to
build
abstractions
in
a
vacuum.
F
If
you've
got
a
specific
protocol
that
you're
trying
to
support,
we
should
consider
that
protocol
and-
and
maybe
there
is
a
generic
http
object
protocol.
Well,
we
should
look
at
that
specifically.
G
But
I
would
look
at
like
think
about
just
a
web,
any
kind
of
web
interface
web
access,
meaning
I
curl
something-
or
I
that's
that's
kind
of
the
the
thought
process
behind
it-
that
if
I
want
to
provision.
G
Sorry,
just
that,
if
I
want
to
provision
something
a
bucket
which
is
simpler
from
that
point
of
the
access
point
of
view,
and
I'm
not
really
going
to
all
of
these
things
and
for
files
this
you
know
if
I,
if
I
get
access
to
files
and
then
I
can
use
all
of
my
tools
just
the
same,
but
for
for
buckets,
how
do
I
so
I
have
to
go
to
the
that?
I'm
I
mean
I
I
wouldn't
go
in
as
far
as
generic.
G
G
I
was
thinking,
like
you
know,
think
about
it
from
point
of
view
of
entry
point
kind
of
protocol,
maybe
maybe.
A
I
see
I
see
another
thing
is
you
know
we're
not
we're
not
necessarily
trying
to
reduce
the
list
of
protocols
as
much
as
trying
to
standardize
this
interface
for
applications
for
consuming
object,
storage
and
yeah
by
keeping
that
standard
well
defined
and-
and
you
know
adding
to
that
standard-
you
know
in
a
very
structured
process-
ensures
that
that
we
can
maintain
that
standard.
We're
really
not
against
adding
new
protocols
per
se.
G
F
That's
kind
of
sure,
but
it's
pluggable,
but
it's
adhering
to
an
interface.
It's
it's
doing,
create
bucket.
It's
doing
you
know
I
mean
we
have
a
if
you
just
look
at
the
cozy
api
and
you
ask
how
much
of
that
is
applicable
to
this
bare
bones
situation
in
a
way
that
is
predictable
and
portable.
G
Why
not
the
data
the
data
plane
doesn't
really
say
much
about
like
how
much
I
want
to
control
the
life
cycle
of
my
you
know
my
buckets
and
my
so
the
access
might
look
a
bit
different,
but
I
was
suggesting
basic
auth.
I
don't
know.
Maybe
that's
standard
enough,
but
maybe
not.
F
Yeah,
but
I
mean
I'm
not
sure
I
I
think
we
have
to
support
download
credentials
because
that's
the
current
state
of
the
art,
but
I
I
think
we're
kind
of
moving
away
from
that
in
general.
Anyway,
it's
just
not
a
very
secure,
it
doesn't
support
rotation
and
there's
a
bunch
of
issues,
but
I
mean
at
the
end
of
the
day
you
have
a
secret
that
you
mount
in
your
pod
and
then
it
goes
and
talks
to
right
I
mean
that's
really
kind
of
all
you're
talking
about
is
replacing
right
is
replacing.
A
F
A
G
G
Application
usage,
of
course,
is
like
the
cloud
applications
and
all
that,
but
you
know
there's
there's
a
bunch
of
ways
where
you
can
experiment
with
with
you
know
the
entire
life
cycle
things
and
with,
like
maybe
a
bare
bones:
data
access
as
well
yeah
yeah,
maybe
it's
just
the
data
sets
that
are
public
in
some
ways
and
you're,
just
you
know,
refer
like
referring
to
them
or
something
right,
not
public
public.
But
you
know.
A
I
mean
I
mean
urls,
people
can
technically
do
it,
so
they
could
just
set
it
to
say.
S3,
provide
dummy
fields
and
whatever
special
fields
that
they
want
to
provide
can
be
passing
through
parameters
which
sure.
G
True
yeah,
I
mean
the
the
only
question
was
if,
if
it
sounds
like
that,
you
know
the
the
kind
of
a
script
you
know
a
shell
script
and
a
curl
application
or
a
job
right,
if
that's
also
a
use
case
that
we
just
want
to
be
able
to
supply
as
a
basic
kind
of
access
protocol.
G
F
Yeah,
so
I
guess
I
think
I
understand
now,
because
that
that
does
at
least
check
one
of
my
boxes,
which
is
you
can
now
articulate
a
very
explicit
thing,
which
is
I'm
curling
against
an
existing
public
data
set,
there's
no
buckets
there.
It's
just.
I
need
an
endpoint
then,
and
it's
a
single
endpoint
and
I
need
credentials.
What
I
would
question
is:
are
there
enough
applications
written
to
that
to
justify
building
into
cozy?
At
this
point
right
I
mean
it's
a
it
it.
F
There
are
risks
to
building
it
in
because
then
it
becomes
this
vehicle
for
for
corruption
of
the
overall
system.
There
are
there's
effort
to
bring
it
in.
I
Andrew
you're
describing
a
brownfield
case
which
is
actually
where
cozy
is
weakest
right
like
because,
because
you
can
already
address
those
brownfield
cases
outside
of
cozy
by
just
pointing
your
pod
at
the
at
the
bucket
and
doing
what
you
want
to
do
with
it,
that
the
value
of
cozy
is
the
green
field
case,
where
you
have
some
process
for
bucket
life
cycle,
automation
and
that
doesn't
fit
this
case
that
we're
talking
about
here,
where
you're,
creating
buckets
and
deleting
buckets.
And
you
know
in
an
automated
way
and
using
them.
Yeah.
F
Right,
I
get,
I
guess
I
I
guess
the
the
brownfield
case
is
so
I
guess
it
comes
down
to
the
what
is
it
you're
provisioning
in
the
brownfield
case,
where
we
have
a
clear
understanding
of
a
bucket,
there
is
a
namespace.
There
are
objects
within
that
namespace.
We
have
a
an
assumption
of
the
overall
model
and
then
there's
access
to
get
it
then,
and
yes,
the
bucket
may
already
exist
and
the
objects
may
already
exist
or
not,
and
you've
got
a
data
protocol
to
deal
with
that.
F
I
I
A
Okay,
so
we're
out
of
time.
I
think
I
think
we
can
we.
We
have
a
conclusion
on
on
this
particular
discussion.
I'll
have
to
well
on
the
monday
meeting
it's
going
to
be
more
about
development.
A
We
will
continue
talking
about
where
we
are
in
terms
of
development,
and
one
last
ask
I
have
is
to
everyone
here
it
would.
You
know
we're
trying
to
we're
trying
to
get.
A
You
know
as
much
as
possible
towards
the
demo
done
before
the
end
of
the
year,
and
if
all
of
you
could
help
us,
you
know
accelerate
that
by
code
reviews
or
participating
in
in
writing
code
contributing
it.
It
is
welcome
and
very
highly
appreciated,
so
so
yeah
as
as
we
make
new
pull
requests
I'll,
make
sure
they're
posted
in
the
sixth
storage
cosy
channel.
Please
take
some
time
to
review
them.
Leave
your
feedback
so
that
we
can
move
fast.
J
I
said
some
time
ago
you
guys
were
discussing
whether
to
reduce
the
frequency
of
this
meeting,
because
there
are
like
weekly
standups
and
then
I
think
at
that
time.
I'm
saying
oh
wait
until
the
cap
is
merged
and
then.
J
A
Think
there
are
still
things
to
talk
about
and,
as
we
flush
things
out,
you
know
we
will
we
we
will
figure.
I
think
I
think
once
the
api
is
you
know.
So
this
is
what
happened
with
the
cloud
provider
thing.
We
did
start
thinking
that
we
wouldn't
need
it
and
for
more
than
a
year
there
was
there
was
enough
content
enough
things
to
discuss
that
it.
You
know
that
it
required
the
weekly
meetings
yeah.
A
L
L
A
A
Thank
you
all
right,
that's
it
for
now,
let's
meet
again
monday
at
11
o'clock,
pst
and,
in
the
meantime,
I'll
I'll,
add
all
the
different
tasks
that
we're
doing
all
the
different
things
that
need
to
be
done.
You
know
into
github
and
post
a
link
on
on
the
on
the
slack
channel.