config_additional_variables format incorrect when nested config defined

[jimmybigcommerce]

Not sure if this is a bug or a feature request, however if an array of values is passed into rabbitmq::config_additional_variables, the config that is generated is invalid.

Example:

Providing this config:

# hiera
rabbitmq::config_additional_variables:
  ra: 
    wal_max_size_bytes: 128000000
    segment_max_entries: 65535

The generated config stanza is:

  {ra, {"wal_max_size_bytes"=>128000000, "segment_max_entries"=>65535}}

however it should be:

{ra, [{segment_max_entries, 65535},{wal_max_size_bytes, 128000000}]}

[wyardley]

What if you mirror the structure of the config that should be generated (i.e., pass two maps as the first and second elements of an array) — does that work as expected?

I guess the behavior I’d expect is that the input structure for additional variables would be followed / modeled in the config, though without looking more deeply, I’m not sure if that’s how the module behaves now.

[jimmybigcommerce]

Do you mean like this?

rabbitmq::config_additional_variables:
  ra:
    - segment_max_entries: 65535
    - wal_max_size_bytes: 134217728

Generated this:

{ra, [{"segment_max_entries"=>65535}, {"wal_max_size_bytes"=>134217728}]}

Which is slightly closer, but still has => instead of commas.

The only thing that works is just putting the complete string the in the key (which is fine, but not perfect):

rabbitmq::config_additional_variables:
  ra: '[{segment_max_entries, 65535},{wal_max_size_bytes, 134217728}]'

[wyardley]

Hrm. Yeah, then probably the right fix is to add proper support for these variables, though sounds like there’s a workaround that will do it in the short term.

[wyardley]

It might also be possible to make the template support nested data structures better, but I’m not sure if this would be a good idea or not.