| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-16 | |||
| 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. | |
| 15:00:39 | mriedem | ShilpaSD: if that works, i'm not sure if it's a field we'd want to always populate on the Instance object or make it optional, like the other fields in _INSTANCE_OPTIONAL_JOINED_FIELDS | |
| 15:01:18 | mriedem | if it's optional, then it could just be a very targeted thing that gets populated in the db api if that field is requested in columns_to_join | |
| 15:01:30 | mriedem | *expected_attrs | |
| 15:01:51 | mriedem | dansmith might have an opinion on that | |
| 15:02:45 | dansmith | yep, like bdms, makes sense | |
| 15:03:55 | efried | mriedem: Do I have my time wrong, or are we supposed to be doing the delete-placement-from-nova hangout right now? | |
| 15:04:20 | gibi | efried: isn't it 17:00 UTC? | |
| 15:04:38 | efried | d'oh, that's my bad. Thanks gibi | |
| 15:04:58 | efried | gibi: and the bw one is also 1700 UTC, on friday? | |
| 15:05:03 | gibi | efried: yes | |
| 15:05:27 | mriedem | ShilpaSD: i left some comments in the patch | |
| 15:06:51 | ShilpaSD | mriedem: will check, thank you for explaination and comments | |
| 15:07:30 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Add Cyborg device profile groups to spec obj. https://review.openstack.org/631243 | |
| 15:07:30 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Add utility function to get Cyborg client. https://review.openstack.org/631242 | |
| 15:07:31 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Get resolved Cyborg ARQs and add PCI BDFs to VM's domain XML. https://review.openstack.org/631245 | |
| 15:07:31 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Create and bind Cyborg ARQs. https://review.openstack.org/631244 | |
| 15:14:36 | mriedem | melwitt: will your max volume attach series change the device name of existing attached bdms if the user reboots their server? i believe device tags are linked to bdms via device name, so was wondering if we could possibly have an upgrade impact with the device tag <> bdm.device_name getting out of whack | |
| 15:15:02 | mriedem | artom: ^ you might know off the top of your head on the device tag stuff | |
| 15:15:46 | artom | mriedem, it's been a while, lemme check the code | |
| 15:18:12 | artom | mriedem, yeah, it's by name | |
| 15:24:58 | mriedem | artom: do you remember why we used bdm.device_name as the correlation key for that stuff? maybe bdm uuid didn't exist when you wrote that | |