[Openstack-stable-maint] Controversial backport

Assaf Muller amuller at redhat.com
Tue Aug 19 08:47:35 UTC 2014



----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> 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.

> /Ihar
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> 
> iQEcBAEBCgAGBQJT8wzoAAoJEC5aWaUY1u578HAH/0DB3+IpYWjKbwo9th3Phaf/
> EvQEON2tMA177ufdgzO3KsWdx8VJxNzFfHU6Jl8aY9GQ3NYsg+5QYOJPcX0hHg4t
> g3yfrcUybDZ9roqzHZNYOUddm10Te7a+Q4Ykj2X2QiqEZC/VpxudRYDGU5O5cDpg
> sNeFltCp/vb/oGfX/E5dxdF5hzGd1sJQvDs+0jXfLghaCmNITvLFELN56JsUFxvr
> ZuzNxCnyvL7iJSHA+vWiG36jZCF/dR4eYly2CpRaQJ2Fp6ObVvkWCv+U+wtv+5bm
> TYl8PHpDmmGOlJPaBQn7OXAGc5eQZnkBwXGDxhRl6Fi9JF2fRSV0blSZl4rwpEA=
> =lxWH
> -----END PGP SIGNATURE-----
> 



More information about the Openstack-stable-maint mailing list