| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-15 | |||
| 16:51:32 | whoami-rajat | bauzas, we've the glance code in nova that calls the glanceclient, eg: for add location https://github.com/openstack/nova/blob/93a65f06df67ce39d65827692150c78013c7f6d5/nova/image/glance.py#L558 | |
| 16:51:41 | whoami-rajat | s/code/file | |
| 16:52:24 | whoami-rajat | all the places calling glance should be calling this file but not sure if that's what you mean | |
| 17:20:17 | gibi | sean-k-mooney: one more info for the todays pci-tracking work PciDeviceStats is not good for me as the pool count is 0 if the devices are consumed, but I still need to create inventory for consumed devices too. So I need to build the inventory based on the PciDevice objects alone and match them to DeviceSpec one by one to get the metadata (resource_class, and traits from the config) | |
| 17:34:21 | sean-k-mooney | ok so you can either get the rows directly from the tracker or build them i guess | |
| 17:34:39 | sean-k-mooney | i tought the stats also had the capastity but i guess not | |
| 17:36:55 | sean-k-mooney | ah yes | |
| 17:37:05 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/objects/pci_device_pool.py#L55= | |
| 17:38:40 | gibi | I can access count via stats.pools directly but that is only meaningful if there is no pci allocation at all on the compute | |
| 17:38:50 | gibi | and yes I saw that the count is not visible via the object interface | |
| 17:42:00 | sean-k-mooney | right i tought we also had a total in the stats | |
| 17:42:11 | sean-k-mooney | that did not change in addtion to the count of free devices | |
| 17:42:13 | sean-k-mooney | we do not | |
| 17:50:13 | gibi | sean-k-mooney: quick question, does nova alway have a PciDevice object for parent devices? E.g. if only the VF is whitelisted nova still create a PciDevice for the parent is it so? | |
| 17:52:56 | gibi | never mind I will track it down tomoroow | |
| 17:52:59 | gibi | o/ | |
| 17:58:27 | sean-k-mooney | no i dont think we do | |
| 17:58:43 | sean-k-mooney | we could build oen but i dont know if we do by default | |
| 17:58:50 | sean-k-mooney | in the pci tracker today | |
| 17:59:11 | sean-k-mooney | if you whitelist a vf we do not create a row for the vf in the db | |
| 18:24:06 | melwitt | elodilles: I wanted to get your opinion on backporting a refactor that skips a release https://review.opendev.org/c/openstack/nova/+/844750 | |
| 18:28:47 | elodilles | melwitt: hmm. is there any reason to skip ussuri? O.o | |
| 18:29:51 | sean-k-mooney | im not aware of one | |
| 18:30:08 | melwitt | elodilles: not that I know of. we also don't know why the patch helps or why it's needed to make CI pass. have you ever heard of something like that? | |
| 18:30:39 | sean-k-mooney | unless it merged in ussuri when it was master | |
| 18:30:46 | melwitt | I looked at it and nothing rang a bell why it would help ¯\_(ツ)_/¯ | |
| 18:31:07 | sean-k-mooney | it merged in victoria | |
| 18:31:18 | sean-k-mooney | https://github.com/openstack/nova/commit/980711f3d3f2db9dfd792a8c6fd15cb45a85f615 | |
| 18:31:48 | elodilles | i guess it was added in train to avoid some kind of conflict maybe? (and i guess it was not needed in ussuri) | |
| 18:32:08 | sean-k-mooney | i would guess so too | |
| 18:32:27 | sean-k-mooney | perhaps it was merged in in ussurit into one of the other commtis | |
| 18:32:45 | sean-k-mooney | or artom just forgot | |
| 18:33:12 | melwitt | the commit message says CI was failing with "No such file or directory: '/home/zuul/src/opendev.org/openstack/nova/instances/tmpif84g_jd'" i.e. looking for a tempdir and it doesn't exist. but it's weird it wasn't needed in ussuri | |
| 18:33:39 | elodilles | anyway, i'd rather see that either removed from the patch series, or backported to ussuri as well (if that is really needed) | |
| 18:34:27 | melwitt | ++ | |
| 18:35:37 | melwitt | thanks | |
| 18:36:03 | sean-k-mooney | is it because of python 2? | |
| #openstack-nova - 2022-06-16 | |||
| 02:08:39 | opendevreview | Steve Baker proposed openstack/nova master: Align ironic driver secure boot with other drivers https://review.opendev.org/c/openstack/nova/+/844243 | |
| 02:34:58 | opendevreview | norman shen proposed openstack/nova master: Clear connection info if vol disconnected https://review.opendev.org/c/openstack/nova/+/845995 | |
| 04:47:03 | opendevreview | Takashi Kajinami proposed openstack/os-vif master: Drop lower-constraints.txt and its testing https://review.opendev.org/c/openstack/os-vif/+/840020 | |
| 08:14:33 | gibi | good morning | |
| 08:35:45 | Uggla | gibi, good morning. | |
| 10:37:02 | gibi | sean-k-mooney: another question, maybe you remember. Do we set the PciDevice.instance_uuid to the migration_uuid on the source host when the VM using the device is being migrated? | |
| 10:37:26 | sean-k-mooney | i dont think so | |
| 10:37:31 | sean-k-mooney | we dont need too | |
| 10:37:54 | gibi | OK, then I look up running migrations for reshape | |
| 10:38:06 | gibi | and pair them to PciDevs | |
| 10:38:18 | gibi | as I have to heal the allocation for the running migrations too | |
| 10:38:19 | sean-k-mooney | the instance uuid should be set to the instance uuid on both hosts | |
| 10:38:25 | gibi | ack | |
| 10:38:29 | gibi | that what I guessed | |
| 10:39:05 | sean-k-mooney | i think the corralation is done via the migrate_data object which is only in memory | |
| 10:39:16 | sean-k-mooney | although you can just look at the relevent host form the migration object | |
| 10:39:30 | sean-k-mooney | to know which one it belongs too | |
| 10:39:39 | sean-k-mooney | e.g migration vs instance | |
| 10:39:56 | gibi | yeah something like that | |
| 10:40:21 | sean-k-mooney | that reminds me we still do not use consumer types | |
| 10:40:50 | sean-k-mooney | that is out of scope but ya | |
| 10:41:18 | sean-k-mooney | are we going to have a reshape in the future that will move all migrations to the migration consumer type | |
| 10:44:46 | gibi | we should have add that yes | |
| 10:45:33 | sean-k-mooney | thats what i assuemd but i dont recall if the placment spec actully spoke about how nova or other porjects would use them once the feature was added | |
| 10:45:52 | gibi | me neither | |
| 10:45:53 | sean-k-mooney | so i was not sure if we woudl do a reshape or just stat using the consumer type for new migrations | |
| 10:46:12 | gibi | I think reshape would be better | |
| 10:46:19 | sean-k-mooney | and let it heal over time as old migration get compelte/aborted. | |
| 10:46:30 | sean-k-mooney | it would be cleaner for sure | |
| 10:46:54 | sean-k-mooney | but proably a nova manage command so that it does not have any impact on rolling upgrade | |
| 10:47:14 | sean-k-mooney | although old nova will proably ignore the type so i might be over thinking it | |
| 10:47:34 | sean-k-mooney | future us problems | |
| 10:50:11 | gibi | yepp | |
| 10:53:05 | gibi | \one more architectural difference for today: for pci it cannot be decided if reshape is needed without checking existing nova allocations of pci also exists in placement too. As during rolling upgrade new pci allocations can arrive to a compute without placmeent allocation | |
| 10:53:32 | gibi | so for pci we will do periodic healing | |
| 10:53:37 | gibi | instead of a one time reshape | |
| 10:56:18 | sean-k-mooney | fun | |
| 10:56:27 | sean-k-mooney | is that not the case for cpus? | |
| 10:57:18 | sean-k-mooney | the reshape will be tied to the pci/repot_to_placement conf or whatever it was right | |
| 10:58:06 | sean-k-mooney | so this will be skiped if that is not set | |
| 11:10:48 | gibi | it seems for cpus we did not needed this | |
| 11:11:17 | sean-k-mooney | im not really sure why it woudl be differnt | |
| 11:11:32 | gibi | yes, the whole tracking and reshape code starts with an if not CONF.pci.report_in_placement: return | |
| 11:12:14 | gibi | sean-k-mooney: for cpus we do two a_c queries to enforce allocation if placement has inventory | |
| 11:12:29 | sean-k-mooney | oh the fallback query | |
| 11:12:31 | gibi | and fall back to legacy query | |
| 11:12:32 | gibi | yeah | |
| 11:12:39 | sean-k-mooney | i mean we can do that for pci | |
| 11:12:42 | sean-k-mooney | if we want too | |
| 11:13:45 | sean-k-mooney | i guess that does nto really work the same if we use a prefilter | |
| 11:13:57 | sean-k-mooney | we had to do some extra chagnes for the fallback | |
| 11:14:23 | gibi | periodic healing feels less complex to me code wise | |
| 11:14:31 | sean-k-mooney | ack | |
| 11:15:22 | gibi | I also would like make the healing code accessible from nova-manage | |
| 11:15:56 | gibi | healing / audit | |
| 11:16:09 | gibi | basically the same code can tell if something is missing and also can fix it | |
| 11:16:20 | gibi | or delete if there are overallocations in placement | |
| 11:23:45 | sean-k-mooney | yep that makes sense too | |
| 11:24:37 | sean-k-mooney | personally i think we should merge audit and heal by the way or at least move the delete allcoation logic form audit to heal | |
| 11:25:02 | sean-k-mooney | audit is very very badly named | |
| 11:25:08 | gibi | yepp | |
| 11:25:10 | gibi | I agree | |
| 11:25:23 | gibi | we need only one CLI to check and fix | |