| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-06-04 | |||
| 16:31:50 | sean-k-mooney | this is us doing a read call to check the status fo the job | |
| 16:31:58 | erlon | I was actually thinking and just returning, an empty info and leave nova call it again in the next periodic task, since this is just a info report | |
| 16:31:58 | sean-k-mooney | bauzas: and neutorn and cinder | |
| 16:32:48 | sean-k-mooney | perhaps or catching it an logging a warning | |
| 16:32:56 | sean-k-mooney | rather then a trace back | |
| 16:33:03 | bauzas | I wouldn't hide | |
| 16:33:11 | sean-k-mooney | anywya if you have a repoducer we can discuss the solution in gerrit | |
| 16:33:12 | bauzas | if I were catching that exception | |
| 16:34:00 | erlon | to the destination host, it is not properly cleaned up on the source host. | |
| 16:34:00 | erlon | periodic tasks do not complete the migration. Consequently, while the VM is migrated | |
| 16:34:00 | erlon | The issue with the current process is that, although it triggers the section again, the | |
| 16:34:03 | bauzas | honestly, exception giving a better log to the operator saying 'libvirt is getting weirdo, see", I don't see the benefit of adding another handler to a periodic | |
| 16:34:11 | opendevreview | Merged openstack/nova stable/2023.2: Improve logging at '_numa_cells_support_network_metadata' https://review.opendev.org/c/openstack/nova/+/900840 | |
| 16:34:30 | bauzas | anyway, we have three other topics to discuss | |
| 16:34:45 | bauzas | erlon: please file a bug report and come to us once's done | |
| 16:34:56 | erlon | Okay, let's move, thanks | |
| 16:34:57 | bauzas | and yeah, a reproducer may help | |
| 16:35:11 | bauzas | particularly with some mitigation actions | |
| 16:35:25 | bauzas | like, I know libvirt gives me this but we can workaround by that | |
| 16:35:49 | bauzas | that way, we could log a better warning than just "heh, look, that's what I got from libvirt" | |
| 16:36:04 | bauzas | moving on anyway | |
| 16:36:14 | bauzas | next item (2 of 4) | |
| 16:36:19 | bauzas | marlinc: rotation_rate blueprint: https://blueprints.launchpad.net/nova/+spec/rotation-rate | |
| 16:36:32 | bauzas | I guess you're asking for a specless approval ? | |
| 16:37:00 | marlinc | Honestly I am not entirely sure what is best, I thought specless might work for this but I'm not sure | |
| 16:37:10 | bauzas | that's the point | |
| 16:37:26 | bauzas | you're saying you would get the detail from the cinder connection info | |
| 16:37:31 | bauzas | do we already have that ? | |
| 16:37:53 | sean-k-mooney | if we add a new compute service version for this and a min compute service version check i think that woudl resolve most if not all the upgrade concerns | |
| 16:38:07 | marlinc | Yes so we have an internal Cinder driver for our own storage platform which does give that property in the cinder connection info, we didn't have change anything in Cinder itself | |
| 16:38:12 | bauzas | I would honestly then recommend to write a spec | |
| 16:38:26 | sean-k-mooney | marlinc: is there an upstream driver that support this | |
| 16:38:31 | bauzas | there could be some upgrade and compatibility concerns I may see | |
| 16:38:36 | sean-k-mooney | marlinc: without that we can proceed with this in nova | |
| 16:38:47 | sean-k-mooney | we do not add supprot for out of tree drivers in other project | |
| 16:38:49 | marlinc | No there is currently no upstream driver that has this | |
| 16:39:12 | bauzas | then we can't just modify nova to blindly check anything that's not upstream | |
| 16:39:22 | sean-k-mooney | so implementing this in the lvm or a diffent intree cinder driver would likely be a requirement if we did this for cinder only | |
| 16:39:29 | bauzas | spec it is | |
| 16:39:49 | bauzas | and I guess you probably need to discuss that with the cinder folks | |
| 16:40:24 | marlinc | Oke I will look into creating a spec and also see if I can get this implemented in a in-tree driver | |
| 16:41:13 | bauzas | thanks | |
| 16:41:26 | bauzas | ping me anytime if you require assistance on the paperwork process | |
| 16:41:27 | marlinc | I'm going to have to see how to implement the min compute service version check and bump | |
| 16:41:42 | sean-k-mooney | marlinc: i would proably add it to the lvm driver personally, i think it woudl be relvitly simple to do | |
| 16:41:58 | bauzas | before doing anything with version checks, please check with the cinder folks about populating the rotation rate into the connection info details | |
| 16:42:14 | bauzas | yeah, lvm seems the easiast approach | |
| 16:42:25 | marlinc | (Also actually the functional test for live migration, honestly I have never implemented something so complex as I have no experience at all with the testing framework and how it works in Nova) | |
| 16:42:26 | bauzas | but that's not my own garden :) | |
| 16:42:48 | marlinc | Especially since there is no existing volume based live migration functional I could see | |
| 16:42:54 | bauzas | marlinc: once you get a go from the cinder folks about exposing the rotation rate, come to me | |
| 16:43:03 | sean-k-mooney | marlinc: if cinder accpet the enhancement we can revisit that and or help you with that | |
| 16:43:07 | marlinc | Alright | |
| 16:43:20 | bauzas | cool | |
| 16:43:23 | bauzas | moving on then | |
| 16:43:26 | marlinc | Thank you, I'll update our internal ticket | |
| 16:43:44 | bauzas | marlinc: I assume you know how to reach the cinder folks? | |
| 16:44:36 | marlinc | Well, I'm going to assume #openstack-cinder and I'll check their contribution documentation | |
| 16:44:39 | bauzas | I have no potential design disapproval on using a specific connection info detail for setting the right value in the xml | |
| 16:45:00 | sean-k-mooney | marlinc: yep thats the correct channel | |
| 16:45:05 | bauzas | but you'll need to write a nova spec for explaining that it'll require a recent enough cinder and new computes | |
| 16:45:19 | sean-k-mooney | by the way there may be a usecase here for nova local storage too. | |
| 16:45:22 | marlinc | I was maybe a bit afraid though about the special rotation_rate 1 that is libvirt specific | |
| 16:45:23 | bauzas | and testing will be interesting to be discussed in the spec proocess | |
| 16:45:40 | marlinc | But that is probably something for the spec | |
| 16:45:52 | bauzas | the rotation rate is storage specific | |
| 16:46:07 | bauzas | how you tune it for the guest is libvirt specific indeed | |
| 16:46:34 | marlinc | That is why, right now we return rotation_rate 1 for SSDs, however that might not be smart from a cinder -> nova integration perspective | |
| 16:46:42 | marlinc | It is a magic value | |
| 16:46:56 | sean-k-mooney | well really your tryign to say "this is an ssd" or not | |
| 16:46:58 | bauzas | we're overtime and we still have two topics to discuss | |
| 16:47:05 | sean-k-mooney | afnd there may be better way to express that | |
| 16:47:15 | bauzas | but I think we may need to discuss that from a cross-project perspective | |
| 16:47:19 | sean-k-mooney | ya lets continue this converatoin after the meeting | |
| 16:47:23 | marlinc | Yes that is right now the primary use case though we also use it to set it to 7200 for HDDs | |
| 16:47:32 | marlinc | Alright thank you | |
| 16:47:38 | bauzas | next one then (3 of 4) | |
| 16:47:45 | bauzas | Luzi: floating ip behavior (assign fip: https://bugs.launchpad.net/neutron/+bug/2060808 , remove fip: https://bugs.launchpad.net/nova/+bug/2060812) | |
| 16:47:47 | Luzi | these two bugs describe changes with the neutron handling of floating ips (compared to the deprecated nova code). 1. one allows allocating a floating ip to a vm even if it is attached to another vm ("stealing" it). The 2. one does not check the VM when removing a floating ip, resulting in always removing the ip (even if the vm-name was correct, and the ip a mistake) | |
| 16:48:17 | bauzas | are you asking for reviews on the nova patch ? | |
| 16:48:24 | Luzi | I raised that at the PTG with Neutron, but they wanted Nova poeple to look over it, and tell, whether you want to change these bahaviors or not | |
| 16:48:33 | bauzas | oh my bad | |
| 16:49:08 | Luzi | (i normally don't have time to attend the Nova meetings) | |
| 16:49:31 | Luzi | I would be glad if you could check out these bugs again and give your input on it | |
| 16:49:56 | bauzas | Luzi: well, it's hard to comment those bugs on a limited timeframe | |
| 16:50:09 | Luzi | yeah, we can discuss this on launchpad also | |
| 16:50:11 | bauzas | could you please go back to the nova channel on another time ? | |
| 16:50:15 | Luzi | sure | |
| 16:50:31 | bauzas | Luzi: well, what's your timezone, please remind me ? | |
| 16:50:39 | Luzi | UTC-1 | |
| 16:51:09 | bauzas | okay, would that work if you would ping us again on tomorrow UTC afternoon ? | |
| 16:51:34 | Luzi | yeah i can do taht | |
| 16:51:43 | bauzas | thanks | |
| 16:52:01 | bauzas | last one | |
| 16:52:05 | bauzas | kgube: re-proposed extend volume completion spec: https://review.opendev.org/c/openstack/nova-specs/+/917133 | |
| 16:52:12 | kgube | Hi, this is just a review request | |
| 16:52:27 | bauzas | cool, we'll review all the proposed specs indeed | |
| 16:52:40 | kgube | The spec has been reproposed from last cycle and not much has changed | |
| 16:52:49 | bauzas | I think I need to remember the exact situation we had last cycle | |
| 16:53:06 | bauzas | and why this didn't get enough traction | |