| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-19 | |||
| 15:16:11 | hrw | sean-k-mooney: qemu has 3 x86 platforms: isa-pc (no one uses), i440fx (pci based), q35 (pcie based) | |
| 15:16:29 | mriedem | Placeed: i'm not intimately familiar with the bug nor the fix - melwitt has carried the patch for a long time, so she might be able to help once she's around | |
| 15:16:31 | sean-k-mooney | hrw: really i taught i440fx supported pcie | |
| 15:16:42 | hrw | sean-k-mooney: i440fx is older than pcie ;D | |
| 15:17:13 | mriedem | Placeed: you could also ask about that bug in the #openstack-operators channel and ask if anyone has patched it out of tree and if so, how? | |
| 15:17:17 | kashyap | sean-k-mooney: Yeah, first I'll read your full comment before talking further. And yes, Q35 does have the limitation you note. | |
| 15:17:38 | mriedem | Placeed: i know SAP is probably doing something for it | |
| 15:17:47 | mriedem | they use NFS for everything, and are i think suse customers | |
| 15:18:11 | Placeed | mriedem : Ok thank you very very much for your help. I will also check with SUSE Guys. | |
| 15:18:58 | kashyap | sean-k-mooney: My second sentence in my previous message was misphrased. Correct: Q35 _solves_ that limitation of older QEMUs PCIe support. | |
| 15:19:32 | hrw | would be nice to see some future qemu dropping <q35 ;D | |
| 15:19:48 | hrw | but that's not gonna happen | |
| 15:19:56 | openstack | Launchpad bug 1740241 in OpenStack Compute (nova) "Network info not always displayed for a created instance" [Undecided,New] | |
| 15:19:56 | bauzas | stupid question but we get network information from the compute right ? https://bugs.launchpad.net/nova/+bug/1740241 | |
| 15:20:06 | bauzas | at least until we do that from the conductor | |
| 15:21:43 | mriedem | efried: questoin here https://review.openstack.org/#/c/540111/5/specs/rocky/approved/update-provider-tree.rst@73 | |
| 15:21:44 | bauzas | nevermind, got the line | |
| 15:23:43 | mriedem | lyarwood: are you around this week? i want to flush some ocata patches since ocata eol is supposedly next week | |
| 15:24:33 | kashyap | hrw: Yes, that won't happen. Majority still use the 'i440fx', as you can guess. | |
| 15:25:11 | hrw | yep | |
| 15:25:34 | kashyap | mriedem: FWIW, I at least saw him on IRC briefly in the (CET) morning | |
| 15:28:08 | bauzas | mriedem: I can help | |
| 15:28:36 | bauzas | mriedem: lemme know which ones you'd like to see reviewed | |
| 15:28:41 | bauzas | for the moment, looking at LP | |
| 15:30:46 | mriedem | bauzas: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata+label:Code-Review=2 | |
| 15:31:01 | mriedem | some of those might have things on pike yet | |
| 15:31:08 | mriedem | like https://review.openstack.org/#/c/539008/ | |
| 15:31:13 | bauzas | mriedem: ack, will look at them ASAIC | |
| 15:31:20 | mriedem | thanks | |
| 15:31:37 | bauzas | 24 open bugs :p | |
| 15:31:41 | bauzas | woooot | |
| 15:45:48 | sean-k-mooney | hrw: kashyap is there a spec to enable Q35 proposed. i assume it will be via an image metadata item or perhaps a config option in the libvirt section of the nova.conf | |
| 15:46:00 | kashyap | sean-k-mooney: I updated the upstream QEMU doc to clearly spell out machine type requirements for PCIe features. | |
| 15:46:15 | hrw | sean-k-mooney: you set hw_machine_type = q35 in image and done | |
| 15:46:16 | kashyap | sean-k-mooney: Hmm, not that I know of; I have a TODO item to propose one, unless someone beats me to it | |
| 15:46:27 | kashyap | But yeah, currently what hrw tells above ^ | |
| 15:46:38 | hrw | sean-k-mooney: and then you review https://review.openstack.org/#/c/545034/ to have slots for hotplug ;d | |
| 15:46:41 | kashyap | You can either set it via the machine type Nova image metadat property | |
| 15:46:47 | kashyap | Or via the global configuration option | |
| 15:47:26 | hrw | sean-k-mooney: as AArch64 porter I would love to see more and more people moving to Q35 | |
| 15:47:48 | kashyap | sean-k-mooney: FWIW, I sent that (hopefully) clarifying patch -- https://lists.nongnu.org/archive/html/qemu-devel/2018-02/msg04905.html | |
| 15:50:39 | hrw | sean-k-mooney: as then they will share similar issues as we have on aarch64 ;D | |
| 15:57:06 | kashyap | sean-k-mooney: So these are the two possibilities with Nova: | |
| 15:57:13 | kashyap | (1) Image metadata property: | |
| 15:57:19 | kashyap | $ openstack image set --property hw_machine_type=x86_64=pc-q35-2.10 Fedora27_Template | |
| 15:57:22 | kashyap | (2) Nova conf: | |
| 15:57:35 | kashyap | hw_machine_type=x86_64=pc-q35-2.10 | |
| 15:57:35 | kashyap | ... | |
| 15:57:35 | kashyap | [libvirt] | |
| 15:58:32 | kashyap | sean-k-mooney: The remaining item in Nova is graceful handling of "distributions shipping 'q35' by default". | |
| 16:03:19 | openstackgerrit | Jay Pipes proposed openstack/os-vif master: zuul: Enable functional tests in gate https://review.openstack.org/530961 | |
| 16:07:47 | sean-k-mooney | kashyap: yep that all makes sense to me. operator can set in in nova.conf if they want to force it by default or tenant can request it in image metadata if there image requires q35 features to work e.g. vIOMMU support | |
| 16:09:20 | sean-k-mooney | kashyap: hrw it seams pretty strait forward to add Q35 support so a specless blueprint might be sufficent. will ye be at the ptg next week? | |
| 16:10:59 | kashyap | sean-k-mooney: Yes, at least I'll be there | |
| 16:11:17 | kashyap | (And nod to your previous comment, too) | |
| 16:16:50 | mriedem | dansmith: left a comment in https://review.openstack.org/#/c/544698/2/nova/tests/unit/db/test_sqlalchemy_migration.py - if you're meh on that, then i'll +2 anyway | |
| 16:19:01 | dansmith | mriedem: I'm pretty meh | |
| 16:23:10 | efried | jaypipes, cdent: edleafe: mriedem found a discrepancy in the update_provider_tree spec that I'd like to discuss and clear up. | |
| 16:23:21 | cdent | was just reading that | |
| 16:23:55 | efried | Here's the scenario: my compute node is aggregated with a sharing provider. The sharing provider happens to be part of its own tree. We want the sharing provider itself to be included in the ProviderTree that u_p_t gets - that's for sure. | |
| 16:23:58 | efried | But | |
| 16:24:30 | efried | Do we want to include the sharing provider's whole tree? Or just the provider itself, as a "root" even if it isn't really a root in its own tree? | |
| 16:25:14 | efried | jaypipes: I want to say you and I discussed this briefly when I was writing the code and decided on the latter, but thinking through it again, I'm not convinced that's The Right Thing. | |
| 16:25:31 | edleafe | efried: sounds like you have a huge recursion problem if you include trees of trees of trees of ... | |
| 16:25:38 | mriedem | i assume the compute driver got an n-1 view of things it doesn't control | |
| 16:25:43 | mriedem | edleafe: yes agree | |
| 16:26:06 | jaypipes | mriedem: I don't understand what you mean by an "n-1 view" | |
| 16:26:12 | efried | edleafe: Well, we have explicit boundaries. We definitely don't go and spider out to the sharing provider's aggregate-associated providers. | |
| 16:26:13 | mriedem | 1 removed | |
| 16:26:24 | efried | ^ that | |
| 16:26:37 | mriedem | so the virt driver gets the compute node + the sharing provider aggregate, but none of that things children | |
| 16:26:39 | edleafe | efried: another way to look at it: would the compute node ever need to know about /interact with any of the shared provider's tree other than the SP itself? | |
| 16:26:51 | efried | Arguably the unrelated bits of the sharing provider's tree are n-2 - but I'm not sure that's a horrible thing. | |
| 16:27:17 | cdent | I think edleafe's question is the crux. | |
| 16:27:33 | efried | edleafe: No. But. I don't feel great about the caveat that it would show up as a root even if it's not a root. Rather have more information (that's not used) in the tree than have some of it be inaccurate? | |
| 16:27:38 | mriedem | if the virt driver shouldn't mess with stuff outside of the compute node's tree, it should just be able to see that there is a relationship, right? but not the whole other thing's tree, lest the virt driver gets the idea it has access to update that other thing (which it shouldn't do) | |
| 16:27:59 | efried | Yeah, I agree with that. | |
| 16:28:02 | mriedem | i can't tell if it being a root or not matters | |
| 16:28:07 | efried | That's the thing. | |
| 16:28:18 | efried | We *do* want the virt to be able to mess with the sharing provider. | |
| 16:28:19 | mriedem | if my virt driver shouldn't mess with the sharing provider, why do i care if it's a root or not? | |
| 16:28:37 | mriedem | why? | |
| 16:28:45 | jaypipes | mriedem: this goes back to the powervm virt driver structure. | |
| 16:28:55 | cdent | efried: yes we do, but for those sharing providers that we want to mess with, do we want them to existing in a nested hieararchy? I would think/hope not. | |
| 16:28:57 | jaypipes | mriedem: they want the ability to manage storage pools in their virt driver. | |
| 16:28:59 | efried | As one example, yes. I think VCenter also had an example. | |
| 16:29:09 | cdent | vcenter's example is basically the same | |
| 16:29:15 | edleafe | efried: if the shared provider is the one with the inventory, it would be the one we allocate against, no? Why do we need its root provider? | |
| 16:29:35 | mriedem | inadvertently." | |
| 16:29:35 | mriedem | compute host. Care must be taken not to remove or modify such providers | |
| 16:29:35 | mriedem | however, that it may contain providers not directly owned/controlled by the | |
| 16:29:35 | mriedem | the spec says, "Note, | |
| 16:29:37 | jaypipes | edleafe: the virt driver doesn't allocate. | |
| 16:29:45 | dansmith | mriedem: rc2 is tagged, yeah? are we good to land the compute rpc thing now? | |
| 16:29:49 | efried | mriedem: Yes, there's that too. | |
| 16:29:50 | sean-k-mooney | jaypipes: just regarding those 2 os-vif changes you +2'd i am happy to merge them too but i think there may be an alternitive way to adress https://review.openstack.org/#/c/531358/ that would also work on centos but it might be tricky to do in the gate so ill run it by ye in dublin. | |
| 16:29:53 | mriedem | dansmith: sure | |
| 16:29:57 | mriedem | dansmith: i haven't looked at it yet | |
| 16:30:00 | edleafe | jaypipes: but I thought we were talking placement | |
| 16:30:17 | jaypipes | edleafe: we're talking virt driver's use of the ProviderTree struct | |