DoubleCloud.org

Upon hearing about my leaving VMware, quite a few members in the community sent me emails or tweets asking about the future of the API. Most of them have built products or automation scripts using the API, therefore would like to see the continuous success of the open source project. I am sure there will be more inquiries coming without this post.

As it stands today, I do plan to maintain the project in the future, mainly upgrading the API to the latest and greatest future vSphere releases. If my time allows, I would also like to enhance the APIs in the following areas: [Note: all these should not be interpreted as a commitment; contact me otherwise.]

1. Continue the high level abstraction as I laid out in the VI Java API Crescendo release. A small part of the abstraction had been included in version 5 (Have you noticed it? BTW). But we still have a long way to go before we can match PowerCLI on the task oriented abstraction. Again, we will not re-implement PowerCLI in VI Java API, but would make it significantly easier to achieve similar tasks. After all, API is NOT command line or scripting; otherwise it’s wrong. I will blog about this more about the differences and how they should be related to each other.
2. Expand to other VMware APIs. It’s no doubt that vSphere APIs is, and I think continues to be in foreseeable future, the most important APIs from VMware. As VMware continues to innovate, many other important APIs will come up. It would nice if there is a unified API that works across different product lines. It’s more than simple addition of API calls, but an aggregated APIs among which you can navigate from one to another. The one on top of my head is the vCloud API. Please feel free to name others you want the first in your comment.
   Early this year, I made a presentation proposal to talk about interoperability of VMware APIs. Better than a talk, this expansion, if done right, would give you real APIs to work with. As ambitious as it may seem, it’s indeed not an easy project, let alone the amount of work.
3. Support other open source hypervisors like XEN, KVM. This was actually my vision for the project I had two years ago. I believe a unified API to manage all hypervisors would be very helpful for the customers, and in particular for partners who want to write once and integrate with all.
   As I found out after studying some of the management APIs, the biggest challenge is to come up with a common object model that makes sense for all the hypervisors. Given that each hypervisor has its different object model and even different naming, this effort may result in a least denominator of the existing object models. In my estimation, the least denominator would most likely equate to the vCloud API level abstraction.

To achieve these, I would like to get helps from the community, and companies as well:

1. Development/build/test environment, including hardware/software. It doesn’t need to be big, but good enough for the project. If it’s an environment accessible remotely, that would work too, probably even better.
2. Advisory board. I would like to invite experts who would agree to give meaningful help on regular basis (quarterly or bi-yearly, TBD) in many different areas, from project direction, user feedbacks, technology, etc.
3. Contribution, including coding, documenting, evangelism, etc.

Should you be interested in helping the project or referring others, please leave a comment or contact me: sjin2008 at users dot sf dot net.