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 <alaw...@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 <cl...@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 <s...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
