| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-22 | |||
| 11:58:30 | gibi | yes. I would keep the upgrade checks separate as they have a well defined scope | |
| 11:58:42 | sean-k-mooney | ack | |
| 11:59:35 | sean-k-mooney | im not nessisarly plannign on adding them myslef in the near term. but long term i think we want to codify some of those check rahter then providing a set of sql quriese to custoemr to run | |
| 11:59:57 | gibi | I agree | |
| 12:00:12 | gibi | my recent leaked migration allocation case could be added there too | |
| 12:01:03 | sean-k-mooney | yep and depending on how we write them perhaps they could be reused for healtch checks later | |
| 12:01:26 | sean-k-mooney | i feel like many of these checks are two heavy weight for that | |
| 12:01:56 | gibi | we need to measure the load they create | |
| 12:02:04 | sean-k-mooney | but there are some simple cases where we currently raise excptiont that could set a booleing flag | |
| 12:02:06 | gibi | I can imageine that some of them are too heavy | |
| 12:02:48 | sean-k-mooney | yep for the reousce tracker brakages we already have a pattern in the code i created for catching expctins and using those to set flags | |
| 12:03:16 | sean-k-mooney | which will be the simple way to detect two vms using the same cpus for examle | |
| 12:03:34 | sean-k-mooney | we can catch the qemu issue when two vms try to use the same pci device the same way | |
| 12:03:39 | sean-k-mooney | without computeing it | |
| 12:04:14 | sean-k-mooney | having the ablity to ask nova for the conflciitng vms seperatly however will help operators resolve that | |
| 12:04:36 | sean-k-mooney | and thats kind of where i was going with the new commands | |
| 12:04:53 | gibi | make sense | |
| 12:05:22 | sean-k-mooney | so healtch notices we failed to boot because fo conflciting pci devices. then operartor runs the command to deterim what vms are using the wrong devices | |
| 12:05:42 | sean-k-mooney | then they cold migrate them to fix it or manually fix the port in neutron | |
| 12:47:55 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix rescue volume-based instance https://review.opendev.org/c/openstack/nova/+/852737 | |
| 13:41:59 | gibi | sean-k-mooney: btw, I cannot set request_id during __init__ of InstancePCIRequest as that is forbiden for ovos :/ https://github.com/openstack/nova/blob/3af84811c8b181a49195f640c9c971d16d6d3477/nova/tests/unit/objects/test_objects.py#L1327 | |
| 13:43:22 | opendevreview | ribaudr proposed openstack/nova master: Alphabetizes objects https://review.opendev.org/c/openstack/nova/+/853986 | |
| 13:43:27 | sean-k-mooney | oh ok i guess that explains why we do it seperatly | |
| 13:52:25 | opendevreview | Balazs Gibizer proposed openstack/nova master: Generate request_id for Flavor based InstancePCIRequest https://review.opendev.org/c/openstack/nova/+/853835 | |
| 13:52:53 | gibi | sean-k-mooney: ^^ I will move this into the PCI in placement series so we don't need to merge it before we really need the request_id | |
| 13:59:08 | opendevreview | sean mooney proposed openstack/nova master: Fix suspend for non hostdev sriov ports https://review.opendev.org/c/openstack/nova/+/841017 | |
| 13:59:08 | opendevreview | sean mooney proposed openstack/nova master: Add source dev parsing for vdpa interfaces https://review.opendev.org/c/openstack/nova/+/841016 | |
| 13:59:09 | opendevreview | sean mooney proposed openstack/nova master: Add VDPA support for suspend and livemigrate https://review.opendev.org/c/openstack/nova/+/853704 | |
| 14:00:28 | sean-k-mooney | gibi: ack, will this need an offline data migration to populate that on old records or are you jsut going to set it on load from the db when not set and heal it over time | |
| 14:01:54 | sean-k-mooney | by the way i dont know if you want to do this or not but you could set the requester_id=flavor.uuid in the flavor case if you wanted too | |
| 14:02:01 | sean-k-mooney | we dont need that but it might be nice | |
| 14:02:03 | gibi | sean-k-mooney: I think we don't need a data migration. The request_id == None asumption is now removed but those old request and old pci devices that exists already still work as InstancePCIRequest.source works via alias_name | |
| 14:02:33 | gibi | I could set requester_id, but I don't use it | |
| 14:02:54 | sean-k-mooney | its just a nice to have | |
| 14:02:56 | gibi | also requester_id pointing to flavor_id is problematic as extra_spec can change on a flavor | |
| 14:03:21 | sean-k-mooney | well they can but they should not but i take your point | |
| 14:03:52 | sean-k-mooney | it would just be nice if it was also always set | |
| 14:03:59 | sean-k-mooney | but it does not have to be | |
| 14:04:18 | gibi | anyhow until I don't know how requester_id would be used I don't know if a changing flavor extra spec could cause trouble | |
| 14:04:38 | sean-k-mooney | well we woudl use the embeded copy anyway | |
| 14:05:11 | sean-k-mooney | i was wondering if it woudl help for resize | |
| 14:05:20 | gibi | that would work, but I cannot enforce that when a InstancePCIRequest.requester_id is compared to a flavorid then that flavorid is actually a stored copy or not | |
| 14:05:22 | sean-k-mooney | so we can corralate the pci request to the source or dest flavor | |
| 14:06:23 | sean-k-mooney | for example today there si no way to differnceate between source and dest flavor when resizing to same host | |
| 14:06:37 | gibi | I definitely have to look at the resize case with pci in placement as the move claim re-creates the InstancePCIRequest so new uuids will be generated there | |
| 14:06:40 | sean-k-mooney | but if the requester id was the flavor uuid in that case we could | |
| 14:07:26 | gibi | yes, it sounds useful | |
| 14:07:28 | gibi | I keep it in mind | |
| 14:07:58 | sean-k-mooney | ack im trying not to over complicate the requirement for your mvp | |
| 14:08:04 | opendevreview | Balazs Gibizer proposed openstack/nova master: Generate request_id for Flavor based InstancePCIRequest https://review.opendev.org/c/openstack/nova/+/853835 | |
| 14:08:15 | gibi | sean-k-mooney: no worries :) | |
| 14:08:49 | sean-k-mooney | stephenfin: gibi when you have time the vdpa seriese i belive is not ready for review | |
| 14:08:59 | stephenfin | now? | |
| 14:09:02 | sean-k-mooney | im going to switch to some down stream stuff for a bit | |
| 14:09:05 | stephenfin | (or not) | |
| 14:09:07 | sean-k-mooney | stephenfin: yes just pushed it | |
| 14:09:18 | sean-k-mooney | sorry now | |
| 14:09:26 | sean-k-mooney | :) | |
| 14:09:32 | gibi | I will review it right now, to fit it before the downstream call | |
| 14:28:20 | gibi | sean-k-mooney: there are some service version mistmatches in the last vdpa patch, I left a -1 there | |
| 14:28:37 | sean-k-mooney | ya also i just ran those tests localy and 2 of them fail | |
| 14:28:43 | sean-k-mooney | i tought i did that but i guess not | |
| 14:29:08 | sean-k-mooney | ill fix the issues today but likely after our downstream meetings | |
| 14:29:23 | sean-k-mooney | thanks for taking a look | |
| 14:30:19 | gibi | ack | |
| 15:02:54 | JayF | Hey all again, still looking for reviews on this improvement to CI for Ironic-related patches https://review.opendev.org/c/openstack/nova/+/853529 | |
| 15:03:26 | JayF | and a couple of stable patches I'm trying to get through the gate; one is at victoria right now ( https://review.opendev.org/c/openstack/nova/+/821350 ) and the other is at ussuri ( https://review.opendev.org/c/openstack/nova/+/853540 ) | |
| 15:03:44 | JayF | Also if there's anything I can do to more properly integrate my requests for reviews into whatever process you all use, I'm happy to take feedback. | |
| 16:05:02 | opendevreview | Sofia Enriquez proposed openstack/nova master: WIP: Check NFS protocol https://review.opendev.org/c/openstack/nova/+/854030 | |
| 16:37:41 | opendevreview | Jean-Sébastien Bevilacqua proposed openstack/nova master: Add Lustre support to nova https://review.opendev.org/c/openstack/nova/+/853786 | |
| 16:49:04 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix rescue volume-based instance https://review.opendev.org/c/openstack/nova/+/852737 | |
| 16:57:42 | opendevreview | sean mooney proposed openstack/nova master: Add VDPA support for suspend and livemigrate https://review.opendev.org/c/openstack/nova/+/853704 | |
| 17:15:28 | opendevreview | Elod Illes proposed openstack/nova stable/victoria: Ignore plug_vifs on the ironic driver https://review.opendev.org/c/openstack/nova/+/821350 | |
| 17:16:49 | stephenfin | sean-k-mooney: question on the last vDPA patch but good on the other two https://review.opendev.org/c/openstack/nova/+/853704 | |
| 17:17:43 | sean-k-mooney | gibi: stephenfin what is the lifetime of this fixture https://github.com/openstack/nova/blob/master/nova/tests/functional/libvirt/test_pci_sriov_servers.py#L83 | |
| 17:18:08 | sean-k-mooney | when i inhirt form this class instead it not actully in applied in my live migration test | |
| 17:18:15 | sean-k-mooney | do i need to assgin that to a varible | |
| 17:18:23 | gibi | a single test case | |
| 17:18:27 | sean-k-mooney | to extend it to the full test | |
| 17:18:51 | gibi | do you call super() from your class setUp? | |
| 17:19:03 | sean-k-mooney | yep | |
| 17:19:14 | sean-k-mooney | if i do | |
| 17:19:17 | sean-k-mooney | from nova.tests.fixtures.libvirt import Domain as Dom | |
| 17:19:19 | sean-k-mooney | self.assertEqual(self._migrate_stub, Dom.migrateToURI3) | |
| 17:19:23 | sean-k-mooney | they are not the same | |
| 17:19:54 | sean-k-mooney | stephenfin: looking now | |
| 17:20:30 | gibi | strange. I would say push the patch and I will look at it but I will only do that tomorrow. I' mostly off for today | |
| 17:21:01 | sean-k-mooney | gibi: the current one has the issue | |
| 17:21:08 | sean-k-mooney | and no worries | |
| 17:21:19 | sean-k-mooney | i might assign it to a var and see if that helps | |
| 17:21:49 | gibi | should not make a difference but worth trying as it maybe tease out something else | |
| 17:22:04 | sean-k-mooney | gibi: by the way stephenfin question is basicaly somethign i need you to answer https://review.opendev.org/c/openstack/nova/+/853704/5/nova/objects/service.py#236 | |
| 17:22:53 | sean-k-mooney | gibi: it can wait till tomorrw but my current answer is becasue gibi said so | |
| 17:23:43 | gibi | stephenfin, sean-k-mooney: about the N-1 version list in service.py. I think the easiest way out is not to change that in this patch series | |
| 17:23:52 | gibi | we change that at every start of a cycle | |
| 17:24:09 | sean-k-mooney | ack i can drop it | |
| 17:24:21 | stephenfin | wfm | |
| 17:24:32 | gibi | but to answer the question. When I introduced that logic I made it generic to support the case when somebody upgrade nova to beta version (or to m2 version) | |
| 17:24:58 | gibi | so the recorded service version for a given release is the first version appeared in that release | |
| 17:25:29 | gibi | so when we say Yoga supports Xena computes it means Yoga supports even the first (not just the last) service version of the Xena computes | |