Hi,
The bug opened in Nova https://bugs.launchpad.net/nova/+bug/1221320 has a fix
pending core nova developer approval.
The 2nd bug opened for Neutron is fixed and approved.
As we need this quite urgently to complete our testing in time for Havana, I
would appreciate if another core reviewer will review
https://review.openstack.org/#/c/45691/ and hopefully will approve.
Regards,
-Sam.
From: Avishay Balderman
Sent: Sunday, September 08, 2013 11:15 AM
To: OpenStack Development Mailing List; [email protected]
Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a
non-shared network in another tenant
Hi
I have opened two bugs that are related to the topic below:
https://bugs.launchpad.net/neutron/+bug/1221315
https://bugs.launchpad.net/nova/+bug/1221320
Thanks
Avishay
From: Samuel Bercovici
Sent: Wednesday, August 07, 2013 1:05 PM
To: OpenStack Development Mailing List;
[email protected]<mailto:[email protected]>
Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a
non-shared network in another tenant
Hi Yong,
Garry has recommended that I will you the following:
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.
Around line 123: search_opts = {"tenant_id": project_id, 'shared': False}
As far as I understand, Neutron already filters non-shared networks by the
tenant ID, so why do we need this explicit filter, even more, I think that the
behavior of neutron will also return the shared network in addition to the
private ones by default so instead of the code doing two calls it could only do
one call to Neutron with if needed filtering by net_ids.
Do you see a reason why the code should remain as is?
Thanks,
-Sam.
From: Samuel Bercovici
Sent: Thursday, August 01, 2013 10:58 AM
To: OpenStack Development Mailing List;
[email protected]<mailto:[email protected]>
Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a
non-shared network in another tenant
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;
[email protected]<mailto:[email protected]>
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:[email protected]]
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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
