| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-14 | |||
| 12:58:13 | sean-k-mooney | yes i know evga may have the same part running at a different clockrate then gagabyte or asusu but we are not that detailed in our tracking | |
| 13:00:15 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova list when a cell is down https://review.openstack.org/567785 | |
| 13:00:17 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add get_by_cell_and_project() method to InstanceMappingList https://review.openstack.org/591656 | |
| 13:00:17 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova service-list when a cell is down https://review.openstack.org/584829 | |
| 13:00:18 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: API microversion bump for handling-down-cell https://review.openstack.org/591657 | |
| 13:00:20 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova show when a cell is down https://review.openstack.org/591658 | |
| 13:02:43 | kosamara | sean-k-mooney efried: so in the end, does it make sense to leave that open in the inventory yaml spec? maybe for a future use? | |
| 13:08:02 | sean-k-mooney | kosamara: i dont think so. i think that might be leaking too much host specific info to the enduser. we could leave a comment but i dont think we should whoudl consider 2 GTX1080s form differend ODMs to be different | |
| 13:11:10 | sean-k-mooney | kosamara: your other option is to modify libvirt. the reaosn we get the nic feature flags from libvirt instead of ethtool is because we were not allow to bypass libvirt to look this up form ethool or sysfs in the past so going to sysfs to get the subvendor will likely not be allow nor is lspci likely to be accepted but you could document those approches. | |
| 13:12:08 | gmann | tssurya: hi | |
| 13:12:26 | sean-k-mooney | anyway im really goint to lunch now. | |
| 13:14:10 | kosamara | sean-k-mooney: I agree, just mentioning the possibilities | |
| 13:29:13 | tssurya | gmann: nothing urgent, was just wondering if https://review.openstack.org/#/c/502859/ - this series could be rebased | |
| 13:30:25 | tssurya | also thanks for https://review.openstack.org/#/q/topic:bp/api-extensions-merge-rocky+(status:open) in general, for the handling-down-cell, I guess the two more dependencies are that of extended status and extended volumes part | |
| 13:30:41 | gmann | tssurya: ack, ll do. i am waiting to do policy removal first. anyways will check it tomorrow. | |
| 13:30:55 | tssurya | gmann: np, thanks! | |
| 13:51:34 | openstackgerrit | Surya Seetharaman proposed openstack/python-novaclient master: Client changes for handling-down-cell with microversion bump https://review.openstack.org/579563 | |
| 13:58:12 | efried | kosamara: I think I would like to converge on an approach where the schema allows the union of what's recognized by all the drivers, for identification. And then each driver documents which fields it pays attention to. | |
| 13:58:46 | efried | kosamara: I haven't caught up yet, in case you've responded to the comments I left last night, but how do you feel about making the spec address both libvirt and powervm? | |
| 13:59:57 | sean-k-mooney | still eating lunch but +1 on a single schema that could be used for any virt dirver | |
| 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 | |