| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-28 | |||
| 02:15:17 | opendevreview | Ghanshyam proposed openstack/nova master: HyperV: Remove extra specs of HyperV driver https://review.opendev.org/c/openstack/nova/+/906992 | |
| #openstack-nova - 2024-01-29 | |||
| 02:23:48 | gmann | bauzas: sean-k-mooney:dansmith: removing HyperV driver/APIs are up for review, please check https://review.opendev.org/q/topic:%22bp/remove-hyperv-driver%22 | |
| 06:45:55 | opendevreview | Amit Uniyal proposed openstack/nova master: Allow swap resize from non-zero to zero https://review.opendev.org/c/openstack/nova/+/857339 | |
| 08:40:32 | gibi | elodilles: when you have time could you take a look https://review.opendev.org/q/topic:%22power-mgmt-fixups%22+branch:stable/2023.2 ? | |
| 08:41:25 | gibi | hold on, I was naively thought the master rever landed | |
| 08:50:51 | elodilles | gibi: i'll have a look soon | |
| 08:51:10 | elodilles | i mean just after master poatch has landed :D | |
| 08:52:28 | gibi | I know the rules :) | |
| 10:49:21 | opendevreview | Merged openstack/python-novaclient master: Update hacking version in pre commit config https://review.opendev.org/c/openstack/python-novaclient/+/906964 | |
| 11:16:58 | sean-k-mooney | gmann: thanks ill try and make my way through that series this week | |
| 11:17:31 | sean-k-mooney | skimming over it, the patches make sense | |
| 13:31:49 | gibi | bauzas: did you deploy the manila series in devstack? if so which backend you used nfs, or ceph? | |
| 13:32:06 | bauzas | nope I just reviewed the code for the moment | |
| 13:32:30 | bauzas | until we merge the API change, it's not a problem if we don't test it | |
| 13:33:04 | gibi | bauzas: I just tested it with nfs backend and it worked for me | |
| 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. | |