Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for arbitrary config sections #442

Open
acranox opened this issue May 11, 2017 · 9 comments
Open

Support for arbitrary config sections #442

acranox opened this issue May 11, 2017 · 9 comments
Milestone

Comments

@acranox
Copy link

acranox commented May 11, 2017

prior to 4.11.0 i was able to add a an item to node['rabbitmq']['conf'], for setting custom rabbitmq_management config options, but with this change:
https://github.com/rabbitmq/chef-cookbook/blob/master/templates/default/rabbitmq.config.erb#L21-L26
any arbitrary configs won't be honored, because you end up with two rabbitmq_management [] blocks, which don't seem to get merged, so it doesn't work.

A more flexible way to define the configuration options would be awesome.

@michaelklishin
Copy link
Member

@acranox feel free to submit a PR that adds support for more options

@acranox
Copy link
Author

acranox commented May 11, 2017

Fair enough.

I'm really suggesting a complete rewrite for arbitrary and flexible configuration implementation.
ie: the difference between these two templates:
https://github.com/openstack/cookbook-openstack-compute/blob/liberty-eol/templates/default/nova.conf.erb
https://github.com/openstack/cookbook-openstack-compute/blob/stable/mitaka/templates/default/nova.conf.erb

The way the template is today doesn't allow setting any options for the rabbitmq_management plugin.

@michaelklishin
Copy link
Member

@acranox there was a fair number of breaking changes in this cookbook recently. I'm not a fan of "let's rewrite everything" but adding more properties is a backwards-compatible and easy way out. Except for perhaps TLS listener options and sample retention policies, all other properties are trivial to cover that way.

@michaelklishin
Copy link
Member

That said, free form (text) sections are not mutually exclusive with what I'm suggesting above and I am not against that approach in general.

@dragonsmith
Copy link
Contributor

Hello @michaelklishin @acranox

Please, let me revive this thread a bit. I've started to use this cookbook recently. And I stumbled on a similar problem as @acranox . If I understand the previous messages right, small non-breaking changes to improve the situation are welcome. So I've created the pull request to enable ip address selection for management console: #464

Please, can you review it and tell me your thoughts? It would be great if we can fix at least this part.

Thank you very much!

@michaelklishin
Copy link
Member

I suggest that we wait for RabbitMQ 3.7 and switch to the new config format instead. It is significantly easier to generate and adding arbitrary config lines will also be possible, which should side step most of such issues entirely.

@acranox @dragonsmith how does that sound?

@dragonsmith
Copy link
Contributor

@michaelklishin

That sounds reasonable. If I'll have/see an opportunity to help you I'll come back to open a new discussion. Thank you very much!!!

@majormoses
Copy link
Contributor

majormoses commented Dec 8, 2017

I'm excited to use the new config format! Even discounting custom config which I ended up eventually just specifying my own template, writing serverspec tests to validate config with the old format was less than pleasant with long ugly regexes.

@michaelklishin michaelklishin changed the title unable to set custom rabbitmq_management config options Support for arbitrary config sections Feb 14, 2018
@michaelklishin
Copy link
Member

So there already are arbitrary config sections but I can imagine they are not very easy to use, so this can be closed when we make it trivial to hook up a bunch of arbitrary lines from the new format in 6.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants