Re: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Le 2015-07-01 15:21, Mike Dorman a écrit : As a follow up to the discussion during the IRC meeting yesterday, please vote for one of these approaches: 1) Make the default for the rabbit_heartbeat_timeout_threshold parameter 60, which matches the default in Kilo oslo.messaging. This will by default enable the RMQ heartbeat feature, which also matches the default in Kilo oslo.messaging. Operators will need to set this parameter to 0 in order to disable the feature, which will be documented in the comments within the manifest. We will reevaluate the default value for the Liberty release, since the oslo.messaging default most likely will change to 0 for that release. Just a small correction: For kilo release, this is 0 not 60 per default since oslo.messaging 1.8.3, because some operators have reported critical issues with heartbeat enabled and some versions of py-amqp and kombu, and because we can't raise anymore the requirements for kilo we have disable it by default. For liberty, we have raise the requirements and we perhaps re-enable heartbeat, if nobody report new issue. Cheers, - --- Mehdi Abaakouk mail: sil...@sileht.net irc: sileht -BEGIN PGP SIGNATURE- Version: OpenPGP.js v.1.20131017 Comment: http://openpgpjs.org wsFcBAEBCAAQBQJVm8SRCRAYkrQvzqrryAAAnaEQAIMVd6FdW593wi87SFlv zP/Jc+bNyivQPynE/o4smgm5feuBqCou/8Zig7p1Ac5wpMGtsmK+wYKkdC03 nQaeSZ7hqlu2EZb2+xdB0sRBm2CZZHNcYIG/NF7E6dYHNfksrT6qeOUM3HBi JLVxBonF1Ch7zFaNhprrd0S9t/0vnXQlvDp+9Co0j5I0MV4hczkpFsQlPcr/ +sphCn65c+GeVkpGuxqYYsOvwvhqi8Xcm414OI5xLVb2N/iR5R1jg3Z4OT0a qhm6Tj6v4tOjAkyFVF4gDI9IxXMUG19IaKzwdAON1czFOgaqPlgWa0dc6dqW BqurTvolBtcr8VUqs0l96/+Wr18u/7ctQtarwYhRMau8GbwYRod2fcV/8vFB wX/gdMHz3hc/bpYTTKX6CqBfn1QInNuNP1nDH8kpcUOMDMPjhL2SvPDVeKRH 15lq6cBO0vRUwZZVjCc8B3OWum4kIC84ji04drzxYq/Ha2SBM9HAjtOg+1rJ s53IPegUT+L8F/9SsLkmX4uRfEu4eGn2rVL3jrss9R3Wy50/3j4MM44nDVDN TH6gAf4/DFdjrwDNuAnMv4FNSNl7mE/enYOtTpQy1Wnj70qwmDluTf9sA9RB fpjf+cctCy6HEUzeSc8lVZmyswh2fipMKf3j6Z0oX2G33JFDKyIiGG1sHbqn i8M/ =RJtG -END PGP SIGNATURE- __ 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
Re: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support
On 07/01/2015 09:21 AM, Mike Dorman wrote: As a follow up to the discussion during the IRC meeting yesterday, please vote for one of these approaches: 1) Make the default for the rabbit_heartbeat_timeout_threshold parameter 60, which matches the default in Kilo oslo.messaging. This will by default enable the RMQ heartbeat feature, which also matches the default in Kilo oslo.messaging. Operators will need to set this parameter to 0 in order to disable the feature, which will be documented in the comments within the manifest. We will reevaluate the default value for the Liberty release, since the oslo.messaging default most likely will change to 0 for that release. +1 for #1 2) In addition to #1 above, also add a rabbit_enable_heartbeat parameter, which will default to false. Setting that to true will be needed to explicitly enable the RMQ heartbeat feature, regardless of the value of rabbit_heartbeat_timeout_threshold. By default the RMQ heartbeat feature will be disabled, which may be a marginally safer approach (due to the requirements.txt stuff, see below), but will not match the upstream Kilo oslo.messaging default. This will also turn off the feature for people who have already been “getting it for free” if they do nothing and don’t update their composition module. My vote is for #1. Let’s plan to close the voting by next week’s IRC meeting, so we can come to a final conclusion at that time. Thanks, Mike From: Mike Dorman Reply-To: OpenStack Development Mailing List (not for usage questions) Date: Tuesday, June 23, 2015 at 5:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support 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 -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support
As a follow up to the discussion during the IRC meeting yesterday, please vote for one of these approaches: 1) Make the default for the rabbit_heartbeat_timeout_threshold parameter 60, which matches the default in Kilo oslo.messaging. This will by default enable the RMQ heartbeat feature, which also matches the default in Kilo oslo.messaging. Operators will need to set this parameter to 0 in order to disable the feature, which will be documented in the comments within the manifest. We will reevaluate the default value for the Liberty release, since the oslo.messaging default most likely will change to 0 for that release. 2) In addition to #1 above, also add a rabbit_enable_heartbeat parameter, which will default to false. Setting that to true will be needed to explicitly enable the RMQ heartbeat feature, regardless of the value of rabbit_heartbeat_timeout_threshold. By default the RMQ heartbeat feature will be disabled, which may be a marginally safer approach (due to the requirements.txt stuff, see below), but will not match the upstream Kilo oslo.messaging default. This will also turn off the feature for people who have already been “getting it for free” if they do nothing and don’t update their composition module. My vote is for #1. Let’s plan to close the voting by next week’s IRC meeting, so we can come to a final conclusion at that time. Thanks, Mike From: Mike Dorman Reply-To: OpenStack Development Mailing List (not for usage questions) Date: Tuesday, June 23, 2015 at 5:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support 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
Re: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support
On 06/23/2015 06:07 PM, Mike Dorman wrote: 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.� +1 We should follow: * what popular distros ship * what we test in our CI (trusty UCA centos7 RDO) 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 -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ 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
[openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support
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
