Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-14
09:29:07 mdbooth I think live migration should fail only if there aren't physically enough bits on the destination to hold the source bits.
09:29:08 gryf we don;t want to change that by allocation ratio if it's something else from 1
09:29:40 sean-k-mooney gryf: why not
09:30:07 sean-k-mooney the allocation ratio should only be applied to the portion of the disk that is not reserved
09:32:15 gryf so, isn't it be (total disk space - used disk space - reserved disk space) * allocation ratio?
09:33:09 cdent "If we need to take disk allocation ratio into account, we should do that at the point of use." yes
09:33:09 gryf or even (total disk space - used disk space) * allocation ratio - reserved disk space
09:33:58 sean-k-mooney actully gryf no we dont want to multiple the used disk space by the allocation ratio
09:34:04 sean-k-mooney but its not needed in either case
09:34:08 sean-k-mooney i just realised https://github.com/openstack/nova/blob/0502b0ffaf20ef3735e633715ba0f9dda976cb7a/nova/virt/libvirt/driver.py#L6768
09:34:11 mdbooth There are 2 ways to get a live migration destination:
09:34:22 mdbooth 1. From the scheduler, which will take this stuff into account
09:34:27 sean-k-mooney is using the actul size of the disk not the virtual size
09:34:54 mdbooth 2. From the admin, who doesn't care about your pesky artificial resource constraints.
09:35:26 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consumer gen support for delete instance allocations https://review.openstack.org/591597
09:35:53 sean-k-mooney in the overcomit case that is so the driver only compares bytes need to copy the disk to actul bytes free on the dest and the schduler/placement operates on teh virtual disk size with allocation ratios taken into account
09:36:24 mdbooth sean-k-mooney: That's the only thing it should ever compare. Anything else is legacy.
09:37:01 sean-k-mooney mdbooth: yes just trying to get the full end to end effect of this change right in my head to make sure there was no edge case missed
09:37:45 mdbooth Right. If an admin wants to move a workload to compute X, the only reason we should say no is if it physically won't fit. Any future problems caused by that are the admin's to deal with.
09:39:33 gryf mdbooth, by "phisically fit" do you mean current src image size, or the maximum one?
09:39:33 mdbooth But hopefully the admin only does that if they really, really need to, and usually they ask the scheduler.
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.

Earlier   Later