sylvanld | Hello everyone! I was playing with subnet deletion API and I have a quick question :) Our use case: we want a share to be attached to multiple subnets that might change, so we need to be able to add/remove subnets from a share network that is attached to a share though a share server. Question: I can't figure out why currently share server is deleted on share-network-subnet deletion (other subnets might be | 13:06 |
---|---|---|
opendevreview | Renan Vitor proposed openstack/manila master: [NetApp] Fix NetApp driver create from snapshot https://review.opendev.org/c/openstack/manila/+/883175 | 13:27 |
sylvanld | Hello! we want a share to be attached to multiple subnets that might change, so we need to be able to add/remove subnets from a share network that is attached to a share though a share server. | 13:40 |
sylvanld | Question: why are share servers deleted on share-network-subnet deletion? Other subnets might be configured on it, so IMO share-server lifecycle seems more related to the share than the subnet. | 13:43 |
sylvanld | Other related question: Currently we can't delete a subnet that is used by a share. Why this choice of design? (We would like to be able to change the subnets of a share without destroying it) | 13:48 |
sylvanld | I am asking a few questions to understand whether a blueprint might be appropriate. If so I would happy to help with implementation :) | 13:50 |
carloss | o/ hey there sylvanld | 13:51 |
carloss | > Question: why are share servers deleted on share-network-subnet deletion? | 13:51 |
carloss | is this happening when you already have two subnets attached? | 13:51 |
carloss | > I am asking a few questions to understand whether a blueprint might be appropriate. If so I would happy to help with implementation :) | 13:51 |
carloss | oh, great :) | 13:51 |
carloss | please feel free to fire questions away :) | 13:52 |
carloss | we also have some maintainers that made some changes to share network subnets attached to multiple server recently, so they can back me up :) | 13:52 |
carloss | yeah, we are not allowing the deletion of the share network subnets when they have shares attached to it | 13:56 |
carloss | I wouldn't have problems against it though | 13:56 |
carloss | I mean, not if you have other share network subnets also attached to the share server | 13:56 |
sylvanld | > is this happening when you already have two subnets attached? | 13:57 |
carloss | nahimsouza[m] felipe_rodrigues: do you have some background on this? do you recall if we have limitations wrt this? | 13:58 |
sylvanld | With current implementation, we can only delete subnet if no share has been created yet with this share network. So no share network exists. | 13:58 |
sylvanld | * no -share-server sry | 13:58 |
sylvanld | > I mean, not if you have other share network subnets also attached to the share server | 14:01 |
sylvanld | I had a quick look at the code. I was wondering why having at least one subnet in a share network is mandatory ? | 14:01 |
sylvanld | I mean the share won't have any export path, but IMO there is no problem with this behaviour | 14:03 |
nahimsouza[m] | <carloss> "nahimsouza felipe_rodrigues..." <- hey guys, sorry carloss, I don't know much about the design decisions for share network subnets, I would need to analyze the code before answering this... but right now I don't recall of any limitations | 14:12 |
carloss | > I had a quick look at the code. I was wondering why having at least one subnet in a share network is mandatory ? | 14:14 |
carloss | sylvanld: it iss important to ensure that the share will always be tied to a share network subnet, which holds the allocation details for the share server, where the share is located | 14:14 |
carloss | if a share exists and it does not have an export location, then the share becomes "useless" I'd say, as no one can mount that share | 14:15 |
carloss | and if you drop a share network subnet when there are sharesthere, the driver would remove the allocation and the current mounts would be disrupted | 14:16 |
carloss | s/sharesthere/shares there | 14:17 |
sylvanld | > if a share exists and it does not have an export location, then the share becomes "useless" I'd say | 14:23 |
sylvanld | I agree but it might get one later once a new subnet is added to the share-network. Not a big deal for our use case anyway. We could simply add subnetB before removing subnetA. | 14:24 |
sylvanld | > if you drop a share network subnet when there are shares there, the driver would remove the allocation and the current mounts would be disrupted | 14:31 |
sylvanld | I understand that this can cause unintended behaviour. But as a manila user, I expect to be able to do it. | 14:31 |
sylvanld | Maybe by setting some kind of flag through query params to indicate I know the consequences of what I am doing. (E.G: umount_existing_shares=true) | 14:32 |
sylvanld | What do you think about it ? | 14:32 |
carloss | sylvanld: --force in this case would be the way to go, I think. Specially if we consider that when we want to force something in other operations, that's the pattern we follow | 14:41 |
carloss | unmount_existing_shares flag would sound a bit like "manila knows who is mounting this share and we will umount them at the end of this operation", when it actually doesn't | 14:42 |
carloss | > We could simply add subnetB before removing subnetA. | 14:43 |
carloss | I'd say I prefer ^ over forcing the deletion of the subnet and the share becoming unavailable for some time | 14:43 |
carloss | even though we would expect the operator know what they are doing, this could be way too disruptive and impact many shares at once | 14:44 |
carloss | other people might have different opinions though :) | 14:44 |
carloss | gouthamr: thoughts? :) | 14:44 |
gouthamr | hey sylvanld carloss: i'm catching up now, so may be slow | 14:47 |
gouthamr | > Question: why are share servers deleted on share-network-subnet deletion? Other subnets might be configured on it, so IMO share-server lifecycle seems more related to the share than the subnet. | 14:47 |
gouthamr | ^ would you like a behavior where manila doesn't cleanup share servers after deletion of shares? if yes, there is a configuration option to force this behavior | 14:48 |
gouthamr | ``delete_share_server_with_last_share``: https://docs.openstack.org/manila/latest/configuration/shared-file-systems/config-options.html#id10 | 14:50 |
sylvanld | > would you like a behavior where manila doesn't cleanup share servers after deletion of shares? if yes, there is a configuration option to force this behavior | 14:54 |
sylvanld | No, it is more related to share_network_subnets API. I would like to delete a subnet of a share-network used by one or many share(s) | 14:56 |
sylvanld | This is not possible currently, but I was trying to figure out what would occurs if it was authorized. | 14:58 |
gouthamr | ack; then i agree with the thought process here; if were to allow deletion of subnets, we'd need atleast one subnet connected - so if you were replacing an existing subnet, we could allow adding the new one and then removing the other one.. | 15:00 |
gouthamr | sylvanld: https://specs.openstack.org/openstack/manila-specs/specs/release_independent/share-server-multiple-subnet.html -- this was supposed to be a multi-part specification | 15:00 |
gouthamr | felipe_rodrigues isn't here today; but i think in one of the earlier iterations of the spec, he was seeking the ability to remove subnet/s as well | 15:01 |
gouthamr | sylvanld: if you plan to implement that feature, a short spec would help and we can brainstorm the implications | 15:05 |
sylvanld | > if you plan to implement that feature, a short spec would help and we can brainstorm the implications | 15:08 |
sylvanld | Is a blueprint here the good place to start this kind of spec? https://blueprints.launchpad.net/manila | 15:09 |
gouthamr | sylvanld: yes please, and there's a specs repository: https://opendev.org/openstack/manila-specs --- this is where we host design docs; we review them the same way as we review code (via review.opendev.org) | 15:15 |
gouthamr | sylvanld: here are some open specs being reviewed at the moment: https://review.opendev.org/q/project:openstack%252Fmanila-specs+status:open | 15:15 |
gouthamr | a blueprint is helpful because a feature may have multiple code changes and blueprints make that easy to track for posterity | 15:18 |
gouthamr | but the tool doesn’t allow conversations/review | 15:19 |
sylvanld | gouthamr: great! I will create a first version of this spec to discuss this :) | 15:23 |
sylvanld | thanks everyone! | 15:23 |
gouthamr | perfect, thanks sylvanld | 15:25 |
rdupontovh | Hi, i work with sylvanld and have an other small topic to discuss while we're at it gouthamr :) | 15:31 |
rdupontovh | about this change: https://review.opendev.org/c/openstack/manila/+/880852 | 15:31 |
rdupontovh | we had some discussion about https://bugs.launchpad.net/manila/+bug/2012742 but it stopped last month :D | 15:32 |
gouthamr | ah my bad rdupontovh | 15:32 |
rdupontovh | no problem | 15:32 |
gouthamr | meant to take another look at it; you taught me about Oslo config drivers! so thanks! :) | 15:32 |
carloss | thanks sylvanld :D | 15:40 |
opendevreview | Merged openstack/devstack-plugin-ceph stable/wallaby: Cap cinder-tempest-plugin version for stable/wallaby https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/871920 | 19:33 |
opendevreview | Goutham Pacha Ravi proposed openstack/devstack-plugin-ceph master: Update default ceph version to "quincy" https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/883444 | 20:35 |
opendevreview | Merged openstack/manila-tempest-plugin master: [CI] Fix cephfs-nfs job by running on centos-stream-9 https://review.opendev.org/c/openstack/manila-tempest-plugin/+/882624 | 22:46 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!