| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-21 | |||
| 13:48:48 | bauzas | I think Uggla doesn't support already mounted shares without having share mappings | |
| 13:48:52 | bauzas | Uggla: right? | |
| 13:48:57 | sean-k-mooney | thats fine | |
| 13:49:06 | sean-k-mooney | we can keep the vm in stopped with the share attach | |
| 13:49:13 | sean-k-mooney | and the instnace action in error | |
| 13:49:31 | sean-k-mooney | and then the user can either start the vm or try the detach again | |
| 13:49:32 | bauzas | yeah | |
| 13:49:35 | sean-k-mooney | depending on what they want | |
| 13:49:50 | bauzas | if they start the instance, they will have the share in it | |
| 13:49:58 | sean-k-mooney | if that is the approch we take then we dont need a perodic | |
| 13:50:05 | Uggla | I could add a detach force option, that will allow the instance to start ? (but leak the share, I could avoid db surgery) | |
| 13:50:06 | sean-k-mooney | yep | |
| 13:50:27 | sean-k-mooney | Uggla: please no :) we have scares form any time we add force | |
| 13:50:38 | Uggla | ok | |
| 13:50:39 | bauzas | Uggla: I can't remember, does your series support to look at shares that are altrady mounted ? | |
| 13:50:51 | sean-k-mooney | i think if we just start with the share mounted as if you never tired the detach then we are good | |
| 13:51:08 | sean-k-mooney | we just need to make sure that we dont update the vm unless the host unmount works | |
| 13:51:19 | Uggla | bauzas, yes you will be able to see the share in error state. | |
| 13:51:32 | sean-k-mooney | Uggla: the share does not need to be in error | |
| 13:51:42 | sean-k-mooney | the share can stay in attached/in-use | |
| 13:51:48 | sean-k-mooney | the instance action should be in error | |
| 13:52:00 | sean-k-mooney | oh actully | |
| 13:52:08 | sean-k-mooney | detach is not an instance ac tion n the normal case | |
| 13:52:17 | sean-k-mooney | do we have an instnace action event for detach | |
| 13:53:02 | sean-k-mooney | if we are going t oboot the vm with the share attached then the share attachemnt state should not be error | |
| 13:53:07 | Uggla | sean-k-mooney, yes there will have an instance action for detach. | |
| 13:53:11 | bauzas | Uggla: I need to look again at the spec then | |
| 13:53:16 | sean-k-mooney | ack then ya only that need to go to error | |
| 13:53:28 | sean-k-mooney | eveything else can keep its previous status | |
| 13:53:32 | bauzas | because I think users shouldn't know whether the share is already mounted or not | |
| 13:53:57 | sean-k-mooney | correct | |
| 13:53:59 | sean-k-mooney | we should not leak that | |
| 13:54:13 | sean-k-mooney | we should just report we failed to detach the share form the vm | |
| 13:54:33 | bauzas | tbc, I thought the detail was: | |
| 13:54:33 | sean-k-mooney | and unmounting it is part of that internally but not somethign we should tell the use via the api | |
| 13:54:45 | bauzas | as an user, I want to attach an instance to a share | |
| 13:54:58 | bauzas | it will create a share mapping | |
| 13:55:17 | bauzas | eventually, when I'm starting, then nova looks at the share | |
| 13:55:26 | bauzas | if the share is already mounted, cool | |
| 13:55:36 | bauzas | if the share needs to be mounted, all cool too, it does it now | |
| 13:55:42 | bauzas | right? | |
| 13:55:52 | sean-k-mooney | thats my expectation | |
| 13:56:28 | sean-k-mooney | the user contract is if a share mappign exits between an instnace and a share | |
| 13:56:47 | Uggla | bauzas, no. User need to ensure the share is in active status (means it is mounted and VM and share has a link) | |
| 13:56:52 | sean-k-mooney | if we start the instance then nova will do whatever is required to ensure teh vm starts with the share | |
| 13:57:07 | bauzas | Uggla: okay, hence my needing to look at your spec | |
| 13:57:16 | Uggla | I mean if you start the VM and the share is still in "attaching status" then it will fail. | |
| 13:57:22 | bauzas | Uggla: when is the share checked whether it's mounted ? | |
| 13:57:41 | bauzas | inactive == mounted, while active == mounted, right ? | |
| 13:57:46 | sean-k-mooney | Uggla: that sounds wrong to me | |
| 13:57:46 | bauzas | doh | |
| 13:57:51 | bauzas | inactive == unmounted | |
| 13:58:21 | bauzas | there it goes, opening https://specs.openstack.org/openstack/nova-specs/specs/2024.1/approved/libvirt-virtiofs-attach-manila-shares.html | |
| 13:58:27 | sean-k-mooney | the use should not have to pool the share mapping status to start the vm | |
| 13:58:42 | sean-k-mooney | when the vm is stopp and we attach a share | |
| 13:58:53 | sean-k-mooney | we should be able to do start immietaly | |
| 13:59:12 | gibi | but then there will be a race between the mount RPC and the start RPC | |
| 13:59:23 | bauzas | "Mount operation will be done when the share is not mounted on the compute host. If a previous share would have been mounted on the compute host for another server, then it will attempt to mount it and a warning will be logged that the share was already mounted." | |
| 13:59:23 | Uggla | bauzas, nothing = nothing, attaching = attach in progress, inactive = share mounted and ready, actif = Vm up and share readable | |
| 13:59:29 | bauzas | it doesn't say when we mount | |
| 13:59:37 | sean-k-mooney | well the mount api call can only return after the mapping is created in the db | |
| 13:59:46 | sean-k-mooney | so there should not be a race | |
| 14:00:00 | sean-k-mooney | or rather theer does not need to be a race | |
| 14:00:01 | gibi | the race would be about the host mount not about the DB | |
| 14:00:14 | sean-k-mooney | right but spwan should be ensuring the mount | |
| 14:00:21 | bauzas | Uggla: nothing == nothing, that's the "phi" you have in the spec ? | |
| 14:00:30 | gibi | but we have a separate RPC to ensure the mount | |
| 14:00:34 | Uggla | yep. | |
| 14:00:46 | gibi | it is not the spawn that does the host mount | |
| 14:01:08 | bauzas | gibi: when is called that RPC method ? | |
| 14:01:10 | sean-k-mooney | that soudn incorrect to me | |
| 14:01:19 | bauzas | shit, I need to go in meeting | |
| 14:01:21 | gibi | bauzas: during the attach REST API call | |
| 14:01:44 | bauzas | ah, now I remember, that's the async RPC call | |
| 14:02:04 | gibi | if I understood Sean correctly they want to do the host mount during spawn instead | |
| 14:02:13 | sean-k-mooney | yep | |
| 14:02:28 | bauzas | I'm fine whenever | |
| 14:02:52 | sean-k-mooney | i would also expect the share to be unmoutned when we stop the vm for what its worth | |
| 14:02:58 | bauzas | my point is that the share mount can be done whenever we want, at least *before* we start | |
| 14:03:14 | sean-k-mooney | because i would expect hard reboot to unmount it and remount it | |
| 14:03:24 | sean-k-mooney | since we normally use hard reboot to fix things like that | |
| 14:03:24 | bauzas | sean-k-mooney: you can attach the same mount multiple times | |
| 14:03:30 | sean-k-mooney | thats fine | |
| 14:03:53 | sean-k-mooney | the mount and unmount could be based on the first/last active vm | |
| 14:04:16 | sean-k-mooney | or better each instance could have its onw mount and we could avoid reusign it. that what i orgianly wanted in the spec | |
| 14:04:25 | bauzas | sean-k-mooney: fwiw, in the spec it says that an instance stop does make the share umounted | |
| 14:04:30 | sean-k-mooney | to have the same share mounted multipel times in seperat locations | |
| 14:04:35 | sean-k-mooney | but i know that is not what is in the code | |
| 14:04:37 | bauzas | so it's already fine | |
| 14:04:51 | bauzas | (if the implementation is the same) | |
| 14:04:51 | sean-k-mooney | so a few weeks ago i was sruprised | |
| 14:05:01 | gibi | I guess the RPC during the attach REST API call is created to prepare for the future when a share can be mounted live without a stop/start cycle. | |
| 14:05:02 | sean-k-mooney | wehn the share was not mounted under the instance state dir | |
| 14:05:28 | sean-k-mooney | because i was orgianlly expecting the share not to be shared betwen instnace on the same host | |
| 14:05:28 | bauzas | I think the word "inactive" is correct | |
| 14:05:39 | bauzas | nothing is using the share | |
| 14:05:52 | bauzas | but we still have the reservation | |
| 14:06:13 | sean-k-mooney | bauzas: the active/inactive state of a share mapping cant be mapped ot if its mounted on the hsot | |
| 14:06:27 | bauzas | I hope so | |
| 14:06:32 | sean-k-mooney | since if we are sharing the mount point betwen vms it woudl depend on if other vms on the host are using it | |