Mailing List Archive

Help with hardcoded project_id query_filter in neutron when not admin
Hi!

I got a problem with neutron-server, and I am not sure if I should
consider it a bug, a platform limitation, or a future improvement.

My scenario is that I want to allocate floating ips from project "admin"
to project "project1".
On project admin, I have an external network, and a router connecting
the external network "external" and a internal network "access-network"

"access-network" is shared to "user1".

When a user in "project1" (non-admin) tries to assign floating ip to an
instance that is connected to "access-network", the returned error is
"Router {ID} could not be found".

Letting our projects create their own routers on the external network
wastes a lot of IPs for us, so we would like to use a shared router.

After debugging I have found out that this is due to a check in
neutron/_model_query.py in query_with_hooks that checks if the current
context is service or admin, and IF NOT, adds a query_filter that limits
the query to the current project.

This seems by design but I cannot for the life of me understand why the
policy system cannot enforce this instead (or the rbac system?).


For now I have decided to just patch it myself and push the change to my
cluster, but it would be interesting to hear if there are any design
decisions for it.



Regards
Johan Jatko
LuleƄ Academic Computer Society

_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: Help with hardcoded project_id query_filter in neutron when not admin [ In reply to ]
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:
https://docs.openstack.org/neutron/pike/admin/config-service-subnets.html

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.


On Aug 17, 2018 06:17, "Johan Jatko" <armedguy@ludd.ltu.se> wrote:

Hi!

I got a problem with neutron-server, and I am not sure if I should
consider it a bug, a platform limitation, or a future improvement.

My scenario is that I want to allocate floating ips from project "admin"
to project "project1".
On project admin, I have an external network, and a router connecting
the external network "external" and a internal network "access-network"

"access-network" is shared to "user1".

When a user in "project1" (non-admin) tries to assign floating ip to an
instance that is connected to "access-network", the returned error is
"Router {ID} could not be found".

Letting our projects create their own routers on the external network
wastes a lot of IPs for us, so we would like to use a shared router.

After debugging I have found out that this is due to a check in
neutron/_model_query.py in query_with_hooks that checks if the current
context is service or admin, and IF NOT, adds a query_filter that limits
the query to the current project.

This seems by design but I cannot for the life of me understand why the
policy system cannot enforce this instead (or the rbac system?).


For now I have decided to just patch it myself and push the change to my
cluster, but it would be interesting to hear if there are any design
decisions for it.



Regards
Johan Jatko
LuleƄ Academic Computer Society

_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack