►
Description
Presented by: Jiffin Tony Thottan
Introduction to Container Object Storage Interface aka COSI for ceph RGW
For applications in Kubernetes, CSI provides a way to consume file/block storage for their workloads. The main motivation behind the Container Object Storage Interface is to provide a similar experience for Object Store. Basic idea is to provide a generic, dynamic provisioning API to consume the object store and the app pods can access the bucket in the underlying object-store like a PVC. The major challenge for this implementation there is no standard protocol defined for object and the COSI project need to be vendor agonistic. It won't handle the orchestration/management of object store, rather it will be another client and provide bucket access on behalf of applications running in Kubernetes. The initial version of the ceph-cosi driver can be found at https://github.com/ceph/ceph-cosi.
A
So
so
myself,
different
on
the
thought
and
I
am
working
as
a
senior
software
engineer
in
the
dead,
Chef
storage
and
most
of
my
work
are
related
to
integrating
RCW
with
kubernet
text.
So
as
a
part
of
that,
I
was
worked
with
the
Cosi
Community
for
last
couple
of
years,
and
currently
it's
in
a
alpha
status.
So
I
just
give
a
brief
update
about
the
project
about
things
now
and
all
those
stuff
so
yeah.
A
Moving
on
to
the
next
slide.
Today
we
are
I,
am
planning
to
cover
following
topics.
First
I
give
a
brief
intro
like
beef,
brief
idea
about
CSA
and
kubernetes,
and
what
was
the
motivation
behind
the
Cozy
and
a
bit
depth
about
course,
architecture
and
workflow
and
finally,
about
the
cefcocet
driver
voice
chance
today.
A
A
Can
because
for
PV
of
previous
excuse
me-
and
it
is
the
position
storage
which
was
created
by
administrator
like
which
was
created
given
by
the
kubernetes
and
dynamically
through
it
through
a
driver
and
a
result
of
the
PV,
is
a
PVC,
and
this
is
the
actual
storage
which
is
provided
or
accessed
by
the
application,
and
it
uses
the
previous
sources
yeah,
which
means
basically
price.
What
was
the
size
of
the
storage
and
how?
What
is
the
type
of
the
access
which
you
are
getting
moving
on?
A
So
let's
talk
about
Cozy,
so
the
Coursey
project,
as
you
know,
like
the
CSR,
provides
support
for
file
and
block
storage
to
address
the
object,
storage
or,
like
the
use
cases,
the
people.
You
know
that
started
working
bit
on
that
and
here
the
main
idea
is
like
the
application
or
the
user
can
Dynamic
provision
provision.
The
storage
of
gesture
for
the
use
case
and
the
app
Port
can
directly
access
the
bucket
in
the
obser
like
PVC,
and
we
need
to
automate
with
the
kubernetes
design
similar
to
PVC.
A
We
need
a
plugable
version
in
which
different
vendors
can
be
plugged
in,
and
we
need
to
provide
similar
experience
for
new
and
existing
buckets.
I
will
go
deep
into
this
part
in
the
next
slides
and
similar
to
CSA.
It
need
to
be
vendor
agnostic
and
one
of
the
issue
with
that.
This
is
like.
If
for
obser,
there
are
different
types
of
protocol
itself
is
supported
like
profile
and
block.
A
The
protocol
is
kind
of
a
defined
one,
but
here
those
are
sure-
and
this
history,
then
the
Google
Cloud,
so
different
protocols
have
different
mechanisms
and
we
need
to
handle
all
those
like.
At
least
we
need
to
be
when
the
diagnostic
and
like
we
need
to
support
each
drivers,
and
it's
only
manages
the
storage
it
won't
handle.
The
setting
of
the
objectial
part
like
pushing
the
object,
store
like
to
say
I
said,
do
the
same
thing.
A
So
it's
similar
to
that
just
in
case
and
how
we
started,
as
I
mentioned
before,
like
the
couple
of
people
or
developers
from
the
other
city
office,
worked
on
a
library
known
a
slip
bucket
position.
So
it's
just
a
goal
line
library
and
which
have
an
obsession
for
bucket
and
and
a
bucket
request
on
top
of
it,
and
it
was
initially
developed
by
John,
Jeff
and
Irwin,
and
mostly
it
was
consumed
by
Luke
and
nuba
project
as
an
external
library
of
vendor.
A
Then
what,
when
you
add
this
library
to
the
project
like
it
watches
for
bucket
requests
and
bucket
claims?
And
it
will
do
the
reconciling
part-
and
it
also
creates
those
sources
like
conflict
map
and
secret,
which
need
to
be
consumed
by
application
port
and
delete
those
sources
whenever
the
request
is
needed
and
So
based
on
that,
like
we
created
a
set,
of
course,
also
the
one
of
the
issue
with
the
bucket
portion.
It's
not
a
standalone
project
like
it
need
to
be
have
part
of
the
I
either.
Look
like
nuba.
A
We
need
to
support
portability
in
the
sense
like
if
user
changes
the
cluster
from
one
to
another,
like,
even
if
the
the
anger
like
I
I,
cannot
say
like
it's
the
or
not
like
if
the
one
bucket
was
in
Amazon
and
he
want
to
move
to
Microsoft
option
in
future.
We
need
to
support
some
that
kind
of
portability.
That's
what
in
our
mind
and
the
when
the
neutrality
issue
like,
depending
on
different
protocols
or
depending
on
different
objects
or
like
we
need
to
provide
a
support
for
that
and
yeah.
A
It
need
to
be
a
standard
risk
mechanism
which
might
not
be
difficult
to
digest
because
of
just
product
or
like
up
just
a
protocol
does
not
have
a
standard
mechanism,
but
we
are
talking
about
the
aps,
which
generally
cozy
uses
for
going
on
and
brief
our
you
about
the
Cosi
architecture
and
the
terminologies.
So
first
I
will
start
with
the
terminologies,
which
can
be
easily
compared
with
the
CSA
terminology
as
well.
A
So
this
is
a
part
which
is
bit
different
in
go
see
you
with
CSI
like
the
CSA.
We
only
have
the
pvco
like
after
that
you,
when
you
get
the
PV,
then
everything
is
fine.
But
the
second
stage
is
access
is
a
different
part.
So
user
can
request
for
Access
for
same
bucket
or
different
bucket,
depending
on
the
the
use
cases,
or
something
like
that.
A
Services
CSA
part
like
it's
not
an
apple
to
Apple
comparison,
but
still
I'm,
trying
to
compare
the
three
years
generally
so
similar
to
storage
class.
We
have
bucket
classes
on
the
left
side
and
per
System
model
and
processing
claim
is
a
combination
of
bucket
axis
and
bucket.
It's
not
a
single
thing
like
we
have
two
different
cers
and
yeah.
So
here
most
likely
one
application
will
be
attaching
to
like
a
user
will
apply
request
for
a
PV,
and
it's
not
that
much.
The
access
policy
is
bit
less
cleaner.
A
When
you
compare
the
use
cases,
it's
cozy
and
we
have
different
access
mode
like
read,
write
or
read
only
like
kind
of
stuff,
but
course
is
bit
more
what
you
said:
more
General
land
CSI
in
this
part,
but
the
use
cases
are
different.
Csi
handles
file
and
block
and
go
see
handles
the
object.
Part
go
into
the
next
slide.
So
this
is
the
basic
architecture
design
or
like
how
the
Cozy
topology
looks.
Like
the
excuse
me.
A
A
Name
says
which
will
have
the
side
car
and
the
driver,
so
sidecar
will
receive
the
request
and
it
will
be
passed
to
the
Cosi
diary
grpc
and
the
driver
will
send
us
across
to
the
depending
on
the
which
window
like
which
backend
it
is,
and
that
sorry
the
backend
can
hand
will
be
on
different
namespace
or
something
like
that,
and
on
the
lowest
level
we
have.
The
application.
Namespace,
which
will
be
Port,
will
be
running
and
code
will
be
so
at
the
end.
A
The
result
is
a
secret
like
that
which
we
have
the
access
information
for
the
application
and
poor
need
to
mount
that
secret.
So
Ford
will
be
running
until
this
Cricket
secret
is
created.
So
that's
how
the
workflow
workflow
will
be
and
on
the
right
side.
I
am
also
having
some
references
like
the
how
the
bucket
claim
bucket
and
bucket
access
are
related,
so
the
bucket
claim
will
be
also
in
the
market.
Class
and
bucket
will
be
created,
based
on
that
and
bucket
taxes
have
earphones
through
the
bucket
claim
and
yeah.
A
We
have
cozy
control
manager,
as
you
see
in
the
previous
slides,
which
have
the
basically,
it
manages
the
course
AP
objects
and
its
life
cycle
so
and
we
need
a
at
least
one
control
manager
like
we'll
be
running
for
the
course
you
need
to
be
working.
So
whenever
user
do
groups,
it
till
Q8,
bucket
double
Crystal
frustrates
on
the
Cosi
manager
and
the
request
will
be
passed
to
the
side
car.
A
So
the
sideka
is
a
place
for
the
drivers
or,
like
course,
you
will
be
interacting
and
it
will
send
the
jrps
or
different
apas
like
create
bucket
or
create
access
delete
bucket
to
the
driver
and
the
side.
Car
will
be
one
into
another
driver
so
as,
but
normally
the
which
side
cost
you
and
for
each
driver.
There
should
be
one
side
card
to
be
running
like
independently.
If
you
have
multiple
drivers,
then,
or
each
driver
should
have
a
different
side.
A
Car
excuse
me,
and
finally,
we
have
the
Cosi
driver,
which
is
the
plug
rubber
part
like
which
can
support
different
back
ends,
even
if
it
supports
different
protocols
that
can
be
also
supported
as
well,
and
the
buckets
will
be
created
based.
On
the
first
hand,
access
will
be
created
based
on
request,
so.
A
Now
I
will
cover
how
the
Cozy
APA
works
and
how
it
handles
the
Green
Field
and
brown
field
cases.
So
the
Green
Field
is
like
it's
purely
based
on
the
design
like
most
of
the
subs
are
yet
to
implemented
or
like
at
least
the
infill
cases.
Complete
Front
Field
is
yet
to
complete.
So
this
is
based
on
the
design.
A
All
these
rights
or
upcoming,
slides
and
so
Green
Field
is
a
case
in
which
the
bucket
will
be
created
when
the
user
is
requested
and
Brownfield
is
like,
my
user
is
getting
an
access
for
accessing
bucket
or
like
so
the
bucket
can
be
created
by
cozy
or
it
cannot
be
created
by
COC.
So
these
are
the
two
cases
for
the
blonde
field.
So
here
the
assumption
is
that
the
bucket
class
and
bucket
access
classes
are
created
by
the
Admin,
so
user
just
need
to
create
the
bucket
claim
or
like
bucket
access
after
that.
A
A
What
the
content
of
speaker
so
mentioning
the
secret
name-
and
it
tells
me
to
mention
the
bucket
claim
so,
which
will
have
the
reference
to
the
bucket
and
the
central
will
try
to
create
a
great
excuse
me,
the
bucket
Access
First.
It
will
call
the
sender,
custom,
sidecar
controller
and
a
soft
side
can
cause
it
driver
and
which
will
request
the
access
mechanism
from
the
vendor
professional.
A
So
if
the
report
is
like
like,
if
you
created
the
board
and
if
the
port
is
in
pending
status,
when
Once
the
Securities
get
created,
Port
will
be
on
running
status
or
you
can
create.
The
bucket
access
then
attach
the
secret
to
the
podium
after
that
as
well,
and
now
I
am
talking
about
the
brown
field
case.
So
for
both
cases,
as
of
now
for
the
design
in
the
alpha
status,
we
can
change
it
future.
A
But
for
both
like
the
bucket
need
to
be
created,
I
mean
the
bucket
users
need
to
be
created
by
the
administrator,
and
here
the
difference
is,
is
the
bucket
access
will
have
response
to
the
bucket?
Then
the
claim
and
similar
to
that,
like
the
request
for
the
bucket
assets
will
be
like
will
be
given
to
the
sidecar
controller.
I
mean
the
site
car
is
by
the
driver,
and
driver
will
look
us
for
the
access
access
for
the
bucket
and
vendor
will
provide
the
access.
A
So
one
thing
which
I
want
to
mention
like
the
Brownfield
cases
like
this,
can
be
a
bucket
which
will
be
created
or
we
create
in
different
namespace
or
something
like
that
by
that
means,
and
it
need
to
be
shared
to
different
namespace.
That's
one
use
case.
Another
use
case
is
like
the
back
end
will
already
have
the
bucket,
but
it
is
not
Dynamic
created
it's
all
decision
bucket
in
the
back
end.
For
that
also,
like
you
also
need
to
create
a
bucket
resource.
A
A
A
Access,
so
the
vendor
can
do
like
Windows
can
work
the
permissions,
that's
it
like.
We
can
delete
the
backend
access
key
or
something
like
that
or
we
can.
If
it's
a
policy
base
you
can,
you
can
remove
the
policy,
something
like
that
and
finally,
the
controller
will
after
the
working
assets,
the
controller
will
delete
the
secret.
A
A
It's
based
on
the
policy
purely
based
on
the
policy.
Then
this
is
about
the
bucket
info.json.
So
this
is
the
content
of
the
secret
file,
so
basically
it
will
have
so
I
have
it
included
information
about
the
S3
So.
Currently
we
have
two
drivers,
which
are
at
least
working
in
condition
like
one
is
assured
on
this
S3,
so
the
bucket
info
will
be
with
indented
to
that
one.
So
the
exam
which
I
used
to
have
the
SP
one
like,
which
will
have
the
endpoint
information
and
set
it
credentials.
A
One
is
access,
key
circuit,
key
and
the
rich
information,
and
also
it
will
be
different.
They
have
token
or
something
like
that,
and
the
protocol
field
is
like
if
the
vendor
is
something
what
you
say
different
from
the
standard
ones
like
S3
or
sure
like
Google
Cloud,
then
you
can
use
the
protocol
field
to
include
the
details.
That's
it
now
post
Alpha
plan.
So
we
also
plan
to
support
IM
side,
authentication
or
token
based
authentication
So.
Currently
it
only
support
the
key
based
or
like
access
key
secret,
key
kind
of
for
the
indication.
A
Then
we
need
to
automate
the
bucket
sharing,
of
course,
at
least
the
kubernetes
level
of
bucket
chain
or
plant
field
cases.
If
the
user
create
a
bucket
on
one
name,
space,
the
bucket
access
can
be
created
only
if
the
bucket
is
present
in
the
main
space
of
the
city
is
not
supported,
and
we
also
need
to
support
like
different,
like
bucket
kind
of
features
like
standard
features
like
life
cycle
or
like
policies,
or
something
like
that,
and
currently
it's
bit
of
a
manual
work.
A
You
also
need
to
add
the
secret
to
the
application,
port
and
all
those
stuff,
and
we
don't
have
any
control
on
the
application
side,
but
CSA
have
a
node
driver
kind
of
stuff.
So
at
least
we
are
planning
to
support
a
cubelet
kind
of
plugin
which
will
have
some
checks
on
the
application
Level
and
which
need
to
validate
for
the
secret.
It's
why
it
was
something
like
that,
so
that
port
won't
be
up
and
all
the
stuff
can
be
handled
and
integrate.
A
A
So
basically
it
only
supports
extra
protocol
at
the
moment
and
so
as
the
input
to
a
driver.
We
need
to
provide
the
end
point
and
use
the
credentials
and
this
this
user
need
to
have
some
admin
caps
like
for
that.
We
don't
need
to
be
work
and
this
details
need
to
provide
us
a
kubernetes
secret
and
all
the
basic
functionality
of
APs
are
supported
with
the
driver,
but
the
changes
I
have
to
emerge
in
Upstream.
I
can
do
a
small
demo
if
the
time
permits.
A
No,
so
that's
a
to-do
list
for
the
Posse
driver,
like
current
plan,
is
to
I
need
to
merge
all
the
changes
to
the
Upstream.
Master
then
have
an
ph
up
to
test
driver,
and
currently
we
need
to
locally
build
images.
I
need
to
host
it
somewhere
so
that
people
can
access
the
image
directly
so
like
I
need
to
have
a
CA
job.
To
do
that.
A
A
So
these
are
some
responses
right,
I
guess:
I
have
completed
the
percentage
on
time,
and
these
are
people
who
worked
with
the
community.
You
can
watch
us
on
community
slack,
channel
six
storage
Cosi
and
we
have
a
weekly
meeting
on
every
Thursday
yeah
6
PM
GMT
time
any
questions
I,
don't
know
whether
we
have
time
to
have
questions
otherwise
I
can
wrap
it
up
different.
You
can.
B
Yeah,
it's
you're
a
little
bit.
It's
a
poster
the
time.
That's
that's
a
big
problem
for
me,
but
I'm,
not
sure
if
index
speakers
have
enough
time
to
allow
for
even
more
questions
or
demo.
So
well,
thanks
for
the
presentation,
it
was
ready
for
all
I,
don't
see
any
questions
yet
in
the
chat.
So
we'll
just
give
people
some
time
to
think
of
a
question.
Yeah.