[Openstack-stable-maint] Controversial backport

Ihar Hrachyshka ihrachys at redhat.com
Tue Aug 19 08:56:43 UTC 2014


-----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-----



More information about the Openstack-stable-maint mailing list