| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-16 | |||
| 10:07:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fix incompatible version handling in BuildRequest https://review.openstack.org/631179 | |
| 10:26:21 | stephenfin | TIL nova has a 'reserved_huge_pages' option. Who knew | |
| 11:13:56 | openstackgerrit | Jan Gutter proposed openstack/os-vif master: Apply workaround to host_info serialization test https://review.openstack.org/631173 | |
| 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 | ShilpaSD | gibi: i am fixing py27 failure for https://review.openstack.org/#/c/612626/ | |
| 13:30:38 | sean-k-mooney | e1000 is a pci device and is not supported with q35 which woudl need e1000e | |
| 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: Fix overcommit for NUMA-based instances https://review.openstack.org/629281 | |
| 14:50:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Handle libvirt reporting incorrect 4k page quantities https://review.openstack.org/631038 | |
| 14:50:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Make overcommit check for pinned instance pagesize aware https://review.openstack.org/631053 | |
| 14:50:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Split '_get_host_numa_topology' function https://review.openstack.org/631237 | |
| 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 | |