Open Stack

Devananda,



> While that is de rigueur today, it's actually at the core of the
> current problem space. Blessing a project by integrating it is not a
> scalable long-term solution. We don't have a model to integrate >1
> project for the same space // of the same type, or to bless the
> stability of a non-integrated project. You won't see two messaging
> services, or two compute services, in the integrated release. In fact,
> integration is supposed to occur only *after* the community has sorted
> out "a winner" within a given space. In my view, it should also happen
> only after the community has proven a project to be stable and
> scalable in production.


After looking at such profiles:
http://boris-42.github.io/ngk.html
And getting 150 DB requests (without neutron) to create one single VM, I
don't believe that set of current integrated OpenStack projects is scalable
well. (I mean without customization)

So I would like to say 2 things:

- Rules should be the same for all projects (including
incubated/integrated)
- Nothing should be incubated/integrated. Cause projects have to evolve, to
evolve they need competition. In other words, monopoly sux in any moment of
time (even after community decided to chose project A and not project B)


Best regards,
Boris Pavlovic



On Wed, Sep 10, 2014 at 4:18 AM, Adam Lawson <alawson at aqorn.com> wrote:

> *"should OpenStack include, in the integrated release,
> a messaging-as-a-service component"*
>
> Assuming this is truly a question that represents where we are and not
> exploratory of what we might want to address, I would say the answer is a
> resounding no, as queuing is within the scope of what Openstack is and has
> always been. If we get into integrated messaging, I'm struggling to
> understand what value it adds to the IaaS goal. We might as well start
> integrating office and productivity applications while we're at it.
>
> Sorry if i sound cheeky but considering this seems rather odd to me.
>
>
> *Adam Lawson*
> *CEO, Principal Architect*
>
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072
>
>
> On Tue, Sep 9, 2014 at 5:03 PM, Clint Byrum <clint at fewbar.com> wrote:
>
>> Excerpts from Devananda van der Veen's message of 2014-09-09 16:47:27
>> -0700:
>> > On Tue, Sep 9, 2014 at 4:12 PM, Samuel Merritt <sam at swiftstack.com>
>> wrote:
>> > > On 9/9/14, 12:03 PM, Monty Taylor wrote:
>> > [snip]
>> > >> So which is it? Because it sounds like to me it's a thing that
>> actually
>> > >> does NOT need to diverge in technology in any way, but that I've been
>> > >> told that it needs to diverge because it's delivering a different
>> set of
>> > >> features - and I'm pretty sure if it _is_ the thing that needs to
>> > >> diverge in technology because of its feature set, then it's a thing I
>> > >> don't think we should be implementing in python in OpenStack because
>> it
>> > >> already exists and it's called AMQP.
>> > >
>> > >
>> > > Whether Zaqar is more like AMQP or more like email is a really strange
>> > > metric to use for considering its inclusion.
>> > >
>> >
>> > I don't find this strange at all -- I had been judging the technical
>> > merits of Zaqar (ex-Marconi) for the last ~18 months based on the
>> > understanding that it aimed to provide Queueing-as-a-Service, and
>> > found its delivery of that to be lacking on technical grounds. The
>> > implementation did not meet my view of what a queue service should
>> > provide; it is based on some serious antipatterns (storing a queue in
>> > an RDBMS is probably the most obvious); and in fact, it isn't even
>> > queue-like in the access patterns enabled by the REST API (random
>> > access to a set != a queue). That was the basis for a large part of my
>> > objections to the project over time, and a source of frustration for
>> > me as the developers justified many of their positions rather than
>> > accepted feedback and changed course during the incubation period. The
>> > reason for this seems clear now...
>> >
>> > As was pointed out in the TC meeting today, Zaqar is (was?) actually
>> > aiming to provide Messaging-as-a-Service -- not queueing as a service!
>> > This is another way of saying "it's more like email and less like
>> > AMQP", which means my but-its-not-a-queue objection to the project's
>> > graduation is irrelevant, and I need to rethink about all my previous
>> > assessments of the project.
>>
>> Well said.
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140910/fec839ce/attachment-0001.html>