Dear Gregor, just one more thing. We are currently participating at the Cloud Plugfest and test all available OCCI implementations, improve them and discuss the interpretation of the specification. As we are especially focusing on testing OCCI for the EGI FedCloud you may want to join our discussions remotely. If you intend to do so, please register as a remote participant here http://www.cloudplugfest.org/next-event/registration and we can send you all information regarding chat room, test tools and test results. I also missed to note the repositories for the rOCCI code. We split the code in a server part and a OCCI Core + Client part. The server part can be found here: https://github.com/gwdg/rOCCI-server The OCCI Core and Client can be found here: https://github.com/gwdg/rOCCI Cheers, Florian Am 10.12.2012 um 17:16 schrieb Feldhaus, Florian:
Dear Gregor,
I'm one of the maintainers of rOCCI, an implementation of OCCI 1.1 with support for OpenNebula >= 3.2. This framework is successfully used within the EGI Federated Cloud Task Force to manage the OpenNebula sites through OCCI. The rOCCI client has been tested against the rOCCI server and the OpenStack OCCI implementation and works with both.
During the last months we concentrated on the core OCCI classes and the OCCI client side and will improve the OCCI server side in the next months with support for all OpenNebula entities (e.g. users, groups, special OpenNebula features, …) as well as implement other backends to the OCCI server such as EC2 and CloudStack.
rOCCI server and client just got VOMS support which might be interesting for you as well.
For specific discussion on rOCCI technical details you can also ask them on the rOCCI mailinglist here: https://listserv.gwdg.de/mailman/listinfo/rocci
Cheers, Florian
Am 10.12.2012 um 13:18 schrieb Gregor von Laszewski:
All:
please could someone provide me with a status update on OCCI and OpenNebula distribution. We in FG are interested in finding more out about it (does it work for the newest version of OpenNebula, and so forth). Furthermore, we would appreciate any help from the community to discuss a community managed OpenNebula distribution on FG that supports OCCI.
We have in FG an internal OpenNebula cloud deployed, that is however not accessible to the public as it is strictly used for some internal services we have. The main reason it is private is manpower. Thus we thought we could use OpenNebula to identify if it is possible to identify if users can set up their on managed clouds. The idea came based on an experiment that we ran on Openstack Essex, where we for example developed a one line command so that a novice user could set up an entire virtual cluster with a couple of options such as a label and the number of worker nodes. This did set up one or more slurm clusters each with its own virtual worker nodes. Now we started thinking further.
What if a user has a command such as
fg-cloud-seeding -label gregorsCloud -IaaS OpenNebula -workers 12
This would than set up my private open nebula distribution on FG. Now if i add anther parameter that determines accessibility of the cloud I even could make it a public cloud.
Recently we developed a new tool that allows us more easily to "redistribute" resources to different clouds and it may be the right time to look into how to best set up a "public" OpenNebula cloud with what I term cloud-shifting e.g. resources can be moved on demand into a particular cloud IaaS framework. This allows us for example to move resources from a batch queuing system to Eucalyptus, to OpenStack, naturally we are interested to do the same with OpenNebula as this seems to be a IaaS framework the OCCI community is often referring to. Any thoughts?
What are the commands in OpenNebula that allow us to register and unregister a node from the cloud in open nebula? If we know these commands, we could add them to our tools and start thinking about what needs to be done to integrate OpenNebula.
Furthermore, we are removing the dependency of our tools that we developed on the need for XCAT and Moab. This means one could deploy such tools also elsewhere. We work steadily towards this goal but probably need some more time, and than gradually improve its functionality and capability.
Thoughts are much appreciated.
Thanks
Gregor _______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg