Open Stack

2017-03-29 5:06 GMT+09:00 Matt Riedemann <mriedemos at 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-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