Created attachment 1064486 [details] Shows missing buttons in 7.0 compared to 6.0 with existing buttons Description of problem: Horizon does not have 'Create Router' button or 'Create Network' button under Project -> Network -> Routers Project -> Network -> Networks Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Deploy RHOSP 2. Log in to Horizon (as Admin or any Project User) 3. Go to Project -> Network -> Routers 4. Go to Project -> Network -> Networks Actual results: =============== 3. 'Create Router' button is missing 4. 'Create Networks' button is missing Expected results: ================= 3. 'Create Router' button should exist 4. 'Create Networks' button is missing Additional info: ================ Screenshot is enclosed Note: These buttons exist in RHOSP 6.0
Another note: Creating networks and routers works fine in the CLI as well.
Created attachment 1064914 [details] Summary of differences from 3.0.1 to 4.0 Added a summary of the differences from 3.0.1 to 4.0
Are you using PKI tokens again? Creating networks works well in my RHOS-7 setup.
Works for me?
No, we have the change for token_provider = uuid, and we see our project lists now after that fix. Is there another setting that will allow us to see the create network and create router buttons?
First guess would be: /etc/openstack-dashboard/neutron_policy.json There are rules listed for networks. My snippet looks like: "create_network": "", ... (snipped)... "create_network:shared": "rule:admin_only", "create_network:router:external": "rule:admin_only", "create_network:segments": "rule:admin_only", "create_network:provider:network_type": "rule:admin_only", "create_network:provider:physical_network": "rule:admin_only", "create_network:provider:segmentation_id": "rule:admin_only", Just to make sure, are you just using neutron networks (with default openvswitch?) Second question would be then (if policy is identical): do you have an exception in logs?
I had the opportunity to look at a system installed by ofi. A few observations: - there are no quotas set up for networks - there's a nova v3 endpoint set to http://127.0.0.1/v3 - it might have been an issue with this specific install, but network_topology overview page crashed with an exception: 126, in get_context_data context['network_quota_exceeded'] = self._quota_exceeded('networks') File "/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/network_topology/views.py", line 114, in _quota_exceeded available = usages[quota]['available'] KeyError: 'available' which leads us again to quotas. Both observations are different from installs made by director and from installs made by packstack. Packstack and director installs are showing both buttons to create networks and routers.
a possible duplicate of this: https://bugzilla.redhat.com/show_bug.cgi?id=1235844
Regarding C10, yes, we see the Network Topology crash as well noted in bz 1233644, and we're release noting that issue for this release.
I think I tracked this down to https://launchpad.net/bugs/1483379 There's even a patch up for this: https://review.openstack.org/#/c/211310/ Short workaround: in /etc/openstack-dashboard/local_settings: in OPENSTACK_NEUTRON_NETWORK = { 'enable_lb': True, 'enable_firewall': True, 'enable_quotas': False, 'enable_security_group': True, set enable_quotas to True The remaining question here is: why it has been set to False. (i.e. no not support quota for networking). It seems, nobody uses it with quota set to false. Nevertheless, horizon should be fixed here.
The linked patch fixes the network topology page.
Both linked patches are currently work in progress and likely to change. they are not approved upstream yet.
This change to astapor resolves the issue for me: https://github.com/redhat-openstack/astapor/pull/560 I have a test environment available at Red Hat, if you'd like to confirm. Michael.
(In reply to Michael Solberg from comment #18) > This change to astapor resolves the issue for me: > > https://github.com/redhat-openstack/astapor/pull/560 > > I have a test environment available at Red Hat, if you'd like to confirm. > > Michael. I have done similar tests, and can verify this does seem to fix the problem. However, the bug was left here with horizon because horizon itself should not break just because quotas are disabled. That said, I am still not opposed to enabling them in astapor as well. That change happened with the n1kv work, and I am not sure that there was any real reason for quotas to have been disabled to begin with.
I agree, Horizon shouldn't break with quotas disabled at all. That being said, this has just been discovered lately and reported upstream. Looking at the code, I'm somewhat convinced, horizon never worked with quotas disabled. Since this is quite visible, I would expect a bug report way earlier. Or installing with quotas disabled must be a rare case.
Slow progress here, proposed backport to kilo: https://review.openstack.org/#/c/228329/
How to test: in /etc/openstack-dashboard/local_settings, set in OPENSTACK_NEUTRON_NETWORK = { ... 'enable_quotas': False, } (Neutron quotas to false) and visit dashboard/project/network_topology/ Previously, this fails, now it should work. Unfortunately, one of our installers disabled neutron quotas.
Verified ======== python-django-horizon-2015.1.1-4.el7ost.noarch
Currently it is targeted for zstream. I thought that was already released last week. So was that change done in OSP-D and OFI?
Arkady, this bug here fixes the issue in Horizon; I remember, we talked about fixing OFI; OSP-D did not disable neutron quotas. If disabling neutron quotas makes sense in your setup, that's up to you. OFI disabled neutron quotas in the past.
(In reply to arkady kanevsky from comment #28) > Currently it is targeted for zstream. > I thought that was already released last week. > So was that change done in OSP-D and OFI? In OFI, we enabled quotas as of 4.0.7
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2015:1951