2017-03-29 5:06 GMT+09:00 Matt Riedemann <mriede...@gmail.com>: > 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.
Sorry for my late. Yes, nova supports nova-network API in API version up to 2.35. Horizon now consumes python bindings from novaclient with version 2 (not latest API version) unless we need to use more recent version. Horizon just started micro versioning support in Pile and most work is under development. > 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. Yeah, this is the most tricky part. Is there any deprecation policy in novaclient python binding? I was not aware of deprecation warnings. If novaclient follows nova deprecation, it sounds reasonable to me. > 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 novaclient. Horizon is both for tenant users and admin/operators. In my understanding, operators need to know deprecation notices of various projects and decide which version they should provide. This applies to horizon too. If they want to provide nova-network support in horizon, they can choose a way not to upgrade horizon to Pike. Nova already deprecated nova-network after Nova API 2.36 and this means users cannot use newer features anymore as if a newer API version is used nova-network is not take into account. What is the merit of upgrading nova and horizon? Considering the above, it looks okay to me to drop nova-network support from horizon in Pike based on nova-team deprecation of nova-network in Newton. (question not directly related to this topic) I am not sure there is a case where users still use API 2.36 for network management and newer API versions for other compute operation. Akihiro > >> >> 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-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > -- > > Thanks, > > Matt > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
