[openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?

Sean Dague sean at dague.net
Thu Mar 20 16:38:28 UTC 2014

On 03/20/2014 12:29 PM, Kurt Griffiths wrote:
>> The incorporation of AGPLv3 code Into OpenStack Project  is a
>> significant decision
> To be clear, Marconi does not incorporate any AGPL code itself; pymongo is
> Apache2 licensed.
> Concerns over AGPL were raised when Marconi was incubated, and I totally
> respect that some folks are not comfortable with deploying something like
> MongoDB that is AGPL-licensed. Those discussions precipitated the work we
> have been doing on SQLAlchemy and Redis drivers. In fact, the sqla driver
> was one of the graduation requirements put in place but the TC. Now, if
> people want to use something else than what the Marconi team is already
> working on, we are more than happy to have them contribute and help us
> evolve the driver interface as needed.
> On the subject of minimizing the number of different backends that
> operators need to manage, some relief may be found by making the backends
> for projects more customizable. For example, as we move more projects to
> using the oslo caching library, that will give operators an opportunity to
> migrate from memcached to, say, Redis. And if OpenStack Service X
> (Marconi, for example) supports Redis as a backing store, now the operator
> can reuse their Redis infrastructure and know-how.

Yep, that's definitely goodness.

> The software industry has been moving towards hybrid NoSQL+SQL
> architectures for a long time now, in order to create best-fit solutions;
> I think we’ll see more OpenStack projects following this model in the
> future, not less, and so we need to work out a happy path for supporting
> these kinds of operating environments.

Absolutely, but lets at least be deliberate about it. Also, the burden,
and thus concern, would go way down if the service actually used heat
and/or nova to deploy it's backend as well. Like Savana and Trove do. It
seems like we've got all this infrastructure in OpenStack already to
deploy and manage things on computes programatically. It would be nice
to reuse that for application centric services.


Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140320/3f49bdca/attachment.pgp>

More information about the OpenStack-dev mailing list