I think that only in exceptional cases should we allow changing of default configuration variables. This may break existing setups. I am not in favor of this back port. On 8/19/14, 11:56 AM, "Ihar Hrachyshka" <ihrachys@redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 19/08/14 10:47, Assaf Muller wrote:
----- Original Message ----- Hi all,
we have a Neutron backport proposed in stable/havana that is in grey area in terms of applicability for stable branches. Located at [1].
The controversy is that it changes the default value of a configuration setting, which is generally considered as a no-go for backports. That said, it has additional aspects that may trigger the exception.
Basically, the default value of the setting breaks all L3 agents we have in our tree. The failure state is an unstoppable agent resync due to incorrect gateway outside of subnet. To avoid the failure for any L3 agent that we ship, users need to change the value of that setting from default one.
It's also not clear what's the value of having a gateway outside the current subnet. As of Juno, this 'feature' is obsolete and marked to be removed in Kilo.
There is a change though that there are some third-party agents in the wild that support that 'feature'; in that case, changing the default value will affect them. Though we don't know whether they really exist. All in all, the 'feature' won't be available for them since Kilo, and there is no sign that its removal is controversial, so probably no one is interested in it anyway.
So we have a dilemma: we may break the official stable rule of 'not introducing inconmpatible configuration changes' and in that way fix major failure scenario in Neutron; or we may leave everything as-is (=our own agents broken) to stick to the rule.
My common sense tells me that we should fix our agents first, and then think about potential third-party L3 agents that possibly rely on that 'feature' being enabled by default. Hence my +2 vote.
But your common sense may vary, so I'd like to hear from others on the matter.
[1]: https://review.openstack.org/#/c/113129/
Some more context: Vishal has a patch on master, currently in review: https://review.openstack.org/#/c/114185/
Which fixes the issue for the L3 agent, but not for the DHCP agent. Personally I think that the backport should be permitted, and the agents should be fixed in the Juno and Kilo cycles.
Thanks.
So the feature in question is actually considered as valid, even though exotic.
How about enforcing the rule on per-agent base instead of globally? We know that our agents are broken, though we're not sure whether there are other agents in production that are not. So why not just disable the 'feature' for our agents but still allow other third-party agents to run with the current default value, in case they rely on that?
/Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iQEcBAEBCgAGBQJT8xFLAAoJEC5aWaUY1u57lnkIAOQUVXFeGnmLzChcKBR/Bw2D ORDALIBAXOlXbX1UoefJQsW4shZa//fdjXsX1NSaa+p46/OqLVlsuXw2iB/cs4X7 0bdDGL8K8a0fHSVI4Z7ZWnL6DrTm48vZmKv2BwGO+OPgW1TWoN5sw8gV33WevZ8t rQ7JLDxYMXNdB0BCGQmfbUIluhUznVdCLNub26Tw4sa1dtNOrRudOoEy9ylQk9hM w/8QodX4bbpnw+iLw7ox1h7J02XsjkVEpnokF1r4WketxQULE+xNukcekosNy5XJ /seJPjflF09uoxHqScNZC8kVAfGLsNTaaSivX7N+2rGrSBXunZBg0RXIGaTWefA= =9Ygu -----END PGP SIGNATURE-----
_______________________________________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint