| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-21 | |||
| 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 | |
| 14:06:59 | bauzas | yeah, inactive just means that the instance doesn't use the share but it's still 'mapped' to it | |
| 14:07:13 | bauzas | whether the share is umounted or not, that's something internal | |
| 14:07:39 | bauzas | as you say, the share could be continued to be mounted, because used by other instances | |
| 14:07:55 | bauzas | now, back to the original question from gibi, | |
| 14:08:08 | bauzas | there are two possibilities | |
| 14:08:13 | sean-k-mooney | for me active means we have done what is required in nova and maniall so that the vm can use it if you start the vm | |
| 14:08:52 | Uggla | sean-k-mooney, no active means VM is up and uses the share. | |
| 14:09:07 | sean-k-mooney | then it has no extra info | |
| 14:09:15 | bauzas | IMHO, I think that a detach action that eventually goes into unmounting and which is impossible to do so should make the instance action on error | |
| 14:09:17 | sean-k-mooney | that is what instnace status=active means | |
| 14:09:32 | bauzas | or we need a periodic | |
| 14:09:49 | bauzas | but honestly, I think we should say the truth | |
| 14:10:22 | sean-k-mooney | the active status of a share mappign shoudl not depend on the vm status (active vs powered off) | |
| 14:10:41 | bauzas | that's written in the spec | |
| 14:10:42 | sean-k-mooney | these are two diffenet logical resouces in the api | |
| 14:11:36 | gibi | bauzas: it is not about the instance action but about the state of the sharemapping. We can keep it inactive or we can put it in error. | |
| 14:12:37 | bauzas | gibi: I got that, lemme summarize the exception handling case | |
| 14:12:59 | bauzas | user stops a VM, share mapping goes inactive | |
| 14:13:12 | sean-k-mooney | looking at the Share mapping status diagram in the spec | |
| 14:13:21 | bauzas | when it stops the VM, some internal call is doing two actions : | |
| 14:13:34 | bauzas | 1/ detach the share from the VM | |
| 14:13:43 | sean-k-mooney | i can see where you were going with it but it does not follow the same conventiosn as cinder or neutron ports | |
| 14:13:47 | bauzas | 2/ umount the share if not used elsewhere | |
| 14:14:04 | gibi | bauzas: OK so you suggest to do the unmount during stop, not during the detach REST API call | |
| 14:14:20 | sean-k-mooney | well the spec says we do the unmount during stop | |
| 14:14:21 | bauzas | nah, sorry | |
| 14:14:28 | bauzas | I'm waaaay confused | |
| 14:14:39 | bauzas | user has to do two actions then | |
| 14:14:44 | bauzas | stop then detach | |
| 14:14:50 | bauzas | right? | |
| 14:14:56 | Uggla | yep | |
| 14:15:00 | bauzas | and detach does two things | |
| 14:15:04 | bauzas | (internally) | |
| 14:15:16 | bauzas | one is updating the guest XML | |
| 14:15:23 | gibi | nope | |
| 14:15:25 | bauzas | the other is to umount the share | |
| 14:15:32 | gibi | the vm is stopped no need to update the XML | |
| 14:15:41 | Uggla | gibi ++ | |
| 14:15:57 | bauzas | my head is full of vGPU crap for now | |
| 14:16:03 | gibi | the XML is generated during start based on the share_mappings | |
| 14:16:05 | bauzas | I have to reload that context | |
| 14:16:12 | sean-k-mooney | the vm is stopped meaning the share is also unmoutned already | |
| 14:16:17 | gibi | not | |
| 14:16:21 | gibi | today | |
| 14:16:31 | sean-k-mooney | in the spec that what the diagram states | |
| 14:16:39 | gibi | today stop is not unmounting the share from the host | |
| 14:16:50 | gibi | OK, then that is a gap between the spec and the code | |
| 14:16:51 | sean-k-mooney | well that is not in line with the spec then | |
| 14:16:54 | sean-k-mooney | yep | |
| 14:17:09 | sean-k-mooney | what in the spec i think aligns with what i would like to see | |
| 14:17:09 | gibi | do we want to move the host unmount to stop? | |
| 14:17:25 | sean-k-mooney | if we do that then detach cant fail in this edge case | |
| 14:17:35 | gibi | and do we want to fail the stop action if unmount fails? | |
| 14:18:02 | bauzas | do we all agree on the fact that unmount is not strictly required ? | |
| 14:18:15 | sean-k-mooney | and i belive unmounting the share (if no other vm is using it) in stop is also more secure | |