Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-28
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/*/
18:08:15 cdent too many things
18:14:32 mriedem you need to accelerate
18:14:37 mriedem amphetamines
18:14:54 mriedem Meth-as-a-service?!
18:41:58 cdent that acronym's taken
20:17:23 openstackgerrit Matt Riedemann proposed openstack/nova master: Use consumer generation in _heal_allocations_for_instance https://review.openstack.org/577905
20:33:34 mriedem efried: yeah this is fun https://review.openstack.org/#/c/576099/
20:34:03 mriedem i think that especially probably kills vcenter because it's 1 compute service per vcenter cluster, which can have like what 1000s of vms?
20:34:16 mriedem i wonder if powervc has hit something like that...
20:34:51 mriedem i sent it on to our internal perf team b/c they hit some similar types of issues where the big lock in the RT was being held too long when there are like 80 vms on the same host

Earlier   Later