In response to Gil Yehuda's comments on MongoDB and the AGPL (here
http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html), I
understand the concern about the AGPL. But in this case it's completely,
absolutely unfounded. As mentioned earlier, MongoDB Inc. wants people to use
On Thu, 2014-03-20 at 01:28 +, Joshua Harlow wrote:
Proxying from yahoo's open source director (since he wasn't initially
subscribed to this list, afaik he now is) on his behalf.
From Gil Yehuda (Yahoo’s Open Source director).
I would urge you to avoid creating a dependency between
On Wed, 2014-03-19 at 12:37 -0700, Devananda van der Veen wrote:
Let me start by saying that I want there to be a constructive discussion
around all this. I've done my best to keep my tone as non-snarky as I could
while still clearly stating my concerns. I've also spent a few hours
reviewing
On 20/03/14 09:09 +, Mark McLoughlin wrote:
On Wed, 2014-03-19 at 12:37 -0700, Devananda van der Veen wrote:
Let me start by saying that I want there to be a constructive discussion
around all this. I've done my best to keep my tone as non-snarky as I could
while still clearly stating my
Let me start by saying that I want there to be a constructive discussion around
all this. I've done my best to keep my tone as non-snarky as I could while
still clearly stating my concerns. I've also spent a few hours reviewing the
current code and docs. Hopefully this contribution will be
Excerpts from Flavio Percoco's message of 2014-03-19 03:01:19 -0700:
FWIW, I think there's a value on having an sqlalchemy driver. It's
helpful for newcomers, it integrates perfectly with the gate and I
don't want to impose other folks what they should or shouldn't use in
production. Marconi
Hi,
Marconi manages its own sharding (doesn't rely on mongoDB's own sharding)
in order to have more control on where data is stored. Sharding is done
based on project_id + queue_id and stored in a catalog. Since Marconi
manages it's own shards, it can use the same logic with any storage. If it
Excerpts from Ozgur Akan's message of 2014-03-20 14:18:27 -0700:
Hi,
Marconi manages its own sharding (doesn't rely on mongoDB's own sharding)
in order to have more control on where data is stored. Sharding is done
based on project_id + queue_id and stored in a catalog. Since Marconi
Kurt Griffiths,
Thanks for detailed explanation. Is there a comparison between Marconi and
existing message brokers anywhere that you can point me out?
I can see how your examples can be implemented using other brokers like
RabbitMQ. So why there is a need another broker? And what is wrong with
Kurt already gave a quite detailed explanation of why Marconi, what
can you do with it and where it's standing. I'll reply in-line:
On 19/03/14 10:17 +1300, Robert Collins wrote:
So this came up briefly at the tripleo sprint, and since I can't seem
to find a /why/ document
Flavio Percoco wrote:
On 19/03/14 10:17 +1300, Robert Collins wrote:
My desires around Marconi are:
- to make sure the queue we have is suitable for use by OpenStack
itself: we have a very strong culture around consolidating technology
choices, and it would be extremely odd to have Marconi be
On Wed, 2014-03-19 at 10:17 +1300, Robert Collins wrote:
So this came up briefly at the tripleo sprint, and since I can't seem
to find a /why/ document
(https://wiki.openstack.org/wiki/Marconi/Incubation#Raised_Questions_.2B_Answers
and https://wiki.openstack.org/wiki/Marconi#Design don't
On 03/19/2014 07:49 AM, Thierry Carrez wrote:
Flavio Percoco wrote:
On 19/03/14 10:17 +1300, Robert Collins wrote:
My desires around Marconi are: - to make sure the queue we have
is suitable for use by OpenStack itself: we have a very strong
culture around consolidating technology choices,
On 20 March 2014 01:06, Mark McLoughlin mar...@redhat.com wrote:
I think we need a slight reset on this discussion. The way this email
was phrased gives a strong sense of Marconi is a dumb idea, it's going
to take a lot to persuade me otherwise.
Thanks Mark, thats a great point to make. I
Let me start by saying that I want there to be a constructive discussion
around all this. I've done my best to keep my tone as non-snarky as I could
while still clearly stating my concerns. I've also spent a few hours
reviewing the current code and docs. Hopefully this contribution will be
Can someone please give more detail into why MongoDB being AGPL is a problem?
The drivers that Marconi uses are Apache2 licensed, MongoDB is separated by the
network stack and MongoDB is not exposed to the Marconi users so I don't think
the 'A' part of the GPL really kicks in at all since the
Its my understanding that the only case the A in the AGPL would kick in is if
the cloud provider made a change to MongoDB and exposed the MongoDB instance to
users. Then the users would have to be able to download the changed code. Since
Marconi's in front, the user is Marconi, and wouldn't
On 03/19/2014 02:24 PM, Fox, Kevin M wrote:
Can someone please give more detail into why MongoDB being AGPL is a
problem? The drivers that Marconi uses are Apache2 licensed, MongoDB is
separated by the network stack and MongoDB is not exposed to the Marconi
users so I don't think the 'A' part of
2014-03-19 22:38 GMT+01:00 Fox, Kevin M kevin@pnnl.gov:
Its my understanding that the only case the A in the AGPL would kick in is
if the cloud provider made a change to MongoDB and exposed the MongoDB
instance to users. Then the users would have to be able to download the
changed code.
On Wed, Mar 19, 2014 at 12:37 PM, Devananda van der Veen
devananda@gmail.com wrote:
Let me start by saying that I want there to be a constructive discussion
around all this. I've done my best to keep my tone as non-snarky as I could
while still clearly stating my concerns. I've also spent
Proxying from yahoo's open source director (since he wasn't initially
subscribed to this list, afaik he now is) on his behalf.
From Gil Yehuda (Yahoo’s Open Source director).
I would urge you to avoid creating a dependency between Openstack code and any
AGPL project, including MongoDB. MongoDB
So this came up briefly at the tripleo sprint, and since I can't seem
to find a /why/ document
(https://wiki.openstack.org/wiki/Marconi/Incubation#Raised_Questions_.2B_Answers
and https://wiki.openstack.org/wiki/Marconi#Design don't supply this)
we decided at the TC meeting that I should raise it
I think we can agree that a data-plane API only makes sense if it is
useful to a large number of web and mobile developers deploying their apps
on OpenStack. Also, it only makes sense if it is cost-effective and
scalable for operators who wish to deploy such a service.
Marconi was born of
23 matches
Mail list logo
