| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-17 | |||
| 15:42:58 | sean-k-mooney | tosky: ^ | |
| 15:43:01 | lyarwood | gmann: so this wouldn't help if I wanted to look at NV jobs in the check queue right? | |
| 15:43:26 | lyarwood | gmann: trying to figure out a way of showing something is now stable and can be made voting | |
| 15:43:27 | gmann | oh . yeah n-v jobs data are not there | |
| 15:43:39 | lyarwood | kk np | |
| 15:43:48 | lyarwood | and thanks :) | |
| 15:44:47 | tosky | sean-k-mooney: but then I shouldn't see this in master | |
| 15:44:54 | tosky | sean-k-mooney: so there must be something else too | |
| 15:45:12 | sean-k-mooney | on master no but grenade installs with train frist then upgrdaes to master | |
| 15:45:20 | sean-k-mooney | so all the train deps will be installed with both | |
| 15:45:28 | tosky | oh, right | |
| 15:45:34 | sean-k-mooney | then we will upgrade to train without updateing the python 2 deps | |
| 15:45:51 | tosky | this means that when we install train/py3 we have a problem | |
| 15:46:14 | tosky | not a problem normally, as train is technically py2 for devstack | |
| 15:46:19 | tosky | but I'm not sure how to solve | |
| 15:46:24 | sean-k-mooney | yes well a traing/py3 intsall install both under py3 and py2 | |
| 15:46:40 | sean-k-mooney | tosky: well no | |
| 15:46:50 | sean-k-mooney | train should would with python 3 aswell | |
| 15:46:57 | efried | gibi: if you have a second, could you please remind me the context around why we're parsing a RP name to identify an interface? | |
| 15:48:01 | sean-k-mooney | tosky: what is the specific issue you are having | |
| 15:48:53 | sean-k-mooney | one way to solve it would be do a pip freeze and unistall any openstack package that is installed | |
| 15:49:00 | sean-k-mooney | on python 2 | |
| 15:52:32 | tosky | sean-k-mooney: see my comment above: both versions of osc are installed, but the osc plugins are py3 only, and then the py2 openstack fails to use them | |
| 15:55:34 | sean-k-mooney | ya so that is the same issue we have with console_scripts entry points | |
| 15:56:08 | sean-k-mooney | the python 2 version of osc console sript overites teh python 3 version on train | |
| 15:56:56 | sean-k-mooney | so grenade or devstack could be updated to explictly remvoe osc everytime it stacks | |
| 15:57:12 | sean-k-mooney | and install it again | |
| 15:57:15 | sean-k-mooney | that should fix it | |
| 15:58:31 | tosky | maybe devstack; at the end, if it's USE_PYTHON3, pip uninstall python-openstackclient (keeping the 3 version) | |
| 16:01:06 | sean-k-mooney | tosky: well it would want to do it near the start not the end | |
| 16:01:30 | sean-k-mooney | because you want to have it installed and ensure any place we use it in devstack to do things wew use the correct one | |
| 16:02:09 | sean-k-mooney | also you want it to deffinetly happen before the local.sh gets executed as its common to use the client to do things in the local.sh | |
| 16:03:55 | tosky | sean-k-mooney: so basically tune the piece of code you mentioned above to not install the py2 version of osc? | |
| 16:04:44 | sean-k-mooney | am i guess you could do that too. i was thinking of adding a new function that gets invoked after the install phase but before the post-config phase | |
| 16:05:55 | tosky | gmann: any thoughts about this ^ ? | |
| 16:06:21 | gmann | sorry, did note read that. too many bugs for py2 :( | |
| 16:06:28 | gmann | did not | |
| 16:10:14 | gmann | i will followup on that later on review | |
| 16:17:56 | KeithMnemonic1 | hello all. one last plea to get this merged https://review.opendev.org/683008 . We have confirmation from the customer that this resolves the issue they were seeing with their Lenovo storage. | |
| 16:18:33 | KeithMnemonic1 | this was that issue we had with the cinder stuff jungleboyj: if you recall and the DS6200. | |
| 16:19:00 | stephenfin | artom, efried: Did you folks get any closer to figuring out that nova-live-migration gate issue yesterday? | |
| 16:19:51 | sean-k-mooney | lyarwood: could you review KeithMnemonic1 backport | |
| 16:19:52 | jungleboyj | KeithMnemonic1: Ah, glad that you guys were able to make a change there. | |
| 16:20:31 | KeithMnemonic1 | it was the issue gorka said, losing track of the luns | |
| 16:22:12 | jungleboyj | Bakcport makes sense to me. | |
| 16:31:23 | Sundar | Hi sean-k-mooney: How's the deployment coming along? | |
| 16:32:04 | openstackgerrit | sean mooney proposed openstack/nova stable/rocky: Block rebuild when NUMA topology changed https://review.opendev.org/703116 | |
| 16:32:04 | openstackgerrit | sean mooney proposed openstack/nova stable/rocky: Remove 'test_cold_migrate_with_physnet_fails' test https://review.opendev.org/703115 | |
| 16:32:05 | openstackgerrit | sean mooney proposed openstack/nova stable/rocky: FUP for in-place numa rebuild https://review.opendev.org/703118 | |
| 16:32:05 | openstackgerrit | sean mooney proposed openstack/nova stable/rocky: Disable NUMATopologyFilter on rebuild https://review.opendev.org/703117 | |
| 16:32:32 | sean-k-mooney | Sundar: i have been trying to do some backport today before the weekend so ill likely get back to it again tomorow | |
| 16:32:37 | sean-k-mooney | well monday | |
| 16:33:24 | Sundar | sean-k-mooney: NP. Have a good weekend. | |
| 16:34:39 | artom | stephenfin, https://review.opendev.org/#/c/702960/ | |
| 16:37:13 | stephenfin | artom: ta | |
| 16:42:59 | belmoreira | Hi, I'm trying to boot an aarch64 image on x86_64 compute node and initially I though would be easy... but I'm still struggling. I was assuming that I just needed to define the arch in the image and nova will use that to trigger qemu-system-arm, but apparently not. Googling about it I can't find any answer... only similar questions. Do you have any pointer? | |
| 16:43:41 | sean-k-mooney | you can only do that if you set the virt type to qemu | |
| 16:43:52 | sean-k-mooney | and then i belive you have to set a nova config option | |
| 16:44:57 | sean-k-mooney | i belive you have to configre the machine types | |
| 16:44:59 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.hw_machine_type | |
| 16:45:43 | belmoreira | sean-k-mooney yes, I'm doing the machine type | |
| 16:47:00 | sean-k-mooney | ok then i think provide virt_type=qemu is deiend and you have the arch set in the image i think that shoudl work | |
| 16:47:30 | sean-k-mooney | you might need to set a cpu model but if you do that would force the host to only be able to run aarch64 | |
| 16:47:53 | sean-k-mooney | we do not have a way to set a cpu model per arch | |
| 16:49:12 | belmoreira | what I tried: virt_type=qemu and hw_machine_type=aarch64=machinetype1 | |
| 16:49:31 | belmoreira | also the image is set with the correct arch | |
| 16:49:35 | sean-k-mooney | what is the error you get | |
| 16:49:53 | sean-k-mooney | you might need to set [libvirt]/cpu_models | |
| 16:50:22 | belmoreira | libvirt.libvirtError: XML error: No PCI buses available | |
| 16:51:02 | sean-k-mooney | well machinetype1 is not a real machein type | |
| 16:51:19 | sean-k-mooney | it was an example for the config you need to use a real one | |
| 16:51:28 | kashyap | Yeah, belmoreira: Also any reason you're using 'virt_type' as 'qemu', instead of 'kvm'? | |
| 16:51:51 | sean-k-mooney | kashyap: because its aarch64 on x86 | |
| 16:51:53 | sean-k-mooney | so it has to be qemu | |
| 16:52:01 | kashyap | Ah, didn't read the full scroll, my bad | |
| 16:52:15 | kashyap | belmoreira: To get the supported machine types on your host, run `qemu-system-aarch64 -machine help` | |
| 16:52:27 | kashyap | (Or whatever the QEMU binary name is on your host.) | |
| 16:53:31 | sean-k-mooney | try seting hw_machine_type=aarch64=virt | |
| 16:53:35 | belmoreira | ohh :) that's the machine type | |
| 16:54:38 | sean-k-mooney | virt should be an alias to the newst arm machien type your qemu supprots | |
| 16:54:46 | sean-k-mooney | for me that is virt-4.1 | |
| 16:55:34 | sean-k-mooney | there are some specifc system it can emulate but virt is what you want mostlike with openstack | |
| 16:56:06 | kashyap | belmoreira: Yes, 'virt' is actually the _recommended_ machine type for AArch64 | |
| 16:56:09 | belmoreira | thanks for let me know what the machine type means | |
| 16:56:18 | kashyap | I've documented it "why" in the libvirt driver.py | |
| 16:56:51 | sean-k-mooney | thinks of the machine type as the "motherboard" of the vm | |
| 16:57:00 | sean-k-mooney | its not quite the same thing but its close enough | |
| 16:57:39 | kashyap | Yes, that's the analogy I use. A "virtual motherboard" with some default devices built-in | |
| 16:58:10 | sean-k-mooney | including hopefully a pci bus which is what it was previously unhappy about | |
| 16:59:07 | kashyap | sean-k-mooney: Yes, it does include | |
| 16:59:25 | kashyap | belmoreira: sean-k-mooney: I mention it in the commit message here, FWIW, https://opendev.org/openstack/nova/commit/e155baefb0 | |
| 17:02:21 | belmoreira | after changing to hw_machine_type=aarch64=virt I'm still getting the same error | |
| 17:03:50 | sean-k-mooney | kashyap: that chages the default for armv7 which is a completely different architecture | |
| 17:04:21 | sean-k-mooney | oh i guess you did it for both | |
| 17:04:24 | kashyap | Yes | |
| 17:04:35 | kashyap | sean-k-mooney: Not denying that. But the point stands, for AArch64, Armv7, etc, the recommended machine type is 'virt' :-) | |
| 17:05:19 | sean-k-mooney | belmoreira: the people that work at/with lenaro are probly your best bet | |
| 17:05:37 | sean-k-mooney | belmoreira: we have no upstream testing of cross architecure support | |
| 17:06:45 | belmoreira | sean-k-mooney kashyap thanks for your tips. I will continue to dig into this and will let you know when I find more | |
| 17:06:48 | sean-k-mooney | i have dont this with libvirt a few times in the past but never actully done it with openstack | |