Posted	Nick	Remark
#openstack-nova - 2017-10-18
19:42:12	cdent	efried: thanks for the attention to detail, the content of that stack has expanded a lot since I started, so some steps have been lost
19:42:53	efried	cdent Swhat I'm here for. Eventually I'll be useful for something other than pointing out typos and missed paperwork.
19:43:22	dansmith	efried: don't forget rebasing
19:43:34	efried	Mm
19:43:49	dansmith	you can rebase a mofo like a sonofabee
19:44:54	mriedem	sdague: can you get this pike backport and the one below?
19:45:33	mlavalle	mriedem: any chance we can get nova team eyes on the lastest revisions of https://review.openstack.org/#/c/375580/ and https://review.openstack.org/#/c/502306/
19:45:42	dansmith	edleafe: cdent: so that limits or {} thing.. limits is nullable in reqspec.. are we sure we need do that thing?
19:46:02	dansmith	also, I'm not clear on what part of this series requires this when we didn't before
19:46:37	mriedem	mlavalle: honestly i think the bandwidth provider thing is not going to happen in queens
19:46:45	mriedem	given the various dependencies and overall complexity
19:47:39	mlavalle	mriedem: dependencies meaning functionality that is being developed in the Nova side?
19:47:45	mriedem	mlavalle: yes
19:48:01	mriedem	there are some major challenges to overcome before we can even get to bandwidth provider
19:48:56	mriedem	mlavalle: for example, it relies on the compute pushing the bandwidth allocations and we're moving away from the computes trying to create allocations
19:53:02	openstackgerrit	Chris Dent proposed openstack/nova master: [placement] manage cache headers for usages https://review.openstack.org/513174
19:54:34	edleafe	dansmith: it caused multiple unit test failures without the 'or {}
19:54:58	edleafe	dansmith: not sure if the change back to including limits makes that no longer the case.
19:55:04	dansmith	edleafe: lol. well we should put that in the comment then, eh?
19:55:16	dansmith	edleafe: I'd like to understand why we're making that change if we are
19:55:20	openstackgerrit	Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
19:55:21	openstackgerrit	Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
19:55:22	jaypipes	efried: fixed. ^
19:56:49	cdent	goodnight all
19:57:03	mriedem	gdi i hate reviewing specs in new gerrit
19:57:14	mriedem	jumps all over the place when trying to expand comments
19:57:31	jaypipes	mriedem: yuuuuup. drives me friggin nuts.
19:57:49	mriedem	firefox?
19:57:58	jaypipes	yup.
19:58:08	edleafe	dansmith: re-running tests with that change reverted - will let you know
19:58:30	dansmith	edleafe: thanks
19:58:38	dansmith	mriedem: jaypipes not just in firefox
19:59:11	dansmith	mriedem: left one nit and one real comment in johnthetubaguy's ironic patch
19:59:23	dansmith	I can fix the nit (and the functional bit too I guess) if you agree
20:01:56	mriedem	replied
20:05:42	dansmith	mriedem: I do it in with statements because python requires it :P
20:06:33	dansmith	mriedem: so you think we have no other situations other than moves that ironic doesn't support where we don't want said stomping?
20:08:07	mriedem	my brain is kind of fried,
20:08:16	mriedem	at this point, you're likely to blow your foot off either way
20:08:27	mriedem	because of the minefield i mean
20:09:06	mriedem	the stomp was really because of moves from ocata to pike nodes i thought, scheduler would claim on both (double stuff) and ocata periodic would overwrite the allocations created by the scheduler,
20:09:17	mriedem	and then the dest node would overwrite the allocations again once the move was done
20:09:43	mriedem	you can't resize, live migrate or unshelve an ironic instance
20:09:54	mriedem	and with evacuate, the source host isn't running the stomper
20:11:50	dansmith	alright
20:12:05	mriedem	i could be missing something
20:12:09	mriedem	like i said, minefield
20:12:15	mriedem	seinfeld minefield
20:12:43	mriedem	"what's the deal with all these allocations?!"
20:14:47	openstackgerrit	Dan Smith proposed openstack/nova master: Keep updating allocations for Ironic https://review.openstack.org/513085
20:15:55	mriedem	omfg,
20:16:03	mriedem	dansmith: jaypipes: change the rendering setting to 'slow'
20:16:05	mriedem	seems to help
20:16:09	mriedem	smcginnis: ++
20:17:19	smcginnis	mriedem: It helped even more in the last gerrit. This one has some more quirks, but I think it's better.
20:17:20	dansmith	I don't even know what that would mean, but... cool
20:18:00	mriedem	gerrit settings
20:18:12	dansmith	I mean I dunno what fast rendering would be
20:18:21	dansmith	it all seems pretty slow to me :)
20:19:19	mriedem	they should rename the setting to "stop fucking up my gd cursor placement fucker"
20:19:20	mriedem	i agree
20:20:24	mriedem	efried: thanks for helping to review this https://review.openstack.org/#/c/502306/
20:20:27	mriedem	it's definitely hairy
20:20:45	efried	mriedem phew, thought I was just being dense.
20:21:19	smcginnis	mriedem: +1 to that name, it would be much more accurate.
20:21:23	mriedem	no man, it's building on like all of the worst things
20:21:43	mriedem	port orchestration, nested resource providers, scheduling, neutron agent stuff, etc etc
20:29:02	mriedem	sean-k-mooney: in https://review.openstack.org/#/c/502306/ - so when nova binds a port to a selected host, neutron will put some kind of allocation information in the port binding profile, and nova will proxy that allocation information to placement?
20:29:14	mriedem	and the suggested flow is:
20:29:22	mriedem	1. conductor asks scheduler for a host
20:29:51	mriedem	2. scheduler filter looks for ports with a qos policy and if found, gets allocatoin candidates for hosts that have a nested bw provider
20:29:59	mriedem	3. scheduler returns host to conductor
20:30:05	mriedem	4. conductor binds the port to the host
20:30:24	mriedem	5. the bound port profile has some allocation juju that nova proxies to placement as an allocation request for the port on the bw provider
20:30:34	mriedem	6. conductor sends to compute to build the instance
20:30:42	mriedem	7. compute activates the bound port
20:30:48	mriedem	8. compute plugs vifs
20:30:53	mriedem	9. profit?!
20:31:43	mriedem	why can't the allocation juju happen on the neutron side when the port is bound
20:31:44	mriedem	?
20:33:33	mriedem	i seem to remember some discussion at the ptg about it being cool that nova will proxy the allocation creation for neutron, but i'm not sure why
20:33:39	mriedem	mlavalle: ^ do you remember?
20:34:16	mriedem	ultimately we don't want nova managing resource allocations for network things
20:34:31	mriedem	especially out of band things like qos policies in neutron
20:36:19	efried	mriedem This may be slightly off topic, but who will be the consumer of the allocations related to the port? The port itself, or the instance?
20:38:56	mriedem	i think the port
20:40:22	mriedem	it's a bit confusing in the spec
20:40:23	mriedem	"A virtual machine port can consume bandwidth from one of these Resources
20:40:24	mriedem	Providers."
20:40:35	mriedem	and
20:40:38	mriedem	"By the time the port is bound, the bandwidth allocated to the instance is already recorded."
20:40:41	sdague	mriedem: I looked at the stable stuff, should be good. You still need somone else on the top patch
20:40:59	mriedem	sdague: yeah, thanks - i can find someone
20:41:03	mriedem	someone named dan
20:41:43	dansmith	link m
20:41:44	dansmith	e
20:42:27	mriedem	can't find it
20:42:37	dansmith	offer expires in 3....2...
20:43:05	mriedem	dansmith: https://review.openstack.org/#/c/512716/
20:48:42	efried	mriedem The port is actually the only thing that makes sense.

Earlier   Later