[openstack-dev] [oslo][nova] Messaging: everything can talk to everything, and that is a bad thing

gordon chung gord at live.ca
Tue Mar 22 12:44:16 UTC 2016



On 21/03/2016 9:43 PM, Adam Young wrote:
> I had a good discussion with the Nova folks in IRC today.
>
> My goal was to understand what could talk to what, and the short
> according to dansmith
>
> " any node in nova land has to be able to talk to the queue for any
> other one for the most part: compute->compute, compute->conductor,
> conductor->compute, api->everything. There might be a few exceptions,
> but not worth it, IMHO, in the current architecture."
>
> Longer conversation is here:
>   http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2016-03-21.log.html#t2016-03-21T17:54:27
>
> Right now, the message queue is a nightmare.  All sorts of sensitive
> information flows over the message queue: Tokens (including admin) are
> the most obvious.  Every piece of audit data. All notifications and all
> control messages.
>
> Before we continue down the path of "anything can talk to anything" can
> we please map out what needs to talk to what, and why?  Many of the use
> cases seem to be based on something that should be kicked off by the
> conductor, such as "migrate, resize, live-migrate" and it sounds like
> there are plans to make that happen.
>

i think the community is split on "anything can talk to anything". this 
was a side topic[1] on another thread a few months ago regarding 
versioned notifications(FUN!).

i agree with you that we should map what talks with what and why. i 
personally think it would reduce load and security risk on queue since 
the messages and the content would be tailored to consumer rather than 
the current grab bag dump. the counter argument was that it's a lot less 
flexible and contrary to the purpose of pub/sub.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/080215.html

cheers,

-- 
gord



More information about the OpenStack-dev mailing list