Re: [openstack-dev] [Manila]Rename driver mode
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
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
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
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