Hi Deepak,
Ø When you say VM, its confusing, whether you are referring to service VM or Ø tenant VM. Since you are also saying share-server, I presume you mean Ø service VM! Ø IIUC each share-server VM (also called service VM) is serving all VMs Ø created by a tenant. In other words, generic driver creates 1 service VM Ø per tenant, and hence serves all the VMs (tenant VMs) created by that tenant Ø Manila experts on the list can correct me if I am wrong here. Generic Ø driver creates service VM (if not already present for that tenant) as part Ø of creating a new share and connect the tenant network to the service VM Ø network via neutron router (creates ports on the router which helps connect Ø the 2 different subnets), thus the tenant VMs can ping/access the service Ø VM. There is no question and/or need to have 2 service VMs talk to each Ø other, because they are serving different tenants, thus they need to be Ø isolated! Sorry for the bad expression, yes, I mean service VM. I don’t agree with “each share-server VM (also called service VM) is serving all VMs created by a tenant”. Because from my practices , 1 service VM is created for 1 share-network. A share-network -> A service VM -> shares which are created with the same “share-network”. A tenant(the tenant concept in keystone) can has more than one share-networks, even a same neutron network & subnet can be “registered” to several share-networks if user do want to do that. Actually, I didn’t see strong connections between manila shares and tenant (the concept in keystone), but this is other topics then. But, I think I get your point about service VMs need to be isolated. I agree with that. Ø Typically GlusterFS will be deployed on storage nodes (by storage admin) Ø that are NOT part of openstack. So having the share-server talk/connect Ø with GlusterFS is equivalent to saying "Allow openstack VM to talk with Ø non-openstack nodes", in other words "Connect the neutron network to Ø non-neutron network (also called provider/host network)". This is the part I disagree. Ø This is achieved by ensuring your openstack Network node is configured to Ø forward tenant traffic to provider network, which involves neutron skills Ø and some neutron black magic :) Ø To know what this involves, pls see section "Setup devstack networking to Ø allow Nova VMs access external/provider network" in my blog @ Ø http://dcshetty.blogspot.in/2015/01/using-glusterfs-native-driver-in.html Ø This should be taken care by your openstack network admin who should Ø configure the openstack network node to allow this to happen, this isn't a Ø Manila / GlusterFS driver responsibility, rather its an openstack Ø deployment option thats taken care by the network admins during openstack Ø deployment. What I want to do is enable GluserFS with Manila with Ganesha in my environment. I’m working as a cloud admin. So, what I expecting is, 1. I need to prepare a GlusterFS cluster 2. I need to prepare images and other stuff for service VM 3. I need to configure my GluserFS cluster’s information (IPs, volumes) into manila.conf ð All things can work if I start Manila now, Yeah ! The only thing I know is manila would create VMs to connect to my GlusterFS cluster. Currently, the neutron network & subnet where service VMs work is created by Manila. Manila called them service_network & service_subnet. So, I don’t think it is possible for me to configure the network before I create shares. Another problem is there is no router I can used to let service_network connected to GlusterFS cluster. Because service_subnet are already connected to user’s router ( if connect_share_server_to_tenant_network = False) Thanks. -chen From: Deepak Shetty [mailto:dpkshe...@gmail.com] Sent: Thursday, February 12, 2015 1:24 PM To: Li, Chen Subject: Fwd: [openstack-dev] [Manila]Question about gateway-mediated-with-ganesha Li Chen, Fwdign it to you , since u didn't recieve the below mail to your outlook. Hope you get this one! While responding pls Cc the openstack-dev list, so that the discussion can continue on the public list thanx, deepak ---------- Forwarded message ---------- From: Deepak Shetty <dpkshe...@gmail.com<mailto:dpkshe...@gmail.com>> Date: Wed, Feb 11, 2015 at 2:31 PM Subject: Re: [openstack-dev] [Manila]Question about gateway-mediated-with-ganesha To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> On Tue, Feb 10, 2015 at 1:51 AM, Li, Chen <chen...@intel.com<mailto:chen...@intel.com>> wrote: Hi list, I’m trying to understand how manila use NFS-Ganesha, and hope to figure out what I need to do to use it if all patches been merged (only one patch is under reviewing, right ?). I have read: https://wiki.openstack.org/wiki/Manila/Networking/Gateway_mediated https://blueprints.launchpad.net/manila/+spec/gateway-mediated-with-ganesha From documents, it is said, within Ganesha, multi-tenancy would be supported: And later the Ganesha core would be extended to use the infrastructure used by generic driver to provide network separated multi-tenancy. The core would manage Ganesha service running in the service VMs, and the VMs themselves that reside in share networks. => it is said : extended to use the infrastructure used by generic driver to provide network separated multi-tenancy So, when user create a share, a VM (share-server) would be created to run Ganesha-server. => I assume this VM should connect the 2 networks : user’s share-network and the network where Glusterfs cluster is running. But, in generic driver, it create a manila service network at beginning. When user create a share, a “subnet” would be created in manila service network corresponding to each user’s “share-network”: This means every VM(share-server) generic driver has created are living in different subnets, they’re not able to connect to each other. When you say VM, its confusing, whether you are referring to service VM or tenant VM. Since you are also saying share-server, I presume you mean service VM! IIUC each share-server VM (also called service VM) is serving all VMs created by a tenant. In other words, generic driver creates 1 service VM per tenant, and hence serves all the VMs (tenant VMs) created by that tenant Manila experts on the list can correct me if I am wrong here. Generic driver creates service VM (if not already present for that tenant) as part of creating a new share and connect the tenant network to the service VM network via neutron router (creates ports on the router which helps connect the 2 different subnets), thus the tenant VMs can ping/access the service VM. There is no question and/or need to have 2 service VMs talk to each other, because they are serving different tenants, thus they need to be isolated! If my understanding here is correct, the VMs that running Ganesha are living the different subnets too. => Here is my question: How VMs(share-servers) running Ganesha be able to connect to the single Glusterfs cluster ? Typically GlusterFS will be deployed on storage nodes (by storage admin) that are NOT part of openstack. So having the share-server talk/connect with GlusterFS is equivalent to saying "Allow openstack VM to talk with non-openstack nodes", in other words "Connect the neutron network to non-neutron network (also called provider/host network)". This is achieved by ensuring your openstack Network node is configured to forward tenant traffic to provider network, which involves neutron skills and some neutron black magic :) To know what this involves, pls see section "Setup devstack networking to allow Nova VMs access external/provider network" in my blog @ http://dcshetty.blogspot.in/2015/01/using-glusterfs-native-driver-in.html This should be taken care by your openstack network admin who should configure the openstack network node to allow this to happen, this isn't a Manila / GlusterFS driver responsibility, rather its an openstack deployment option thats taken care by the network admins during openstack deployment. Disclaimer: I am not neutron expert, so feel free to correct/update me HTH, thanx, deepak
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
