<div dir="auto">This isn't a direct answer to your question, but you can use service subnets to avoid the routers burning public IP addresses to make per-tenant routers feasible: <a href="https://docs.openstack.org/neutron/pike/admin/config-service-subnets.html">https://docs.openstack.org/neutron/pike/admin/config-service-subnets.html</a><div dir="auto"><br></div><div dir="auto">As for enabling the shared router use case, I recommend filing a request for enhancement (RFE) bug because it seems reasonable to allow tenant floating IP allocations via a router attached to a subnet owned by the tenant. </div><br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Aug 17, 2018 06:17, "Johan Jatko" <<a href="mailto:armedguy@ludd.ltu.se">armedguy@ludd.ltu.se</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
I got a problem with neutron-server, and I am not sure if I should <br>
consider it a bug, a platform limitation, or a future improvement.<br>
<br>
My scenario is that I want to allocate floating ips from project "admin" <br>
to project "project1".<br>
On project admin, I have an external network, and a router connecting <br>
the external network "external" and a internal network "access-network"<br>
<br>
"access-network" is shared to "user1".<br>
<br>
When a user in "project1" (non-admin) tries to assign floating ip to an <br>
instance that is connected to "access-network", the returned error is <br>
"Router {ID} could not be found".<br>
<br>
Letting our projects create their own routers on the external network <br>
wastes a lot of IPs for us, so we would like to use a shared router.<br>
<br>
After debugging I have found out that this is due to a check in <br>
neutron/_model_query.py in query_with_hooks that checks if the current <br>
context is service or admin, and IF NOT, adds a query_filter that limits <br>
the query to the current project.<br>
<br>
This seems by design but I cannot for the life of me understand why the <br>
policy system cannot enforce this instead (or the rbac system?).<br>
<br>
<br>
For now I have decided to just patch it myself and push the change to my <br>
cluster, but it would be interesting to hear if there are any design <br>
decisions for it.<br>
<br>
<br>
<br>
Regards<br>
Johan Jatko<br>
Luleå Academic Computer Society<br>
<br>
_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org" target="_blank" rel="noreferrer">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
</blockquote></div><br></div></div>