I am okay to drop nova-network feature in Pike. More generally, can we horizon team say the following?
A feature deprecated in a back-end project is automatically deprecated in Horizon and a feature in horizon will be dropped if a corresponding support is dropped in a back-end project and/or its support library (like python bindings) even though horizon may provide an extended supports. Akihiro 2017-03-29 7:02 GMT+09:00 Rob Cresswell <robert.cressw...@outlook.com>: > Frankly, it sounds like we can pretty comfortably drop support for nova-net > in Pike. I'm fine with that, from a Horizon point of view. > > Rob > > On 28 March 2017 at 21:06, Matt Riedemann <mriede...@gmail.com> wrote: >> >> 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 >> novaclient. >> >> > >> > 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 > __________________________________________________________________________ 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
