As a follow up to https://review.openstack.org/#/c/194399/ and the meeting discussion earlier today, I’ve determined that everybody (RDU, Ubuntu, Debian) is packaging oslo.messaging 1.8.2 or 1.8.3 with the Kilo build. (This is also the version we get on our internal Anvil-based build.) This is considerably lower than 1.11.0 where the default rabbit_heartbeat_timeout_threshold changes (from 60 to 0.)
If we go forward using the default rabbit_heartbeat_timeout_threshold value of 60, that will be the correct default behavior up through oslo.messaging 1.10.x. When people upgrade to 1.11.0 or higher, we’ll no longer match the upstream default behavior. But, it should maintain the _actual_ behavior (heartbeating enabled) for people doing an upgrade. Once Liberty is cut, we should reevaluate to make sure we’re matching whatever the default is at that time. However, the larger problem I see is that oslo.messaging requirements.txt in <=1.10.x does not enforce the needed versions of kombu and amqp for heartbeat to work: https://github.com/openstack/oslo.messaging/blob/1.8.2/requirements.txt#L25-L26 This is confusing as heartbeat is enabled by default! I am not sure what the behavior is when heartbeat is enabled with older kombu or amqp. Does anyone know? If it silently fails, maybe we don’t care. But if enabling heartbeat (by default, rabbit_heartbeat_timeout_threshold=60) actively breaks, that would be bad. I see two options here: 1) Make default rabbit_heartbeat_timeout_threshold=60 in the Puppet modules, to strictly follow the upstream default in Kilo. Reevaluate this default value for Liberty. Ignore the kombu/amqp library stuff and hope “it just works itself out naturally.” 2) Add a rabbit_enable_heartbeat parameter to explicitly enable/disable the feature, and default to disable. This goes against the current default behavior, but will match it for oslo.messaging >=1.11.0. I think this is the safest path, as we won’t be automatically enabling heartbeat for people who don’t have a new enough kombu or amqp. Personally, I like #1, because I am going to enable this feature, anyway. And I can’t really imagine why one would _not_ want to enable it. But I am fine implementing it either way, I just want to get it done so I can get off my local forks. :) Thoughts? Mike
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
