Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-14
09:39:46 mdbooth gryf: I mean current, allocated disk.
09:39:50 gryf ack
09:39:57 sean-k-mooney mdbooth: gryf cool im much happier this this change then. its sutle but makes sense in context
09:44:49 openstackgerrit Surya Seetharaman proposed openstack/python-novaclient master: [WIP/POC] Client changes for down cell https://review.openstack.org/579563
09:54:43 gryf sean-k-mooney, do you want me to rebase and correct typo on commit message?
09:54:49 gryf typos*
09:54:59 sean-k-mooney gryf: they are just nits so no its fine
09:55:12 gryf cool. thanks
09:55:46 sean-k-mooney gryf: if you have to respin the patch for some other reason then sure but no need to respin just for that. that said my spelling is terrible so other may have a different view
09:56:52 gryf sean-k-mooney, I'd just like to have it merged :)
09:57:15 sean-k-mooney gryf: by the way im not sure if johnthetubaguy is around at the moment to review this or not
09:57:53 gryf I guess he is not
09:58:00 sean-k-mooney gryf: his time upstream has been limited this cycle i belive given his current positon
09:59:09 gryf Right.
10:02:18 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Force refresh instance info_cache during heal https://review.openstack.org/591607
10:02:53 sean-k-mooney mriedem: i dont know if your still about but your pretty familar with the livemigration code perhaps you could take a look at https://review.openstack.org/#/c/536351/3 in johnthetubaguy absence. that said not sure this is high enough prority to make it into RC2 so maybe it will have to wait till stein in anycase
10:03:19 mriedem Kevin_Zheng: see https://review.openstack.org/591607
10:03:25 mriedem sean-k-mooney: just going to dinner
10:03:37 mriedem sean-k-mooney: oh that one, idk
10:04:23 sean-k-mooney mriedem: no worries i was just trying to think who was about to take a look at it.
10:05:55 openstackgerrit Jay Pipes proposed openstack/nova master: placement: order multi-row INSERT by PK https://review.openstack.org/591609
10:15:24 openstackgerrit Jay Pipes proposed openstack/nova master: placement: order multi-row INSERT by PK https://review.openstack.org/591609
10:58:56 openstackgerrit Chen proposed openstack/nova master: Typo fixes on notifications doc https://review.openstack.org/591621
12:14:33 sean-k-mooney mriedem: so far i have found 3 neutron bugs and 1 nova bug in my livemigration testing :( im taking notes and will open them later. ovs-ovs and lb-lb migration seam to be fine however
12:15:00 tssurya gmann: around ?
12:16:24 kosamara efried: Hi! You say that pci subsys_vendor_id etc should appear in libvirt. I checked what libvirt.Host.device_lookup_by_name returns (calls libvirt) and it doesn't report those properties.
12:19:29 sean-k-mooney kosamara: if you do virsh nodedev-list and then virsh nodedev-dumpxml pci_0000_00_00_0 you will see the xml fragment that nova parses form libvirt
12:21:10 sean-k-mooney kosamara: if you do a nodedev-dumpxml on a network device it will also return the feature supported by that nic http://paste.openstack.org/show/728005/
12:21:51 sean-k-mooney kosamara: we currently store does as netwrok_capablites in the pci_devcice table and they will need to be translated to traits in the future
12:28:11 sean-k-mooney kosamara: this is where we currently parse all the pcidevice info in the libvirt driver https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5855-L5935
12:29:09 sean-k-mooney kosamara: we invoke that in _get_pcidev_info which is called in get_available_resource
12:33:35 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consumer gen support for put allocations https://review.openstack.org/591647
12:35:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consumer gen support for put allocations https://review.openstack.org/591647
12:49:55 kosamara sean-k-mooney: Still, it doesn't show the subsystem vendor/prod, rev id or class.
12:50:42 kosamara sean-k-mooney but maybe this is just missing from libvirt and should be there, because it makes sense.
12:52:50 sean-k-mooney kosamara: the vendor id is in the parent pci device
12:53:43 sean-k-mooney kosamara: http://paste.openstack.org/show/728011/
12:55:48 kosamara sean-k-mooney: subsystem vendor (SVendor in lspci) is a separate property. Eg an Evga-made GPU might have a different SVendor than a Gigabyte one.
12:56:20 kosamara but the same "vendor_id" (nvidia)
12:56:50 sean-k-mooney hum perhaps. we dont track that difference in nova
12:57:35 sean-k-mooney from a driver/guest perspective we would not be able to tell the differecne really provided its the same model number.
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: Return a minimal construct for nova service-list when a cell is down https://review.openstack.org/584829
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: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 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:02 openstack Launchpad bug 1786346 in OpenStack Compute (nova) rocky "live migrations slow" [High,In progress] - Assigned to Matt Riedemann (mriedem)
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 openstackgerrit Matthew Booth proposed openstack/nova master: Add regression test for bug 1550919 https://review.openstack.org/591733
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:13:18 mdbooth lyarwood mriedem: https://review.openstack.org/#/c/591733/ Regression test for evacuate on shared storage deleting data

Earlier   Later