Comment 6 for bug 1160580

Revision history for this message
Akihiro Motoki (amotoki) wrote : Re: Allow extensions already implemented in Quantum in Brocade plugin

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.