<div dir="ltr"><div>2014-09-05 9:09 GMT-03:00 Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span>:<br></div><div class="gmail_extra"><div class="gmail_quote"><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"><span class="">On 09/05/2014 07:39 AM, Robert Collins wrote:<br>
> On 5 September 2014 23:33, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
><br>
>> I think realistically a self certification process that would have<br>
>> artifacts in a discoverable place. I was thinking something along the<br>
>> lines of a baseball card interface with a short description of the<br>
>> project, a list of the requirements to deploy (native and python), a<br>
>> link the the API docs, a link to current test coverage, as well as some<br>
>> statement on the frequency of testing, stats on open bugs and current<br>
>> trending and review backlog, current user testimonials. Basically the<br>
>> kind of first stage analysis that a deployer would do before pushing<br>
>> this out to their users.<br>
><br>
> Add into that their deployment support - e.g. do they have TripleO<br>
> support // Chef // Fuel // Puppet etc etc etc.<br>
<br>
</span>ACK, good points. I expect packaging might go on that list as well.<br>
<br>
I won't pretend I've got the whole baseball card self cert thing worked<br>
out, just trying to sketch an idea that might bear fruit.<br>
<span class="im"><br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</span><div class=""><div class="h5">_______________________________________________<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></div></div></blockquote><div><br></div>Hi all,<div><br></div><div>Thanks for bringing up this topic Flavio and everyone for the feedback!</div><div><br></div><div>From my humble junior developer point of view I would like to share some comments about some of the concerns mentioned.</div><div><br></div><div>- Added complexity on adding Zaqar to the ecosystem and the NoSQL concern</div><div><br></div><div>I won't deny that adding Zaqar, if operators need it, will make OpenStack a little more harder to deploy. But this will happen with any extra project added.</div><div><br></div><div>Complexity is part of OpenStack though. We, as OpenStack, are trying to provide a software solution for a really complex need. And that is what makes us great.</div><div><br></div><div>IMO operators interested in using Zaqar will consider the pros and cons of adding it and will make their choice based on that.<br></div><div><br></div><div>And it's not about the tools we use. NoSQL was chosen to make the job for Zaqar because it was proven to do a better job. And, in the whole family of NoSQL solutions, we choose the ones that were considered easier to deploy.</div><div><br></div><div>It's a tecnology that has been in use for a long time now and it fits perfectly the requirements of Zaqar. In this regard, I think there is a long way to go and is something that Zaqar care about everyday. Zaqar will keep on researching for the best solutions for the users and working on adding support for them, as every other project does.</div><div><br></div><div>- Reinventing or not reinventing a messaging system</div><div><br></div><div>In the last couple of months I has been working on adding AMQP as a storage/transport backend for Zaqar. During that period I managed to learn a lot from other messaging systems, including the ones that has been discussed from now.</div><div><br></div><div>With that basis I can say that Zaqar is covering other, different, uses cases that the mentioned technologies are not meant to cover. And the best of all, it's being specialized for the cloud.</div><div><br></div><div>Most widely used cloud services already has they message and notification systems solution, and we should be up to the game with that. Right now it doesn't seems like that need is being filled.</div><div><br></div><div>- Integration as a sign of stability</div><div><br></div><div>Right now we are in a situation in which Zaqar is a mature project with many features to provide, but in order to keep on growing and getting better it needs to integrate with other projects and start showing what is capable of.</div><div><br></div><div>Zaqar is robust, well documented and with a team willing to keep on enhancing it.</div><div><br></div><div>It doesn't matter what places it takes on the stack, what is matter is that it's on the stack.</div><div><br></div><div>Hope this all makes sense and please correct me if I'm wrong. I want the best for both OpenStack and Zaqar, as you do.<br></div><div><br></div><div>All the best,</div><div><br></div><div>Victoria</div></div></div></div>