Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-10
15:13:04 cdent was generalizing that that's how it _should_ work
15:13:16 mriedem alex_xu: if you're really concerned about it, i can make the quick change to check for it if version<2.59 and just pop it off the req.GET
15:13:22 cdent and it should work for both /rp and /ac
15:13:26 kashyap mriedem: Yep, we won't see, because Nova already baked in (correctly so) the '--force-share' with your commit
15:13:36 mriedem alex_xu: i'm just trying to get done as much as i can before i'm out next week
15:13:54 mriedem kashyap: i meant nova won't see b/c it would be in the qemu/libvirtd logs,
15:13:58 mriedem and we don't look there unless it's an error
15:14:00 efried cdent Ah, that's it, actually the code I have up is only applying it to /ac. https://review.openstack.org/#/c/517757/1
15:14:06 kashyap Ah, like that.
15:14:32 cdent efried: thus my comment on line 23 on https://etherpad.openstack.org/p/nova-ptg-rocky
15:14:52 alex_xu mriedem: got it, you can have my promise to review that patch again tomorrow
15:15:02 mriedem alex_xu: ok i'll update it today then
15:15:06 alex_xu mriedem: thanks
15:15:06 mriedem thanks for the solid review as always
15:15:56 simondodsley Any idea when it became a valid option to add to the ```live_migration_flags``` parameter in ```nova.conf``` and since this parameter was deprecated in Mitaka does Nova now automatically use ‘unsafe’ or is there something else that needs to be set to force the ‘unsafe’ switch?
15:15:56 simondodsley I can see that this switch was added in libvirt 0.9.11 back in 2012, but I’m struggling in finding references to it or VIR_MIGRATE_UNSAFE as valid options in Kilo or later releases of OpenStack (other than just comments)
15:15:56 simondodsley What I’m trying to find out is when and if Nova supported/supports the use of the ```virsh –-unsafe``` switch when ```cachemode != none```?
15:15:56 simondodsley Hi - hope I'm on the correct channel to ask these questions...
15:16:15 mriedem cdent: efried: dansmith: klindgren_ pinged me last night about the number of REST calls from the compute to placement during the update_available_resource periodic task which runs by default every minute,
15:16:25 simondodsley sorry about the format there :)
15:16:25 alex_xu cdent: efried, for the trait, the only left thing is expose 'required' parameter intthe 'GET /allocation_candidates' API
15:16:28 mriedem from his pike deployment it's 5 calls https://paste.ubuntu.com/26356656/
15:16:32 mriedem at least
15:16:33 mriedem per compute
15:16:43 mriedem cdent: efried: dansmith: the thing i noted was the 2 calls for aggregates,
15:16:59 mriedem which if you look at the code, the provider aggregate map is there in the report client but not used,
15:16:59 cdent mriedem: yes, you remember that post i made mid year about such things ?
15:17:04 mriedem b/c we don't support shared providers yet
15:17:11 mriedem cdent: not the detalis no
15:17:24 mriedem cdent: can you summarize?
15:17:27 mriedem we might be on the same page
15:17:37 dansmith two hits to inventories?
15:17:51 mriedem dansmith: i wondered about that too
15:18:05 mriedem for the aggregates ones, i told him the obvious thing to do is just comment out that code as it's totally unused
15:18:16 cdent it was also five, iirc, and I was able to do some tricks to trim it but they were deemed risky. agree that one way to cut is to reduce is not make the agg map
15:18:34 cdent let me find the message, because I think it had something to say about the double inventory
15:19:57 mriedem _get_inventory is only called by _get_inventory_and_update_provider_generation which is only called to check if we need to update inventory (if things changed), or delete inventory
15:21:12 mriedem i wonder if he's on baremetal
15:21:28 mriedem because there are cases where the driver.get_inventory call for ironic will return an empty dict which is an indication to delete the inventory for the provider
15:21:38 mriedem klindgren_: ^
15:21:51 mriedem were you seeing those inventory calls to placement on libvirt or ironic computes?
15:27:28 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] Fix resource provider delete https://review.openstack.org/529519
15:27:34 cdent sigh, took me forever to find http://lists.openstack.org/pipermail/openstack-dev/2017-January/110953.html
15:27:35 mriedem oh i see,
15:27:38 mriedem _update_inventory_attempt is called in a loop
15:27:42 cdent not yet clear if it will be any use
15:28:06 mriedem so if we get a 409 trying to update inventory we try again
15:28:12 mriedem that's why there are multiple GETs for inventory
15:28:30 sean-k-mooney efried: syntaks for traits to resouces. there was discusstion of a resouce_1=<class x>,required1=<trait y>,<trait z> query arg syntaks for get allocation candiates
15:28:40 cdent mriedem: that may not be right, have a look at point B1 in the list posting above
15:29:29 openstackgerrit Balazs Gibizer proposed openstack/nova master: Deduplicate service status notification samples https://review.openstack.org/531381
15:29:39 cdent (it maybe also be right, though, but without logs, hard to say)
15:29:53 sean-k-mooney efried: i dont think we have a similar fuctionality for the resouce providres api however.
15:31:17 mriedem cdent: yeah, you might be right, because if we hit an inventory conflict, we delete the rp_uuid from the cache and then get the resource provider again to update the generation, but i don't see a GET to just /resource_providers in klindgren_'s output
15:31:51 mriedem so likely hitting something that's not a 409, but would need logs
15:33:59 efried sean-k-mooney Correct.
15:34:19 efried mriedem FYI, I'm trying to rework all of this atm
15:34:43 efried mriedem But are you looking for a way to get this "fixed" in pike?
15:38:25 mriedem efried: well, kind of depends on how much operators that are rolling up to ocata and pike are going to be complaining about the new load their computes are making becaues of a lot of http traffic to placement every minute
15:38:43 mriedem i think klindgren_ is working around it by turning down the update_available_resource report interval so it doesn't run every minute
15:39:42 efried Okay, well, keep me posted. I'll be interested in contributing to (or at least reviewing) the code if we go there.
15:41:13 mriedem cdent: ha "After that every 60s or so, five requests are made:"
15:41:14 mriedem right on
15:41:39 mriedem tracking here btw https://bugs.launchpad.net/nova/+bug/1742467
15:41:41 openstack Launchpad bug 1742467 in OpenStack Compute (nova) "Compute unnecessarily gets resource provider aggregates during every update_available_resource run" [Undecided,New]
15:43:06 cdent mriedem: in your thinking just now did you get any clearer picture on the why of double inventory GET?
15:43:11 openstackgerrit Mark Goddard proposed openstack/nova master: Add get_traits() method to ComputeDriver https://review.openstack.org/532287
15:43:11 openstackgerrit Mark Goddard proposed openstack/nova master: WIP: Send traits to ironic on server boot https://review.openstack.org/508116
15:43:12 openstackgerrit Mark Goddard proposed openstack/nova master: Implement get_traits() for the ironic virt driver https://review.openstack.org/532288
15:43:12 openstackgerrit Mark Goddard proposed openstack/nova master: Add has_any_traits() to provider tree https://review.openstack.org/532289
15:43:13 openstackgerrit Mark Goddard proposed openstack/nova master: Call get_traits() in the resource tracker https://review.openstack.org/532290
15:43:13 openstackgerrit Mark Goddard proposed openstack/nova master: Add support to scheduler client for setting traits https://review.openstack.org/532539
15:43:59 mriedem cdent: yes it's the RT
15:44:09 mriedem _update_available_resource is the call from the compute periodic task,
15:44:13 mriedem which calls _init_compute_node
15:44:23 mriedem when we already have the compute node, it calls _update
15:44:32 mriedem which eventually does the update_inventory_attempt stuff in the report client
15:44:42 mriedem then at the end of _update_available_resource,
15:44:44 mriedem we call _update again
15:44:53 mriedem so that's your 2 inventory updates
15:45:06 mriedem which, johnthetubaguy changed in queens
15:45:16 mriedem or wait,no
15:45:37 mriedem https://review.openstack.org/#/c/520024/
15:45:44 mriedem that would fix the double GET inventories
15:48:00 mriedem maciejjozefczyk: have you figured out anything more about https://review.openstack.org/#/c/520024/ ?
15:49:25 maciejjozefczyk mriedem: hah!
15:49:32 maciejjozefczyk mriedem: aready working on this
15:49:51 maciejjozefczyk and yes, I found something strange, but I need big prove about it
15:49:57 maciejjozefczyk I'll post it today in review
15:52:01 maciejjozefczyk mriedem: basically: each time self._provider_tree.has_inventory_changed() returns False here:
15:52:02 maciejjozefczyk https://github.com/openstack/nova/blob/cf33de28b15bb445d34bbdda1897130812e3b5c5/nova/scheduler/client/report.py#L696
15:52:10 maciejjozefczyk without my change
15:53:00 maciejjozefczyk with my change: It tries to update inventory_data to placement and then placement raises this strange Exception
15:54:09 maciejjozefczyk so for now in upstream we update only DB (once with faulty values, second time with proper ones)
15:54:53 mriedem so it's failing this check? https://github.com/openstack/nova/blob/master/nova/objects/resource_provider.py#L231
15:55:22 maciejjozefczyk mriedem: exactly
15:56:48 mriedem do you see this debug message with the PUT inventory request body in it when this fails? https://github.com/openstack/nova/blob/cf33de28b15bb445d34bbdda1897130812e3b5c5/nova/scheduler/client/report.py#L765
15:57:43 maciejjozefczyk mriedem: yes
15:57:49 maciejjozefczyk WARNING nova.scheduler.client.report [None req-89e951da-7283-473f-9de0-53854741839a None None] [req-b6f884cd-883a-4964-8e99-a8f0 f754c0df] Failed to update inventory for resource provider 52559824-5fb1-424b-a4cf-79da9199447d: 400 {"errors": [{"status": 400, "request_id": "req-b6f884cd-883a-4964-8e99-a8f0f754c0df", "detail": "The server could not comply with the request since it is e ither
15:57:51 maciejjozefczyk malformed or otherwise incorrect.\n\n Unable to update inventory for resource provider 52559824-5fb1-424b-a4cf-79da9199447 d: Invalid inventory for 'VCPU' on resource provider '52559824-5fb1-424b-a4cf-79da9199447d'. The reserved value is greater than or equal to total. ", "title": "Bad Request"}]}

Earlier   Later