openstack-cinder

[Everett Toews]

Hi All,

Now that Cinder [1] (Volumes) is part of the OpenStack Folsom release and Rackspace just went GA [2] with their deployment I'd like to create a labs/openstack-cinder project and associated rackspace-cloudblockstorage-us/uk projects. 

The API for Cinder isn't that big, see the Volume section (everything starting with "v1/") of the API docs [3] so I don't think openstack-cinder would be a huge amount of work but first I wanted to check:

1. Has anyone else started work on something like this?

2. Is anyone else interested in helping out?

Regards,

Everett

[1] http://wiki.openstack.org/Cinder

[2] http://www.rackspace.com/blog/cloud-block-storage/

[3] http://api.openstack.org/

[Adrian Cole]

I offer to help make sure the maven archetype can generate the
skeleton.. maybe even make one for keystone-based apis.

-A

> --
> You received this message because you are subscribed to the Google Groups
> "jclouds-dev" group.
> To post to this group, send email to jclou...@googlegroups.com.
> To unsubscribe from this group, send email to
> jclouds-dev...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/jclouds-dev?hl=en.

[Everett Toews]

Cool. Thanks.

After a bit of coding I've got a number of questions on how
openstack-cinder will fit into the overall jclouds architecture.

1. Region or Zone?

openstack-glance, openstack-nova and openstack-quantum all use the
ZoneModule but openstack-swift uses the RegionModule. I was leaning
towards using the RegionModule for openstack-cinder because the
serviceCatalog from Keystone spits back things called region but I thought
there might be more to it than that. Which should I use and why?

2. To split or not split the API?

The API isn't that big but there are 3 distinct parts to it: Volumes,
Volume Types, and Snapshots. Most OpenStack APIs (whether driven by
extensions or not) seem to get the split out treatment. Should I follow
that pattern here?

3. Best practice for getting a handle on the API?

I've got a bit of working code now that I can run against my local Folsom
devstack. Here's how I'm doing it.

Iterable<Module> modules = ImmutableSet.<Module> of(
new SLF4JLoggingModule());

String provider = "openstack-cinder";
String identity = "demo:demo"; // tenantName:userName
String key = "devstack";


RestContext<CinderApi, CinderAsyncApi> cinder =
ContextBuilder.newBuilder(provider)
.credentials(identity, key)
.endpoint("http://172.16.0.1:5000/v2.0/")
.modules(modules)
.build(CinderApiMetadata.CONTEXT_TOKEN);

System.out.println(cinder.getApi().getConfiguredRegions());

Is that the best way to get a handle on the API to start working with it?


Any other sage advice for a Friday afternoon?

Cheers,
Everett

[Adrian Cole]

inline!

On Fri, Oct 26, 2012 at 8:25 PM, Everett Toews
<everet...@rackspace.com> wrote:
> Cool. Thanks.
>
> After a bit of coding I've got a number of questions on how
> openstack-cinder will fit into the overall jclouds architecture.
>
> 1. Region or Zone?
>
> openstack-glance, openstack-nova and openstack-quantum all use the
> ZoneModule but openstack-swift uses the RegionModule. I was leaning
> towards using the RegionModule for openstack-cinder because the
> serviceCatalog from Keystone spits back things called region but I thought
> there might be more to it than that. Which should I use and why?

region is a service that has datacenter failure resilience, zone is
for things better mapped to datacenters. HP named their urls for
swift on region basis, which was the original history. Hopefully,
swift is indeed resilient to a zone failure. Otherwise it might not
have been a good choice.

Keystone has a generic field named ~region, but since that's not used
precisely, you can ignore it. For example,our ZoneModule uses the
same data that is in the Keystone region field, since keystone has no
location scope defined outside region right now (unless that's
changed)

Very likely cinder has the same fault tolerance as nova, so I'd assume
it is zone.

>
> 2. To split or not split the API?
>
> The API isn't that big but there are 3 distinct parts to it: Volumes,
> Volume Types, and Snapshots. Most OpenStack APIs (whether driven by
> extensions or not) seem to get the split out treatment. Should I follow
> that pattern here?

yep. I don't see a reason to change, as the intent is to be resource
based (ex. volume is a distinct resource from snapshot, etc)

>
> 3. Best practice for getting a handle on the API?
>
> I've got a bit of working code now that I can run against my local Folsom
> devstack. Here's how I'm doing it.
>
> Iterable<Module> modules = ImmutableSet.<Module> of(
> new SLF4JLoggingModule());
>
> String provider = "openstack-cinder";
> String identity = "demo:demo"; // tenantName:userName
> String key = "devstack";
>
>
> RestContext<CinderApi, CinderAsyncApi> cinder =
> ContextBuilder.newBuilder(provider)
> .credentials(identity, key)
> .endpoint("http://172.16.0.1:5000/v2.0/")
> .modules(modules)
> .build(CinderApiMetadata.CONTEXT_TOKEN);
>
> System.out.println(cinder.getApi().getConfiguredRegions());
>
> Is that the best way to get a handle on the API to start working with it?

yeah

>
>
> Any other sage advice for a Friday afternoon?

sorry too late for that :) Anyway, best advice is always to look at
most recent code and follow that. best luck!