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 h
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 practica
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
cu
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
(https://wiki.openstac
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 Ma
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 s
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
On 20 March 2014 01:06, Mark McLoughlin 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 don't think Marc
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
benefici
bject: Re: [openstack-dev] [Marconi] Why is marconi a queue implementation vs
a provisioning API?
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 concern
dev@lists.openstack.org
Subject: Re: [openstack-dev] [Marconi] Why is marconi a queue implementation vs
a provisioning API?
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 licens
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 :
> 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
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 s
Cc:
"legal-disc...@lists.openstack.org<mailto:legal-disc...@lists.openstack.org>"
mailto:legal-disc...@lists.openstack.org>>
Subject: Re: [openstack-dev] [Marconi] Why is marconi a queue implementation vs
a provisioning API?
Its my understanding that the only case the A in the
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 betwee
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
> reviewin
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 con
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 bene
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. Marcon
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
wa
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
>
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
23 matches
Mail list logo
