openstack-poc team mailing list archive
Mailing list archive
Re: [Openstack] 3rd Party APIs
Mark McLoughlin wrote on 05/08/2012 10:58:45 AM:
> What I'd like to see us get to is:
> Deep overlap between the OpenStack developer community and the
> community of folks drafting whatever IaaS standard(s) wind up being
> e.g. prominent, active Nova developers developers contributing to the
> CIMI or OCCI standards and bringing the needs of OpenStack to the
> standard and bringing ideas from the standards process to OpenStack.
> This isn't a question of asking existing OpenStack developers to join
> these standards bodies. It's about enabling members of those standards
> bodies to become as much a part of OpenStack as any other developer.
> How to do that? Encourage members the various standards communities to
> actively contribute an implementation of their standard to OpenStack
> and, more importantly, stick around to become an ongoing active member
> of the OpenStack developer community.
While the issue of "what goes into the core vs is a plug-in" is certainly
an important one, I think the above touches on a higher-order issue that
I think is just as important. And it's around the proliferation of IaaS
Certainly each IaaS author is going to favor their own APIs - as expected.
As a result there will be resistance to adopt, or even look at, others.
They will also try to push their favorite IaaS API on others.
In the end though, and this may be hard for some to believe :-), it's just
an API. What matters more is the functionality behind the APIs.
E.g. we all have our favorite API to mock and yet there are people out
there using it. Why? Because they want the features behind it despite any
odd use of HTTP/REST.
One of the first things we noticed in our CIMI work was that pretty much
every IaaS input contribution was basically the same - not syntactically
but semantically. This made our lives so much easier. It's also
by the fact that adapter projects (like DeltaCloud) can exist. If there
semantic similarities between all of those IaaS providers then I doubt
DC would be able to work.
So, why am I bringing this up? Because while I agree with Mark that
standards folks into OS is a good idea, I think having it be a good
communication is even better. Meaning, I think it would be good for Nova
folks to find a way to influence the standards too. Just as I'm sure
some Nova guys are already running from their keyboards at the prospect of
talking to standards weenies :-) I know there are plenty of standards
who will never join Openstack (for a variety of technical and business
Yet for the sake of the broader community I think we need to find a way to
them work together.
Additionally, and now the hard part, I think it would be good for people
realize that there is a spot in the middle where both sides can meet.
looked at a variety of IaaS APIs, and more recently looking at how CIMI
to Nova, I'm (again) struck at how similar they are. And if I were to play
God for a moment, I'd slap both sides upside their heads and tell them to
each bend a little and find a spot in the middle. CIMI can change, and
can change - after all, it's just an API.
With the recent folks that joined Openstack, the amount of overlap between
CIMI authors and Openstack members is actually quite large. Just off the
of my head (and this is just me talking, I have no idea how any of these
feel about this), but there's RedHat, HP, Rackspace, IBM, Cisco, Dell and
I'm sure others. I'm pretty sure that folks from those companies would be
to help bridge the communications between the standards folks and the
folks - thus allowing the OS devs who want to avoid standards bodies to do
so, but still have a voice over there. Or at least, speaking just for
I'd be more than happy to work to make that happen - been doing it already
for a while behind the scenes.
But course, this would require at least some commitment from the various
Openstack groups to entertain the idea of this collaboration. At a
it means both sides being willing to see what the other has and to offer
suggestions on how to find that middle ground. I'd be more than willing to
help get those harmonization discussions going but only if there's
May not be the easiest thing, but I also don't see it is as that hard
once a decision to explore that option is made. Just my 2 cents...