rpc-api-review: topic names can conflict across exchanges

Bug #1173552 reported by Mark McLoughlin on 2013-04-27
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
oslo.messaging
High
Unassigned

Bug Description

On the face of it, it looks like if each service chooses a different rpc_control_exchange then services should be able to topics using the same name

The most obvious example is that nova and cinder should both be able to have completely unrelated 'scheduler' topics but, in fact, cinder's scheduler topic is named 'cinder-scheduler'

One problem seems to be that AMQP exchange names are scoped to the virtual host, but we're not prefixing per-topic fanout exchanges with rpc_control_exchange:

in impl_kombu:

class FanoutConsumer(ConsumerBase):
     ...
    def __init__(self, ..., topic, ...):
        exchange_name = '%s_fanout' % topic
        queue_name = '%s_fanout_%s' % (topic, unique)
        ...
        exchange = kombu.entity.Exchange(name=exchange_name, type='fanout',

and impl_qpid:

class ConsumerBase(object):
     ...
    def __init__(self, session, callback, node_name, node_opts,
                 link_name, link_opts):
        ...
        self.address = "%s ; %s" % (node_name, jsonutils.dumps(addr_opts))

class FanoutConsumer(ConsumerBase):
    ...
    def __init__(self, ..., topic, ...):
        ...
        super(FanoutConsumer, self).__init__(
            session, callback,
            "%s_fanout" % topic,
            {...},
            "%s_fanout_%s" % (topic, uuid.uuid4().hex),
            {...})

the obvious fix here would seem to be to name the exchanges e.g. 'nova_scheduler_fanout' and 'cinder_scheduler_fanout'

The difficult part is to make this switch while retaining backwards compatibility - e.g. by adding a consumer for the new fanout topic format in Havana then in I (when we know all consumers support the new name) we switch the producers to the new name and then in J (when we know no producers are using the old name) remove the old name

We also need to check that all our queue names are unique across services, since those too are scoped at the virtual host level - it seems like we're fine there, because you can see in the code above that we include a random uuid in the queue name

Mark McLoughlin (markmc) on 2013-11-29
affects: oslo → oslo.messaging
Changed in oslo.messaging:
importance: High → Low
importance: Low → High
ChangBo Guo(gcb) (glongwave) wrote :

It's 4 years old, not sure we still have this issue.

Changed in oslo.messaging:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers