Re: [openstack-dev] [Manila]Question about gateway-mediated-with-ganesha

2015-02-11 Thread Deepak Shetty
On Thu, Feb 12, 2015 at 7:32 AM, Li, Chen  wrote:

>  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.
>

You may be right, but we cannot be sure until we test, qualify, validate
against a real setup. Also there is no infrastrucutre to run Ganesha in
service VM, so the major work would be to bundle Ganesha and make it
available as a service VM image and use that image instead of the existing
service VM image. Csaba and Ramana (in CC) can comment more on this.


>  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
>

So even if the service_network or service_subnet is not created, this
information from the conf file can be used by the network admin to
bridge/connect the service network (whenever it comes up) with the
host/provider network.


>  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.
>

Thanks for clarifying.

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


Re: [openstack-dev] [Manila]Question about gateway-mediated-with-ganesha

2015-02-11 Thread Li, Chen
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:dpkshe...@gmail.com]
Sent: Thursday, February 12, 2015 2:09 PM
To: Li, Chen
Cc: OpenStack Development Mailing List (not for usage questions) 
(openstack-dev@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 
mailto:chen...@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 i

Re: [openstack-dev] [Manila]Question about gateway-mediated-with-ganesha

2015-02-11 Thread Deepak Shetty
On Thu, Feb 12, 2015 at 6:41 AM, Li, Chen  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 ser

Re: [openstack-dev] [Manila]Question about gateway-mediated-with-ganesha

2015-02-11 Thread Li, Chen
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 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)" 
mailto:openstack-dev@lists.openstack.org>>



On Tue, Feb 10, 2015 at 1:51 AM, Li, Chen 
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://blue

Re: [openstack-dev] [Manila]Question about gateway-mediated-with-ganesha

2015-02-11 Thread Deepak Shetty
On Tue, Feb 10, 2015 at 1:51 AM, Li, Chen  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


[openstack-dev] [Manila]Question about gateway-mediated-with-ganesha

2015-02-09 Thread Li, Chen
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.

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 ?

Looking forward to hear from you.

Thanks.
-chen
__
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