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:
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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
