| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-29 | |||
| 13:33:22 | gibi | bauzas: so if you test it you can start with ceph to increase manual coverage :) | |
| 13:33:35 | gibi | I'm reviewing the code now | |
| 13:34:11 | bauzas | OK | |
| 13:34:26 | bauzas | I needed to work last week on a lot of changes, but I can start | |
| 13:34:54 | bauzas | I also need to test my own mdev live-migration series :) | |
| 15:43:18 | opendevreview | Merged openstack/nova master: Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | |
| 16:34:25 | bauzas | Uggla: now that patch is merged, a gentle reminder that I asked you a follow-up patch for https://review.opendev.org/c/openstack/nova/+/839401/36/nova/objects/share_mapping.py#93 | |
| 16:35:15 | Uggla | @bauzas, I'll do it no pb. | |
| 16:46:15 | opendevreview | zhouzhong proposed openstack/nova master: Validate flavor image min ram when resizing a volume-backend instance https://review.opendev.org/c/openstack/nova/+/906813 | |
| 17:43:05 | gibi | Uggla: I see a discrepancy between the spec and the impl | |
| 17:43:07 | gibi | The spec says | |
| 17:43:09 | gibi | Share attachment/detachment can only be done if the VM state is ``STOPPED`` | |
| 17:43:12 | gibi | or ``ERROR``. | |
| 17:43:15 | gibi | These are operations only on the database, and no RPC calls will be required | |
| 17:43:18 | gibi | to the compute API. This is an intentional design for this spec. | |
| 17:43:20 | gibi | As a result, this could lead to situation where the VM start operation fails | |
| 17:43:23 | gibi | as an underlying share attach fails. | |
| 17:43:26 | gibi | -- | |
| 17:43:37 | gibi | But I see that the actauly host attachment happens during the attach API call in my devstack | |
| 17:43:53 | gibi | is it intentional? | |
| 17:45:30 | Uggla | @gibi, if I'm not wrong this case is handled or I misunderstand something. If the share is in error it is "discarded" from the list and the VM should start. | |
| 17:45:42 | Uggla | If think it is in get_share_info | |
| 17:46:58 | gibi | my point is the spec states that attaching a share via the REST API is a DB only operation. But in my devstack the host attachment happens during the attach REST API call. | |
| 17:52:20 | gibi | I guess the original plan was to do the share attachment to the host during the VM start, but for some reason it is moved to the share attach call. | |
| 17:54:13 | Uggla | yes we discussed that, we moved from that because it made it more complex and causes some issue. But I do not remember well what were the issues. | |
| 17:54:54 | gibi | The current design means that all the share mounting logic and the retry loop waiting for the share access setup from manial is in a syncronous RPC call that holds up the share attach REST API response. | |
| 17:55:33 | Uggla | yes. It was the intention to have it syncronous. | |
| 17:57:05 | gibi | OK. If bauzas is OK with this then I can accept it, but we need to document for the share_apply_policy_timeout that it cannot be set over our RPC timeout as that will lead to strange errors. | |
| 17:57:13 | Uggla | I remembered discussing that with @bauzas too. | |
| 17:57:17 | bauzas | I quickly looked | |
| 17:57:22 | gibi | and we need to amend the spec | |
| 17:57:24 | bauzas | I need to leave by now | |
| 17:58:00 | bauzas | I obvisouly need to reload that context in my mind | |
| 17:58:41 | bauzas | oh I remember | |
| 17:58:44 | Uggla | @bauzas, I'm sure we discussed that synchronous etc stuff. But this is old discussion I don't remember well. | |
| 17:59:09 | bauzas | the fact is that you start making it asynchronous (which is OK with me) then you need to manage the states somewhere | |
| 17:59:41 | gibi | bauzas: the spec said that the share attach REST API is DB only so I assume the state is managed in the DB :) | |
| 18:00:40 | gibi | also I understood from the spec that the host mount happens during the start_instance RPC | |
| 18:00:58 | bauzas | because the instance has to be in stopped state, right? | |
| 18:01:03 | bauzas | (as a precondition) | |
| 18:01:05 | gibi | yes | |
| 18:01:41 | bauzas | I'm a bit afraid of a blocking call, I may have missed it | |
| 18:02:11 | Uggla | If I remember well, doing it at power_on led to "large" change in the error handling of power_on / power_off and other actions. | |
| 18:02:13 | bauzas | gibi: you only saw that behaviour by testing, right? I'm saying that because I haven't yet reviewed the API change | |
| 18:02:32 | bauzas | and I guess the blocking call to the compute RPC API is made there | |
| 18:02:37 | gibi | bauzas: I saw that in testing, but I can probably dig up the RPC call from the API code | |
| 18:02:59 | bauzas | no worries, I was just asking because I missed your very good point when reviewing | |
| 18:03:14 | bauzas | so it should have been done later in the API patch, or I am blind | |
| 18:03:36 | gibi | bauzas: https://review.opendev.org/c/openstack/nova/+/836830/42/nova/api/openstack/compute/server_shares.py#150 | |
| 18:03:44 | bauzas | Uggla: I think that we more likely discussed on how to decouple the RPC call | |
| 18:03:55 | bauzas | but not *when* we were calling it | |
| 18:04:10 | bauzas | (*when* or *where* if you prefer) | |
| 18:04:33 | bauzas | yeah, OK, I'm not blind, I just haven't went up to that point | |
| 18:05:41 | bauzas | Uggla: IIRC we discussed on decoupling two actions that were made in one lockstep | |
| 18:05:54 | bauzas | the first one was to "allocate" the mapping | |
| 18:06:01 | bauzas | the other one was to "mount" it | |
| 18:06:38 | bauzas | in your early patches, iirc you were doing all of them thru the compute manager and I asked you to provide RPC methods for differenciating both actions | |
| 18:06:52 | bauzas | amirite? | |
| 18:11:21 | Uggla | bauzas, we discussed the call /cast and yes all the previous code used the compute part, and we changed in that way. If I'm not wrong. | |
| 18:11:40 | Uggla | I have the old code somewhere, I could check. | |
| 18:11:45 | bauzas | ok, that's then a good news | |
| 18:11:57 | bauzas | I'm not yet forgetting everything | |
| 18:12:11 | bauzas | so, now you decoupled both actions, | |
| 18:12:32 | bauzas | you need to just ensure to issue those two actions in the right lifecycle we agreed | |
| 18:12:59 | bauzas | meaning that you should call the share mount only when the instance is starting | |
| 18:13:32 | bauzas | get rid of that single line : https://review.opendev.org/c/openstack/nova/+/836830/42/nova/api/openstack/compute/server_shares.py#150 | |
| 18:14:13 | bauzas | and just call mount_share in the compute manager | |
| 18:14:21 | bauzas | when the instance is starting | |
| 18:14:44 | bauzas | later you could call the RPC bus for that, but that would be for other actions | |
| 18:15:39 | Uggla | nope we revert from that, to not mount in the compute part. | |
| 18:16:06 | Uggla | that was the "original" code. | |
| 18:19:19 | bauzas | Uggla: let's do a gmeet with gibi tomorrow | |
| 18:19:31 | bauzas | this is late for all of us :) | |
| 18:20:13 | Uggla | ok yes and I'm cooking in // so I can not follow well. | |
| 18:21:54 | gibi | ack | |
| #openstack-nova - 2024-01-30 | |||
| 13:04:59 | gibi | I've reviewed the manila series up to the API patches left questions and feedback along the way | |
| 13:29:44 | bauzas | gibi: I'll review the series too today | |
| 13:38:11 | fwiesel | bauzas: Do you happen to know how to add a CI to the "Third Party CI mail filter list"? According to the Wiki it would be contacting the Third Party Coordinators (https://review.opendev.org/admin/groups/440), but I am hesitant to write them directly. Also I've heard two of those people have left the openstack community years ago. | |
| 13:48:35 | bauzas | fwiesel: good question, I think you should rather ask the infra team | |
| 13:49:09 | bauzas | please join #openstack-infra and then I'll ask the folks there | |
| 14:14:53 | opendevreview | Arnaud Morin proposed openstack/nova master: Fix tipo https://review.opendev.org/c/openstack/nova/+/907208 | |
| 14:31:42 | Uggla | @gibi, @bauzas I think bauzas wanted to discuss https://review.opendev.org/c/openstack/nova/+/836830/comment/ac1b1f5f_024fa843/. But I could not do it till the end of nova meeting. | |
| 14:32:18 | bauzas | tomorrow morning then ? | |
| 14:32:42 | bauzas | I can review your series meanwhilz | |
| 14:32:48 | Uggla | @gibi, @bauzas so we can do a gmeet right after the meeting or I think it is better tomorrow morning. | |
| 14:33:37 | Uggla | bauzas, yep do you want me to create an invite or we will do it on the fly tomorrow morning ? | |
| 14:40:33 | gibi | I'm available from 9:00 CET to 10:30 CET tomorrow morning. | |
| 14:57:45 | bauzas | 9am CET works for me | |
| 14:59:29 | gibi | Uggla: if 9:00 CET works for you to then please send an invite | |
| 15:08:42 | Uggla | gibi, bauzas works for me too. I'll create an invite | |
| 15:08:47 | gibi | thanks | |
| 15:20:36 | gibi | I've added my topics to https://etherpad.opendev.org/p/nova-caracal-status | |
| 15:31:34 | Uggla | gibi, btw thanks for your review. | |
| 15:58:47 | bauzas | nova meeting in 2 mins | |
| 16:00:27 | bauzas | #startmeeting nova | |
| 16:00:27 | opendevmeet | Meeting started Tue Jan 30 16:00:27 2024 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:00:27 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:27 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:41 | bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 16:00:45 | bauzas | hello folks | |