Open Stack

If we limited Openstack projects to just one database, is that database (e.g. MySQL) going to be the best storage deployment for that job?  Or are there cases where other technologies such as Redis, MongoDB, Cassandra, CouchDB, etc make more sense?

Marconi has a pluggable storage driver model which allows these other storage drivers to be implemented (Redis is on the books).  The operator can then make their own informed choice on which backend makes the most sense for them based on their needs.

The alternative is that Openstack projects limit themselves to just one option (to reduce the deployment stack operators have to be concerned with – for example: only MySQL backends allowed), but may (likely) result in reduced performance/features/experience.  To me that would be an injustice to the users of that cloud.

How do back ends utilized relate to the amount/type/churn of data?  Is the blessed database ideal for that job or are there more scalable options? Im not saying you can’t scale MySQL, but db’s like Mongo/Cassandra/etc are better equipped for it (personal opinion).

I agree that investments in projects like Heat etc will reduce the burden on operators that deploy Openstack.


Amit Gandhi
Senior Manager, Rackspace.



From: Stan Lagun <slagun at mirantis.com<mailto:slagun at mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, March 20, 2014 at 2:23 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?

Kurt,

Your point is that NoSQL solution may be required for innovative project. And that is MongoDB. But what if come another amazing project that needs CouchDB, neo4j, Riak, (put your favorite NoSQL DB here)? It would be in the same position cause everyone would say hey, we already have NoSQL in OpenStack so you have to use MongoDB which is not fair. But is also obvious that OpenStack cannot demand cloud operators to maintain MySQL, MongoDB, CouchDB, neo4j etc in simultaneously

I hate to say that (I happen to be MongoDB fan) but the only way we can introduce external dependencies to OpenStack is by making technology that would make possible the project to be responsible for deployment and maintenance of that dependency (DBMS) rather then cloud operator. It seems to me that the right way to introduce MongoDB is to invest in projects like TripleO, Fuel, Murano, Heat and Ironic


On Thu, Mar 20, 2014 at 9:09 PM, Gil Yehuda <gyehuda at yahoo-inc.com<mailto:gyehuda at yahoo-inc.com>> wrote:
>To be clear, Marconi does not incorporate any AGPL code itself; pymongo is
Apache2 licensed.

Understood, but here's the rub. Someone else is going to want to build on this (which it the point of this open source project). Whereas 'pymongo' is Apache licensed, since the copyright holder, MongoDB Inc. declared it as such, the authors of the other community drivers (for other language bindings and features of MongoDB, etc.) are also of releasing drivers under the Apache or BSD licenses too (thinking that's OK to do since no one is telling them otherwise). That community is unaware of their legal obligations when creating drivers to an AGPL database. Thus if one of those community drivers gets intertwined in a court case clarifying their license to be infringing on the AGPL terms, we've inadvertently impacted our community. This is a credible risk that is difficult for OpenStack to abate, since the problem lies with the way a different community chose to operate.

There are three interconnected issues here:
1. The confusion that MongoDB has created in Open Source licensing due to the asymmetric control they have on licensing terms.
2. The diligence of Open Stack to remain careful with OpenStack's CLA compliance and Apache-friendly terms.
3. The pragmatics of the effect MondgoDB would have onto OpenStack's economic viability and legal risks at large.

The first problem is out of scope for this list. But I think people who rely upon Open Source for their business ought to understand what MongoDB is doing to open source software. The second is, to your point, the issue in this conversation. As long as Openstack only use Apache licensed code >>from MondgoDB Inc.<< and diligently avoids using any open source contributions from any community contributor to the MongoDB ecosystem, then you remain compliant the your CLA. But you will have to exclude the rest of the MongoDB community (which goes against the spirit of Open Source -- back to the problem #1, which is out of scope). As for #3, I think the foundation needs to weigh in on the pragmatics here, since this has an economic and legal impact to the entire endeavor, not just to persisting data in one component of the project.

Gil Yehuda
Sr. Director Of Open Source, Open Standards

-----Original Message-----
From: Kurt Griffiths [mailto:kurt.griffiths at rackspace.com<mailto:kurt.griffiths at rackspace.com>]
Sent: Thursday, March 20, 2014 9:29 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?

> The incorporation of AGPLv3 code Into OpenStack Project  is a
>significant decision



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Sincerely yours
Stanislav (Stan) Lagun
Senior Developer
Mirantis
35b/3, Vorontsovskaya St.
Moscow, Russia
Skype: stanlagun
www.mirantis.com<http://www.mirantis.com/>
slagun at mirantis.com<mailto:slagun at mirantis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140320/3ad97deb/attachment-0001.html>