Horizon overview page is not displayed when quantum plugin w/o router ext support is used

Proposed change that fixes this:

quantum/plugins/brocade/QuantumPlugin.py -- d3676b6..adfa69f 100644
--- INDEX:/quantum/plugins/brocade/QuantumPlugin.py
+++ WORKDIR:/quantum/plugins/brocade/QuantumPlugin.py
@@ -193,6 +193,7 @@ class AgentNotifierApi(proxy.RpcProxy,

 class BrocadePluginV2(db_base_plugin_v2.QuantumDbPluginV2,
+ l3_db.L3_NAT_db_mixin,
                       sg_db_rpc.SecurityGroupServerRpcMixin,
                       agents_db.AgentDbMixin):
     """BrocadePluginV2 is a Quantum plugin.
@@ -207,7 +208,9 @@ class BrocadePluginV2(db_base_plugin_v2.QuantumDbPluginV2,
         and db configuration.
         """

- self.supported_extension_aliases = ["binding", "security-group"]
+ self.supported_extension_aliases = ["binding", "security-group",
+ "router", "agent", "agent-scheduler"]
+
         self.binding_view = "extension:port_binding:view"
         self.binding_set = "extension:port_binding:set"

this is a bug in horizon support quantum, as horizon should not make assumptions about non-core APIs being implemented.

akihiro or nachi should be the best to respond in more detail.

This is definitely worth fixing, and I've marked it as an RC2 bug, with a few caveats:

  1. I need a better understanding of which feature(s)/API(s) the Brocade plugin doesn't support, 'cuz this report and the related email thread are a bit all over the map.

  2. The right solution to this (for now) will be adding another setting to control this feature like we do for the load balancer plugin.

  3. If the change is too invasive I'm not gonna take it for RC2 and instead release note that the Brocade plugin is not supported for Quantum + Horizon in Grizzly.

Unfortunately we're waaaaay too late in the release cycle to be making any fundamental changes, so if it's not just a couple if statements it's gonna have to wait for Havana.

We should identify ways to test the different quantum plugins more thoroughly for the H cycle to prevent these from sneaking in in the future.

I still believe that this can be fixed from Quantum perspective. Brocade plugin needs these extensions anyways. Fixing this in Horizon at this stage is like using a sludge hammer for a minor issue.

These are well tested extensions in other plugins (there is no code change needed in the plugin, the extension only needs to be turned on).

This has been tested for Brocade plugin.

The worst case possible:
Even if this becomes a problem (which it is not, since I have tested this), it will affect ONLY Brocade plugin users.

I believe brocade plugin should turn on these extensions.

The cause itself is that Horizon quantum implementation calls router extension as Dan commented.
Horizon quantum api does not use other extension methods.

As a solution, it looks a good idea to add another settings in Horizon.
Router and Network Topology panel depend on router extension.
I will post a patch to disable these panels if router settings is False.

On the other hand, If I remember correctly quantum team have a consensus router extension is regarded as core api in Grizzly in the documentation. though in the code router extension is still an extension. We discussed in the quantum team meeting (That is before Brocade plugin was merged). So I have not add any settings for router so far.

I investigated the issue more detail. The situation is different from what I thought.

I think the issue can be split into three items.

(1) local_setting.py issue provided by devstack
The original issue reported that "QuantumClientException at /project/" is displayed seems to be caused by a wrong local_settings.py.
When local_settings.py provided by devstack is used, exceptions from client library are not handled properly in Horizon and they are visible to users.
If there is no local_settings.py or local_settings.py.example is copied to local_settings.py, I didn't see this exception and the project page was displayed with an error message "Unable to retrieve floating IP addresses".

Horizon local_setting.py provided by devstack is confusing and should be fixed in devstack.

(2) Floating IP management with a quantum plugin without router extension

If a quantum plugin does not support the router extension, users cannot use Floating IP.
It is not a matter whether nova API or quantum API is called.
From the point of view of Horizon, no fix is needed (it is okay that exceptions are handled properly and tracebacks are not visible to users.)
From Quantum perspective, router extension shoudl be supported in Brocade plugin in the future.

(3) Router management panel with a quantum plugin without router extension

It would be better to enable/disable quantum panels which depend on quantum extension such as router panel.
When there is no router extension support in Quantum, the current Horizon implementation behaves as follows:
- [router panel] Error messages are displayed at the upper right, but I got no tracebacks.
- [network topology] Javascript tries to retrieve router information infinitely.

Considering the above behavior, router panel and network topology should be disabled when router extension is not supported.

In Quantum side, features for Grizzly are already freezed and this issue should be handled in Horizon.
I mark it as invalid in Quantum.

This is not adding any new feature - we are simply bringing brocade plugin at par will all other plugins.

All other plugins have this enabled, I am requesting that this be allowed in Brocade plugin as well.

[ if at all this is a problem (and I have verified and tested that it does not introduce any regression), it will logically affect Brocade environments only, and of absolute no risk to anyone else]

Speaking only on the Horizon side of things, if the exceptions *are* properly handled, I'm more inclined to release note the failure with the Brocade plugin for Grizzly. This goes beyond just enabling or disabling certain panels and would get into anyplace the floating IP code is exercised... Just from past experience, changes to floating IP code tends to have unintended side effects, and it's a pretty core feature for Horizon users that I'd rather not mess with at this point.

My question now is whether we should look into optionally disabling any of this functionality in Havana, or whether it's going to be evened out across all the extensions?

[Comment on Quantum side]
I am not sure whether the router extension needs to be added to Brocade plugin into Grizzly release. According to my experience so far, adding support of a specific plugin is regarded as mini feature in the quantum community and we try to avoid adding mini feature during RC period.

On the other hand, router extension is regarded as Core API (at the documentation level) in Grizzly though router extension is still an extension in the code. We discussed it in the team meeting around G-3. Thus I think there is a room to consider adding router extension support in Quantum. This change only affects Brocade plugin and the only concern is Brocade plugin is not well tested with router feature at the timing of Grizzly release. At the end, it depends on PTL decision.

[Comment on Horizon side]

Floating IP is a key feature in OpenStack and I think it is not a kind of features disabled by settings.

> My question now is whether we should look into optionally disabling any of this functionality in Havana, or whether it's going to be evened out across all the extensions?

I believe Major features like router or quota will be supported by all plugins and such features are planed to move Quantum core API in Havana.

However, some features are not supported by all plugins. Agent Management is a good example. Some plugins uses quantum agents but some some plugins do not use agents. I think it is better to enable/disable some functionality in Horizon according to the supported extension list rather than settings in Horizon. The supported extension list can be retrieved through Quantum API.

Okay. I'll release note this for Grizzly and we'll look at using the Quantum supported extensions list in H.

Fix proposed to branch: master
Review: https://review.openstack.org/25645

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/25648

Gabriel,

Can you please add a line in the release notes to refer folks to how to use the quantum plugin in the Grizzly release.

Please add "refer to https://wiki.openstack.org/wiki/Brocade-quantum-plugin" for how to use with Grizzly. I will update the page appropriately.

Thanks,

-Shiv

Reviewed: https://review.openstack.org/25645
Committed: http://github.com/openstack/horizon/commit/c38b989c5378981bb33f48818a91ac211c125c22
Submitter: Jenkins
Branch: master

commit c38b989c5378981bb33f48818a91ac211c125c22
Author: Gabriel Hurley <email address hidden>
Date: Wed Mar 27 18:57:44 2013 -0700

    Release notes on Quantum Brocade plugin incompatibility.

    Fixes bug 1160580.

    Change-Id: Ib9b56e8b452b040c483a93adb5ff6c16894d5eb1

Reviewed: https://review.openstack.org/25648
Committed: http://github.com/openstack/horizon/commit/14ac6a90f469097647b0e5425b0ecbe244432c06
Submitter: Jenkins
Branch: milestone-proposed

commit 14ac6a90f469097647b0e5425b0ecbe244432c06
Author: Gabriel Hurley <email address hidden>
Date: Wed Mar 27 18:57:44 2013 -0700

    Release notes on Quantum Brocade plugin incompatibility.

    Fixes bug 1160580.

    Change-Id: Ib9b56e8b452b040c483a93adb5ff6c16894d5eb1

Hi Dan,

Just asked you about this question. I was looking at this process /usr/local/bin/quantum-ns-metadata-proxy. It seems that it uses a unix domain socket to communicate with the instances, and it then relay the requests to nova metadata service. Two of the metadata fields are local-ipv4 and public-ipv4. So my question is that if the ip addresses can be obtained from metadata using unix domain socket, why would it still need DHCP for ip addresses. After all, the ip addresses obtained from dnsmasq are allocated by quantum and added into the dnsmasq table. The second question is that if dhcp is still necessary, why Vms need local-ip and public-ip from metadata services. In other words, what are they used for by the instances?

Thanks,
Robert