Posted	Nick	Remark
#openstack-nova - 2017-08-28
19:31:46	mriedem	we already have an AllocationCandidate object today right?
19:32:12	mriedem	sorry, it's called AllocationRequest
19:32:53	mriedem	which has a list of AllocationRequestResource
19:33:09	edleafe	mriedem: I guess I'll try following that pattern
19:33:20	mriedem	why not just use the same exact objects?
19:33:30	mriedem	if that's exactly what you want for the structure?
19:33:36	edleafe	it's not
19:34:05	mriedem	ok
19:34:11	edleafe	I need a thing that is a hostname, and the blob needed to claim/unclaim the resources for the particular request
19:34:49	mriedem	"(2:22:02 PM) cdent: edleafe: so you’re idea at this point is an object that is effectively; ‘target’: String, ‘allocation’: Dict"
19:35:04	edleafe	mriedem: yep
19:35:08	mriedem	and then return a list of those
19:35:19	mriedem	AlternativeHost, and AlternativeHostList
19:35:21	mriedem	or something
19:35:35	edleafe	we can bikeshed on the name :)
19:35:56	mriedem	and you're wondering if you need to break down the 'allocation' field into a more specific type?
19:36:05	edleafe	what I was asking is: what ovo field type do I use for the allocation part of that?
19:36:21	edleafe	I don't want to break it down if at all possible
19:36:27	edleafe	It's a unit
19:36:39	edleafe	(for a particular claim)
19:37:01	artom	edleafe, so a single allocation (ie, resource_provider and resources)
19:37:02	artom	?
19:37:24	edleafe	artom: well, it would be a set of allocations, but yes
19:37:28	mriedem	edleafe: then it's just Dict
19:37:53	mriedem	edleafe: and this is an allocation, yes?
19:37:54	mriedem	{ "resource_provider": { "uuid": "9cf544dd-f0d7-4152-a9b8-02a65804df09" }, "resources": { "VCPU": 2, "MEMORY_MB": 8096 } }
19:37:59	edleafe	mriedem: even with dansmith's note at https://github.com/openstack/nova/blob/master/nova/objects/fields.py#L72 ?
19:38:12	mriedem	edleafe: yes, as i said, that's about using the nova.fields vs ovo fields
19:38:24	mriedem	versioned objects started in nova,
19:38:33	mriedem	that note is saying, stuff is moving to ovo, so use the fields from there directly
19:38:56	edleafe	mriedem: ok, then that note confused me
19:38:56	mriedem	https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/fields.py#L657
19:39:23	edleafe	everyone back to work!
19:39:51	mriedem	update the note with "Use these directly from oslo.versionedobjects for new code." or something if that clarifies it
19:41:00	edleafe	mriedem: will do
19:42:06	sdague	mriedem: https://review.openstack.org/#/c/498477 and https://review.openstack.org/#/c/498478 are redone with the git sha
19:42:40	mriedem	sdague: ok, but i'm going to hold off on stable/pike stuff until we release
19:42:51	sdague	mriedem: that's fine
19:43:02	sdague	it will still have real test results on it
19:43:19	openstackgerrit	Steve Noyes proposed openstack/nova master: update live migration to use v3 cinder api https://review.openstack.org/463987
19:43:24	sdague	I was less concerned for the release, but just more for "these things should be in there sometime"
19:46:08	openstackgerrit	Ed Leafe proposed openstack/nova master: Clarify the field usage guidelines https://review.openstack.org/498581
19:46:10	edleafe	mriedem: quick note clarification ^^
20:24:47	openstackgerrit	Dan Smith proposed openstack/nova master: Add placeholder migrations for Pike backports https://review.openstack.org/496932
20:24:47	openstackgerrit	Dan Smith proposed openstack/nova master: Add uuid to migration object and migrate-on-load https://review.openstack.org/496934
20:24:48	openstackgerrit	Dan Smith proposed openstack/nova master: Add uuid online migration for migrations https://review.openstack.org/498589
20:24:48	openstackgerrit	Dan Smith proposed openstack/nova master: Add uuid to migration table https://review.openstack.org/496933
20:25:02	dansmith	mriedem: that placeholder one failed out of the gate if you want to hit it again ^
20:25:40	mnaser	(sorry, trying to get some help from another project that might have ran into this: i've discovered a performance issue in sahara and identified it to sqlalchemy lazy='joined' in the relationships which results in a giant set of joins)
20:25:52	mnaser	i noticed the nova code had none of that. was that a decision that was taken or just.. no one ever set that to anything
20:26:13	mnaser	i figure nova is probably one of the longer codebases out here that might have ran into these perofmance regressions so i'd ask around
20:26:40	dansmith	mnaser: we generally join things explicitly when we want them
20:27:06	dansmith	intentionally.
20:28:14	mnaser	dansmith makes perfet sense. looking at the git blame.. looks like it was just magically changed with no explanation. ill do my checks
20:28:16	mnaser	thank you for that info
20:49:28	openstackgerrit	Matt Riedemann proposed openstack/nova master: Refactor ServerMovingTests for non-move tests https://review.openstack.org/498596
20:50:29	mriedem	dansmith: ^ as you asked for
20:50:38	dansmith	ah thanks
20:52:12	openstackgerrit	Michael Still proposed openstack/nova master: Move lvm handling to privsep. https://review.openstack.org/495516
20:52:13	openstackgerrit	Michael Still proposed openstack/nova master: Move shred to privsep. https://review.openstack.org/495537
20:52:13	openstackgerrit	Michael Still proposed openstack/nova master: Move xend existence probes to privsep. https://review.openstack.org/495538
20:52:14	openstackgerrit	Michael Still proposed openstack/nova master: WIP / Aspirational: we don't need rootwrap any more. https://review.openstack.org/495542
20:52:14	openstackgerrit	Michael Still proposed openstack/nova master: Cleanup mount / umount and associated rmdir calls https://review.openstack.org/494423
20:52:15	openstackgerrit	Michael Still proposed openstack/nova master: Move loopback setup and removal to privsep. https://review.openstack.org/495664
20:52:16	openstackgerrit	Michael Still proposed openstack/nova master: Don't shell out to mkdir, use ensure_tree() https://review.openstack.org/492326
20:52:16	openstackgerrit	Michael Still proposed openstack/nova master: Move libvirt usages of chown to privsep. https://review.openstack.org/471972
20:52:17	openstackgerrit	Michael Still proposed openstack/nova master: Move ploop commands to privsep. https://review.openstack.org/492325
20:52:17	openstackgerrit	Michael Still proposed openstack/nova master: Move the idmapshift binary into privsep. https://review.openstack.org/495541
20:52:18	openstackgerrit	Michael Still proposed openstack/nova master: Read from console ptys using privsep. https://review.openstack.org/489486
20:52:21	openstackgerrit	Michael Still proposed openstack/nova master: Avoid chowning console logs in libvirt https://review.openstack.org/472229
20:52:22	openstackgerrit	Michael Still proposed openstack/nova master: First attempt at adding a privsep user to nova itself. https://review.openstack.org/459166
20:52:23	openstackgerrit	Michael Still proposed openstack/nova master: Move execs of touch to privsep. https://review.openstack.org/489190
20:52:24	openstackgerrit	Michael Still proposed openstack/nova master: Move libvirts dmcrypt support to privsep. https://review.openstack.org/490737
20:52:24	openstackgerrit	Michael Still proposed openstack/nova master: Replace dd with shred for zeroing lvm volumes. https://review.openstack.org/495532
20:52:26	openstackgerrit	Michael Still proposed openstack/nova master: Move execs of tee to privsep. https://review.openstack.org/489438
20:53:10	mikal	sdague: that's me rebasing that series, thanks for the review on the first one
20:53:53	mikal	sdague: https://review.openstack.org/#/c/495532/ is a similarly trivial head-of-series refactor if you're bored
20:54:23	mikal	sdague: well, "refactor" might be strong. "removal of historical silliness" might be more accurate.
20:55:19	sdague	sure, it's about end of day here, so I can look tomorrow
20:55:27	edleafe	mikal: I prefer "hysterical silliness", myself
21:00:37	mriedem	mikal: your test removal in the bottom change cuts a bit too deep
21:03:48	mriedem	wow
21:03:49	mriedem	"Took 269.99 seconds to spawn the instance on the hypervisor."
21:04:08	mriedem	clarkb: ^
21:04:12	cfriesen_	is that running on a raspberry pi?
21:04:18	mriedem	ubuntu-xenial-vexxhost-ca-ymq-1-10660012
21:05:46	mriedem	that was on http://logs.openstack.org/94/498094/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/8e0a0d0/
21:06:51	mikal	mriedem: as in on that shred change?
21:07:06	mriedem	mikal: yeah
21:07:18	mikal	mriedem: hmmm, I'll take a look today
21:07:20	mriedem	mikal: the slow node thing above is not that change
21:07:26	mriedem	just the test removal
21:09:34	clarkb	mriedem: what image is being booted? that looks normal for ubuntu
21:10:19	mriedem	cirros
21:11:28	mriedem	cf0d1557-c4b3-4304-b4ec-5e6eaf4a7123
21:11:43	mriedem	http://logs.openstack.org/94/498094/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/8e0a0d0/logs/devstacklog.txt.gz#_2017-08-28_14_49_41_357
21:11:43	mriedem	sorry
21:11:50	mriedem	cirros-0.3.5-x86_64-disk
21:14:01	mriedem	looking at most of these "seconds to spawn the instance on the hyperviso" messages, most are around 2 seconds
21:14:06	mriedem	but some just spike to like 1-2+ minutes

Earlier   Later