There was another patch needed: In: /opt/stack/nova/nova/network/neutronv2/api.py In the def _get_available_networks function, the developer has added a specific line of code filtering networks by the tenant_id. In general as far as I understand, this might be unneeded as quantum will already filter the networks based on the tenant_id in the context while if is_admin, will elevate and return all networks which I belive is the behavior we want.
Do you think this can somehow be solved only on neutron side or must it also be done by rmoving the tenant_id filter in the nova side? When removing the filter of tenant_id + the pathc bellow, I get the behavior that as admin, I can createVMs connected to another tenants private network but as non-admin I am not able to do so. Regards, -Sam. From: Samuel Bercovici Sent: Wednesday, July 31, 2013 7:32 PM To: OpenStack Development Mailing List; sorla...@nicira.com Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a non-shared network in another tenant Hi Slavatore, I thought that creating a qport would be enough but it looks like I still missing something else. I have commented in /opt/stack/quantum/neutron/api/v2/base.py in the create function the ._validate_network_tenant_ownership call. I can now as an Admin user, can create a qport from tenant-a that is mapped to a private network in tenant-b. The following still fails with ERROR: The resource could not be found. (HTTP 404) ... nova boot --flavor 1 --image <image-id> --nic port-id=<port-id> Where <port-id> is the one I got from the port-create Any ideas where I should look next? Regards, -Sam. From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: Wednesday, July 31, 2013 5:42 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a non-shared network in another tenant Hi Sam, is what you're trying to do tantamount to creating a port on a network whose tenant_id is different from the network's tenant_id? We have at the moment a fairly strict ownership check - which does not allow even admin users to do this operation. I do not have a strong opinion against relaxing the check, and allowing admin users to create ports on any network - I don't think this would constitute a potential vulnerability, as in neutron is someone's manages to impersonate an admin user, he/she can make much more damage. Salvatore On 31 July 2013 16:11, Samuel Bercovici <samu...@radware.com<mailto:samu...@radware.com>> wrote: Hi All, We are providing load balancing services via virtual machines running under an admin tenant that needs to be connected to VMs attached to a non-shared/private tenant network. The virtual machine fails to be provisioned connected to the private tenant network event if it is provisioned using the admin user which has admin role on both tenants. Please advise? Best Regards, -Sam. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev