| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-16 | |||
| 11:28:42 | openstackgerrit | Merged openstack/os-vif master: Extend port profiles with datapath offload type https://review.openstack.org/572081 | |
| 11:30:22 | kashyap | stephenfin: Death by a thousand config options | |
| 11:30:32 | kashyap | We're reaching QEMU command-line parity | |
| 11:32:10 | kashyap | As of winter 2015, QEMU had 139 total command-line options (of which, 129 are "officially supported") | |
| 11:32:49 | kashyap | QMP (run-time machine interface) is even bigger (also as of KVM Forum 2015): 126 commands + 33 events. And more than 700 named arguments and results. | |
| 11:33:30 | kashyap | QMP is bigger than Gospel of Luke. (Heard that comparison from a QEMU developer, Markus Armbruster.) | |
| 11:39:23 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fix ComputeNode ovo compatibility code https://review.openstack.org/631199 | |
| 12:24:54 | gibi | stephenfin: thanks the quick feedback on ^^ | |
| 12:25:08 | gibi | stephenfin: there is another really simple fix related to this https://review.openstack.org/#/c/631179/ | |
| 12:28:03 | kashyap | Hey folks, would be useful to put these through their misery: https://review.openstack.org/#/q/topic:bp/support-qemu-native-tls-for-live-migration+(status:open+OR+status:merged) | |
| 12:44:07 | gibi | kashyap: looking | |
| 12:49:22 | gibi | kashyap: I'm +2 on both | |
| 12:49:35 | kashyap | Thank you very much! | |
| 12:49:46 | gibi | stephenfin: easy approve opportunity https://review.openstack.org/#/q/topic:bp/support-qemu-native-tls-for-live-migration | |
| 12:50:06 | gibi | kashyap: thank you to working on this | |
| 12:50:53 | kashyap | NP. Now I can get to some of the gory machine types work in Nova. | |
| 12:52:09 | gibi | :) | |
| 12:55:29 | kashyap | But that requires a full re-reading of some really long QEMU mailing list threads, and find the haystack in those bits that are useful for Nova... | |
| 12:55:57 | kashyap | To borrow a quote from DanPB: "trying to find a specific piece of hay in a haystack" | |
| 12:56:16 | gibi | sounds like fun | |
| 13:16:47 | kashyap | This is the starting point: https://blueprints.launchpad.net/nova/+spec/handle-default-machine-type-as-q35 | |
| 13:17:13 | sean-k-mooney | kashyap: do you need a blueprint for that? | |
| 13:17:26 | sean-k-mooney | you can do that in rocky no? | |
| 13:17:39 | sean-k-mooney | actully maybe in older release | |
| 13:18:40 | sean-k-mooney | oh its handeling when qemu moves to q35 by default | |
| 13:19:29 | sean-k-mooney | kashyap: that will be for train cycle yes since we are pass the spec/blueprint approval deadline | |
| 13:21:07 | kashyap | sean-k-mooney: Yeah, right. It's for Train, indeed. | |
| 13:21:15 | kashyap | It needs a _lot_ of details to be ironed out. | |
| 13:21:43 | kashyap | sean-k-mooney: I even posted a spec, actually. As we _might_ introduce flavor extra_specs; we discussed this briefly, you might recall | |
| 13:21:44 | sean-k-mooney | kashyap: you could just say nova will default to pc to keep backwads compatiblity | |
| 13:22:01 | sean-k-mooney | kashyap: yes i saw https://review.openstack.org/#/c/631154/1 | |
| 13:22:06 | kashyap | sean-k-mooney: Maybe we can make a decision based on the OS | |
| 13:22:12 | sean-k-mooney | i have start it for later descision | |
| 13:22:20 | sean-k-mooney | kashyap: on which os | |
| 13:22:24 | sean-k-mooney | you cant look at the guest | |
| 13:22:39 | kashyap | sean-k-mooney: Don't start on it yet, it has some broken sentences, and I need to rewrite some bits, add some more, etc. | |
| 13:22:48 | kashyap | sean-k-mooney: E.g. upstream libosinfo has done quite a bit of work in this area -- | |
| 13:23:02 | kashyap | ... so that we can make an intelligent decision | |
| 13:23:27 | sean-k-mooney | kashyap: yes but we cant and should not change which chipset a gust image will boot on over an upgrade or migration | |
| 13:23:38 | kashyap | sean-k-mooney: See line-82: https://review.openstack.org/#/c/631154/1/specs/stein/approved/gracefully-handle-qemu-machine-types.rst@82 | |
| 13:23:44 | kashyap | sean-k-mooney: Sure, we won't do that. | |
| 13:24:14 | kashyap | I'll add all these considerations in the spec. There's too much detail here, I need to condense it and note them down. :-) | |
| 13:25:05 | root___ | leave | |
| 13:25:14 | sean-k-mooney | ya the only time i think we will be able to enable q35 without the existing image property or nova config value set is if the guest image says it cant supprot the pc type | |
| 13:25:40 | sean-k-mooney | anything else would potentially be an observal behavior change | |
| 13:25:59 | kashyap | sean-k-mooney: Right, on guest saying: "can't do 'pc'". | |
| 13:26:25 | kashyap | sean-k-mooney: Are you saying Nova can't choose 'q35' based on certain concrete factors? | |
| 13:26:35 | sean-k-mooney | yes | |
| 13:27:04 | sean-k-mooney | not with out a potential iteropo issue between clouds with different version of openstack | |
| 13:27:23 | sean-k-mooney | that said the interop issue would be no worse then seting the nova.conf value | |
| 13:27:44 | sean-k-mooney | anyway we can discuss on the spec at some later point | |
| 13:28:03 | kashyap | sean-k-mooney: Oh, please hang on. We _can_ make a decision to pick 'q35' or 'pc. | |
| 13:28:21 | sean-k-mooney | we can but i dont think we should | |
| 13:28:26 | kashyap | If guest says: "I can do both 'pc' and 'q35'", a future Nova should of course pick Q35. | |
| 13:28:35 | sean-k-mooney | nope | |
| 13:28:38 | kashyap | sean-k-mooney: Why not? I don't get the point about "potential interop" | |
| 13:28:43 | kashyap | I'd like to understand that more clearly. | |
| 13:28:53 | sean-k-mooney | that is a behvior change on upgrade without a specifc config flag to enable it | |
| 13:29:02 | kashyap | Yeah, we can talk on the spec, though. So if you want to "save your words", that's fine. | |
| 13:29:28 | sean-k-mooney | well there is alway the irc log | |
| 13:29:54 | ShilpaSD | gibi: hi | |
| 13:29:55 | kashyap | sean-k-mooney: Okay, the upgrade aspect, I need to spend more thought on it. But I don't think we can rule out altogether making a conscious choice in some scenarios. | |
| 13:30:06 | gibi | ShilpaSD: hi | |
| 13:30:13 | sean-k-mooney | the prime example of where auto select q35 may be a proable is if i had set e1000 as the hw_vif_model in the image | |
| 13:30:38 | sean-k-mooney | e1000 is a pci device and is not supported with q35 which woudl need e1000e | |
| 13:30:38 | ShilpaSD | gibi: i am fixing py27 failure for https://review.openstack.org/#/c/612626/ | |
| 13:30:55 | kashyap | sean-k-mooney: Right, I see that point, though. | |
| 13:31:16 | ShilpaSD | gibi: here Instance object version is increased from 2.4 to 2.5 and updated dict _INSTANCE_OPTIONAL_JOINED_FIELDS | |
| 13:31:43 | ShilpaSD | gibi: observed that test case failing with error 'Cannot call obj_load_attr on orphaned Instance object' | |
| 13:32:14 | ShilpaSD | gibi: help me to understand, in Unit test case framework what all changes i have to carry to resolve this issue | |
| 13:32:23 | ShilpaSD | looking into fake_instance.py | |
| 13:34:02 | sean-k-mooney | kashyap: there are probaly things we can do to hanel some and maybe all the edgecase but we need to be sure the upgrade impact is fully understood. anyway i need to go rebase a path and write tests :) | |
| 13:34:30 | kashyap | [Just checking w/ DanPB elsewhere (since he's not here) about a couple of things.] | |
| 13:34:36 | kashyap | sean-k-mooney: Oh, absolutely. | |
| 13:34:53 | kashyap | I'm with you on that "upgrade impact" needs to be carefully considered. I am all for careful consideration. | |
| 13:36:53 | openstackgerrit | Merged openstack/nova master: Make functional-py37 job work like others https://review.openstack.org/630745 | |
| 13:41:58 | ShilpaSD | gibi: hi | |
| 13:47:15 | gibi | ShilpaSD: I'm not sure about the answer | |
| 13:47:47 | ShilpaSD | gibi: ok, will check further | |
| 13:47:56 | gibi | ShilpaSD: what code in your patch makes sure that the BlockDeviceMapping is loaded from the db? | |
| 13:48:26 | ShilpaSD | gibi: ok, will check that | |
| 13:50:33 | gibi | ShilpaSD: also I think jichenjc has a valid point about loading bdm directly instread of through the instance https://review.openstack.org/#/c/612626/2/nova/api/openstack/compute/simple_tenant_usage.py@170 | |
| 13:52:15 | ShilpaSD | gibi: IMO it will increase DB call and will imact performance | |
| 13:53:36 | gibi | ShilpaSD: I dont see how it is different from db load perspective if we load the bdm through the instance or load it directly by instance.uuid | |
| 13:55:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fix ComputeNode ovo compatibility code https://review.openstack.org/631199 | |
| 13:55:20 | gibi | stephenfin: fixed your comment in ^^ | |
| 14:49:14 | ShilpaSD | mriedem: hi, please give me your views on https://review.openstack.org/#/c/612626/2/nova/api/openstack/compute/simple_tenant_usage.py@170 | |
| 14:50:22 | mriedem | ShilpaSD: what you added wasn't really what i was thinking | |
| 14:50:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Handle libvirt reporting incorrect 4k page quantities https://review.openstack.org/631038 | |
| 14:50:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Fix overcommit for NUMA-based instances https://review.openstack.org/629281 | |
| 14:50:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Split '_get_host_numa_topology' function https://review.openstack.org/631237 | |
| 14:50:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Make overcommit check for pinned instance pagesize aware https://review.openstack.org/631053 | |
| 14:52:02 | ShilpaSD | mriedem: ohh, i think misunderstood, can you please expalin in simpler way | |
| 14:52:22 | stephenfin | mriedem: I _think_ most of your comments are addressed for the second of those ^ | |
| 14:52:55 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fix ovo compatibility code unit tests https://review.openstack.org/631239 | |
| 14:54:57 | mriedem | ShilpaSD: i mean something like https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L100 where that creates a 'services' attribute on the Instance model and uses that join query | |
| 14:56:06 | mriedem | we already have a relationship like that between instances and bdms https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L599 | |
| 14:56:25 | mriedem | but this would be a more targeted query based on bdm boot_index and destination_type | |
| 14:57:21 | mriedem | and i'm wondering if we can do that when pulling the instance from the db rather than make multiple queries to get all of the instances and then for each instance, get all of the bdms for that instance | |
| 14:59:11 | ShilpaSD | mriedem: thank you for this explaination, i will again go through the said above links and revisit the fixes. | |