Posted	Nick	Remark
#openstack-nova - 2017-02-01
22:06:54	mriedem	btw, newton compute supports the minimum ironic api that supports resource classes https://github.com/openstack/nova/blob/stable/newton/nova/virt/ironic/client_wrapper.py#L37
22:07:10	bauzas	cool then
22:07:17	mriedem	anyway, the scheduler won't use placement until computes are ocata or newer,
22:07:23	mriedem	which supports high enough ironic api
22:07:45	mriedem	i thought the thing was, the flavor extra spec would have the resource class in it, and if it's there, then we filter on ironic RPs using that resource class
22:08:02	mriedem	jroll: i just need you to appreciate my live in tokyo reference
22:08:06	jroll	+1
22:08:09	mriedem	because dansmith failed to do so
22:09:03	mriedem	jroll: we're just talking about what the implications are for our ability to do things in pike if https://review.openstack.org/#/c/404472/ doesn't make ocata
22:09:06	bauzas	alright
22:09:09	jroll	mriedem: so we need to be putting inventory (based on resource class) in the placement API a cycle before we can filter on it
22:09:11	jroll	I think
22:09:29	mriedem	jroll: well, we can use nova-compute service versions to flag that i think
22:09:38	mriedem	i.e. https://review.openstack.org/#/c/404472/ bumps the compute service version
22:09:46	jroll	maybe I shouldn't try to think this through on irc for the fifth time and just hang out with y'all for a while at ptg
22:09:50	mriedem	so once all of your computes are at that level, then we support filter on resource class in the scheduler
22:10:15	dansmith	mriedem: I failed to do what?
22:10:29	jroll	mriedem: where does that bump the version?
22:10:35	mriedem	jroll: that patch doesn't today
22:10:43	jroll	ah
22:10:45	mriedem	we're saying if it doesn't land until pike, we do it in pike
22:10:49	jroll	that explains everything
22:11:09	mriedem	jroll: e.g. https://review.openstack.org/#/c/425806/
22:11:38	bauzas	I'm just trying to find the implications
22:11:43	mriedem	then we used that here https://review.openstack.org/#/c/417961/41/nova/scheduler/filter_scheduler.py@174
22:11:51	bauzas	and how if we don't merge it by Ocata, how to flag that
22:12:04	mriedem	so with service version 16, your nova-compute won't start unless configured for placement,
22:12:17	jroll	aha
22:12:20	mriedem	and then the scheduler checks if the minimum nova-compute in the deployment is at least 16, and if so, it goes hog wild on placement
22:12:36	mriedem	i'm saying we do the same for ironic resource classes if we need to in pike
22:12:43	bauzas	so the scheduler could possibly know whether it could verify new-way
22:12:46	mriedem	so if you have ocata computes, then you don't get that function yet
22:12:55	mriedem	but once you're computes are upgraded to pike, you get it
22:12:58	mriedem	*your
22:13:01	bauzas	exactly
22:13:11	jroll	and then we'll have... if 'extra_spec:custom_foo' in request_spec.flavor AND service_version > the_one_with_resource_classes: placement_client.find_nodes_with_class('custom_foo')
22:13:16	jroll	or whatever
22:13:24	jroll	else do the old crap
22:13:30	mriedem	yeah basically
22:13:48	bauzas	something like that indeed
22:14:01	jroll	and in queens we make the extra spec thing mandatory and maybe even fix flavor to not need that
22:14:28	mriedem	maybe
22:14:33	mriedem	i can't think n+2
22:14:39	jroll	fair
22:14:42	jroll	s/queens/future
22:14:59	mriedem	by at least pike-eol :)
22:15:04	jroll	regardless, pike looks like progress
22:15:06	jroll	heh
22:15:13	jroll	sounds good to me, thanks
22:15:27	mriedem	solid progress either way i think
22:45:40	mriedem	this is wrong right? https://review.openstack.org/#/c/408571/41/nova/api/openstack/compute/schemas/servers.py@277
22:45:45	mriedem	should be terminated_at?
22:51:18	melwitt	mriedem: I think so. that's what the db column is called, anyway 'terminated_at'
22:51:34	mriedem	yeah i'm going through https://review.openstack.org/#/c/421760/10/api-ref/source/parameters.yaml
22:58:34	mriedem	fixing
23:03:03	openstackgerrit	Ed Leafe proposed openstack/nova: placement: RT now adds proper Ironic inventory https://review.openstack.org/404472
23:03:14	edleafe	jaypipes: mriedem: ^^ tests should be fixed now
23:03:24	jaypipes	edleafe: ty ed!
23:06:40	mriedem	can you list servers with a query parameter with a 'none' value, to make it equate to NULL in the db query, i.e. GET /servers/?terminated_at=none
23:06:41	mriedem	?
23:07:27	mriedem	i guess let's find out
23:18:15	tonyb	cdent, mriedem: who did the placement stuff in devstack? and is the placement implementation/upgrade from mitaka -> newton -> ocata in devref documented
23:19:04	mriedem	tonyb: cdent did the devstack patches,
23:19:12	tonyb	mriedem: okay
23:19:34	tonyb	cdent: shoudl expect strange questions in his future
23:19:40	mriedem	and http://docs-draft.openstack.org/67/427367/3/check/gate-nova-docs-ubuntu-xenial/de76755//doc/build/html/placement.html
23:19:43	mriedem	for devref
23:19:56	mriedem	see 'deployment' and 'upgrade notes'
23:20:37	tonyb	Thanks!
23:21:29	openstackgerrit	Matt Riedemann proposed openstack/nova: Fix the terminated_at field in the server query params schema https://review.openstack.org/427964
23:21:31	mriedem	oomichi: gmann: alex_xu: Kevin_Zheng: ^
23:21:33	mriedem	sdague: ^
23:21:53	mriedem	fwiw, filtering instances by those datetime fields doesn't seem to work anyway
23:22:18	mriedem	i have an instance created at 2017-02-01T23:14:26Z according to nova show, but nothing is returned from:
23:22:25	mriedem	curl -s -H "X-Auth-Token: $OS_TOKEN" http://9.5.124.95:8774/v2.1/servers?created_at=2017-02-01T23:14:26Z
23:24:10	mriedem	oh interesting it's a regex
23:24:11	mriedem	curl -s -H "X-Auth-Token: $OS_TOKEN" http://9.5.124.95:8774/v2.1/servers?created_at=^2017-02-01.*
23:24:13	mriedem	^ works
23:29:50	armax	mriedem: is the large ops job running for nova changes?
23:29:59	mriedem	armax: the large ops job doesn't run anymore
23:30:03	mriedem	as far as i know
23:30:09	armax	mriedem: ok, thanks for confirming this
23:30:13	mriedem	which reminds me, i was going to kill that stuff from d-g
23:30:18	armax	you mean https://review.openstack.org/#/c/228636/2/stackrc?
23:30:37	mriedem	nope
23:30:47	mriedem	there is some stuff in d-g about the large ops job
23:30:51	armax	mriedem: ok
23:30:53	mriedem	which i was going to clean out since we don't run that job anymore
23:31:15	armax	what about that one? do we want to go back and keep a simpler API_WORKERS expression?
23:31:29	armax	I am thinking of setting the minimum num of workers to 1
23:31:39	Kevin_Zheng	mriedem: so you are suggesting separate Reno with API ref patch?
23:31:46	armax	that cuts the amount of RSS memory per service quite a bit
23:32:00	armax	and should give us some headroom at least for now
23:32:01	mriedem	Kevin_Zheng: at this rate, i think we'll probably want to decouple the release note from the rest of that change
23:32:04	armax	what do you reckon?
23:32:27	mriedem	armax: maximum you mean?
23:32:51	mriedem	right now default in devstack is nproc / 2 right?
23:33:10	Kevin_Zheng	mriedem: ok, will do it, holiday is over :)
23:33:22	mriedem	armax: btw, i'm pretty sure that https://review.openstack.org/#/c/228636/ was all changed after that
23:33:53	mriedem	although that was a long time ago so i might be mixed up on when those changes all happened, mtreinish might remember

Earlier   Later