<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-09-12 10:44 GMT-03:00 Gordon Sim <span dir="ltr"><<a href="mailto:gsim@redhat.com" target="_blank">gsim@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 09/11/2014 07:46 AM, Flavio Percoco wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
On 09/10/2014 03:18 PM, Gordon Sim wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
On 09/10/2014 09:58 AM, Flavio Percoco wrote:<br>
</span><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
     Other OpenStack components can integrate with Zaqar to surface events<br>
to end users and to communicate with guest agents that run in the<br>
"over-cloud" layer.<br>
</blockquote>
<br>
I may be misunderstanding the last sentence, but I think *direct*<br>
integration of other OpenStack services with Zaqar would be a bad idea.<br>
<br>
Wouldn't this be better done through olso.messaging's notifications in<br>
some way? and/or through some standard protocol (and there's more than<br>
one to choose from)?<br>
<br>
Communicating through a specific, fixed messaging system, with its own<br>
unique protocol is actually a step backwards in my opinion, especially<br>
for things that you want to keep as loosely coupled as possible. This is<br>
exactly why various standard protocols emerged.<br>
<br>
</span></blockquote><span>
<br>
Yes and no. The answer is yes most of the time but there are use cases,<br>
like the ones mentioned here[0], that make zaqar a good tool for the job.<br>
</span></blockquote>
<br>
I certainly wasn't saying that Zaqar is not a good tool. I was merely stating that - in my opinion - wiring it in as the only tool would be a mistake.<br></blockquote><div><br></div><div>Fair enough. Zaqar is just one of the possibilities and it's crafted to work with OpenStack. If users prefer to use a different tool, it's totally fine. I guess that operators will choose what it best fit their needs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[0] <a href="https://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases" target="_blank">https://etherpad.openstack.<u></u>org/p/zaqar-integrated-<u></u>projects-use-cases</a><br>
</blockquote>
<br>
Again, Zaqar might be great for those cases, but none of them describe features that are unique to Zaqar, so other solutions could also fit. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
All I'm saying is that if the channel between openstack services and users is configurable, that will give users more choice (as well as operators) and that - in my opinion - would be a good thing.</blockquote></div></div></div>