OpenStack Dashboard (Horizon)

Floating IP quota not coming from Quantum

Reported by Julie Pichon on 2013-01-29
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Medium
Julie Pichon

Bug Description

This is probably like reopening bug 1040956 for Horizon... I'm not sure everything was addressed within it though, feel free to close if my reading is wrong.

1. If Quantum is enabled, at the moment we're still getting the floating IP quota from Nova, thus displaying wrong information in the system panel.

2. I believe this also means we're updating the wrong service (or at least it has no effect) when an admin updates the Floating IP quota using the Project panel, which is misleading. (This is similar to bug 1095876 for Cinder.)

3. Additionally, because we use that same quota information to sometimes disable the Allocate IP button (will be more of a problem after bug 1109098 is fixed), the user could be prevented from allocating new floating IPs when they are actually allowed to have more. The bar chart on that screen also displays incorrect information.

To reproduce:

1. Update /etc/quantum/quantum.conf [QUOTAS] section with "quota_floatingip = 3" (from http://docs.openstack.org/trunk/openstack-network/admin/content/cfg_quotas_common.html) and restart the quantum services
2. Go to the system info quota tab: Floating IP still shows as 10
3. Go to a project's Access and security tab and try to assign 4 IPs: the 4th one will fail with "Error: Unable to allocate Floating IP." Also the Allocate IP button isn't disabled and the bar chart wrongly indicates there are 7 IPs available.

Reproduced on a recent devstack.

Julie Pichon (jpichon) on 2013-02-05
description: updated
Changed in horizon:
status: New → Confirmed
Akihiro Motoki (amotoki) on 2013-02-25
tags: added: quantum
Akihiro Motoki (amotoki) wrote :

This issue has not been solved so far.
Floating IP is assigned by Quantum, but Floating IP Quota information is retrieved from nova.
I agree this situation is misleading.

To address it, the following changes is required:
(1) Quantum provides quota information about floating IP. Quantum now provides quota information only when quota extension is enabled and we need to change Quantum to always provide quota information)
(2) Horizon retrieves quota information about floating IP from Quantum.

Since (1) is not implemented yet in Quantum, this bug needs to be postponed to Havana.

Akihiro Motoki (amotoki) wrote :

Another temporary solution is to change Horizon just to return no usage for floating IP quota when quantum is enabled.
It can be done by Grizzly-rc1.

Changed in horizon:
importance: Undecided → Medium
Julie Pichon (jpichon) wrote :

I had a look at the neutronclient. It seems quotas is still an extension and therefore optional in Neutron.

1. To update Neutron-related quotas, we'll need to check both that Neutron is enabled and the "quotas" extension exists

2. It doesn't seem possible to get the system-wide default quotas at the moment, I think they are still defined in the configuration file? If there's no way to access it via an API we may need to remove the Neutron-related quotas from the system info panel when Neutron is enabled, to avoid confusion.

amotoki, could you confirm if this is correct?

Another interesting one is the security group / security group rules quotas, which exist both in Nova and Neutron. However it's an extension in Neutron as well, which may or may not be used depending on a config setting.

Changed in horizon:
assignee: nobody → Julie Pichon (jpichon)
Akihiro Motoki (amotoki) wrote :

jpich, thanks for diving into this.

In neutron quotas is an extension and it means whether quotas API is available or not depends on its backend plugin. (Most open source plugins and a couple of vendor plugins support quota extensions now.)

> 1. To update Neutron-related quotas, we'll need to check both that Neutron is enabled and the "quotas" extension exists

The situation is a little more complicated. Whether we can update quotas depends on the quota driver used and the driver is configured in the config file.

Neutron quota extension has two mode: (a) config-based system-wide quota and (b) per-tenant quota. (a) is the default value.
In (a) quota configurations are defined in the config file and quota values are exposed through the API. It means we cannot update quota through the API.
In (b) quota can be configured through the API and we can set different quotas per tenant. If quota for a specific tenant is customized, quota-show returns these values. Otherwise, the system default is returned.

> 2. It doesn't seem possible to get the system-wide default quotas at the moment, I think they are still defined in the
> configuration file? If there's no way to access it via an API we may need to remove the Neutron-related quotas from the
> system info panel when Neutron is enabled, to avoid confusion.

The default system-wide quotas is defined in the configuration file. The detail behavior of quota API is explained above. At now there is no way to retrieve the system default quotas explicitly.
It may be better to consider a similar API to "nova quota-defaults".
A dirty workaround is to retrieve quota value for "service" tenant or similar one. It is less likely Quotas for such tenant are configured.

What we need to consider are:
- How to determine neutron quota API is avaialable or not? -> it can be determined through ext-list.
- How to know quota update is supported or not? -> horizon local_settings?
- How to get the system default quotas?
- What should we do if neutron quota API is not available? Just ignore? Disable quota menu?

Julie Pichon (jpichon) wrote :

Thank you for the detailed answer, this is really helpful.

> - How to determine neutron quota API is avaialable or not? -> it can be determined through ext-list.
> - How to know quota update is supported or not? -> horizon local_settings?

I would have liked to avoid an additional setting but it looks like it will be necessary, if there is no API to determine what kind of update is allowed by the current driver.

> - How to get the system default quotas?

Could a read-only API be added to Neutron? (Would that be acceptable to the project?)

> - What should we do if neutron quota API is not available? Just ignore? Disable quota menu?

I think a good solution would be to not show the Neutron quotas + not display the Floating IP quota when Neutron is enabled and the quota_update setting is False. Otherwise it's misleading since Floating IP is actually updating Nova (the current situation).

Julie Pichon (jpichon) wrote :

I filed bug 1204956 with Neutron, on having an API to access the default quotas.

Julie Pichon (jpichon) wrote :

I'm assuming fixed_ips is also a nova network related quota, that is not needed when using Neutron. I'll submit the patch for all this in the next couple of days.

Lawrance (jing) wrote :

hope i can help any way

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

Changed in horizon:
status: Confirmed → In Progress

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

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

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

Reviewed: https://review.openstack.org/41960
Committed: http://github.com/openstack/horizon/commit/913ff38b6dddba83d79950c46a07cbc23f750741
Submitter: Jenkins
Branch: master

commit 913ff38b6dddba83d79950c46a07cbc23f750741
Author: Julie Pichon <email address hidden>
Date: Thu Jul 25 22:19:07 2013 +0100

    Hide default Floating IPs quotas with Neutron

    It is not possible to access the default quotas via an API for
    Neutron. Remove the quota in that case for now, as it comes from Nova
    and could cause confusion.

    Partial-Bug: #1109140

    Change-Id: If8df21b4ecbe541ce53790578820e22f36c32260

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

commit fde88906b34d82443bd9d5615ea1e9297fe26692
Author: Julie Pichon <email address hidden>
Date: Mon Aug 26 16:32:37 2013 +0100

    Show Neutron floating IPs quotas on Overview

    Display the correct limits and usage when Neutron is in use and the
    quotas extension is enabled. If Neutron is enabled but the quotas
    extensions is not supported, assume the floating IPs quota is
    unlimited (a floating IP quota is expected to exist in other places,
    e.g. Security and Access panel)

    Because quotas may not be configured or enabled even if the extension
    is available, add an 'enable_quotas' setting.

    Partial-Bug: #1109140

    Change-Id: Id6345f4700f0ff45be8ce8acb69cca0d4e05e14a

Reviewed: https://review.openstack.org/41962
Committed: http://github.com/openstack/horizon/commit/065786c745e83654d4a35833db97337a4caa4a23
Submitter: Jenkins
Branch: master

commit 065786c745e83654d4a35833db97337a4caa4a23
Author: Julie Pichon <email address hidden>
Date: Wed Aug 21 12:34:58 2013 +0100

    Import is_service_enabled from module

    An additional step for H302, and needed here to make mocking
    is_service_enabled across modules more consistent and easier
    (e.g. mocking only one signature as opposed to both
    api.base.is_service_enabled and quotas.is_service_enabled).

    Partial-Bug: #1109140

    Change-Id: Ie6cec3138de6f2fc57b68e90db45f53bb94ab87d

Reviewed: https://review.openstack.org/41963
Committed: http://github.com/openstack/horizon/commit/3852d1ce19fb4a3eab059a856d0a7dcf89feca27
Submitter: Jenkins
Branch: master

commit 3852d1ce19fb4a3eab059a856d0a7dcf89feca27
Author: Julie Pichon <email address hidden>
Date: Wed Aug 21 12:44:07 2013 +0100

    View and update Neutron project quotas

    Also ensure that the correct quota is displayed in the Floating IPs
    allocation page (Security & Access panel).

    Closes-Bug: #1109140

    Change-Id: I30d207fbf149bfbcfefeaddf91af49082b7b1f53

Changed in horizon:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2013-09-05
Changed in horizon:
milestone: none → havana-3
status: Fix Committed → Fix Released
tags: added: grizzly-backport-potential
Julie Pichon (jpichon) wrote :

Removing the "grizzly-backport-potential" tag, as this is a non-trivial amount of code that would be difficult to backport safely.

tags: removed: grizzly-backport-potential
Thierry Carrez (ttx) on 2013-10-17
Changed in horizon:
milestone: havana-3 → 2013.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints