| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-03 | |||
| 13:27:49 | bauzas | gibi: no I'm working on adding a new tempest test for https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/boot-vm-with-unaddressed-port.html#id11 | |
| 13:28:03 | bauzas | gibi: so I added a new tempest scenario and I want to test it locally | |
| 13:28:11 | bauzas | against some devstack env | |
| 13:28:31 | bauzas | so I guess I'll just create a build subdir and pip -e the source directly | |
| 13:28:40 | bauzas | with a venv | |
| 13:28:53 | gibi | so you have a devstack with the new nova code and with the new tempest code. Then | |
| 13:28:59 | bauzas | yup | |
| 13:28:59 | gibi | tox -evenv -- tempest run --regex <new test case> | |
| 13:29:19 | gibi | in the tempest source tree | |
| 13:29:20 | bauzas | oh man, I haven't thought about it | |
| 13:29:31 | bauzas | I was about to create the venv by hand | |
| 13:29:36 | gibi | :) | |
| 13:29:47 | bauzas | but yeah, sounds what I thought, just magically done with toix | |
| 13:29:48 | bauzas | tox | |
| 13:29:52 | gibi | yepp | |
| 13:30:03 | bauzas | ack, thanks | |
| 13:30:12 | gibi | if you build you devstack with tempest enabled the tempest is properly preconfigured by devstack so you only need to run it | |
| 13:30:44 | bauzas | gibi: oh good catch | |
| 13:31:01 | gibi | I have a similar blindspot with deployment tools like devstack, kolla, tripleoo, etc | |
| 13:31:04 | bauzas | gibi: I was stupidely about to run tempest on my laptop *against* my devstack vm | |
| 13:31:19 | gibi | bauzas: that would probably work but need a bit more setup | |
| 13:31:31 | bauzas | gibi: yup, I was about to configure etc/tempest | |
| 13:31:33 | gibi | as you need a populated tempest.confg | |
| 13:31:38 | bauzas | :) | |
| 13:31:38 | gibi | yepp | |
| 13:31:51 | bauzas | gosh, I feel stupid | |
| 13:31:58 | bauzas | I know tempest is delivered with devstack | |
| 13:32:09 | bauzas | I even ran it a couple of times | |
| 13:32:15 | bauzas | but I never tweaked it | |
| 13:32:22 | bauzas | I was able to read tempest tests | |
| 13:32:36 | bauzas | but I never contributed to tempest surprinsingly | |
| 13:32:50 | bauzas | gmann: don't look at me like this :D | |
| 13:34:22 | bauzas | now* | |
| 13:34:29 | gibi | :D | |
| 14:14:04 | gibi | dmitriis: went through your series again, looks good. I left some question along the way. | |
| 14:15:03 | gibi | dmitriis: does we have neutron dependencies we need to land first? or are those already landed? | |
| 14:18:07 | yuval | Hey, Is there anyway to tell zuul to install os-brick from master and not pypi? | |
| 14:18:50 | yuval | I added "Depends-On:" in the commit msg but didnt do the trick | |
| 14:28:05 | gibi | yuval: probably need to add | |
| 14:28:06 | gibi | required-projects: | |
| 14:28:10 | gibi | -os-brick | |
| 14:28:14 | gibi | to the job config | |
| 14:28:26 | gibi | required-projects: | |
| 14:28:39 | gibi | - openstack/os-brickj | |
| 14:29:20 | yuval | hmm someone use this option lately so I can see an example? | |
| 14:29:26 | yuval | used | |
| 14:30:06 | gibi | yuval: https://github.com/openstack/neutron/blob/c7f35d3870cb20de997231f2b502973fbcd0c3e7/zuul.d/tempest-singlenode.yaml#L272-L278 I stole the idea from here | |
| 14:31:38 | yuval | Thanks! | |
| 14:38:57 | dmitriis | gibi: RE the depends-on, had a discussion here https://review.opendev.org/c/openstack/nova/+/824833/1/nova/network/neutron.py#669 with sean-k-mooney. So https://review.opendev.org/c/openstack/neutron/+/808961 depends on the Nova change. As such, we don't have Neutron changes that need to be landed first. | |
| 14:39:20 | dmitriis | the VNIC type is already in the neutron lib because of the past Ironic work and we're just reusing it | |
| 14:39:45 | gibi | dmitriis: cool, thanks for the info | |
| 14:41:56 | artom | Huh, so https://review.opendev.org/c/openstack/nova/+/827549 passed | |
| 14:42:06 | artom | Looks like q35 *is* the culprit | |
| 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 | sean-k-mooney | gibi: os-brick is mainly maintained by cidner write | |
| 14:59:09 | yuval | yes, thank you both | |
| 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 | 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: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: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 | stephenfin | what does gibi think? | |
| 15:57:51 | sean-k-mooney | artom: started a mail thread on it but its a q35 issue | |
| 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 | |