<div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:13px">Devananda, </span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>While that is de rigueur today, it's actually at the core of the<br>current problem space. Blessing a project by integrating it is not a<br>scalable long-term solution. We don't have a model to integrate >1<br>project for the same space // of the same type, or to bless the<br>stability of a non-integrated project. You won't see two messaging<br>services, or two compute services, in the integrated release. In fact,<br>integration is supposed to occur only *after* the community has sorted<br>out "a winner" within a given space. In my view, it should also happen<br>only after the community has proven a project to be stable and<br>scalable in production.</blockquote><div><br></div><div>After looking at such profiles:</div><div><a href="http://boris-42.github.io/ngk.html">http://boris-42.github.io/ngk.html</a><br></div><div>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)</div><div><br></div><div>So I would like to say 2 things:</div><div><br></div><div>- Rules should be the same for all projects (including incubated/integrated) </div><div>- 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) </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 10, 2014 at 4:18 AM, Adam Lawson <span dir="ltr"><<a href="mailto:alawson@aqorn.com" target="_blank">alawson@aqorn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><i>"<span style="font-family:arial,sans-serif;font-size:12.7272720336914px">should OpenStack include, in the integrated release, a </span><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">messaging-as-a-service component</span>"</i><div><br></div></span><div>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.</div><div><br></div><div>Sorry if i sound cheeky but considering this seems rather odd to me.</div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><font><div style="font-family:arial;font-size:small"><b><i><br>Adam Lawson</i></b></div><div><font><font color="#666666" size="1"><div style="font-family:arial"><i>CEO, Principal Architect</i></div><div style="font-family:arial"><br></div><div style="font-family:arial;font-size:small">AQORN, Inc.</div><div style="font-family:arial;font-size:small">427 North Tatnall Street</div><div style="font-family:arial;font-size:small">Ste. 58461</div><div style="font-family:arial;font-size:small">Wilmington, Delaware 19801-2230</div><div style="font-family:arial;font-size:small">Toll-free: (844) 4-AQORN-NOW ext. 101</div><div style="font-family:arial;font-size:small">International: +1 302-387-4660</div></font><font color="#666666" size="1"><div style="font-family:arial;font-size:small">Direct: +1 916-246-2072</div></font></font></div></font></div><div style="font-family:arial;font-size:small"><img src="http://www.aqorn.com/images/logo.png" width="96" height="39"><br></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Tue, Sep 9, 2014 at 5:03 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Devananda van der Veen's message of 2014-09-09 16:47:27 -0700:<br>
<div><div>> On Tue, Sep 9, 2014 at 4:12 PM, Samuel Merritt <<a href="mailto:sam@swiftstack.com" target="_blank">sam@swiftstack.com</a>> wrote:<br>
> > On 9/9/14, 12:03 PM, Monty Taylor wrote:<br>
> [snip]<br>
> >> So which is it? Because it sounds like to me it's a thing that actually<br>
> >> does NOT need to diverge in technology in any way, but that I've been<br>
> >> told that it needs to diverge because it's delivering a different set of<br>
> >> features - and I'm pretty sure if it _is_ the thing that needs to<br>
> >> diverge in technology because of its feature set, then it's a thing I<br>
> >> don't think we should be implementing in python in OpenStack because it<br>
> >> already exists and it's called AMQP.<br>
> ><br>
> ><br>
> > Whether Zaqar is more like AMQP or more like email is a really strange<br>
> > metric to use for considering its inclusion.<br>
> ><br>
><br>
> I don't find this strange at all -- I had been judging the technical<br>
> merits of Zaqar (ex-Marconi) for the last ~18 months based on the<br>
> understanding that it aimed to provide Queueing-as-a-Service, and<br>
> found its delivery of that to be lacking on technical grounds. The<br>
> implementation did not meet my view of what a queue service should<br>
> provide; it is based on some serious antipatterns (storing a queue in<br>
> an RDBMS is probably the most obvious); and in fact, it isn't even<br>
> queue-like in the access patterns enabled by the REST API (random<br>
> access to a set != a queue). That was the basis for a large part of my<br>
> objections to the project over time, and a source of frustration for<br>
> me as the developers justified many of their positions rather than<br>
> accepted feedback and changed course during the incubation period. The<br>
> reason for this seems clear now...<br>
><br>
> As was pointed out in the TC meeting today, Zaqar is (was?) actually<br>
> aiming to provide Messaging-as-a-Service -- not queueing as a service!<br>
> This is another way of saying "it's more like email and less like<br>
> AMQP", which means my but-its-not-a-queue objection to the project's<br>
> graduation is irrelevant, and I need to rethink about all my previous<br>
> assessments of the project.<br>
<br>
</div></div>Well said.<br>
<div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>