| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-21 | |||
| 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 | |
| 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 | |