Re: [openstack-dev] [Manila]Rename driver mode

2015-01-20 Thread Valeriy Ponomaryov
We have come to decision with it:
http://eavesdrop.openstack.org/meetings/manila/2015/manila.2015-01-15-15.02.log.html
https://etherpad.openstack.org/p/manila-driver-modes-discussion
https://blueprints.launchpad.net/manila/+spec/rename-driver-modes

Here is change that implements this decision:
https://review.openstack.org/#/c/147821/

I ask people, who is able (driver maintainers?), to test share drivers for
presence of some breakage by this change.

On Thu, Jan 8, 2015 at 6:36 AM, Ben Swartzlander b...@swartzlander.org
wrote:


 On 01/07/2015 09:20 PM, Li, Chen wrote:

  Update my proposal again:



 As a new bird for manila, I start using/learning manila with generic
 driver. When I reached driver mode,I became really confuing, because I
 can't stop myself jump into ideas:   share server == nova instance   
 svm == share virtual machine == nova instance.



 Then I tried glusterFS, it is working under single_svm_mode, I asked why
 it is single mode, the answer I get is  This is approach without usage
 of share-servers  ==  without using share-servers, then why single
 ??? More confusing ! :(





 Now I know, the mistake I made is ridiculous.

 Great thanks to vponomaryov  ganso, they made big effort helping me to
 figure out why I'm wrong.





 But, I don't think I'm the last one person making this mistake.

 So, I hope we can change the driver mode name less confusing and more easy
 to understand.





 First, svm should be removed, at least change it to ss (share-server),
 make it consistent with share-server.

 I don't like single/multi, because that makes me think of numbers of
 share-servers, makes me want to ask: if I create a share, that share need
 multi share-servers ? why ?



 I agree the names we went with aren't the most obvious, and I'm open to
 changing them. Share-server is the name we have for virtual machines
 created by manila drivers so a name that refers to share servers rather
 than svms could make more sense.



  Also, when I trying glusterFS (installed it following
 http://www.gluster.org/community/documentation/index.php/QuickStart),
 when I testing the GlusterFS volume, it said: use one of the servers to
 mount the volume. Isn't that means using any server in the cluster can
 work and their work has no difference. So, is there a way to change
 glusterFS driver to add more than one glusterfs_target, and all
 glusterfs_targets are replications for each other. Then when manila create
 a share, chose one target to use. This would distribute data traffic to the
 cluster, higher bandwidth, higher performance, right ? == This is
 single_svm_mode, but obviously not single.





 vponomaryov  ganso suggested basic_mode and advanced_mode, but I think
 basic/advanced is more driver perspective concept. Different driver might
 already have its own concept of basic advanced, beyong manila scope. This
 would make admin  driver programmer confusing.


 I really do not like basic/advanced. I think you summarized one reason why
 it's a bad choice. The relevant difference between the modes is whether the
 driver is able to create tenant-specific instances of a share filesystem
 server or whether tenants share access to a single server.

  As single_svm_mode indicate driver just have information about
 where to go and how, it is gotten by config opts and some special
 actions of drivers while multi_svm_mode need to create where and how
 with infomation.



 My suggestion is

single_svm_mode == static_mode

multi_svm_mode  == dynamic_mode.



 As where to go and how are static under single_svm_mode, but
 dynamically create/delete by manila under multi_svm_mode.\


 Static/dynamic is better than basic/advanced, but I still think we can do
 better. I will think about it and try to come up with another idea before
 the meeting tomorrow.

  Also, about the share-server concept.



 share-server is a tenant point of view concept, it does not know if it
 is a VM or a dedicated hardware outside openstack because it is not visible
 to the tenant.

 Each share has its own share-server, no matter how it get(get from
 configuration under single_svm_mode, get from manila under multi_svm_mode).


 I think I understand what you mean here, but in a more technical sense,
 share servers are something we hide from the tenant. When a tenant asks for
 a share to be created, it might get created on a server that already
 exists, or a new one might get created. The tenant has no control over
 this, and ideally shouldn't even know which decision manila made. The only
 thing we promise to the tenant is that they'll get a share. The intent of
 this design is to offer maximum flexibility to the driver authors, and to
 accommodate the widest variety of possible storage controller designs,
 without causing details about the backends to leak through the API layer
 and break the primary goal of Manila which is to provide a standardized API
 regardless of what the actual implementation is.

 We need to keep the 

Re: [openstack-dev] [Manila]Rename driver mode

2015-01-07 Thread Ben Swartzlander


On 01/07/2015 09:20 PM, Li, Chen wrote:


Update my proposal again:

As a new bird for manila, I start using/learning manila with generic 
driver. When I reached driver mode,I became really confuing, because I 
can't stop myself jump into ideas:   share server == nova instance   
svm == share virtual machine == nova instance.


Then I tried glusterFS, it is working under single_svm_mode, I asked 
why it is single mode, the answer I get is  This is approach 
without usage of share-servers  ==  without using share-servers, 
then why single ??? More confusing ! :(


Now I know, the mistake I made is ridiculous.

Great thanks to vponomaryov  ganso, they made big effort helping me 
to figure out why I'm wrong.


But, I don't think I'm the last one person making this mistake.

So, I hope we can change the driver mode name less confusing and more 
easy to understand.


First, svm should be removed, at least change it to ss 
(share-server), make it consistent with share-server.


I don't like single/multi, because that makes me think of numbers of 
share-servers, makes me want to ask: if I create a share, that share 
need multi share-servers ? why ?





I agree the names we went with aren't the most obvious, and I'm open to 
changing them. Share-server is the name we have for virtual machines 
created by manila drivers so a name that refers to share servers rather 
than svms could make more sense.


Also, when I trying glusterFS (installed it following 
http://www.gluster.org/community/documentation/index.php/QuickStart), 
when I testing the GlusterFS volume, it said: use one of the servers 
to mount the volume. Isn't that means using any server in the cluster 
can work and their work has no difference. So, is there a way to 
change glusterFS driver to add more than one glusterfs_target, and 
all glusterfs_targets are replications for each other. Then when 
manila create a share, chose one target to use. This would distribute 
data traffic to the cluster, higher bandwidth, higher performance, 
right ? == This is single_svm_mode, but obviously not single.


vponomaryov  ganso suggested basic_mode and advanced_mode, but I 
think basic/advanced is more driver perspective concept. Different 
driver might already have its own concept of basic advanced, beyong 
manila scope. This would make admin  driver programmer confusing.




I really do not like basic/advanced. I think you summarized one reason 
why it's a bad choice. The relevant difference between the modes is 
whether the driver is able to create tenant-specific instances of a 
share filesystem server or whether tenants share access to a single server.


As single_svm_mode indicate driver just have information about 
where to go and how, it is gotten by config opts and some special 
actions of drivers while multi_svm_mode need to create where and 
how with infomation.


My suggestion is

single_svm_mode == static_mode

multi_svm_mode  == dynamic_mode.

As where to go and how are static under single_svm_mode, but 
dynamically create/delete by manila under multi_svm_mode.\




Static/dynamic is better than basic/advanced, but I still think we can 
do better. I will think about it and try to come up with another idea 
before the meeting tomorrow.



Also, about the share-server concept.

share-server is a tenant point of view concept, it does not know if 
it is a VM or a dedicated hardware outside openstack because it is not 
visible to the tenant.


Each share has its own share-server, no matter how it get(get from 
configuration under single_svm_mode, get from manila under 
multi_svm_mode).




I think I understand what you mean here, but in a more technical sense, 
share servers are something we hide from the tenant. When a tenant asks 
for a share to be created, it might get created on a server that already 
exists, or a new one might get created. The tenant has no control over 
this, and ideally shouldn't even know which decision manila made. The 
only thing we promise to the tenant is that they'll get a share. The 
intent of this design is to offer maximum flexibility to the driver 
authors, and to accommodate the widest variety of possible storage 
controller designs, without causing details about the backends to leak 
through the API layer and break the primary goal of Manila which is to 
provide a standardized API regardless of what the actual implementation is.


We need to keep the above goals in mind when making decisions about 
share servers.


I get the wrong idea that about glusterFS has no share server based on 
https://github.com/openstack/manila/blob/master/manila/share/manager.py#L238, 
without reading driver code, isn't this saying: I create share without 
share-server. But, the truth is just share-server is not handled by 
manila, doesn't mean it not exist. E.g. in glusterFS, the share-server 
is self.gluster_address.


So, I suggest to edit ShareManager code to get share_server before 
create_share based on driver mode.


Such as:


Re: [openstack-dev] [Manila]Rename driver mode

2015-01-07 Thread Li, Chen
Update my proposal again:

As a new bird for manila, I start using/learning manila with generic driver. 
When I reached driver mode,I became really confuing, because I can't stop 
myself jump into ideas:   share server == nova instance   svm == share 
virtual machine == nova instance.

Then I tried glusterFS, it is working under single_svm_mode, I asked why it 
is single mode, the answer I get is  This is approach without usage of 
share-servers  ==  without using share-servers, then why single ??? 
More confusing ! :(


Now I know, the mistake I made is ridiculous.
Great thanks to vponomaryov  ganso, they made big effort helping me to figure 
out why I'm wrong.


But, I don't think I'm the last one person making this mistake.
So, I hope we can change the driver mode name less confusing and more easy to 
understand.


First, svm should be removed, at least change it to ss (share-server), make 
it consistent with share-server.
I don't like single/multi, because that makes me think of numbers of 
share-servers, makes me want to ask: if I create a share, that share need 
multi share-servers ? why ?

Also, when I trying glusterFS (installed it following 
http://www.gluster.org/community/documentation/index.php/QuickStart), when I 
testing the GlusterFS volume, it said: use one of the servers to mount the 
volume. Isn't that means using any server in the cluster can work and their 
work has no difference. So, is there a way to change glusterFS driver to add 
more than one glusterfs_target, and all glusterfs_targets are replications 
for each other. Then when manila create a share, chose one target to use. This 
would distribute data traffic to the cluster, higher bandwidth, higher 
performance, right ? == This is single_svm_mode, but obviously not single.


vponomaryov  ganso suggested basic_mode and advanced_mode, but I think 
basic/advanced is more driver perspective concept. Different driver might 
already have its own concept of basic advanced, beyong manila scope. This would 
make admin  driver programmer confusing.

As single_svm_mode indicate driver just have information about where to 
go and how, it is gotten by config opts and some special actions of drivers 
while multi_svm_mode need to create where and how with infomation.

My suggestion is
   single_svm_mode == static_mode
   multi_svm_mode  == dynamic_mode.

As where to go and how are static under single_svm_mode, but 
dynamically create/delete by manila under multi_svm_mode.


Also, about the share-server concept.

share-server is a tenant point of view concept, it does not know if it is a 
VM or a dedicated hardware outside openstack because it is not visible to the 
tenant.
Each share has its own share-server, no matter how it get(get from 
configuration under single_svm_mode, get from manila under multi_svm_mode).

I get the wrong idea that about glusterFS has no share server based on 
https://github.com/openstack/manila/blob/master/manila/share/manager.py#L238, 
without reading driver code, isn't this saying: I create share without 
share-server. But, the truth is just share-server is not handled by manila, 
doesn't mean it not exist. E.g. in glusterFS, the share-server is 
self.gluster_address.

So, I suggest to edit ShareManager code to get share_server before create_share 
based on driver mode.
Such as:
http://paste.openstack.org/show/155930/

This would affect all drivers, but I think it is worth for long term 
perspective.

Hope to hear from you guys.

Thanks.
-chen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Manila]Rename driver mode

2015-01-06 Thread Li, Chen
Hi list,



After study  https://wiki.openstack.org/wiki/Manila/Kilo_Network_Spec

I’d like to change my proposal.



Since driver mode is actually decide by its network situation, how about:

  static_network_mode

  ⇨ No share server

  ⇨ import share server from other place



  dynamic_network_mode

  ⇨ flat network

  ⇨ segmented network

  o share server at the same subnet of share network

  o share server connect to tenant subnet using router



The usecase would like this:



enabled_backends=generic1,generic2,glusterfs1



[generic1]

driver=manila.share.drivers.generic.GenericShareDriver

mode=dynamic_network_mode

network=network1



[generic2]

driver=manila.share.drivers.generic.GenericShareDriver

mode=static_network_mode

enable_share_server=True

share_server=server1



[glusterfs1]

share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver

glusterfs_target = manila:/manila-volume0

mode=static_network_mode

enable_share_server=False



[network1]

plugin=manila.network.Neutron

network_type=flat

network=192.168.10.0

netmask=255.255.255.0

gateway=192.168.10.1

ip_range=192.168.10.50-192.168.10.99



[server1]

server_type=nova

is_deletable=False

id=x


From: Li, Chen [mailto:chen...@intel.com]
Sent: Tuesday, December 30, 2014 5:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Manila]Rename driver mode

Hi list,

There are two driver modes in manila currently, “multi_svm_mode” and 
“single_svm_mode”.

multi_svm_mode means usage of share-networks that contain network information 
for dynamic creation of share-servers (SVMs).
single_svm_mode means usage of predefined some endpoint, without need to 
provide share-network and without creation of share-servers (SVMs).

Currently, the name of driver mode describes how many servers the driver can 
handle.
For multi, it says that share driver can handle more than one server.
And,  if someone share server is just already exist from share driver, but it 
uses some server anyway with host address, username, password, NFS daemon, 
etc... are defined as works in single_svm mode too.

But, as a new user to manila, these names make me really confusing.
Because I thought the driver mode names describe how drivers works with 
share-servers.
I thought “multi-” and “single-” indicate the number of share-servers would 
been created when we create a share, if we are using the driver.
Obviously, my understanding is wrong.

When we’re working under driver generic, one share-server would be created for 
one share-network.
When we’re working under driver glusterfs, no share-server would be created at 
all.

I believe I would not be the only one who is making this mistake.
To make code more readable, I’d like to suggest to rename driver mode names.

Name them based on behavior but not ability.

I think three driver modes are needed:


-  dynamic_svm_mode :

  Usage of share-networks that contain network 
information for dynamic creation of share-servers (SVMs).

  This is how current generic driver works.

  Under this mode, driver manages share servers 
itself,  and share-server would be created and deleted with related shares.



-  static_svm_mode:   Using pre-create share servers.

  The case as 
https://review.openstack.org/#/c/144342/

  Under this mode, driver do not manage share 
servers, but work with them.



-  no_svm_mode:  the case as driver glusterfs working currently, no 
share-server would be created.


Thanks.
-chen


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev