Open Stack

On Mar 20, 2014, at 5:52 AM, Sean Dague <sean at dague.net> wrote:

> On 03/20/2014 08:36 AM, Mark McLoughlin wrote:
>> On Thu, 2014-03-20 at 12:07 +0100, Thierry Carrez wrote:
>>> Monty Taylor wrote:
>>>> On 03/20/2014 01:30 AM, Radcliffe, Mark wrote:
>>>>> The problem with AGPL is that the scope is very uncertain and the
>>>>> determination of the  consequences are very fact intensive. I was the
>>>>> chair of the User Committee in developing the GPLv3 and I am therefor
>>>>> quite familiar with the legal issues.  The incorporation of AGPLv3
>>>>> code Into OpenStack Project  is a significant decision and should not
>>>>> be made without input from the Foundation. At a minimum, the
>>>>> inclusion of APLv3 code means that the OpenStack Project is no longer
>>>>> solely an Apache v2 licensed project because AGPLv3 code cannot be
>>>>> licensed under Apache v. 2 License.  Moreover, the inclusion of such
>>>>> code is inconsistent with the current CLA provisions.
>>>>> 
>>>>> This code can be included but it is an important decision that should
>>>>> be made carefully.
>>>> 
>>>> I agree - but in this case, I think that we're not talking about
>>>> including AGPL code in OpenStack as much as we are talking about using
>>>> an Apache2 driver that would talk to a server that is AGPL ... if the
>>>> deployer chooses to install the AGPL software. I don't think we're
>>>> suggesting that downloading or installing openstack itself would involve
>>>> downloading or installing AGPL code.
>>> 
>>> Yes, the issue here is more... a large number of people want to stay
>>> away from AGPL. Should the TC consider adding to the OpenStack
>>> integrated release a component that requires AGPL software to be
>>> installed alongside it ? It's not really a legal issue (hence me
>>> stopping the legal-issues cross-posting).
>> 
>> We need to understand the reasons "people want to stay away from the
>> AGPL". Those reasons appear to be legal reasons, and not necessarily
>> well founded. I think legal-discuss can help tease those out.
>> 
>> I don't (yet) accept that there's a reasonable enough concern for the
>> OpenStack project to pander to.
>> 
>> I'm no fan of the AGPL, but we need to be able to articulate any policy
>> decision we make here beyond "some people don't like the AGPL".
>> 
>> For example, if we felt the AGPL fears weren't particularly well founded
>> then we could make a policy decision that projects should have an
>> abstraction that would allow those with AGPL fears add support for
>> another technology ... but that the project wouldn't be required to do
>> so itself before graduating.
>> 
>>> This was identified early on as a concern with Marconi and the SQLA
>>> support was added to counter that concern. The question then becomes,
>>> how usable this SQLA option actually is ? If it's sluggish, unusable in
>>> production or if it doesn't fully support the proposed Marconi API, then
>>> I think we still have that concern.
>> 
>> I understood that a future Redis driver was what the Marconi team had in
>> mind to address this concern and the SQLA driver wasn't intended for
>> production use.
> 
> This is a little problematic from a deployer requirement perspective.
> Today we say to all deployers: To run all of OpenStack:
> 
> * You will need to run and maintain a relational database environment
> (and probably cluster it for scale / availability)
> * You will need to run and maintain a queue system (rabbit, qpid, zmq)
> * You will need to run and maintain a web server (apache)

(Don’t forget load balancers and/or proxies)

> 
> Deciding to integrate something to OpenStack that requires a base piece
> of software that is outside of that list is a pretty big deal.
> 
> Forget license for a moment, just specifying that you have to run and
> maintain and monitor a nosql environment in addition to a RDBMS is
> definitely adding substantial burden to OpenStack deployers.

This is an excellent point that I want to emphasize. Maintaining these things
in production is non-trivial; it is the burden of maintenance that has
prevented some of us from integrating Mongo. It is especially troublesome that
there are not options on the noSQL side. If you are already running redis
or cassandra or couch or riak in production, you have to install mongo as well.
Maintaining a noSQL db is a problem, but maintaining a SPECIFIC noSQL db with
no option to replace it with another makes the problem worse.

Vish 
> 
> Big public cloud shops, that's probably fine for them. However OpenStack
> as a site level deploy ? Having to add expertise in nosql engine
> lifecycle management is a real cost. And we better be explicit about it
> from a project wide stance if that's what we're saying.
> 
> 	-Sean
> 
> -- 
> Sean Dague
> Samsung Research America
> sean at dague.net / sean.dague at samsung.com
> http://dague.net
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140320/58af7b74/attachment.pgp>