Open Stack

Yes,  I’m asking about plans for gateway-mediated-with-ganesha.
I want to know what would you do to achieve “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.”
Because after I studied current infrastructure of generic driver,  I guess directly use it for Ganesha would now work.
This is what I have learned from code:

Manila create service_network and service_subnet based on configurations in manila.conf:

    service_network_name =  manila_service_network

    service_network_cidr =  10.254.0.0/16

    service_network_division_mask = 28

service_network is created when manila-share service start.
service_subnet is created when manila-share service  get a share create command, and no share-server exists for current share-network.

ð  Service_subnet create at the same time as share-server created.

Yes, it can be pre-created, manila would check if subnet with no name already exist.

Thanks.
-chen


From: Deepak Shetty [mailto:dpkshetty at gmail.com]
Sent: Thursday, February 12, 2015 2:09 PM
To: Li, Chen
Cc: OpenStack Development Mailing List (not for usage questions) (openstack-dev at lists.openstack.org)
Subject: Re: [openstack-dev] [Manila]Question about gateway-mediated-with-ganesha



On Thu, Feb 12, 2015 at 6:41 AM, Li, Chen <chen.li at intel.com<mailto:chen.li at intel.com>> wrote:
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”.

You are probably right, I don't remember the insides of share-network now, but I always created 1 share-network, so i always had the notion of 1 service VM per tenant.

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.

What exactly do you disagree here ?






>  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

Right now, i think all we support is running Ganesha inside the GlusterFS server node only. I don't think we have qualified
the scenario where Ganesha is running in service VM. The Blueprint talks about doing this in near future.

Ccing Csaba and Ramana who are the right folks to comment more on this.


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.

service_network and service_subnet is pre-created i thought ? Even if it isn't you can bridge the service_network with provider network after the service_network is created (Ideally it should have been pre-created)


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)

If you read my blog, it talks about connecting tenant network to GlusterFS cluster which is on the host/provider network
For your case, it maps to connecting service VM (service_network and service_subnet) to GlusterFS cluster. You can either
use the existign router or create  a new router and have it connect the service_subnet with the external subnet on which GlusterFS is running.
thanx,
deepak

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150212/8b2469db/attachment.html>