| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-28 | |||
| 15:57:54 | mdbooth | mriedem: Sorry, thought we were good on the other patch. I'll pick it up again. | |
| 16:03:02 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Usages per project and user (v1.8, v1.9) https://review.openstack.org/514646 | |
| 16:03:03 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 16:03:04 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: New dict format of allocations (v1.11, v1.12) https://review.openstack.org/542819 | |
| 16:03:05 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Transactionally update allocations (v1.13) https://review.openstack.org/546674 | |
| 16:03:06 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Add nested resource providers (v1.14) https://review.openstack.org/546675 | |
| 16:03:07 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Limit allocation candidates (v1.15, v1.16) https://review.openstack.org/548043 | |
| 16:03:08 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Allocation candidates parameter: required (v1.17) https://review.openstack.org/548326 | |
| 16:03:27 | mriedem | gibi: i think the bottom of that series is good now ^ | |
| 16:03:34 | mriedem | i just cleaned up some leftovers from the command split | |
| 16:08:56 | efried | gibi: IIRC, the func test failure here https://review.openstack.org/#/c/560317/17/nova/tests/functional/libvirt/test_report_cpu_traits.py looks similar to a race you debugged... somewhere else. Do you remember offhand what the fix was? | |
| 16:15:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa in tree https://review.openstack.org/578878 | |
| 16:15:57 | mriedem | would be nice to get this in so we don't burn nodes on docs-only changes ^ | |
| 16:18:34 | stephenfin | mriedem: Any idea is zuul supports YAML roles/anchors, like we use for the API samples (I think)? | |
| 16:18:40 | stephenfin | https://anil.io/blog/symfony/yaml/using-variables-in-yaml-files/ | |
| 16:20:03 | mriedem | no idea | |
| 16:20:10 | mriedem | to define irrelevant-files? | |
| 16:20:15 | stephenfin | aye | |
| 16:20:22 | mriedem | ask in -infra | |
| 16:20:26 | stephenfin | Will do | |
| 16:32:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tox: Reuse envdirs https://review.openstack.org/534382 | |
| 16:32:19 | stephenfin | efried: ^ | |
| 16:32:26 | efried | ... | |
| 16:33:42 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa in tree https://review.openstack.org/578878 | |
| 16:33:50 | mriedem | stephenfin: ^ mostly copied from how i see we do that in api-ref parameters.yaml | |
| 16:34:01 | stephenfin | ack | |
| 16:34:32 | efried | stephenfin: +2, added notes for future me. | |
| 16:34:32 | mriedem | maybe i should split that out into it's own change... | |
| 16:34:42 | stephenfin | probably not a bad idea | |
| 16:34:53 | stephenfin | unless you're backporting, in which case meh | |
| 16:34:54 | mriedem | zuul already barfed on it | |
| 16:34:58 | mriedem | i am backporting | |
| 16:35:29 | stephenfin | Hmm, wonder if zuul has an local linter | |
| 16:35:41 | mriedem | no i think i just copied an example incorrectly | |
| 16:36:23 | mriedem | so i think i'm going to revert to PS1 and then do the dedupe in a non-backportable follow up | |
| 16:36:29 | stephenfin | ack | |
| 16:37:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa in tree https://review.openstack.org/578878 | |
| 16:42:04 | stephenfin | exit | |
| 16:42:10 | stephenfin | whoops | |
| 16:42:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Define common variables for irrelevant-files https://review.openstack.org/578882 | |
| 16:43:08 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Define common variables for irrelevant-files https://review.openstack.org/578882 | |
| 17:00:00 | efried | stephenfin: Where can I find a real os_vif plugin? | |
| 17:01:59 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove file injection from config drive sample docs https://review.openstack.org/578888 | |
| 17:04:08 | openstackgerrit | Merged openstack/os-traits master: Add COMPUTE_TRUSTED_CERTS trait https://review.openstack.org/576595 | |
| 17:08:57 | efried | mriedem: Do you know where I can find a real os_vif plugin? | |
| 17:09:47 | mriedem | efried: yeah | |
| 17:09:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: More config drive docs updates https://review.openstack.org/578890 | |
| 17:10:06 | mriedem | https://github.com/Juniper/contrail-nova-vif-driver | |
| 17:10:08 | mriedem | efried: ^ | |
| 17:10:17 | efried | mriedem: Thanks | |
| 17:15:17 | efried | jangutter: Still lurking? | |
| 17:17:18 | jangutter | efried: yaaaaaas. | |
| 17:17:51 | efried | jangutter: I'm looking at the Juniper contrail os-vif plugin and wanted to confirm what I think I'm seeing. | |
| 17:18:14 | jangutter | efried: actually, the real "reference" plugins are in the os-vif repo for vif_plug_ovs | |
| 17:18:27 | jangutter | efried : and linuxbridge I think. | |
| 17:18:51 | efried | jangutter: First of all, I'm not particularly well-versed on libvirt. But IIUC, plugging a vif entails 1) creating some kind of device thingy on the host, and then 2) modifying the instance's XML to make it show up in the instance. Do I have this right? | |
| 17:18:56 | jangutter | efried: go ahead. it really is as bad as you think. | |
| 17:20:11 | jangutter | efried: the ones I've seen work like this: the xml for libvirt sometimes goes above and beyond. Spawining the VM (which creates the thingy) and plugging the thingy into another thingy in one fell swoop. | |
| 17:20:12 | efried | jangutter: Well, my question is more generic ^ | |
| 17:20:57 | jangutter | efried: the trick is, only the very first few bridges were built like that, then people started building their own. | |
| 17:21:38 | jangutter | efried: which means that, in libvirt you can _also_ say, spawn the VM and leave the thingy dangling, then, call the os-vif plugin to plug the thingy into the thingy. | |
| 17:22:05 | jangutter | efried: and I'm not 100% sure of the order. in theory the order should be independent. | |
| 17:22:38 | efried | jangutter: Right, but my point is this: When my virt driver invokes the plug() method, once that method returns, the virt driver doesn't need to do anything else (like update the xml), right? | |
| 17:22:40 | jangutter | efried: OVS, for example, doesn't really care about the order since it listens to netdevs appearing. | |
| 17:23:02 | jangutter | efried: yeah, those paths diverge completely in libvirt. | |
| 17:24:26 | jangutter | efried: you're talking about the os-vif plugin's plug() method, right? | |
| 17:24:32 | efried | yes | |
| 17:26:04 | efried | jangutter: I'm reviewing cyborg's os-acc spec, and Sundar is asserting that plug() is supposed to return some kind of (platform-specific) metadata that the caller then has to use to do the actual attach of the device. He says in libvirt the metadata would comprise an XML blob and the post-plug() attach would entail injecting that into the instance's XML. | |
| 17:26:37 | efried | jangutter: And that sounds wrong to me, even assuming it's the way os-vif does things. But afaict, it's *not* the way os-vif does things. Once you're done with plug(), you're plugged, end of story. | |
| 17:26:55 | jangutter | efried: aaah, I see: with os-vif the info very much flows one-way there. | |
| 17:27:00 | efried | and I'm just trying to get confirmation of that so I can respond with... confidence :) | |
| 17:29:03 | jangutter | efried: however. os-vif is still inside Nova at this point, so it's conceivable to think of something like like a query mechanism. It's fraught with peril though. | |
| 17:29:49 | efried | jangutter: I'm more concerned about the intent of the architecture than any gory details of the existing implementation. | |
| 17:30:36 | efried | jangutter: I think I've got what I need here. Dankie vir die hulp. | |
| 17:30:44 | jangutter | efried: Plesier! | |
| 17:31:34 | jangutter | efried: the os-acc object should be translateable to libvirt xml without any plugin intervention whatsoever. | |
| 17:34:03 | efried | jangutter: But the point is that nobody outside of the plugin itself should need to do that. | |
| 17:35:53 | jangutter | efried: with os-vif, the translation from the os-vif object to libvirt xml happens inside Nova (completely outside os-vif, and not inside the plugin). | |
| 17:36:43 | efried | jangutter: Hm, then I must be missing where that's being injected into the instance's XML. I'll look again... | |
| 17:38:36 | efried | mriedem: From here https://review.openstack.org/#/c/569498/6/nova/conductor/manager.py@1029 is there no better way to discover the compute node RP than ComputeNode.get_by_host_and_nodename() ? | |
| 17:39:06 | jangutter | efried: Here's one way it gets converted: https://github.com/openstack/nova/blob/master/nova/tests/unit/virt/libvirt/test_vif.py#L1795 | |
| 17:42:44 | efried | jangutter: Aha, I see it now. The plug method isn't returning anything, but the vif object is being used afterwards. Thanks for the pointer. | |
| 17:43:39 | jangutter | efried: yeah, a couple of os-vif plugins just pass, because libvirt does the heavy lifting. | |
| 17:43:54 | efried | In Power's case, it'll be vice versa. | |
| 17:48:34 | mriedem | efried: that's pretty common lookup for the 'source' compute in move operations at least, | |
| 17:49:02 | mriedem | https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L205 | |
| 17:49:14 | mriedem | where self.source = instance.host | |
| 17:49:38 | mriedem | we can rebuild ironic nodes so we'd really need to call ComputeNode.get_by_host_and_nodename() using instance.host and instance.node | |
| 17:49:40 | efried | mriedem: Yeah, saw that. It just seemed pretty heavy-weight. Thought there might be a lighter way to get the compute node UUID. | |
| 17:49:47 | mriedem | from the instance? | |
| 17:50:07 | efried | yeah, or from something else we could potentially have at that point in the code path. | |
| 17:50:24 | efried | like maybe we already looked it up somewhere... | |
| 17:51:09 | mriedem | not for rebuild | |
| 17:52:10 | efried | okay, thanks. | |
| 17:52:42 | mriedem | i don't see ComputeNode.get_by_host_and_nodename() being used in that code, so i'm kind of missing the link - they are just looking up the provider tree a different way right? | |
| 17:53:04 | mriedem | so you're going to tell them to use ComputeNode.get_by_host_and_nodename() ? | |
| 17:55:32 | efried | mriedem: It was karimull's idea to do that; I was just wanting to verify that there wasn't a better way. | |
| 17:56:02 | efried | (karimull has a tendency to PM me rather than tagging me in here, which would be better, hint hint.) | |
| 18:07:43 | efried | Dude, this cyborg stuff is, like, a full-time job. | |
| 18:08:01 | cdent | s/cyborg/*/ | |