Open Stack

Sorry for being late to to discussion.

First, +1 on the DRY principle. Whatever comes out of this, we should make
the same shared logic in oslo. 100% agree.

Second, It doesn't matter to me what the consensus on naming is MatchMaker
or ServiceGroup, but we should figure out the right APIs as the
abstraction. I spent some time looked at the MatchMaker code today. I'm
concerned that the way the code is written is very AMQP lingo specific.
Although the underlying stuff is essentially very similar, but I feel that
getting the right abstractions, including API semantics and naming is
important in this DRY effort. As the RPC/messaging work is moving away from
tightly coupled with AMQP, we should consider doing the same. I might be
very well biased since I spent more time on ServiceGroup, but I felt the
APIs are simpler without Exchange/Binding name complexity.

Thanks,
Yun



On Mon, Apr 22, 2013 at 2:28 PM, Eric Windisch <eric at cloudscaling.com>wrote:

> A summit discussion that didn't make the cut, but seems quite important,
> is that of redundant service inventory solutions.
>
> Presently, we have in OpenStack:
> * ServiceGroup,
> * MatchMaker,
> * OpenAttestation
> * Database (Cinder still does this - Quantum has introduced a NEW
> DB-backed solution)
>
> Problems with the database updates are obvious. The ServiceGroup is only
> in Nova, and OpenAttestation barely fits here at all, but isn't altogether
> unrelated, either.  The MatchMaker is presently in Oslo.rpc, has a static
> JSON file backend, as well as a Redis backend, and being pluggable by
> 3rd-parties.
>
> Clearly, we need to pursue DRY with these efforts.
>
> What I would like to see in Havana, is the creation of a ServiceGroup
> driver driven by the MatchMaker, or the outright removal of ServiceGroup.
> The addition of ServiceGroup's non-DB backends, and possibly the DB as
> well, into the MatchMaker.  Then, to seek the adoption of the MatchMaker by
> the Oslo.rpc.service module, Cinder, and Quantum.
>
> I do not intend to be so biased as only to say that my code, as the
> MatchMaker is, should be the winning solution here. However, whatever
> solution is chosen must be in Oslo, and at present, only the MatchMaker
> fits that requirement.  Additionally, since the MatchMaker is used
> internally by RPC, although not universally, and all present uses of
> ServiceGroup are really maintaining relationships that map to RPC
> relationships, there seems to be disadvantages to keeping these too far
> separated.
>
> Whatever the outcome of this thread might be, I want to seek an end to
> DB-only service inventories, and an end to having multiple implementations
> of the same service within OpenStack.
>
> Regards,
> Eric Windisch
>
>
>
> _______________________________________________
> 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/20130430/ddc01d92/attachment.html>