| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-05-12 | |||
| 09:46:53 | sean-k-mooney | gibi: i have an option d | |
| 09:46:58 | gibi | shoot | |
| 09:47:25 | sean-k-mooney | gibi: if we have consumer types we could create allocations for cached images against the RP | |
| 09:47:37 | sean-k-mooney | using a nova consumer type | |
| 09:47:53 | sean-k-mooney | if we cant create the allcoation because there is not enough sapce then we dont cache it | |
| 09:48:12 | sean-k-mooney | if we can the it will prevent the issue as all usage will be tracked in placment | |
| 09:49:26 | gibi | we migt not need consumer types, we can simple create an allocation where the consumer_id is not an instance or a migration but the cache itself. | |
| 09:49:56 | sean-k-mooney | ya i was thinking we could use the image uuid as the consumer uuid and a cache consumer type | |
| 09:50:15 | sean-k-mooney | that way we would know which image are cached on each node | |
| 09:50:33 | gibi | in the allocation candidate query we have to either include 1x disk space if the host already caching the image or 2x disk space if the host will cache the image due to the current request | |
| 09:51:00 | sean-k-mooney | gibi: not if we change the logic so that the cacheing is optional | |
| 09:51:24 | sean-k-mooney | e.g. have the compute node make the allcoation after the fact when teh node is about to be spawned | |
| 09:52:14 | sean-k-mooney | so if the image is not already cached, chech can you create an allcoation for it, if so cache it and proceed with the boot if not dont cache it and just create a copy | |
| 09:52:20 | ikla | can I request I set multiple names in pci_passthrough for the flavor? | |
| 09:52:20 | sean-k-mooney | for the vm | |
| 09:53:10 | sean-k-mooney | gibi: the only time that would not cache is when the disk is almost full | |
| 09:53:28 | ikla | what would be the syntax or is it multiple pci_passthrough lines for the flavor? | |
| 09:54:14 | gibi | sean-k-mooney: do you see the complexity of making the cache optional in nova code? yesterday we conculded with dansmith that it could be pretty hairy change | |
| 09:54:32 | gibi | but I'm not an expert on the image backends | |
| 09:55:04 | sean-k-mooney | gibi: i know that part of the code makes heavy use of functools.partil and is really hard to follow | |
| 09:55:21 | sean-k-mooney | so i would guess it would be non trivial | |
| 09:55:30 | sean-k-mooney | but mainly due to techdebt | |
| 09:55:48 | openstackgerrit | Jiri Suchomel proposed openstack/nova-specs master: Add spec for downloading images via RBD https://review.opendev.org/572805 | |
| 09:56:27 | ikla | something like: {"pci_passthrough:alias"="name1:1, name2:1, name3:1"} | |
| 09:57:44 | sean-k-mooney | ikla: yes its a comma seperate list | |
| 09:57:46 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/pci/request.py#L234-L237 | |
| 09:58:24 | gibi | sean-k-mooney: thanks. I will look into this direction as well | |
| 09:58:24 | sean-k-mooney | so openstack flavor set --property "pci_passthrough:alias"="name1:1,name2:1,name3:1" my-flavor | |
| 10:01:39 | ikla | Insufficient compute resources: Claim pci failed. | |
| 10:01:41 | ikla | hmm | |
| 10:02:15 | sean-k-mooney | ikla: you might need to weaken the default numa affintiy policy | |
| 10:02:35 | sean-k-mooney | e.g. if you dont have all the device on the same numa node | |
| 10:03:17 | sean-k-mooney | ikla: you can set numa_policy=perfer in the alisa | |
| 10:03:31 | sean-k-mooney | i just need to check that value is correct but i think its prefer or prefered | |
| 10:05:11 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Address issues with flake8 3.8.0 https://review.opendev.org/727140 | |
| 10:05:25 | sean-k-mooney | ikla: its "preferred" | |
| 10:05:28 | stephenfin | gibi, bauzas: if that isn't failing our gate yet, it's going to start soon ^ | |
| 10:05:32 | sean-k-mooney | ikla: https://github.com/openstack/nova/blob/master/nova/objects/fields.py#L734 | |
| 10:05:42 | sean-k-mooney | ikla: it could have failed for other reasons too | |
| 10:05:52 | stephenfin | https://review.opendev.org/727133 will fix it but I don't know how long until that's released | |
| 10:05:58 | stephenfin | *how long it will be | |
| 10:06:08 | bauzas | wait | |
| 10:06:35 | bauzas | stephenfin: doesn't that provide a new exception ? | |
| 10:07:23 | bauzas | stephenfin: do you have more context ? | |
| 10:07:26 | stephenfin | yes, E741 and F522 seem to be new | |
| 10:07:36 | bauzas | so we could ignore them first ? | |
| 10:07:46 | stephenfin | but...why? | |
| 10:07:50 | ikla | set in flavor? | |
| 10:08:03 | ikla | oh, in the alias? | |
| 10:08:17 | ikla | I get the same issue with one device | |
| 10:08:29 | stephenfin | the correct fix is for hacking to limit flake8 to a given minor version instead of the major version range it's using, but we need a new release of hacking for that | |
| 10:09:58 | sean-k-mooney | ikla: are you testing with a gpu | |
| 10:10:23 | sean-k-mooney | ikla: or do you have any specific errors int eh nova compute agent log | |
| 10:11:36 | ikla | no, these are network cards | |
| 10:12:37 | ikla | nothing in logs | |
| 10:12:39 | sean-k-mooney | ok then likely you if its not the numa issue the next thing to check woudl be the pci device type | |
| 10:12:52 | sean-k-mooney | do the nics support sriov? | |
| 10:13:13 | ikla | yes | |
| 10:13:30 | ikla | they are setup and I can see them in the pci list with lspci -nnn | |
| 10:13:30 | sean-k-mooney | if they dont have the capablity of SRIOV then the type will be type-PCI | |
| 10:13:35 | ikla | Virtual x 4 | |
| 10:13:46 | sean-k-mooney | if they do then the PF will be type-PF and the VFs will be type-VF | |
| 10:13:58 | sean-k-mooney | you need to match the alis to the type | |
| 10:14:35 | ikla | thats what I did | |
| 10:14:45 | sean-k-mooney | ikla: by the way you only use that pci aliase for nics if you dont want them to be used with neutron | |
| 10:15:11 | ikla | yup | |
| 10:18:55 | sean-k-mooney | ok so your alias is something like this | |
| 10:19:03 | sean-k-mooney | | [pci] | |
| 10:19:05 | sean-k-mooney | | alias = '{ | |
| 10:19:07 | sean-k-mooney | | "name": "QuickAssist", | |
| 10:19:09 | sean-k-mooney | | "product_id": "0443", | |
| 10:19:11 | sean-k-mooney | | "vendor_id": "8086", | |
| 10:19:13 | sean-k-mooney | | "device_type": "type-vf", | |
| 10:19:15 | sean-k-mooney | | "numa_policy": "preferred" | |
| 10:19:17 | sean-k-mooney | | }' | |
| 10:20:04 | sean-k-mooney | actully it shoudl be type-VF | |
| 10:20:11 | gibi | tony_su: could you make a small fix in https://review.opendev.org/#/c/725788 then I will +2 it | |
| 10:21:35 | bauzas | stephenfin: I mean, your change is a bit unclear | |
| 10:22:10 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/stein: stable-only: skip volume backup tests in cellsv1 job https://review.opendev.org/727147 | |
| 10:22:29 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/rocky: stable-only: skip volume backup tests in cellsv1 job https://review.opendev.org/727148 | |
| 10:23:17 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: stable-only: skip volume backup tests in cellsv1 job https://review.opendev.org/727150 | |
| 10:24:42 | bauzas | stephenfin: so, IMO, we should add a new change ignoring the new errors, then having your own change modifyng what what needed and then also removing the error ignored line | |
| 10:25:23 | bauzas | stephenfin: so in case a new patch would be merged, we would still make sure we would ignore the new errors until you are sure that all of them are fixed | |
| 10:30:19 | sean-k-mooney | do we even need to do that | |
| 10:30:24 | sean-k-mooney | lets just cap it | |
| 10:30:49 | sean-k-mooney | then props a patch to uncap it and a patch that depends on that in nova | |
| 10:31:01 | sean-k-mooney | it should fail and we can iterate on that patch until it passes | |
| 10:31:04 | stephenfin | or, you know, fix the five things that have changed and move on with our lives | |
| 10:31:19 | stephenfin | these are the only changes necessary. I checked. I'll update the commit message shortly | |
| 10:31:21 | sean-k-mooney | stephenfin: you didnt explain why any of the five things needed to be fixed | |
| 10:31:29 | stephenfin | I'll update the commit message shortly | |
| 10:31:35 | sean-k-mooney | and several fo them had #noqa on them | |
| 10:31:40 | sean-k-mooney | so they should have been ignofred | |
| 10:31:41 | stephenfin | they already had noqa | |
| 10:31:47 | sean-k-mooney | yep | |
| 10:31:52 | stephenfin | check my replies | |
| 10:31:53 | sean-k-mooney | so it should not have been checking them | |
| 10:33:24 | sean-k-mooney | stephenfin: https://www.flake8rules.com/rules/E741.html does not feel like we should have it on by default | |
| 10:35:52 | stephenfin | sean-k-mooney: I'd really rather avoid that argument because those tend to be ratholes in nova. I'd much, much rather we just took what flake8 and hacking gave us and dealt with it. | |
| 10:36:33 | sean-k-mooney | arbitary rules like that one make code worse and less readable | |