Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-13
16:28:13 stephenfin but that would actually read " 'network': InstanceNUMANetworkInfo() "
16:28:16 mriedem well, 'networks': NUMANetworkInfo(), doesn't work anyway
16:28:18 mriedem that's not a field
16:28:29 stephenfin oops, fields.ObjectField
16:28:34 dansmith stephenfin: they're equivalent in functionality, just where it goes (top level or nested inside the numa limits obj) right?
16:28:40 mriedem dansmith: yeah
16:28:42 stephenfin dansmith: Correct
16:28:45 mriedem doesn't really matter to me i guess
16:28:49 mriedem i never thought about the nesting
16:28:56 dansmith yeah, so I'm mostly meh, but (b) seems maybe a little better
16:29:12 stephenfin It makes semantic sense to me but making sure I'm not mistaken
16:29:15 mriedem yeah wfm as well
16:29:23 mriedem i just never thought of that as an option
16:29:25 stephenfin I'm still not really up on why that object even exists...
16:29:33 stephenfin Cool, I'll try that out so
16:29:37 edmondsw efried I believe networking-powervm is just our SEA agent, not OVS, whereas I thought os-vif was just for OVS?
16:29:38 mriedem because random dicts o doom aren't fun?
16:29:54 mriedem stephenfin: the limits get passed over rpc
16:30:00 mriedem so they should be in versioned objects
16:30:18 jangutter efried: If Cyborg can pass os-acc objects directly to Nova, then it's already cut through 1.5 stages of migration os-vif is currently undergoing.
16:30:26 stephenfin Not the object itself but rather the idea of NUMA limits in the first place
16:30:34 mriedem jangutter: ++
16:30:38 jangutter edmondsw: os-vif is for EVERYONE
16:30:39 mriedem i wish os-brick was passing objects to nova
16:30:55 edmondsw jangutter ok tx for clarifying
16:30:59 mriedem the host connector dict to/from os-brick and the connection_info dict to/from cinder are totally random
16:31:27 mriedem but standardizing connection_info across 80 cinder backends isn't anything anyone wants to work on
16:32:17 jangutter edmondsw: I think the first reference plugins was for OVS and linuxbridge, but the VIF migration is still underway. There's not a lot left for libvirt anymore.
16:33:04 edmondsw we have a TODO to try to use os-vif. I will expand my thinking to include SEA as well as OVS for that
16:33:09 efried edmondsw: Yeah, it looks like maybe we're supposed to provide an os_vif.objects.vif.VIFSharedEthernetAdapter whose `plugin` field points to... some version of our networking-powervm ml2 thingy??
16:33:16 edmondsw I believe sean-k-mooney had said he might help look at that
16:34:07 efried edmondsw: Okay, if we have a TODO to work on os-vif integration, that's enough for me for now in that direction.
16:34:28 edmondsw yep, it's listed in https://etherpad.openstack.org/p/powervm-in-tree-todos
16:34:41 efried edmondsw: My immediate goal is just to understand the framework so I have context when cyborg says "os-acc is structured like os-vif" and assumes you know what that means.
16:35:03 edmondsw efried add any comments that in that etherpad as appropriate
16:37:06 jangutter edmondsw: efried: nova + external ovs-vif plugin should look and operate exactly like "legacy nova vif handling" (at this stage of os-vif migration)
16:37:55 jangutter edmondsw: efried: the only difference, is that at some point during the plugging process code under your control gets run.
16:38:03 efried jangutter: I haven't looked yet, do folks converting from legacy to os-vif keep their plugin in the same external project or create a new one just for os-vif?
16:38:42 jangutter efried: I think there's only a few in-tree plugins, almost everything is designed to be external or 3rd party.
16:38:57 efried jangutter: That's what I mean - external/3rd-party
16:39:37 jangutter efried: I'm not 100% sure what's the criteria for qualifying to be a 'reference' plugin...
16:39:56 efried jangutter: Just thinking ahead whether code we have in openstack/networking-powervm is gonna stay there, or if we create openstack/os-vif-powervm (or whatever)
16:40:25 jangutter efried: ah, I've seen both. It all depends on the project, I guess.
16:40:46 efried okay
16:41:06 jangutter efried: and the convention seems to be something like vif_plug_powervm (for the os-vif plugin name)
16:41:42 efried jangutter: We're likely to have more than one - vif_plug_sea_powervm, vif_plug_sriov_powervm
16:42:05 efried anyway, I don't want to try to solve that now.
16:43:16 efried can I just say it's confusing that a `plugin` is responsible for providing `plug` and `unplug` actions.
16:44:12 dansmith man, infra is pretty busy
16:44:23 dansmith things have been in there 1.5 hours that still haven't even started a single job
16:47:42 openstackgerrit Eric Berglund proposed openstack/nova master: Powervm configuration cleanup https://review.openstack.org/575171
16:48:41 openstackgerrit Eric Berglund proposed openstack/nova master: Powervm configuration cleanup https://review.openstack.org/575171
16:50:58 simondodsley_ mriedem: can we force a rerun of the final checks for https://review.openstack.org/#/c/558530/
16:53:19 jangutter efried: wait till you try to to say out loud that this plugin is responsible for VIF plugging in Nova.
16:59:33 mriedem simondodsley_: yes, just leave a comment of "recheck" on the change
16:59:46 mriedem simondodsley_: note that because of the depends-on to the cinder docs patch, the nova patch won't merge until the cinder change merges
17:00:59 dansmith I just did
17:01:08 dansmith checked the failure and it seems unrelated
17:07:41 BlackDex Hmm i'm getting an error "DBNonExistentTable: (sqlite3.OperationalError) no such table: services"
17:11:00 openstackgerrit Jan Gutter proposed openstack/nova-specs master: Spec to implement vRouter HW offloads https://review.openstack.org/567148
17:20:53 simondodsley_ mriedem: I did a "recheck" and nothing happened...
17:21:31 mriedem simondodsley_: see dansmith above about busy infra
17:21:36 mriedem simondodsley_: http://zuul.openstack.org/
17:24:19 openstackgerrit Artom Lifshitz proposed openstack/nova master: Add InstanceNUMATopology to LibvirtLiveMigrateData https://review.openstack.org/566398
17:24:20 openstackgerrit Artom Lifshitz proposed openstack/nova master: libvirt live migration: fit NUMA topology on dest https://review.openstack.org/567242
17:24:21 openstackgerrit Artom Lifshitz proposed openstack/nova master: Service version check for NUMA live migration https://review.openstack.org/566723
17:24:22 openstackgerrit Artom Lifshitz proposed openstack/nova master: WIP: Libvirt live migration: update NUMA XML for dest https://review.openstack.org/575179
17:32:53 mriedem alright people https://review.openstack.org/#/c/486204/
17:33:01 mriedem melwitt: if you have the guts ^
17:34:24 jangutter Just out of scary curiosity, what's the highest revision count you've ever seen for a single review?
17:36:27 melwitt mriedem: holy smokes, that's a lot of comments
17:40:35 mgagne mriedem: I tried to run the allocation healer on a cell with libvirt and it crashes with an InstanceNotFound exception. I found that this instance is deleted. So I'm wondering if the code still read deleted instance? And in which database, compute cell?
17:42:00 mgagne the traceback: https://gist.github.com/mgagne/7511aa1e95f624f872d988a34a1a55be
17:45:08 dansmith melwitt: heh, I know, 20+ comments for a +2 is sketchy :)
17:45:17 dansmith melwitt: when you're done, you should totally look at my heartbeating patch
17:45:21 dansmith it'll feel nice and light
17:45:47 melwitt :)
17:49:57 melwitt jangutter: I think that review is the highest I've seen
17:50:44 openstackgerrit Merged openstack/nova master: api-ref: expand on various bdm parameters https://review.openstack.org/574805
17:52:53 dansmith mgagne: that's reading deleted during a lazy load
17:53:16 dansmith mgagne: the healer is actually reading deleted initially
17:54:04 dansmith I guess it might need to read deleted instances to remove stale allocations maybe/
17:54:08 dansmith regardless, that path should be reading deleted during flavor load I would think
17:54:34 dansmith ah, it's not
17:55:23 dansmith and,
17:55:30 dansmith it should be pre-loading flavor it looks like
18:03:04 dansmith mgagne: any chance you have an old nova python module on the system, and are just running nova-manage from newer source?
18:04:22 openstackgerrit Jay Pipes proposed openstack/nova master: placement: Allocation.consumer field https://review.openstack.org/565405
18:04:23 openstackgerrit Jay Pipes proposed openstack/nova master: rework allocation handler _allocations_dict() https://review.openstack.org/565407
18:04:24 openstackgerrit Jay Pipes proposed openstack/nova master: Add a microversion for consumer generation support https://review.openstack.org/565604
18:04:25 openstackgerrit Jay Pipes proposed openstack/nova master: Fix nits from change Id609789ef6b4a4c745550cde80dd49cabe03869a https://review.openstack.org/574324
18:11:14 mriedem jangutter: the multiattach one
18:12:44 mriedem oh maybe not, i guess it was just really old
18:12:46 mriedem https://review.openstack.org/#/c/271047/
18:13:44 mriedem heh would be a tie with https://review.openstack.org/#/c/408964/114
18:14:54 mriedem mgagne: hmm, you're running that against queens?
18:15:39 melwitt bpoulos: quick (hopefully) question for you here https://review.openstack.org/#/c/486204/114/nova/compute/api.py@3137
18:16:10 dansmith mriedem: so on mgagne's issue, I don't know why we're not preloading flavor, but I also think it's wrong to fail lazy-loading it, so:
18:16:12 openstackgerrit Dan Smith proposed openstack/nova master: Always read-deleted=yes on lazy-load https://review.openstack.org/575190
18:16:26 dansmith biab

Earlier   Later