Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-14
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
16:11:15 melwitt .
16:14:59 Sundar_ Thanks, efried! I explained the problem in the email.

Earlier   Later