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:


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

Hope to hear from you guys.



OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to