Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-17
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
17:08:10 sean-k-mooney by the way are you setting hw_machinet_type in the image too https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json#L60
17:10:25 belmoreira In the image I just set the arch. Let me try
17:11:18 sean-k-mooney your setting https://github.com/openstack/glance/blob/54329c6a21b0d3f845b09e79f710fc795976a175/etc/metadefs/glance-common-image-props.json#L26-L29
17:11:33 sean-k-mooney as architecture=aarch64
17:11:44 sean-k-mooney or architecture=arm
17:12:23 sean-k-mooney sorry that should be hw_architecture=aarch64
17:12:55 efried dansmith: This should hopefully be relatively simple for you to understand and sanity check if you don't mind please: https://review.opendev.org/#/c/702261/
17:13:31 dansmith heh first file has random whitespace damage
17:13:34 dansmith but will look in a sec
17:14:46 sean-k-mooney belmoreira: so ya checking https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/virt/arch.py#L21 it should be hw_architecture=aarch64
17:20:05 belmoreira sean-k-mooney also using hw_architecture=aarch64. I'm getting the same error. Thanks. I will review my config
17:34:13 openstackgerrit Ilya Etingof proposed openstack/nova master: [WIP] Add JSON schema for network_data.json https://review.opendev.org/703133
17:48:56 openstackgerrit sean mooney proposed openstack/nova stable/queens: Disable NUMATopologyFilter on rebuild https://review.opendev.org/703141
17:48:56 openstackgerrit sean mooney proposed openstack/nova stable/queens: Block rebuild when NUMA topology changed https://review.opendev.org/703140
17:48:57 openstackgerrit sean mooney proposed openstack/nova stable/queens: FUP for in-place numa rebuild https://review.opendev.org/703142
17:53:05 gmann stephenfin: before you start you beer. i pushed 4-5 policies change on this, if you can check on your Monday which will be earlier than mine so pinging in advance :) - https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/policy-defaults-refresh
17:57:23 gibi efried: regarding RP name parsing: Nova needs to know which PF (known by nova based on PCI address) is represented by which RP in placement. That RP is created by neutron and neutron does not use PCI addresses but uses the device name instead. So now nova also gather the device name and use that to find the device RP in placement
17:58:18 efried mm, okay, this is the same thing we're doing for vgpus?
17:58:33 gibi efried: the neutron behavior is originating from the fact that device mapping in the neutron agent config was always based on device name
17:59:13 gibi efried: for vgpus we don't need to agree on a common ID between diferrent projects so I guess the vgpu case is easier
17:59:27 efried okay, but I think we're using the name to identify the mdev, or something.

Earlier   Later