<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="ltr">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.
<div><br>
</div>
<div>Rob</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 28 March 2017 at 21:06, Matt Riedemann <span dir="ltr">
<<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">On 3/28/2017 9:04 AM, Akihiro Motoki wrote:<br>
> Hi,<br>
><br>
> I would like to raise a topic when horizon nova-network support can be dropped.<br>
> I added [tc] tag as it is related to<br>
> "assert:follows-standard-<wbr>deprecation" tag in the governance.<br>
><br>
> Can horizon drop nova-network support based on the deprecation of nova-network<br>
> from the nova team?<br>
> or does horizon need to deprecate nova-network support in horizon explicitly?<br>
><br>
> Let me summarize the current situation:<br>
> - nova team deprecated nova-network in Newton release. [1]<br>
> - horizon team has not deprecated it so far (just forgot to do it).<br>
> - nova-network security group and floating IP support has been dropped<br>
> from novaclient few days ago [2].<br>
> - When a new release of novaclient comes, horizon security group<br>
> support will be broken (if neutron is not used)<br>
> - Nova microversion also allows to use nova-network but old version of<br>
> novaclient is required for horizon to<br>
> support it and it is not realistic.<br>
<br>
</span>This is the tricky part. You can specify a microversion to use<br>
novaclient with the nova-network behavior. If you're using the python<br>
API bindings in novaclient, which I think Horizon is, then you have to<br>
specify a microversion anyway. The nova-network API bindings in<br>
novaclient will work up until 2.35.<br>
<br>
The messy part about this is when we release novaclient 8.0 then that<br>
code is gone and microversions don't matter. So you'd have to use an<br>
older version, 7.1.0 at this point. To do that, we have to essentially<br>
cap novaclient to 7.1.0 in upper-constraints in the requirements repo<br>
for the rest of Pike since Horizon won't work with 8.0.<br>
<br>
I don't want to cap novaclient in upper-constraints for the rest of<br>
Pike, but at the same time, it's not great to just drop features out of<br>
a UI without first telling users they are deprecated first. However,<br>
having said that, isn't Horizon really the portal for the tenant user? I<br>
know admins use it also, but the admin/operator should already know<br>
about the nova-network deprecation. If they are just finding out about<br>
this because their Horizon features all of a sudden don't work in Pike,<br>
that's pretty bad on their part, in my opinion anyway. In this<br>
perspective, I think it might be OK to drop nova-network support without<br>
a deprecation period in Horizon for the things we've removed from<br>
novaclient.<br>
<span class=""><br>
><br>
> It would be nice that horizon team is allowed to drop some feature<br>
> aligning with feature deprecation<br>
> and drop in backend project(s) (without explicit deprecation notices<br>
> in horizon side).<br>
><br>
> It is not easy that horizon team is aware of all feature deprecations<br>
> in other projects<br>
> and the horizon team tends to be aware of them when the deprecated features are<br>
> actually dropped.<br>
><br>
> Thought?<br>
><br>
> There may be things and solutions I am not aware of. Any feedback<br>
> would be appreciated.<br>
<br>
</span>Me too. :)<br>
<span class="im HOEnZb"><br>
><br>
> Best Regards,<br>
> Akihiro<br>
><br>
> [1] <a href="https://docs.openstack.org/releasenotes/nova/newton.html#deprecation-notes" rel="noreferrer" target="_blank">
https://docs.openstack.org/<wbr>releasenotes/nova/newton.html#<wbr>deprecation-notes</a><br>
> [2] <a href="https://review.openstack.org/#/c/447707/" rel="noreferrer" target="_blank">
https://review.openstack.org/#<wbr>/c/447707/</a><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">
http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
<br>
Thanks,<br>
<br>
Matt<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>