| *** amoralej|off is now known as amoralej | 07:26 | |
| *** hemna8 is now known as hemna | 07:37 | |
| opendevreview | yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | 10:05 |
|---|---|---|
| opendevreview | yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | 10:15 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Refactor trait normalization https://review.opendev.org/c/openstack/placement/+/825847 | 11:02 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Extend the RP db query to support any-traits https://review.opendev.org/c/openstack/placement/+/825848 | 11:02 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: DB layer should only depend on trait id not names https://review.opendev.org/c/openstack/placement/+/826490 | 11:02 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Enhance doc of _get_trees_with_traits https://review.opendev.org/c/openstack/placement/+/825780 | 11:02 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Extend the RP tree DB query to support any-traits https://review.opendev.org/c/openstack/placement/+/825849 | 11:02 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Add any-traits support for listing resource providers https://review.opendev.org/c/openstack/placement/+/826491 | 11:03 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Add any-traits support for allocation candidates https://review.opendev.org/c/openstack/placement/+/826492 | 11:03 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Remove unused compatibility code https://review.opendev.org/c/openstack/placement/+/826493 | 11:03 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Add microversion 1.39 to support any-trait queries https://review.opendev.org/c/openstack/placement/+/826719 | 11:03 |
| opendevreview | Stephen Finucane proposed openstack/nova master: docs: Follow-ups for cells v2, architecture docs https://review.opendev.org/c/openstack/nova/+/827336 | 11:42 |
| artom | I guess we'll need a tracker for the test_tagged_attachment failures :( | 11:56 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: DNM: Testing change to test_tagged_attachment in tempest https://review.opendev.org/c/openstack/nova/+/827549 | 12:27 |
| gibi | artom: yes please :) | 12:46 |
| gibi | artom: and thanks for trying out if switching away from q35 helps | 12:46 |
| artom | gibi, yeah, just trying to gather data points | 12:47 |
| gibi | artom: I will push a tempest change up that will add more logs around that curl command that is used to verify the metadata | 12:57 |
| gibi | as the current code simply drops the exception and returns false so we don't see what fails | 12:57 |
| artom | gibi, yeah, I think the most useful piece of information would be what the metadata API returns | 12:58 |
| artom | Also, https://bugs.launchpad.net/nova/+bug/1959899 is the tracker | 12:58 |
| artom | And I sent an email to the ML | 12:58 |
| gibi | artom: thanks! | 12:58 |
| *** amoralej is now known as amoralej|lunch | 13:00 | |
| opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: troubleshoot nova-next tagged attach test https://review.opendev.org/c/openstack/nova/+/827661 | 13:10 |
| *** dasm|off is now known as dasm|rover | 13:14 | |
| bauzas | dumb question here, but I can't find any docs about how to test our working Tempest branches with it, I guess we need to just use a venv with pip -e tempest ? | 13:25 |
| bauzas | and then running tempest against our new test classes ? | 13:26 |
| gibi | bauzas: you want to run tempest against a nova stable branch? | 13:27 |
| 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:27 |
| bauzas | gibi: so I added a new tempest scenario and I want to test it locally | 13:28 |
| bauzas | against some devstack env | 13:28 |
| bauzas | so I guess I'll just create a build subdir and pip -e the source directly | 13:28 |
| bauzas | with a venv | 13:28 |
| gibi | so you have a devstack with the new nova code and with the new tempest code. Then | 13:28 |
| bauzas | yup | 13:28 |
| gibi | tox -evenv -- tempest run --regex <new test case> | 13:28 |
| gibi | in the tempest source tree | 13:29 |
| bauzas | oh man, I haven't thought about it | 13:29 |
| bauzas | I was about to create the venv by hand | 13:29 |
| gibi | :) | 13:29 |
| bauzas | but yeah, sounds what I thought, just magically done with toix | 13:29 |
| bauzas | tox | 13:29 |
| gibi | yepp | 13:29 |
| bauzas | ack, thanks | 13:30 |
| 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 |
| * bauzas worked on OpenStack since 9 years now but is a total noob with Tempest contributions | 13:30 | |
| bauzas | gibi: oh good catch | 13:30 |
| gibi | I have a similar blindspot with deployment tools like devstack, kolla, tripleoo, etc | 13:31 |
| bauzas | gibi: I was stupidely about to run tempest on my laptop *against* my devstack vm | 13:31 |
| * bauzas facepalms | 13:31 | |
| gibi | bauzas: that would probably work but need a bit more setup | 13:31 |
| bauzas | gibi: yup, I was about to configure etc/tempest | 13:31 |
| gibi | as you need a populated tempest.confg | 13:31 |
| bauzas | :) | 13:31 |
| gibi | yepp | 13:31 |
| bauzas | gosh, I feel stupid | 13:31 |
| bauzas | I know tempest is delivered with devstack | 13:31 |
| bauzas | I even ran it a couple of times | 13:32 |
| bauzas | but I never tweaked it | 13:32 |
| bauzas | I was able to read tempest tests | 13:32 |
| bauzas | but I never contributed to tempest surprinsingly | 13:32 |
| bauzas | gmann: don't look at me like this :D | 13:32 |
| * bauzas new hides | 13:34 | |
| bauzas | now* | 13:34 |
| gibi | :D | 13:34 |
| gibi | dmitriis: went through your series again, looks good. I left some question along the way. | 14:14 |
| gibi | dmitriis: does we have neutron dependencies we need to land first? or are those already landed? | 14:15 |
| yuval | Hey, Is there anyway to tell zuul to install os-brick from master and not pypi? | 14:18 |
| yuval | I added "Depends-On:" in the commit msg but didnt do the trick | 14:18 |
| *** amoralej|lunch is now known as amoralej | 14:19 | |
| gibi | yuval: probably need to add | 14:28 |
| gibi | required-projects: | 14:28 |
| gibi | -os-brick | 14:28 |
| gibi | to the job config | 14:28 |
| gibi | required-projects: | 14:28 |
| gibi | - openstack/os-brickj | 14:28 |
| * gibi cannot type | 14:28 | |
| yuval | hmm someone use this option lately so I can see an example? | 14:29 |
| yuval | used | 14:29 |
| gibi | yuval: https://github.com/openstack/neutron/blob/c7f35d3870cb20de997231f2b502973fbcd0c3e7/zuul.d/tempest-singlenode.yaml#L272-L278 I stole the idea from here | 14:30 |
| yuval | Thanks! | 14:31 |
| 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:38 |
| dmitriis | the VNIC type is already in the neutron lib because of the past Ironic work and we're just reusing it | 14:39 |
| gibi | dmitriis: cool, thanks for the info | 14:39 |
| artom | Huh, so https://review.opendev.org/c/openstack/nova/+/827549 passed | 14:41 |
| artom | Looks like q35 *is* the culprit | 14: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:42 |
| opendevreview | yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | 14:44 |
| yuval | gibi: I added as you mentioned ^ | 14:45 |
| gibi | yuval: does your patch depends on a new os-brick feature? | 14:46 |
| yuval | yes | 14:47 |
| 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 |
| 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:48 |
| sean-k-mooney | gibi: yep was talking to yuval in parrallel about that | 14:58 |
| 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:58 |
| gibi | ack | 14:59 |
| sean-k-mooney | gibi: os-brick is mainly maintained by cidner write | 14:59 |
| yuval | yes, thank you both | 14:59 |
| 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 |
| 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 | 14:59 |
| gibi | sean-k-mooney: yepp it is under cinder | 15:00 |
| 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 |
| sean-k-mooney | i think it should be uncontoversal | 15:01 |
| 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:02 |
| sean-k-mooney | yuval: unless you ment there are followup to the os-brick part | 15:03 |
| sean-k-mooney | in which case wait for those obviously if what is there is not sufficent to be useable | 15:03 |
| yuval | yes - that follow ups to the os-brick | 15:03 |
| 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 |
| 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 |
| gibi | dmitriis: ahh I got you, you are right. Then we cannot reject such config at startup. | 15:23 |
| sean-k-mooney | dmitriis: ya you would have to have the whitelist parsing like quiry sysfs which is not the right approch | 15:24 |
| gibi | dmitriis: with the log the problem is that it will be logged at each match call which could be noisy | 15:24 |
| gibi | dmitriis: let's keep it as is now. maybe mention it in the documentation (if not yet mentioned) | 15:25 |
| 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:25 |
| dmitriis | gibi: could also do a debug or info level message at least | 15:26 |
| gibi | dmitriis: go with a debug then | 15:26 |
| dmitriis | gibi: ack, I mentioned this in the "limitations" note in the doc change and also in the conf module doc | 15:27 |
| gibi | dmitriis: cool | 15:28 |
| gibi | then it is settle | 15:28 |
| gibi | d | 15:28 |
| dmitriis | gibi: ack, will also document this in the Neutron guide since other features cover the compute part as well | 15:29 |
| sean-k-mooney | ya proably debug makes sense but i have not got that far in the change set sorry | 15:40 |
| sean-k-mooney | i have been looking at stephens docs patchs and some downstream stuff so this is sitll on my todo list | 15:41 |
| dmitriis | sean-k-mooney: ack, np | 15:49 |
| 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 |
| stephenfin | I agree | 15:57 |
| stephenfin | what does gibi think? | 15:57 |
| sean-k-mooney | artom: started a mail thread on it but its a q35 issue | 15:57 |
| artom | sean-k-mooney, yeah, my latest DNM patch that removed the q35 machine type from nova-next passed | 15:58 |
| gibi | sean-k-mooney: do we have the result back from the testing that proves that it is q35? | 15:58 |
| gibi | artom: ohh | 15:58 |
| gibi | artom: but you also added the waiters in the same patch isn't it? | 15:58 |
| sean-k-mooney | i think those are seperate | 15:58 |
| artom | gibi, waiters were there before the q35 removal, and they failed | 15:58 |
| sean-k-mooney | ah | 15:59 |
| gibi | artom: ok then q35 it is | 15:59 |
| 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 |
| sean-k-mooney | which is the only q35 one for now | 15:59 |
| gibi | I'm OK to remove the test temporarily from nova-next while we figure out how to fix it | 15:59 |
| sean-k-mooney | artom: are you going to try any of my suggestions form the mail | 16:00 |
| artom | sean-k-mooney, I haven't read it yet | 16:00 |
| sean-k-mooney | no worries | 16:00 |
| gibi | btw, my dnm patch also passed nova-next and it only added logs to tempest :/ | 16:00 |
| sean-k-mooney | you can see on one of stephens patchs that it passed in check and failed in gate | 16:01 |
| sean-k-mooney | so it not a 100% failure just common | 16:01 |
| gibi | yeah | 16:01 |
| yuval | is there a nova-meeting today? | 16:01 |
| sean-k-mooney | no | 16:01 |
| sean-k-mooney | its on tuseday | 16:02 |
| sean-k-mooney | but you can still bring stuff up any time | 16:02 |
| yuval | ohh ok sorr | 16:02 |
| gibi | which also means passing on non q35 might be just luck :/ | 16:02 |
| sean-k-mooney | well maybe but the other jobs seam to be ok | 16:02 |
| sean-k-mooney | i guess we could check logstash and confirm | 16:03 |
| artom | gibi, huh... I mean, it was never 100%, but this does seem like a weird coincidence | 16:03 |
| artom | I wonder if we can check the qemu and/or libvirt versions in ubuntu | 16:03 |
| artom | What changed and when | 16:03 |
| gibi | OK, the tagged attach runs in tempest-integrated-compute and that is nicely green | 16:03 |
| sean-k-mooney | they are in the devstack logs | 16:03 |
| sean-k-mooney | if you want to check but i doubt that is the problem | 16:04 |
| *** whoami-rajat__ is now known as whoami-rajat | 16:12 | |
| 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:28 |
| sean-k-mooney | oh | 16:33 |
| sean-k-mooney | so that could be related to the qemu patch | 16:33 |
| sean-k-mooney | realted to state tracking | 16:33 |
| artom_ | I'm going to try and see what's in the console for the passing run on gibi's patch | 16:37 |
| *** artom_ is now known as artom | 16:37 | |
| 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:42 |
| sean-k-mooney | rosmaita: yes | 16:43 |
| sean-k-mooney | we do not allow code to changes to merge if they depend of unrelease libs | 16:44 |
| rosmaita | sean-k-mooney: ok, i will propose one today ... hopefully will get released right away, since it's not friday yet | 16:44 |
| sean-k-mooney | well anytime before the non-client lib freeze is technically fine | 16:44 |
| artom | Oh wait, we don't log the console by default, do we | 16:44 |
| sean-k-mooney | but the nova patches wont pass ci until the release is done | 16:44 |
| sean-k-mooney | rosmaita: so as long as there is a 5.2.0 before m3 it shoudl be ok | 16:45 |
| sean-k-mooney | the sonner before m3 the less risk to the nova change | 16:45 |
| rosmaita | sean-k-mooney: ok, we are planning to release os-brick one week early this cycle (so next week) | 16:46 |
| rosmaita | if that would be ok, i won't do a pre-release to avoid confusion | 16:46 |
| sean-k-mooney | ack yuval ^ are you ok with that | 16:46 |
| sean-k-mooney | rosmaita: its release with intermediay so you can do addtional release at any point by the way | 16:47 |
| sean-k-mooney | but next week likely will be fine | 16:47 |
| 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 |
| rosmaita | that sounds good, it would be better with the followup patches merged, i think | 16:48 |
| spatel | sean-k-mooney does multiple pci_alias address allow like this in nova.conf file ? - https://paste.opendev.org/show/812504/ | 16:54 |
| 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 |
| sean-k-mooney | it should be in our docs but i dont recall off the top of my head | 16:56 |
| sean-k-mooney | spatel: so yes https://docs.openstack.org/nova/latest/configuration/config.html#pci.alias | 16:56 |
| sean-k-mooney | that sould work | 16:57 |
| spatel | nice thanks | 16:57 |
| *** amoralej is now known as amoralej|off | 17:16 | |
| gibi | bauzas: left some comment for you in the ipless port patch | 17:16 |
| gibi | bauzas: nothing major | 17:16 |
| opendevreview | Merged openstack/placement master: Extra tests around required traits https://review.opendev.org/c/openstack/placement/+/825846 | 18:27 |
| opendevreview | Merged openstack/nova master: docs: Add new architecture guide https://review.opendev.org/c/openstack/nova/+/814563 | 18:28 |
| opendevreview | Merged openstack/nova master: Add 'hw:vif_multiqueue_enabled' flavor extra spec https://review.opendev.org/c/openstack/nova/+/792356 | 18:51 |
| opendevreview | melanie witt proposed openstack/nova master: Raise InstanceNotFound on fkey constraint fail saving info cache https://review.opendev.org/c/openstack/nova/+/826942 | 19:37 |
| admin1 | hi .. what does qemu unexpectedly closed the monitor mean during migration ? log snippet here: https://gist.githubusercontent.com/a1git/3029cfd14883531c8ea7b12d0491d8bb/raw/74f57d9ff1f278f79dc0dca685f71508b779d40d/gistfile1.txt | 20:32 |
| admin1 | qemu-system-x86_64: Length mismatch: 0000:00:03.0/virtio-net-pci.rom: 0x40000 in != 0x80000: Invalid argument | 20:33 |
| opendevreview | melanie witt proposed openstack/nova master: Raise InstanceNotFound on fkey constraint fail saving info cache https://review.opendev.org/c/openstack/nova/+/826942 | 20:45 |
| opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: Introduce remote_managed tag for PCI devs https://review.opendev.org/c/openstack/nova/+/824834 | 20:48 |
| opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: Bump os-traits to 2.7.0 https://review.opendev.org/c/openstack/nova/+/826675 | 20:48 |
| opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Add support for VNIC_TYPE_SMARTNIC https://review.opendev.org/c/openstack/nova/+/824835 | 20:48 |
| opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: Filter computes without remote-managed ports early https://review.opendev.org/c/openstack/nova/+/812111 | 20:49 |
| frickler | admin1: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1713490 | 20:57 |
| *** dasm|rover is now known as dasm|off | 22:02 | |
| admin1 | frickler .. thanks .. i tried the migration again to another hypervisor with the exact same cpu and it worked without issues .. the original error was between E5-2660 v2 @ 2.20GHz -> E5-2670 v2 @ 2.50GHz .. since it was an upgraded version of the cpu, it should have worked | 22:20 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!