> I've spent some time trying to eliminate the number of deprecation warnings > we have in preparation for our upgrade to Kilo. One of the ones that I got > stuck on is the nova::rabbitmq::rabbitmq_class parameter. > > If this parameter is specified, and it is by default, then the class will > include the rabbitmq class given by name, but it also the sets up useful > dependencies between nova and RabbitMQ. For example, it will ensure that > RabbitMQ is running before nova is started. > > It seems to me that this needs to be split into two sets of functionality.
If you specify rabbitmq_class=>false [0], the puppet-nova module will only create required RabbitMQ entities, like user and vhost, but will not install and configure the RabbitMQ. This is expected and desired behavior for the Nova and other puppet modules for OpenStack, AFAIK. What would be pros, if the split introduced? I can see only cons: increased complexity in the settings of parameters. > > *rabbitmq_class* > * Not deprecated > * if provided then it will be used to set up dependencies. > * Defaults to rabbitmq. > * This should perhaps just be hard coded to be rabbitmq now. > > *manage_rabbitmq* > * Deprecated > * If specified, configures and sets up rabbitmq, including the class. > * Defaults to ??? > > Thoughts? [0] https://github.com/stackforge/puppet-nova/blob/master/manifests/rabbitmq.pp#L32-L38 -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com Irc #bogdando __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
