<div dir="ltr"><div>Sorry for being late to to discussion.</div><div><br></div>First, +1 on the DRY principle. Whatever comes out of this, we should make the same shared logic in oslo. 100% agree.<div><br></div><div>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.<div>
<div><br></div><div>Thanks,</div><div>Yun<br></div><div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 22, 2013 at 2:28 PM, Eric Windisch <span dir="ltr"><<a href="mailto:eric@cloudscaling.com" target="_blank">eric@cloudscaling.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A summit discussion that didn't make the cut, but seems quite important, is that of redundant service inventory solutions.<br>

<br>
Presently, we have in OpenStack:<br>
* ServiceGroup,<br>
* MatchMaker,<br>
* OpenAttestation<br>
* Database (Cinder still does this - Quantum has introduced a NEW DB-backed solution)<br>
<br>
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.<br>

<br>
Clearly, we need to pursue DRY with these efforts.<br>
<br>
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.<br>

<br>
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.<br>

<br>
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.<br>
<br>
Regards,<br>
Eric Windisch<br>
<br>
<br>
<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>
</blockquote></div><br></div>