| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-03 | |||
| 14:42:42 | opendevreview | Ilya Popov proposed openstack/nova master: Fix to implement 'pack' or 'spread' VM's NUMA cells https://review.opendev.org/c/openstack/nova/+/805649 | |
| 14:44:26 | opendevreview | yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | |
| 14:45:10 | yuval | gibi: I added as you mentioned ^ | |
| 14:46:58 | gibi | yuval: does your patch depends on a new os-brick feature? | |
| 14:47:32 | yuval | yes | |
| 14:48:29 | gibi | yuval: ok. so what you did not with zuul allows you to test the new os-brick feature together with the nova feautre | |
| 14:48:56 | gibi | yuval: but the final solution will be to merge the os-brick change first, then release os-brick, then bump the requirement to use the new os-brick release | |
| 14:58:16 | sean-k-mooney | gibi: yep was talking to yuval in parrallel about that | |
| 14:58:56 | sean-k-mooney | yuval: if you dont feel comforatable creatign the release patch i can submit it if you are willing to take it over and or respond to any question the maintaienr have | |
| 14:59:08 | gibi | ack | |
| 14:59:09 | yuval | yes, thank you both | |
| 14:59:09 | sean-k-mooney | gibi: os-brick is mainly maintained by cidner write | |
| 14:59:44 | sean-k-mooney | i know its kind fo shared owner ship but officaly its a cinder deliverbale in governace so there ptl/release leaision need to approve? | |
| 14:59:53 | yuval | sean-k-mooney: its ok, let me do some checking. there are 2 followups I need to add to my driver before they release | |
| 15:00:06 | gibi | sean-k-mooney: yepp it is under cinder | |
| 15:01:16 | sean-k-mooney | yuval: ok well its proably good to start the process early. looking at the patch delta https://github.com/openstack/os-brick/compare/5.1.0...master it should be a feature bump to 5.2.0 | |
| 15:01:25 | sean-k-mooney | i think it should be uncontoversal | |
| 15:02:34 | sean-k-mooney | just add another release to https://github.com/openstack/releases/blob/master/deliverables/yoga/os-brick.yaml and follow up with the os-brick/cinder folks on #openstack-cinder | |
| 15:03:06 | sean-k-mooney | yuval: unless you ment there are followup to the os-brick part | |
| 15:03:21 | sean-k-mooney | in which case wait for those obviously if what is there is not sufficent to be useable | |
| 15:03:28 | yuval | yes - that follow ups to the os-brick | |
| 15:22:54 | dmitriis | info from Libvirt because it parses the VPD binary and extracts all the fields. So I can't check the presence of a serial at the whitelist parsing time without having to parse VPD (which belongs in Libvirt as we agreed in the past). Could logging a warning here be a compromise? | |
| 15:22:54 | dmitriis | gibi: RE https://review.opendev.org/c/openstack/nova/+/824834/5..8/nova/pci/devspec.py#322, the problem here is that I cannot do a check during PciDeviceSpec object creation because it gets details from passthrough_whitelist in nova.conf, meanwhile during matching I have access to the device json dict which comes based on info from Libvirt. We need | |
| 15:23:53 | gibi | dmitriis: ahh I got you, you are right. Then we cannot reject such config at startup. | |
| 15:24:03 | sean-k-mooney | dmitriis: ya you would have to have the whitelist parsing like quiry sysfs which is not the right approch | |
| 15:24:21 | gibi | dmitriis: with the log the problem is that it will be logged at each match call which could be noisy | |
| 15:25:30 | gibi | dmitriis: let's keep it as is now. maybe mention it in the documentation (if not yet mentioned) | |
| 15:25:31 | dmitriis | gibi, sean-k-mooney: yeah, if I could check for the serial presence easily without parsing, it would be doable but unfortunately vpd is a binary blob in sysfs | |
| 15:26:03 | dmitriis | gibi: could also do a debug or info level message at least | |
| 15:26:20 | gibi | dmitriis: go with a debug then | |
| 15:27:43 | dmitriis | gibi: ack, I mentioned this in the "limitations" note in the doc change and also in the conf module doc | |
| 15:28:16 | gibi | dmitriis: cool | |
| 15:28:19 | gibi | then it is settle | |
| 15:28:20 | gibi | d | |
| 15:29:58 | dmitriis | gibi: ack, will also document this in the Neutron guide since other features cover the compute part as well | |
| 15:40:38 | sean-k-mooney | ya proably debug makes sense but i have not got that far in the change set sorry | |
| 15:41:02 | sean-k-mooney | i have been looking at stephens docs patchs and some downstream stuff so this is sitll on my todo list | |
| 15:49:34 | dmitriis | sean-k-mooney: ack, np | |
| 15:57:23 | sean-k-mooney | stephenfin: by the way i think we should exclude that failign test in nova-next for now until we find a workaround | |
| 15:57:43 | stephenfin | I agree | |
| 15:57:51 | sean-k-mooney | artom: started a mail thread on it but its a q35 issue | |
| 15:57:51 | stephenfin | what does gibi think? | |
| 15:58:21 | artom | sean-k-mooney, yeah, my latest DNM patch that removed the q35 machine type from nova-next passed | |
| 15:58:24 | gibi | sean-k-mooney: do we have the result back from the testing that proves that it is q35? | |
| 15:58:30 | gibi | artom: ohh | |
| 15:58:40 | gibi | artom: but you also added the waiters in the same patch isn't it? | |
| 15:58:54 | sean-k-mooney | i think those are seperate | |
| 15:58:55 | artom | gibi, waiters were there before the q35 removal, and they failed | |
| 15:59:03 | sean-k-mooney | ah | |
| 15:59:09 | gibi | artom: ok then q35 it is | |
| 15:59:24 | sean-k-mooney | so i think this runs in other test jobs if it does i think we can skip it in nova-next | |
| 15:59:30 | sean-k-mooney | which is the only q35 one for now | |
| 15:59:49 | gibi | I'm OK to remove the test temporarily from nova-next while we figure out how to fix it | |
| 16:00:09 | sean-k-mooney | artom: are you going to try any of my suggestions form the mail | |
| 16:00:15 | artom | sean-k-mooney, I haven't read it yet | |
| 16:00:20 | sean-k-mooney | no worries | |
| 16:00:51 | gibi | btw, my dnm patch also passed nova-next and it only added logs to tempest :/ | |
| 16:01:24 | sean-k-mooney | you can see on one of stephens patchs that it passed in check and failed in gate | |
| 16:01:37 | sean-k-mooney | so it not a 100% failure just common | |
| 16:01:46 | gibi | yeah | |
| 16:01:47 | yuval | is there a nova-meeting today? | |
| 16:01:53 | sean-k-mooney | no | |
| 16:02:02 | sean-k-mooney | its on tuseday | |
| 16:02:10 | sean-k-mooney | but you can still bring stuff up any time | |
| 16:02:11 | yuval | ohh ok sorr | |
| 16:02:17 | gibi | which also means passing on non q35 might be just luck :/ | |
| 16:02:36 | sean-k-mooney | well maybe but the other jobs seam to be ok | |
| 16:03:01 | sean-k-mooney | i guess we could check logstash and confirm | |
| 16:03:15 | artom | gibi, huh... I mean, it was never 100%, but this does seem like a weird coincidence | |
| 16:03:32 | artom | I wonder if we can check the qemu and/or libvirt versions in ubuntu | |
| 16:03:39 | artom | What changed and when | |
| 16:03:44 | gibi | OK, the tagged attach runs in tempest-integrated-compute and that is nicely green | |
| 16:03:54 | sean-k-mooney | they are in the devstack logs | |
| 16:04:05 | sean-k-mooney | if you want to check but i doubt that is the problem | |
| 16:28:35 | artom_ | So one interesting thing is that in the console logs for a failing test_tagged_attachment, I'm seeing "[ 5.322454] pcieport 0000:00:04.5: pciehp: Failed to check link status" | |
| 16:33:44 | sean-k-mooney | oh | |
| 16:33:53 | sean-k-mooney | so that could be related to the qemu patch | |
| 16:33:58 | sean-k-mooney | realted to state tracking | |
| 16:37:29 | artom_ | I'm going to try and see what's in the console for the passing run on gibi's patch | |
| 16:42:54 | rosmaita | sean-k-mooney bauzas: do you need a pre-yoga-release release of os-brick so you can test lightbits code for nova? | |
| 16:43:18 | sean-k-mooney | rosmaita: yes | |
| 16:44:03 | sean-k-mooney | we do not allow code to changes to merge if they depend of unrelease libs | |
| 16:44:07 | rosmaita | sean-k-mooney: ok, i will propose one today ... hopefully will get released right away, since it's not friday yet | |
| 16:44:29 | sean-k-mooney | well anytime before the non-client lib freeze is technically fine | |
| 16:44:31 | artom | Oh wait, we don't log the console by default, do we | |
| 16:44:39 | sean-k-mooney | but the nova patches wont pass ci until the release is done | |
| 16:45:05 | sean-k-mooney | rosmaita: so as long as there is a 5.2.0 before m3 it shoudl be ok | |
| 16:45:18 | sean-k-mooney | the sonner before m3 the less risk to the nova change | |
| 16:46:10 | rosmaita | sean-k-mooney: ok, we are planning to release os-brick one week early this cycle (so next week) | |
| 16:46:25 | rosmaita | if that would be ok, i won't do a pre-release to avoid confusion | |
| 16:46:48 | sean-k-mooney | ack yuval ^ are you ok with that | |
| 16:47:11 | sean-k-mooney | rosmaita: its release with intermediay so you can do addtional release at any point by the way | |
| 16:47:19 | sean-k-mooney | but next week likely will be fine | |
| 16:48:26 | yuval | yes, got it - we finish the followup til 10 feb - so it will leave window to merge the nova code till 21 | |
| 16:48:58 | rosmaita | that sounds good, it would be better with the followup patches merged, i think | |
| 16:54:57 | spatel | sean-k-mooney does multiple pci_alias address allow like this in nova.conf file ? - https://paste.opendev.org/show/812504/ | |
| 16:56:05 | sean-k-mooney | you can have multiple alsiases i need to check if its a multiopt like that or a json list or both | |
| 16:56:17 | sean-k-mooney | it should be in our docs but i dont recall off the top of my head | |
| 16:56:58 | sean-k-mooney | spatel: so yes https://docs.openstack.org/nova/latest/configuration/config.html#pci.alias | |
| 16:57:17 | sean-k-mooney | that sould work | |