Open Stack

2014-09-05 9:09 GMT-03:00 Sean Dague <sean at dague.net>:

> On 09/05/2014 07:39 AM, Robert Collins wrote:
> > On 5 September 2014 23:33, Sean Dague <sean at dague.net> wrote:
> >
> >> I think realistically a self certification process that would have
> >> artifacts in a discoverable place. I was thinking something along the
> >> lines of a baseball card interface with a short description of the
> >> project, a list of the requirements to deploy (native and python), a
> >> link the the API docs, a link to current test coverage, as well as some
> >> statement on the frequency of testing, stats on open bugs and current
> >> trending and review backlog, current user testimonials. Basically the
> >> kind of first stage analysis that a deployer would do before pushing
> >> this out to their users.
> >
> > Add into that their deployment support - e.g. do they have TripleO
> > support // Chef // Fuel // Puppet etc etc etc.
>
> ACK, good points. I expect packaging might go on that list as well.
>
> I won't pretend I've got the whole baseball card self cert thing worked
> out, just trying to sketch an idea that might bear fruit.
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Hi all,

Thanks for bringing up this topic Flavio and everyone for the feedback!

>From my humble junior developer point of view I would like to share some
comments about some of the concerns mentioned.

- Added complexity on adding Zaqar to the ecosystem and the NoSQL concern

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.

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.

IMO operators interested in using Zaqar will consider the pros and cons of
adding it and will make their choice based on that.

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.

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.

- Reinventing or not reinventing a messaging system

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.

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.

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.

- Integration as a sign of stability

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.

Zaqar is robust, well documented and with a team willing to keep on
enhancing it.

It doesn't matter what places it takes on the stack, what is matter is that
it's on the stack.

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.

All the best,

Victoria
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140905/dc485f38/attachment.html>