[Openstack-operators] Deprecation of in tree EC2 API in Nova for Kilo release

Robert Collins robertc at robertcollins.net
Tue Feb 3 05:12:19 UTC 2015

On 31 January 2015 at 06:18, Eric Windisch <eric at windisch.us> wrote:
>> That's a failing of the Nova team that must be addressed. As maintainers
>> it is our job to produce software that meets the needs of our users. We
>> have 35% of users reporting they use this EC2 code, so fixing any problems
>> should be a high priority item & these bugs considered release blockers
>> for Kilo.
> The role of programs are not to solve user's needs, but to to solve the
> needs or desires of its developers and their patrons.

mmmm, programs are a governance structure around disparate communities
of interest. Why we do that is an interesting discussion, but it seems
clear to me that we don't solve the needs or desires of developers (or
patrons!) via programs. Developers needs are solved through discussion
and negotiation and code. Patrons needs are solved by paying
developers to discuss and negotiate and code. And, I think we all know
that there are massive issues with that today - we get a lot done, but
theres a lot more that just stalls for months at a time.

We have repeatedly asked our users, in particular the operators, to
communicate more directly - to make time to talk with the developer
community and tell us what we're doing well, and what we're doing
poorly. If we didn't intend to act on that feedback from users, why
did we ask them to do that?

More broadly, one of the things patrons want out of OpenStack is a
successful, stable, scalable and flexible substrate for their products
(whether they sell hardware that can be consumed by OpenStack, network
gear to be used by it, support and installation of OpenStack, etc etc
etc). Being successful requires meeting the needs of our users. If we
wilfully ignore the data we do have about those needs, we're arguably
doing our patrons a very significant disservice.

> The job of the
> foundation arguably includes rallying developers around needs of the users.
> However, an open source project is not the product of an organization that
> is developed for its users. Ultimately, if those that care don't step up, or
> don't work through a vendor that cares for their needs, they've no right to
> complain. It's also, I believe, the role of the foundation to express these
> basic facts to its users.


Quite seriously: open source projects are absolutely developed for
their users. Thats the entire proposition of both free and open source
software and licenses: that users should have the freedom to modify
things to meet their needs, *and* that users will be building what
they need in the first place. OpenStack is somewhat unique in that
many of its developers are *not* its users. (Compare with e.g. the
kernel, or Python, where approximately every developer of it is
running it themselves - we have lots of contributors that are not
actually using OpenStack themselves, nor using the driver or whatever
that they are writing outside of test environments). So we're *more*
aligned with proprietary software development models. Early on this
was different, when it was only folk that were deploying the thing
writing it.

I'm not saying that users should be able to say 'we need X' and expect
us to say 'how high?', but we're deluding ourselves if we think that
we're writing this project as a traditional open source project. Many
of us are entirely dependent on the market success of OpenStack to
keep hacking on it (contrast e.g. a Cinder driver contributor to a
RackSpace nova operator who sends in patches that are literally
scratching their own itch).

> Where most OpenStack programs have failed is in enabling its developers to
> contributing code without friction. Instead of being an agile startup, it
> has become sluggish and bureaucratic. The bureaucracy makes it difficult for

+1, sadly, I agree with this and wish to subscribe to the newsletter :).

We need to fix that, without adding more red tape.


Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

More information about the OpenStack-operators mailing list