Open Stack

On Thu, Feb 12, 2015 at 6:41 AM, Li, Chen <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/88210a5a/attachment.html>