Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-14
14:01:48 sean-k-mooney it would also be nice the schema wa genreic ennough to support device beyond pci also but that is a streach
14:05:18 efried sean-k-mooney: That's the point. The schema is restrictive to whatever we support right now, but extensible to incorporate other things in the future. And the design statement is explicitly that drivers pay attention to whichever fields they support, and ignore the rest.
14:05:35 efried It's less about the schema being generic and more about it being inclusive.
14:07:17 sean-k-mooney well when i said generic i kind of was infering that we can assume what type of device it is and what bus it is attached to.
14:07:27 sean-k-mooney we have to declar that in the file
14:08:11 efried You would determine the "bus" by parsing the PCI address, right?
14:08:23 sean-k-mooney no
14:08:38 sean-k-mooney that wont work for power where we dont have an adress correct
14:08:54 sean-k-mooney we would know the bus by saying bus: pcie
14:08:55 efried We have an address. It just doesn't look like domain:bus:device.function
14:10:08 efried anyway, determining "device type" (whatever that means) and "bus" (whatever that is) would be the purview of the specific driver.
14:10:22 efried If we can identify common fields, like prod and vendor IDs, great.
14:10:23 cdent (specific driver)++
14:10:50 efried But something like PCI address is going to be ignored by PowerVM; and something like DRC name is going to be ignored by libvirt.
14:11:20 sean-k-mooney efried: im mocking somthin up one sec
14:15:48 sean-k-mooney you know what i might as well jsut use etherpad for this
14:16:08 sean-k-mooney https://etherpad.openstack.org/p/generic-device-schema
14:27:00 kosamara efried: I haven't replied yet, I'm halfway through them :) I do think it's best to have a general YAML spec that caters to the union of the drivers' needs as you say.
14:28:00 kosamara This is the first part, then implementing the "update_provider_tree" algo including understanding the YAML should be driver-specific.
14:28:45 sean-k-mooney kosamara: efried cdent what to you think of somthing like this https://etherpad.openstack.org/p/generic-device-schema
14:30:27 kosamara For the implementation, I don't have any experience on powervm, but I see your reasoning and it makes sense to address both, since it would basically copy over your work on powervm. What I don't know is how much extra attention will have to be paid to the powervm-specific parts, and if this would hold back the rest
14:32:51 efried kosamara: I am developing the powervm bits anyway, so would be delighted to propose them in tree as well as in nova-powervm.
14:32:53 kosamara Sorry, I'll be back in 1h and check it out
14:33:12 efried kosamara: If you're talking about holding up the spec, I think we absolutely need to hold up the spec if we can't agree on an approach that's going to work for powervm as well as libvirt.
14:34:39 kosamara efried: of course, it should pave the way for both, I'm only considering the part of the powervm implementation. Let me fix the YAML part first with your comments and we'll have a clearer picture.
14:43:07 openstackgerrit Chris Dent proposed openstack/nova master: Add placement perf info gathering hook to end of nova-next https://review.openstack.org/591367
14:46:25 openstackgerrit Chris Dent proposed openstack/nova master: placement: order multi-row INSERT by PK https://review.openstack.org/591609
15:08:02 openstack Launchpad bug 1786346 in OpenStack Compute (nova) rocky "live migrations slow" [High,In progress] - Assigned to Matt Riedemann (mriedem)
15:08:02 prometheanfire dansmith: mriedem: not that I'm rushing or anything, but is there an ETA for backports to pike/queens for https://bugs.launchpad.net/nova/+bug/1786346
15:08:43 dansmith prometheanfire: I think we should be good to go on backporting that now
15:08:50 dansmith we need to commit the one to rocky too for rc2
15:09:06 prometheanfire yarp
15:09:14 prometheanfire iirc the backport isn't going to be clean
15:09:18 dansmith melwitt: I assume we just need another stabler to hit it
15:09:29 dansmith prometheanfire: likely not, the revert was messy :/
15:09:47 dansmith lyarwood: can you hit this patch we need for rc2? https://review.openstack.org/#/c/591275/
15:10:56 openstack bug 1550919 in OpenStack Compute (nova) "[Libvirt]Evacuate fail may cause disk image be deleted" [Medium,In progress] https://launchpad.net/bugs/1550919 - Assigned to Matthew Booth (mbooth-9)
15:10:56 openstackgerrit Matthew Booth proposed openstack/nova master: Add regression test for bug 1550919 https://review.openstack.org/591733
15:13:18 mdbooth lyarwood mriedem: https://review.openstack.org/#/c/591733/ Regression test for evacuate on shared storage deleting data
15:13:33 mdbooth It's funky because it actually runs the libvirt driver
15:13:50 mdbooth (but not libvirt)
15:14:19 dansmith mdbooth: just fyi, mriedem is in china this week
15:14:36 mdbooth dansmith: Yeah, I noticed he's been around disturbingly early.
15:14:51 mdbooth Need to be careful what I say about him in the morning ;)
15:15:34 mdbooth dansmith: You may also be interested in ^^^ btw
15:15:42 dansmith you may be surprised
15:15:52 mdbooth Hehe
15:17:26 openstackgerrit Dan Smith proposed openstack/nova stable/queens: WIP: Wait for network-vif-plugged before starting live migration https://review.openstack.org/591735
15:18:07 mdbooth dansmith: Is ^^^ a continuation of the problem originally addressed by sahid's patch?
15:19:23 dansmith mdbooth: it's a test backport of a more generic solution that already landed in master, but with a non-backportable rpc change that I don't think we actually needed to make it work
15:19:25 dansmith so I'm floating that to see if it's possible
15:19:42 dansmith since we have to revert his, I'm hoping we can replace it with that
15:19:47 mdbooth Ah, ok.
15:20:18 mdbooth I didn't follow the whole discussion, but I was under the impression that perhaps linux bridge remained a problem?
15:20:39 mdbooth Or are we good there, too?
15:20:52 dansmith we should be good there to as far as all the evidence we've collected shows
15:20:58 mdbooth Cool
15:21:10 openstackgerrit Matthew Booth proposed openstack/nova master: Move static _get_power_off_values to compute_utils https://review.openstack.org/578822
15:21:11 openstackgerrit Matthew Booth proposed openstack/nova master: Don't delete disks on shared storage during evacuate https://review.openstack.org/578846
15:22:42 dansmith prometheanfire: yeah the backport of the revert to queens is even worse than the original revert
15:23:05 dansmith to the point that I wonder if it's even worth trying to do a normal backport
15:24:31 lyarwood a normal revert you mean, of the stable/queens patch
15:25:00 dansmith what I mean is, a backport of the revert patch from master and rocky might not be worth it,
15:25:23 dansmith but we could do a straight revert of the queens patch on queens yeah
15:25:24 dansmith lyarwood: do you know of any precedent for that?
15:25:32 lyarwood kk, in the past we've just done a straight revert of the stable changes, not backporting anything from branch to branch
15:25:46 dansmith really?
15:25:53 prometheanfire ya, that's kinda what I was thinking
15:26:03 dansmith I'm confident that we've backported reverts, and that's what mriedem did for stable/rocky
15:26:07 prometheanfire iirc, a clean revert isn't possible either for pike at least
15:26:14 dansmith but if that's kosher, that's likely way easier
15:26:27 lyarwood dansmith: I assume it was clean?
15:26:41 dansmith which? I haven't tried the direct revert yet
15:26:43 lyarwood dansmith: once things start to conflict the revert backports get awkward
15:26:51 dansmith yup
15:27:18 lyarwood dansmith: the master to rocky revert sorry, and I assume it was as rocky was only just cut
15:27:31 dansmith yeah, I assume it was, matt did it
15:28:10 dansmith lyarwood: so, different change-id for the revert on queens? or force it to be the same so gerrit shows it properly?
15:29:06 lyarwood dansmith: it has to be different doesn't it?
15:29:26 dansmith no, I can force it to be the same
15:29:35 lyarwood dansmith: I didn't think gerrit allowed the same change-id twice on the same branch
15:29:53 dansmith I mean the same change-id as the reverts on master and rocky
15:30:17 dansmith meaning, use that change id on queens too, even though it's not a direct cherry-pick
15:30:22 lyarwood dansmith: ah right, yeah the same change id for the reverts
15:30:33 openstackgerrit Dan Smith proposed openstack/nova stable/queens: Revert "libvirt: slow live-migration to ensure network is ready" https://review.openstack.org/591761
15:30:37 dansmith okay, queens was clean ^
15:31:58 dansmith as was pike
15:32:00 openstackgerrit Dan Smith proposed openstack/nova stable/pike: Revert "libvirt: slow live-migration to ensure network is ready" https://review.openstack.org/591762
15:33:01 prometheanfire nice
15:35:46 openstackgerrit Eric Fried proposed openstack/nova master: [placement] split gigantor SQL query, add logging https://review.openstack.org/591510
15:37:47 openstackgerrit Eric Fried proposed openstack/nova master: [placement] split gigantor SQL query, add logging https://review.openstack.org/590041
15:45:11 Sundar_ efried: Please ping me when you have the time. Thanks.
15:51:52 openstackgerrit xhzhf proposed openstack/nova master: [vmware] add missing os types in vSphere sdk 6.5 https://review.openstack.org/591771
15:54:17 efried Sundar_: Yo, what's up?
15:57:17 Sundar_ Hi efried, please look at my email to you on merge conflict.
15:57:43 efried Sundar_: Roger that, looking.
15:57:50 efried Sundar_: You probably just need to rebase to master.
15:58:22 efried Sundar_: Right, so I see you tried that, let me see what I can do.
16:02:49 efried Sundar_: What problem did you have rebasing this? It's working out okay for me.
16:05:10 efried Sundar_: Fixed, uploaded PS8

Earlier   Later