Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-28
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 mriedem maybe i should split that out into it's own change...
16:34:32 efried stephenfin: +2, added notes for future me.
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
20:55:03 openstackgerrit Corey Bryant proposed openstack/nova master: Refresh block device connection_info on hard reboot https://review.openstack.org/579004
21:03:07 openstackgerrit Eric Fried proposed openstack/nova master: RT stats deepcopy 1x/node instead of 1x/instance https://review.openstack.org/576591
21:31:27 openstackgerrit karim proposed openstack/nova master: Handle rebuild of instances with image traits https://review.openstack.org/569498
21:40:48 efried mriedem: "kind of surprising given it was red hat people adding it" A guy who worked at IBM is surprised that one guy in a company with thousands of employees could have no clue what's happening in the next department over?
21:41:25 efried ffs, I can't tell you what most of the people in my *own* department are doing.
21:44:45 mriedem i hold red hatters to a higher standard...
21:44:56 mriedem i mean, they all wear the same red hat

Earlier   Later