as a tenant user not able to create a subnetpool associating with a shared address scope

Bug #1697925 reported by Ashok kumaran B on 2017-06-14
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Unassigned

Bug Description

1. created a "--shared" addresscope from admin tenant .
2. From a user tenant, as a normal user I am trying to create a subnetpool associating with the addresscope created in step 1.

this operation fails ,

root@controller01:~# neutron address-scope-show cc21d772-a9b4-41c4-b48d-16c19bb828c6
+------------+--------------------------------------+
| Field | Value |
+------------+--------------------------------------+
| id | cc21d772-a9b4-41c4-b48d-16c19bb828c6 |
| ip_version | 4 |
| name | test-addr-scope |
| project_id | f3e6f186351c441ea49c74e24360289c |
|> shared | True |
| tenant_id | f3e6f186351c441ea49c74e24360289c |
+------------+--------------------------------------+

root@controller01:~# neutron subnetpool-create --pool-prefix 172.80.0.0/16 --default-prefixlen 24 selfservice --address-scope test-addr-scope
Illegal subnetpool association: subnetpool cannot be associated with address scope cc21d772-a9b4-41c4-b48d-16c19bb828c6.
Neutron server returns request_ids: ['req-2be55467-9e18-47a6-a9c2-9c3fe39f7190']

But as far as I understand we do support shared addresscopes.
Please let me know if you want more info

This was tested with Ocata

Akihiro Motoki (amotoki) wrote :

This is a valid use case and we supported this use case in the past.
I can reproduce this in Pike master.

tags: added: l3-ipam-dhcp ocata-backport-potential
Changed in neutron:
status: New → Confirmed
importance: Undecided → High

Got a chance to discuss this with Akihiro, basically the below is the usecase.

"we create a shared addr scope in admin tenant, and then we can create a provider network (as external) and tenants can create networks in a same address scope"

This is very useful for BGP usecase.

Akihiro Motoki (amotoki) on 2017-06-14
Changed in neutron:
milestone: none → pike-3
Roey Chen (roeyc) on 2017-06-14
Changed in neutron:
assignee: nobody → Roey Chen (roeyc)
Akihiro Motoki (amotoki) wrote :

In my understanding, we cannot create subnet pools whose IP address range overlaps in a whole address scope, so we can allow non-admin project to create a subnet pool from a shared address scope. However, I believe we need to check more folks familiar with the L3 area on whether there is a reason we have the current behavior.

Changed in neutron:
status: Confirmed → In Progress
Miguel Lavalle (minsel) wrote :

The behavior reported in this bug in Ocata and master is the expected behavior. Please read the first paragraph of the "Proposed Change" in the spec for address scopes: https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/address-scopes.html#proposed-change. This spec is correctly reflected in the original implementation of address scopes: https://review.openstack.org/#/c/197552/15/neutron/db/db_base_plugin_v2.py@707.

This doesn't mean that it is not possible to discuss new use cases. But given that the current behavior is what was specified, we should proceed with caution following the Request for Feature Enhancement process: https://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements

I also want to point out that the use case as spelled out above in https://bugs.launchpad.net/neutron/+bug/1697925/comments/3 can be implemented with the current functionality. The implementation of this use case is explained here: https://docs.openstack.org/ocata/networking-guide/config-address-scopes.html#routing-with-address-scopes-for-non-privileged-users

Changed in neutron:
importance: High → Wishlist
tags: added: rfe

This bug has had a related patch abandoned and has been automatically un-assigned due to inactivity. Please re-assign yourself if you are continuing work or adjust the state as appropriate if it is no longer valid.

Changed in neutron:
assignee: Roey Chen (roeyc) → nobody
status: In Progress → New
tags: added: timeout-abandon

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.openstack.org/474552
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers