Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170328/b4faabb1/attachment.html>