Open Stack

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 at 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 at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint