Open Stack

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.cresswell at 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 <mriedemos at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>