CloudStack有它自己的 API。像libcloud和 jclouds之类的 Cloud封装器与这个原生的API协作的很好，但是 CloudStack并没有像OCCI 与 CIMI 那样暴露出任何标准的API 。我们 (事实上就是Isaac Chiang ，我刚刚验证过并给他指出了正确的方向) 开始用我们的CloudStack ruby gem （译注：gem是一种文件组织的包,一般ruby的很多插件都由各种这样的包提供。）来做一个CloudStack 后端的 rOCCI 。之所以选择 rOCCI是因为现存的 Opennebula后端（译注：OpenNebula是开放原码的虚拟基础设备引擎，它用来动态布署虚拟机器在一群实体资源上，OpenNebula最大的特色在于将虚拟平台从单一实体机器到一群实体资源。）以及欧洲电网计划联合云测试平台采用了 OCCI 。
我们先来安装 rOCCI服务器，这项工作还没有合并到上层，所以你需要从 Isaac Chiang的分支（fork）开始工作。
git clone https://github.com/isaacchiang/rOCCI-server.git
bundle install
cd etc/backend
cp cloudstack/cloudstack.json default.json
编辑文件 defautl.json，让它包含有关你的 CloudStack 云的信息(例如apikey, secretkey, endpoint)。启动rOCCI 服务器：
bundle exec passenger start
服务器将运行在 http://0.0.0.0:3000 ，接着运行以下测试：
bundle exec rspec
这已经在CloudStack模拟器上以一个基本区域配置测试过了，请帮我们在生产云环境下再测试它。
你也可以试着用OCCI客户端。可以从Github安装这个rOCCI 客户端 ：
git clone https://github.com/gwdg/rOCCI-cli.git
cd rOCCI-cli
gem install bundler
bundle install
bundle exec rake test
rake install
这样你就可以使用这个 OCCI客户端了：
occi --help
针对你之前启动的服务器来测试它。你需要一个运行中的CloudStack云。或者是一个生产云，或者是使用DevCloud的一个开发实例。这个云的凭证和端点应该已经输入在`default.json`文件中了，也就是你在前面部分所创建的那个文件。现在来测试几个OCCI客户端命令：
$ occi --endpoint http://0.0.0.0:3000/ --action list --resource os_tpl
Os_tpl locations:
os_tpl#6673855d-ce9b-4997-8613-6830de037a8f
$ occi --endpoint http://0.0.0.0:3000/ --action list --resource resource_tpl
Resource_tpl locations:
resource_tpl##08ba0343-bd39-4bf0-9aab-4953694ae2b4
resource_tpl##f78769bd-95ea-4139-ad9b-9dfc1c5cb673
resource_tpl##0fd364a9-7e33-4375-9e10-bb861f7c6ee7
你可以从模版中识别出`uuid`，还有你在CloudStack中创建的服务产品。若要启动一个实例的话，只需：
$ occi --endpoint http://0.0.0.0:3000/ --action create --resource compute
--mixin os_tpl#6673855d-ce9b-4997-8613-6830de037a8f
--mixin resource_tpl#08ba0343-bd39-4bf0-9aab-4953694ae2b4
--resource-title foobar
这样将会返回一个创建在这个资源之上的句柄。这样就完成了！
我们将继续改进这个驱动，以便向想要使用标准接口的用户提供一个具有高产品质量的OCCI接口。当然了，我们也会努力在一个CIMI上实现接口。在EGI云联盟上的许多云平台很有希望将会使用 CloundStack，以此来帮助我们改进这个OCCI接口。在 CloundStack，我们的目标是提供用户想要的接口，并保持这些接口是最新的和具有高产品质量的，这样用户就能够依赖它。