Posted	Nick	Remark
#openstack-nova - 2018-01-02
18:14:00	mdbooth	Well, that's been stalled for so long I'm almost entirely certain it's going to fail, and when it fails the 2 behind it will also fail.
18:14:23	mdbooth	So I'm just gonna do my rebase anyway.
18:14:55	openstackgerrit	Matthew Booth proposed openstack/nova master: Add an online migration for BDM.uuid https://review.openstack.org/525599
18:14:55	openstackgerrit	Matthew Booth proposed openstack/nova master: DriverBlockDevice: make subclasses inherit _proxy_as_attr https://review.openstack.org/524167
18:14:56	openstackgerrit	Matthew Booth proposed openstack/nova master: Expose BDM uuid to drivers https://review.openstack.org/529037
18:14:56	openstackgerrit	Matthew Booth proposed openstack/nova master: Give volume DriverBlockDevice classes a common prefix https://review.openstack.org/526346
18:14:57	openstackgerrit	Matthew Booth proposed openstack/nova master: Add DriverLocalImageBlockDevice https://review.openstack.org/526347
18:14:57	openstackgerrit	Matthew Booth proposed openstack/nova master: Rename block_device_info_get_root https://review.openstack.org/529028
18:14:58	openstackgerrit	Matthew Booth proposed openstack/nova master: Add local_root to block_device_info https://review.openstack.org/529029
18:14:58	openstackgerrit	Matthew Booth proposed openstack/nova master: Expose driver_block_device fields as attributes https://review.openstack.org/528362
18:14:59	openstackgerrit	Matthew Booth proposed openstack/nova master: Pass DriverBlockDevice to driver.attach_volume https://review.openstack.org/528363
18:14:59	openstackgerrit	Matthew Booth proposed openstack/nova master: Use real block_device_info data in libvirt tests https://review.openstack.org/527916
18:15:00	openstackgerrit	Matthew Booth proposed openstack/nova master: Fix libvirt volume tests passing invalid disk_info https://review.openstack.org/529328
18:15:00	openstackgerrit	Matthew Booth proposed openstack/nova master: Pass disk_info dict to libvirt_info https://review.openstack.org/529329
18:15:01	openstackgerrit	Matthew Booth proposed openstack/nova master: Local disk serial numbers for the libvirt driver https://review.openstack.org/529380
18:15:01	openstackgerrit	Matthew Booth proposed openstack/nova master: Expose volume host type and path independent of libvirt config https://review.openstack.org/530786
18:15:02	openstackgerrit	Matthew Booth proposed openstack/nova master: Don't generate fake disk_info in swap_volume https://review.openstack.org/530787
18:19:12	mdbooth	stephenfin: Any chance you could stick the +A back on https://review.openstack.org/#/c/525599/ https://review.openstack.org/#/c/524167/ and https://review.openstack.org/#/c/529037/ ?
18:19:15	mdbooth	stephenfin: Rebase
18:20:02	mdbooth	They just failed in the gate, and I needed to rebase the series anyway to pull in some other recently landed patches.
18:20:31	mdbooth	I think I fixed the problem with swap_volume.
18:54:41	openstackgerrit	Matt Riedemann proposed openstack/nova master: Only call numa_fit_instance_to_host if necessary https://review.openstack.org/530792
19:59:15	efried	mikal Does/will the privsep work make the use_rootwrap_daemon conf option obsolete?
20:00:03	openstackgerrit	Jay Pipes proposed openstack/nova-specs master: Support aggregate affinity filters/weighers https://review.openstack.org/529135
20:01:15	efried	mriedem Do you know that answer?
20:01:57	mriedem	efried: yes i think it will
20:02:05	efried	k, thx
20:02:06	mriedem	since there would be no need for rootwrap
20:02:12	efried	right
20:02:15	efried	esberglu ^
20:02:20	dansmith	except for starting privsep
20:02:35	efried	oh
20:02:44	dansmith	I can't remember how we settled on that.. it might be hard-coded in privsep stuff now or something
20:03:27	mriedem	i thought we did a hard-coded thing to get around grenade
20:03:32	efried	Basically, trying to figure out if my driver needs that opt set to True if the only root-y stuff it does is via privsep now.
20:03:36	mriedem	which was the great schizm of 2015
20:04:49	mriedem	https://github.com/openstack/oslo.rootwrap/commit/37c2a041d33f0fdce7ce2832398c1f60f3ee8703
20:04:51	mriedem	is what i'm thinking of
20:05:09	mriedem	which is different from what dansmith is talking about, i think
20:09:05	esberglu	efried: I will push a run through without use_rootwrap_daemon and confirm
20:09:44	efried	esberglu Sounds like a plan. Could consider splitting that bit out of the change; I'd be +2 on the other parts.
20:20:34	openstackgerrit	Matt Riedemann proposed openstack/nova stable/pike: Do not set allocation.id in AllocationList.create_all() https://review.openstack.org/530794
20:49:23	openstackgerrit	Eric Fried proposed openstack/nova master: Move aggregates from report client to ProviderTree https://review.openstack.org/521685
20:49:24	openstackgerrit	Eric Fried proposed openstack/nova master: Track provider traits in report client https://review.openstack.org/521686
20:49:24	openstackgerrit	Eric Fried proposed openstack/nova master: Track associated sharing RPs in report client https://review.openstack.org/526539
20:49:25	openstackgerrit	Eric Fried proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540
20:49:25	openstackgerrit	Eric Fried proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756
20:49:26	openstackgerrit	Eric Fried proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541
20:49:26	openstackgerrit	Eric Fried proposed openstack/nova master: WIP: Scheduler[Report]Client.get_provider_tree https://review.openstack.org/521098
20:49:27	openstackgerrit	Eric Fried proposed openstack/nova master: WIP: ComputeDriver.update_provider_tree() https://review.openstack.org/521187
20:49:27	openstackgerrit	Eric Fried proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246
20:49:36	efried	Rebase only (some manual) ^^
20:59:58	openstackgerrit	Jackie Truong proposed openstack/python-novaclient master: Microversion 2.59 - Add trusted_image_certificates https://review.openstack.org/500396
21:10:13	openstackgerrit	Jay Pipes proposed openstack/nova-specs master: Support aggregate affinity filters/weighers https://review.openstack.org/529135
21:26:32	mnaser	what are the implications of using cpu_allocation_ratio on compute with the placement api?
21:27:23	mnaser	i'm testing around cpu_allocation_ratio=2.0 on a compute node but i'm not sure if its properly reporting that number to the placement as im getting no valid host
21:28:51	jaypipes	mnaser: easy enough to check... in the API database (the one placement uses, do this: SELECT * FROM inventories WHERE allocation_ratio > 1.0 AND resource_class = 0;
21:29:01	mnaser	jaypipes: gah thah was an obvious one
21:29:07	jaypipes	mnaser: :)
21:29:09	mnaser	and i was trying to think how i was going to query the placement api
21:29:15	mnaser	and making curl calls
21:29:16	mnaser	:p
21:29:29	jaypipes	mnaser: you could do that, too, but wouldn't be as fun ;)
21:29:44	jaypipes	mnaser: FYI, VCPU == resource_class "0"
21:29:47	mnaser	jaypipes: true
21:29:57	jaypipes	MEMORY_MB == 1
21:29:59	jaypipes	DISK_GB == 2
21:30:36	mnaser	ok the allocation ratio is indeed there
21:30:45	mnaser	i guess ill have to run the scheduler in verbose
21:31:32	mnaser	i could swear scheduling failures were reported as warnings in the scheduler
21:31:50	mriedem	"and i was trying to think how i was going to query the placement api" - osc-placement plugin has some placement CLI now
21:31:58	mnaser	oh really
21:32:06	mriedem	pretty minimal at this point
21:32:22	mriedem	supports working on resource providers and inventories records
21:32:24	jaypipes	mnaser: no, but in debug/verbose mode, you will see some log messages like "Filter XXX: Started with 10 hosts, finished with 6 hosts" or something like that.
21:33:10	dansmith	mnaser: like a (statistically-consistent) boss
21:33:29	jaypipes	mnaser: however it's just as good to look in the placement-api logs for the requests to GET /allocation_candidates and then I can give you the SQL to run that represents that particular request.
21:33:50	mnaser	3 schedulers, 1 running verbose, 3 build attempts and i am 0-3
21:34:15	mnaser	oh duh because verbose=True is a default now and I should be debug=True
21:34:24	jaypipes	heh
21:34:59	mnaser	um
21:35:09	mnaser	"Got no allocation candidates from the Placement API. This may be a temporary occurrence as compute nodes start up and begin reporting inventory to the Placement service."
21:35:23	mnaser	i might have a bit more on my hands than i expected
21:35:40	mnaser	shouldn't that be WARN instead of DEBUG?
21:36:26	jaypipes	mnaser: there was a deliberate use of DEBUG for most/all messages in the scheduler code paths due to concern about performance.
21:36:28	cdent	mnaser: that's what I was going to suggest: first make sure you're getting any allocations candidates, you can contrust queries direct to /allocation_candidates: https://developer.openstack.org/api-ref/placement/#allocation-candidates
21:36:45	cdent	s/contrust/construct/
21:36:48	mnaser	jaypipes: i see
21:36:54	jaypipes	mnaser: what was the GET /allocation_candidates HTTP request you see in your logs?\
21:37:03	mnaser	cdent: ok, i'll try to do that, might be a bit difficult considering the volume of traffic at the placement api
21:37:06	jaypipes	placement-api logs, that is.
21:37:14	mnaser	because i'm pretty sure this is some upgrade-leftover
21:37:33	mnaser	let me check
21:38:22	mnaser	"GET /allocation_candidates?resources=MEMORY_MB%3A65536%2CVCPU%3A64" status: 200 len: 53 microversion: 1.10
21:39:17	cdent	mnaser: you can also make similar queries to /resource_providers to confirm what you think should be there is in fact there (basically a shorter version of what an /allocation_candidates query might report. you want 64 vcpus?
21:39:56	mnaser	so right now i have an empty 32 physical core machine and im trying to launch 64 cores on it (with allocation ratio set to 2) -- im aware of performance implications but this is just to test out oversubscription
21:40:52	jaypipes	ahhhhhhhhh
21:41:13	jaypipes	mnaser: so, you will notice that max_unit is == 32 for your VCPU inventories.
21:41:28	mnaser	for that host correct
21:41:41	jaypipes	mnaser: this is to prevent someone from attempting to launch an instance that consumes more VCPU than the physical number of CPUs on the host.

Earlier   Later