| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-06 | |||
| 14:33:17 | lyarwood | stephenfin: they are the only reason we need _host to fetch things anyway | |
| 14:33:39 | stephenfin | lyarwood: Left more comments there but probably easier discuss here | |
| 14:33:43 | stephenfin | Also, thanks gibi :) | |
| 14:33:54 | stephenfin | lyarwood: To which two configs do you refer? | |
| 14:35:10 | lyarwood | stephenfin: virt for fields.Architecture.ARMV7 & fields.Architecture.AARCH64 | |
| 14:35:31 | lyarwood | stephenfin: and s390-ccw-virtio for fields.Architecture.S390 & fields.Architecture.S390X | |
| 14:35:44 | stephenfin | Gotcha. Yeah, it's weird that they're there | |
| 14:36:28 | lyarwood | hmm we still pass caps.host.cpu.arch to get_default_machine_type so nvm | |
| 14:36:34 | stephenfin | At the very least, that should probably be done in the 'libvirt_utils.machine_type_mappings' function instead | |
| 14:36:40 | stephenfin | lyarwood: We pass an arch | |
| 14:36:58 | stephenfin | which we're getting from caps.host.cpu.arch but I don't think that's necessary | |
| 14:37:31 | stephenfin | lyarwood: Any reason we could pass the arch from 'libvirt_utils.get_arch' instead? | |
| 14:38:30 | stephenfin | That would probably be more correct since we surely want to retrieve the machine type for the _guest_ architecture | |
| 14:39:09 | kashyap | efried: Actually _very_ good observation on the priority of 'image_meta'... | |
| 14:39:12 | lyarwood | stephenfin:yeah that works | |
| 14:39:28 | lyarwood | stephenfin: totally missed that as an option | |
| 14:39:41 | efried | kashyap: Does it actually wind up mattering? I'll feel less nitpicky if it does. | |
| 14:39:50 | stephenfin | lyarwood: That's got to be a bug too, right? | |
| 14:40:13 | kashyap | efried: I'm not 100% sure; but from my reading, it doesn't. (Sorry for the weasel words.) | |
| 14:41:10 | lyarwood | stephenfin: hmm it's inefficient but I don't think it was a bug | |
| 14:41:12 | stephenfin | kashyap, lyarwood: So from https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4327-L4355 we'll try to retrieve the machine type from image metadata | |
| 14:41:30 | stephenfin | If can't do that, we'll fall back to using something based on the host architecture | |
| 14:41:47 | kashyap | stephenfin: Correct | |
| 14:42:04 | stephenfin | But if the guest is e.g. x86 running on an ARMV7 host, we'll return a machine type of 'virt' | |
| 14:42:05 | kashyap | Am I wrong in insisting to do this extraction thingie in a separate change? | |
| 14:42:38 | kashyap | stephenfin: You mean, an emulated x86 guest running on an ARMv7 host? | |
| 14:42:41 | stephenfin | So the guest would have an x86 architecture but a ARM'y machine type | |
| 14:42:44 | stephenfin | kashyap: Yeah | |
| 14:42:52 | lyarwood | that would be abug | |
| 14:43:09 | kashyap | Yes, that's a bug. | |
| 14:43:14 | stephenfin | Sweet :) | |
| 14:43:32 | kashyap | HOWEVER | |
| 14:43:41 | stephenfin | I imagine no one would ever see this because what sane operator would run fully-emulated guests | |
| 14:43:55 | kashyap | stephenfin: Who in their right mind would do that for any production workload? | |
| 14:44:01 | stephenfin | kashyap: Jinx | |
| 14:44:08 | kashyap | _Exactly_, that was my "HOWEVER" | |
| 14:44:48 | kashyap | So, we can't have 100% guards for people willingly sticking knives in thier necks. | |
| 14:44:58 | kashyap | If that's an analogy at all :D | |
| 14:45:21 | mriedem | stephenfin: i know of an operator in the ML asking for that, to run powervm guests on an x86 host | |
| 14:45:30 | kashyap | lyarwood: Sorry, your good deed is getting punished, is it? | |
| 14:45:37 | stephenfin | Ultimately though, this seems to suggest we can remove the 'caps' argument to '_get_machine_type' and retrieve the *guest* architecture via the 'libvirt_utils.get_arch' function instead | |
| 14:45:45 | stephenfin | and lyarwood gets to fix two bugs in one | |
| 14:45:51 | stephenfin | for the win | |
| 14:45:56 | sean-k-mooney | stephenfin: operator that want to support cross arch developemnt | |
| 14:45:58 | mriedem | i'm pretty sure danpb was also ok (in the ML) with the fully emulated thing | |
| 14:45:59 | kashyap | But in two separate changes, obviously. | |
| 14:46:10 | kashyap | sean-k-mooney: Yeah, for development, yes... | |
| 14:46:22 | stephenfin | mriedem: In production?? | |
| 14:46:36 | sean-k-mooney | yes so its also a valid usecase for build farms | |
| 14:46:37 | mriedem | let me get the thread | |
| 14:46:49 | stephenfin | If so, can they share some of the cash they're burning with me? | |
| 14:47:21 | sean-k-mooney | e.g. if you are a software company uing the cloud to bulid your product for mulitple target archatecure full emulation it totally vailid | |
| 14:47:23 | mriedem | this guy is funded by the US military so they have infinite funds | |
| 14:47:29 | kashyap | sean-k-mooney: I contend that anyone who *REALLY* cares about multiple archs, they will get a devel box for that arch. | |
| 14:47:35 | stephenfin | Called it :) | |
| 14:47:57 | sean-k-mooney | kashyap: that is not what i think the majority of people do | |
| 14:48:11 | mriedem | http://lists.openstack.org/pipermail/openstack-operators/2018-August/thread.html#15617 | |
| 14:48:14 | mriedem | ^ is the thread | |
| 14:48:20 | sean-k-mooney | most use qemu to develop and test locally and only get real hardware if they ware writing low level software | |
| 14:49:40 | mriedem | danpb's reply is in this one http://lists.openstack.org/pipermail/openstack-operators/2018-August/015653.html | |
| 14:49:47 | kashyap | Yeah, I'm not denying there's no devel/test use case | |
| 14:49:48 | mriedem | "> Yes, it should do exactly that IMHO !" | |
| 14:49:52 | stephenfin | mriedem: How'd you manage to link to a specific email on the list page? Manually adding the anchor (or whatever the #foo part of a URL is called)? | |
| 14:50:23 | kashyap | I totally missed that thread :-( | |
| 14:50:30 | kashyap | Because of e-mail filtering snafu | |
| 14:50:33 | mriedem | stephenfin: "thread" under " Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] "" | |
| 14:51:16 | stephenfin | ooh, nifty | |
| 14:51:20 | stephenfin | mriedem++ | |
| 14:52:31 | sean-k-mooney | mriedem: was a blueprint ever filed for that | |
| 14:52:38 | kashyap | Yeah, the thread" view is easy to miss if you're not often parsing the archives :-) | |
| 14:53:17 | kashyap | mriedem: Some elephant-like memory you've got there! | |
| 14:53:35 | kashyap | What is it that you munch on for breakfast? | |
| 14:54:27 | kashyap | sean-k-mooney: No, it wasn't filed, near as I see. | |
| 14:56:17 | sean-k-mooney | thats a shame it would be nice to be able to handel cross arch emultaiton properly in openstack | |
| 14:57:31 | mriedem | sean-k-mooney: not that i'm aware of | |
| 14:57:32 | kashyap | sean-k-mooney: Filing it right now... | |
| 14:58:13 | mriedem | heh so you guys went from "this is a bug burn it burn it!" to "hey it's a feature let's support it!" | |
| 14:58:51 | mriedem | kashyap: i remember the thread because i was the only one engaging chris on it | |
| 14:59:04 | mriedem | and it took me awhile to understand what he was trying to do | |
| 14:59:17 | kashyap | mriedem: I completely missed it due to filtering :-( Normally anything with 'qemu' or 'libvirt' in the thread, I make it a point to engage | |
| 15:00:05 | kashyap | The case is valid for *test* / *devel*: because as of a couple of hours ago, I was running an AArch64 guest on x86_64 -- to test some PCIe stuff | |
| 15:00:26 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP libvirt: Use SATA bus for cdrom devices when using Q35 machine type https://review.opendev.org/663011 | |
| 15:00:26 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM: Run tempest-full-py3 with q35 machine type https://review.opendev.org/662887 | |
| 15:00:27 | lyarwood | stephenfin: ^ can you take a look at that during the team call and I'll sort tests out in the background. | |
| 15:00:33 | kashyap | But even for that test to be reliable, I had to ask a person with actual AArch64 hardware | |
| 15:00:41 | mriedem | couldn't the same be said for nested virt? | |
| 15:01:19 | sean-k-mooney | kashyap: test and dev are two of the larger useces for openstack | |
| 15:01:45 | sean-k-mooney | not everything is a long lived NFV app :) | |
| 15:01:53 | kashyap | mriedem: Somewhat; some people use nested for real workloads | |
| 15:02:03 | mriedem | that's my point | |
| 15:02:06 | kashyap | As that still is using hardware extensions | |
| 15:02:11 | kashyap | s/that/that's/ | |
| 15:02:25 | kashyap | For pure emulation (or "TCG") -- no, every instruction is emulated | |
| 15:02:26 | sean-k-mooney | some people use emulation for real workload too | |
| 15:22:56 | stephenfin | lyarwood: Done. Think there's _another_ bug here. Might be helpful to get aspiers input on it | |
| 15:23:22 | stephenfin | aspiers: Referring to https://review.opendev.org/#/c/663011/9/nova/virt/libvirt/utils.py@563 | |
| 15:27:26 | lyarwood | stephenfin: yup that's true | |
| 15:27:55 | lyarwood | stephenfin: and when you say dedent? | |
| 15:28:09 | stephenfin | the opposite of indent? | |
| 15:28:11 | kashyap | I think he means to unindent | |