Change existing binding doesn't seem to work!

[AnnieTheEagle]

Whenever I try to change an existing binding, that was in the .pp file before, it seems to write to the notice log that it has changed the binding, but it hasn't actually.

Example:

• Old config -

  rabbitmq_binding { "Important alerts ${virtual_host}" :
    ensure           => present,
    source           => 'log_messages',
    destination      => 'alerter_service',                
    vhost            => $virtual_host,
    user             => $admin_username,
    password         => $admin_password,                  
    destination_type => 'queue',
    routing_key      => '',
    arguments        => {                                 
      'x-match'   => 'all',
      'log_level' => 'error',
    }
  }

• New Config -

  rabbitmq_binding { "Important alerts ${virtual_host}" :
    ensure           => present,
    source           => 'log_messages',
    destination      => 'alerter_service',                
    vhost            => $virtual_host,
    user             => $admin_username,
    password         => $admin_password,                  
    destination_type => 'queue',
    routing_key      => '',
    arguments        => {                                 
      'x-match'  => 'all',
      'loglevel' => 'warn',
    }
  }

Notice there is a change to the "log_level" argument (both the key and the value have changed).

When running this change we get:

Notice: Notice: /Stage[main]/Logs_rabbitmq::Messaging/Logs_rabbitmq::Messaging::Environment[dev]/Rabbitmq_binding[Important alerts dev]/arguments: arguments changed {'log_level' => 'error', 'x-match' => 'all'} to '{"x-match"=>"all", "loglevel"=>"warn"}'

But nothing actually changes...

[wyardley]

Is this with the latest version of the module?

[AnnieTheEagle]

@wyardley Hi, yes. I am using module version 8.4.0 and RabbitMQ version 3.7.7

[wyardley]

@AnnieTheEagle thanks. I probably won't be able to investigate this anytime soon, though if you can print the debug output, and the (sanitized) commands that Puppet is calling around that message, that might help see what's going on somewhat? Taking a quick look through the type / provider, I'm not totally sure how it's even updating existing binding resources at all.

Another thing that might help if you can throw it up would be a self-contained example that can reproduce this problem. I most likely won't be able to investigate this, but if you or someone throws up a PR, I'm happy to help review.

[AnnieTheEagle]

@wyardley I think I've at least worked out why it doesn't work. It seems that there is a field required (when using rabbitmqadmin or the API called 'properties_key', which is a string built up of: routing_key + "~" + args_hash, this args_hash is created using some mysterious way, embedded deep in the erlang source (calls phash2/2).

This phash2/2 is an erlang specific function that creates a hash of an object but this code is not portable. I think therefore the only way you'd get it to work is if you have a way of finding out which binding has the old arguments and then find the properties_key on that object and use that.

I don't think it's currently updating existing bindings at all. It's strange that it's logging it to the console, but even if you did create a simple update function in the provider that did destroy old, create new, you'd have to find a way to work out which properties_key to destroy, as it is a required argument of rabbitmqadmin delete_binding