openstack team mailing list archive

[Doug Davis <dug@xxxxxxxxxx>]

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
>   dominant.
> 
>   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 
APIs.

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 
evidenced 
by the fact that adapter projects (like DeltaCloud) can exist. If there 
wasn't
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 
getting
standards folks into OS is a good idea, I think having it be a good 
two-way
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 
folks
who will never join Openstack (for a variety of technical and business 
reasons).
Yet for the sake of the broader community I think we need to find a way to 
make 
them work together.

Additionally, and now the hard part, I think it would be good for people 
to 
realize that there is a spot in the middle where both sides can meet. 
Having
looked at a variety of IaaS APIs, and more recently looking at how CIMI 
can map
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 
Nova
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 
top 
of my head (and this is just me talking, I have no idea how any of these 
folks
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 
willing
to help bridge the communications between the standards folks and the 
Openstack
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 
myself,
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 
minimum
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 
interest.

May not be the easiest thing, but I also don't see it is as that hard 
either, 
once a decision to explore that option is made.  Just my 2 cents...

-Doug Davis
dug@xxxxxxxxxx