[openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

Matt Riedemann mriedemos at gmail.com
Tue Mar 28 20:06:34 UTC 2017

On 3/28/2017 9:04 AM, Akihiro Motoki wrote:
> Hi,
> I would like to raise a topic when horizon nova-network support can be dropped.
> I added [tc] tag as it is related to
> "assert:follows-standard-deprecation" tag in the governance.
> Can horizon drop nova-network support based on the deprecation of nova-network
> from the nova team?
> or does horizon need to deprecate nova-network support in horizon explicitly?
> Let me summarize the current situation:
> - nova team deprecated nova-network in Newton release. [1]
> - horizon team has not deprecated it so far (just forgot to do it).
> - nova-network security group and floating IP support has been dropped
> from novaclient few days ago [2].
> - When a new release of novaclient comes, horizon security group
> support will be broken (if neutron is not used)
> - Nova microversion also allows to use nova-network but old version of
> novaclient is required for horizon to
>   support it and it is not realistic.

This is the tricky part. You can specify a microversion to use 
novaclient with the nova-network behavior. If you're using the python 
API bindings in novaclient, which I think Horizon is, then you have to 
specify a microversion anyway. The nova-network API bindings in 
novaclient will work up until 2.35.

The messy part about this is when we release novaclient 8.0 then that 
code is gone and microversions don't matter. So you'd have to use an 
older version, 7.1.0 at this point. To do that, we have to essentially 
cap novaclient to 7.1.0 in upper-constraints in the requirements repo 
for the rest of Pike since Horizon won't work with 8.0.

I don't want to cap novaclient in upper-constraints for the rest of 
Pike, but at the same time, it's not great to just drop features out of 
a UI without first telling users they are deprecated first. However, 
having said that, isn't Horizon really the portal for the tenant user? I 
know admins use it also, but the admin/operator should already know 
about the nova-network deprecation. If they are just finding out about 
this because their Horizon features all of a sudden don't work in Pike, 
that's pretty bad on their part, in my opinion anyway. In this 
perspective, I think it might be OK to drop nova-network support without 
a deprecation period in Horizon for the things we've removed from 

> It would be nice that horizon team is allowed to drop some feature
> aligning with feature deprecation
> and drop in backend project(s) (without explicit deprecation notices
> in horizon side).
> It is not easy that horizon team is aware of all feature deprecations
> in other projects
> and the horizon team tends to be aware of them when the deprecated features are
> actually dropped.
> Thought?
> There may be things and solutions I am not aware of. Any feedback
> would be appreciated.

Me too. :)

> Best Regards,
> Akihiro
> [1] https://docs.openstack.org/releasenotes/nova/newton.html#deprecation-notes
> [2] https://review.openstack.org/#/c/447707/
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list