[openstack-dev] [Zaqar] Zaqar graduation (round 2) [was: Comments on the concerns arose during the TC meeting]

Victoria Martínez de la Cruz victoria at vmartinezdelacruz.com
Fri Sep 12 14:51:26 UTC 2014


2014-09-12 10:44 GMT-03:00 Gordon Sim <gsim at redhat.com>:

> On 09/11/2014 07:46 AM, Flavio Percoco wrote:
>
>> On 09/10/2014 03:18 PM, Gordon Sim wrote:
>>
>>> On 09/10/2014 09:58 AM, Flavio Percoco wrote:
>>>
>>>>      Other OpenStack components can integrate with Zaqar to surface
>>>> events
>>>> to end users and to communicate with guest agents that run in the
>>>> "over-cloud" layer.
>>>>
>>>
>>> I may be misunderstanding the last sentence, but I think *direct*
>>> integration of other OpenStack services with Zaqar would be a bad idea.
>>>
>>> Wouldn't this be better done through olso.messaging's notifications in
>>> some way? and/or through some standard protocol (and there's more than
>>> one to choose from)?
>>>
>>> Communicating through a specific, fixed messaging system, with its own
>>> unique protocol is actually a step backwards in my opinion, especially
>>> for things that you want to keep as loosely coupled as possible. This is
>>> exactly why various standard protocols emerged.
>>>
>>>
>> Yes and no. The answer is yes most of the time but there are use cases,
>> like the ones mentioned here[0], that make zaqar a good tool for the job.
>>
>
> 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.
>

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.


>
>  [0] https://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases
>>
>
> 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.


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140912/2fd1886a/attachment.html>


More information about the OpenStack-dev mailing list