Still can't put multiple routing keys on the same exchange

[witchbutter]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.10.9
• Distribution: Ubuntu 16.04 and 14.04
• Module version: 8.0.0

How to reproduce (e.g Puppet code you use)

Any incidence where you would want multiple routing keys for a single exchange:

  rabbitmq_binding { 'Alert.Payload@Consumer.Payload.Alerts@/':
    user             => 'someuser',
    password         => $rabbit_password,
    destination_type => 'exchange',
    routing_key      => [ 'One', 'Two', 'Three'],
    arguments        => { },
  }

What are you seeing

Only the first routing key gets used, the others are ignored

What behaviour did you expect instead

Multiple routing keys on the same exchange. This module is useless to me without this detail.

Any additional information you'd like to impart

This has been an issue for over a year and it looks like it got ignored when voxpupuli took over and raised the major version:
https://tickets.puppetlabs.com/browse/MODULES-3679

[wyardley]

Hi @witchbutter
It is supported, and works for me, however, you need to use an arbitrary unique name with source / dest / vhost as separate params. See the example in the README:
https://github.com/voxpupuli/puppet-rabbitmq#rabbitmq_binding
There are additional examples in the acceptance tests.

If you're not getting a duplicate resource error, are you using Hiera, or declaring it resource-like? I think you should get a duplicate error if the latter.

[wyardley]

ps - #504 is the PR. While this enhancement did get added, Vox doesn't take over all of the existing tickets when a module migrates to us from Puppet Labs, so it is true that some issues in the Puppet ticket system may not get dealt with if a new issue isn't raised.

[witchbutter]

Ok it wasn't clear to me that was the intent in the README but it does work now that you pointed that out.

My only comment is for the config I am building I was already at 1000 lines without being able to have all the routing keys and now I will have another 30-50 resource declarations to get the remaining routing keys. I will definitely need to create a few defined resources to reduce the repetitive code where it would have been a lot simpler to be able to insert an array.

Thank you very much for the fast response.

[wyardley]

@witchbutter Yes, my first pass on this was actually to allow an array to be passed in for routing keys.
Unfortunately, there are some problems with doing it this way, as I realized after my first pass on fixing this problem. Not only are there cases where people need to allow same source / dest / vhost, but have other parameters besides the routing key which are different (I don't remember the exact details, since it's been a while, but I think there are some valid examples of this), but also, because RabbitMQ treats each binding as a separate resource, dealing with Puppet's idea of a "resource" becomes very muddled when the data treats the binding as one "resource" in Puppet, but there are actually multiple bindings. I did try to make it work, as this would have been a much easier way to do it for my use case, but with the way Puppet's types / providers work, it didn't seem like it could work.

There was another proposal to just specify it as source@destination@vhost@binding (or similar), but I think that's not really ideal to have all of those params encoded into the namevars.

You may be able to do some stuff in the Puppet language (or defining the bindings in hiera) to tighten it up a bit.

HTH