[rabbitmq-discuss] federation Issues
KGanann at kroll.com
Fri Jun 27 15:10:51 BST 2014
To your first question:
In production, federation links (specifically, x-federation-upstream under exchnages) show as: vHost | federation: e.fed.topic -> sharedfederationid:fed:e.fed.topic B, for example. The sharedfederationid is used in the old parameters section as an explicit identity for a local user, hence, a user token. I believe below you're calling this local_username, sorry for the confusion. The dynamically created queues look much the same.
Now in dev, where we did the upgrade, a similar link would show as: vHost | federation: e.fed.topic -> ClusterName:fed:e.fed.topic B. From what you're saying below, this is due to the change in the authentication manner - the local_username no longer need be applied. There were some artifacts of the old federation style links, and when we've had fed problems in the past, they were resolved by deleting the x-federation-upstreams in fed and the affected vHost, as well as the related queues. On deleting the dynamic queues, they would recreate and recreate the x-federation-upstreams, and everything would work. That isn't happening this time. If I publish to the e.fed.topic exchange in one vHost, it should publish to the queues in other vHosts that are bound to e.fed.topic with the same routing key, but right now the messages are vanishing - I'm having no luck tracing them.
All link statuses are Running. Fed has an upstream to each vHost, and each vHost has an upstream to fed.
If I change the cluster name, will I have to delete all the dynamic streams again to get them to use the new name?
From: Simon MacMullen [mailto:simon at rabbitmq.com]
Sent: Friday, June 27, 2014 6:11 AM
To: Legacy list about RabbitMQ; Ganann, Kale
Subject: Re: [rabbitmq-discuss] federation Issues
On 27/06/14 00:27, Ganann, Kale wrote:
> We just upgraded from 3.2.1 to 3.3.4 and federation died on us.
> Looking at the cluster, it appears some... overenthusiastic dev
> renamed the cluster
That should not be a problem.
From 3.2.x to 3.3.x we changed from having the federation plugin give the cluster a name through the local_nodename parameter, to having a broker-wide cluster name that can be used by the federation plugin.
But the cluster name doesn't matter that much. It's used to name the queues which federation uses internally, and it shows up in transmitted bindings and messages so the plugin (and sysadmins) know where message have been. But it's not something you should have to get "correct" for things to work - there's no correct value.
> and now when federation creates new linkages, it creates them as
> clustername:vHost:queue, rather than usertoken:vHost:queue.
I really do not understand any of this.
What do you mean by "linkages"? Bindings? Federation links (as shown in the status)? Something else?
Also, what do you mean by usertoken?
> Also, on
> the federation upstreams, the parameter field seems to have vanished,
> so I can't update the user tokens for specific vHosts.
I guess you are saying something about the local_username or local_nodename fields here? local_username is gone, there is no need to configure it at all any more. local_nodename is replaced by the cluster name.
> I've been going
> through the patch notes - is this intentional, or is something else
> going on?
The removal of local_username and local_nodename was intentional.
> And can I just remove the cluster name?
Clusters always have a name.
> I've tried deleting
> the old dynamically created fed stuff so that it gets recreated, but
> the new stuff just doesn't seem to work. Any help is appreciated.
What does the link status look like?
This communication contains information that is confidential,
proprietary in nature, and may also be attorney-client privileged
and/or work product privileged. It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s) or
the person responsible for delivering it to the intended
recipient(s), please note that any form of dissemination,
distribution or copying of this communication is strictly
prohibited and may be unlawful. If you have received this
communication in error, please immediately notify the sender by replying
to this message and delete this email immediately. Thank you for your cooperation.
Please be advised that neither Altegrity, its affiliates, its employees
or agents accept liability for any errors, omissions or damages
caused by delays of receipt or by any virus infection in this
message or its attachments, or which may otherwise arise as a
result of this e-mail transmission.
More information about the rabbitmq-discuss