Posted	Nick	Remark
#openstack-nova - 2018-01-31
16:37:10	sean-k-mooney	gibi: i dont think thats in conflict
16:37:24	mriedem	i will say that i've evacuated all of that spec from my brain
16:37:31	mriedem	including it's mish mash of dependencies
16:37:58	sean-k-mooney	gibi: for the multiple port binding spec we wanted to move the point of getting the port info form neutron to the conductor before calling placement
16:38:17	gibi	sean-k-mooney: "neutron would update the allocations in Placement rather than nova doing that" this part seems conflicting to me
16:38:45	gibi	sean-k-mooney: I'm not against moving the port creation to the conductor
16:39:38	sean-k-mooney	gibi: moving the port bind/createion to the condoctor means we can skip a host if binding would fail early instead of after we have set up everything on the destination
16:40:10	sean-k-mooney	gibi: this is of benifit most with multicells deployment where we cant retry like we used too
16:40:42	cdent	efried: nothing leaps out while reading through that test. I'm going to go with the old standby of "eventlet is probably messing with something somewhere"
16:41:06	efried	cdent: Thanks for looking. You like the test case in general tho?
16:41:21	cdent	seems legit
16:41:30	gibi	sean-k-mooney: I might missing something here but for me binding a port and claiming the resources for that port happens independently
16:42:53	sean-k-mooney	gibi: when you bind a port you set the host id so you have already claimed the resouce at this point so currently we find out if neutron can bind a node very late
16:43:50	gibi	sean-k-mooney: so this means for me that claiming the port related resources has to happen before the bind
16:44:42	sean-k-mooney	gibi: the idea was create/get the neutron before placement is called to get extra requiremetn. then go through placement and scheduler steps and select a host. try to bind it and if it fails go to next candiate and when binding all ports succeds then call compute node to boot instance
16:45:07	sean-k-mooney	gibi: yes claiming has happend before binding today
16:46:50	gibi	sean-k-mooney: in the idea does the bind happen in the conductor?
16:47:01	sean-k-mooney	gibi: yes
16:47:13	gibi	sean-k-mooney: OK that is the piece that I missed so far
16:47:37	gibi	sean-k-mooney: thanks, I have to restart some thinking based on this information
16:49:06	sean-k-mooney	but again this is all up for debate. there could be better ways to do it but if we do the port creation and bindign in the conductor before we claim we can eliminate nodes the would fail before ever calling the compute node.
16:50:06	sean-k-mooney	you could have neutron do the claim in placement as part of the port bind on sucess if you wanted for example. or the condoctor could do it when you claim everything else
16:50:18	tssurya	dansmith : thank you I will have a look, should we probably do the same thing here as well or add an exception or something? -> https://github.com/openstack/nova/blob/stable/pike/nova/scheduler/host_manager.py#L601
16:51:05	tssurya	dansmith : also do we have a cells meeting today ? not that we have anything from our side (since we are discussing it here)
16:51:34	dansmith	tssurya: I'm (very) cool with canceling.. mriedem melwitt ?
16:51:39	mriedem	cancel
16:51:53	melwitt	+1
16:51:56	dansmith	woot
16:52:12	tssurya	cool
16:52:18	dansmith	tssurya: we should convert that to scatter/gather for performance, and make it not freak out on timeout/fail yeah
16:52:32	dansmith	tssurya: I can stack that on top of my patch from earlier
16:52:42	dansmith	tssurya: unless you already have one ready to go
16:52:44	tssurya	dansmith: yes sounds good
16:52:48	tssurya	thank you
16:52:54	tssurya	nope I don't have one
16:53:00	dansmith	okay, give me a bit
16:53:33	gibi	sean-k-mooney: If the neutron claims then there is window of race condition. If nova claims in one step in the conductor then we can eliminate such race
16:55:06	gibi	sean-k-mooney: therefore I more like the idea to let nova do the claim based on the requests from the port
16:55:13	gibi	sean-k-mooney: and I think we agree. :)
16:55:27	mdbooth	mriedem: ack
16:58:16	openstackgerrit	Matt Riedemann proposed openstack/nova master: Pass limit to /allocation_requests https://review.openstack.org/531517
17:03:00	stephenfin	bauzas: Could you hit these at some point, please :) https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike+topic:bug/1736759-stable/pike
17:04:49	stephenfin	mriedem: Assuming you're not completely burnt out yet, could you take a look at this backport https://review.openstack.org/#/c/530743/ ?
17:06:50	mriedem	stephenfin: i see that neither jaypipes or bauzas reviewed the patch on master,
17:07:01	mriedem	so i think i'd like to see that they are cool with that before we merge all the way back to ocata
17:07:06	bauzas	dansmith: FWIW, I think I found a possible issue with https://review.openstack.org/#/c/532924/
17:07:29	bauzas	dansmith: which would require the object to check the service version
17:07:33	dansmith	bauzas: I was assuming you were going to -2 that
17:08:10	bauzas	-2 that change because we're close to RC1 ?
17:08:22	bauzas	and defer to Rocky?
17:08:35	bauzas	because I don't disagree with that cleanup
17:08:37	dansmith	bauzas: no because of the use of the 0.0 as sentinels for the DB or whatever that hack was
17:08:56	dansmith	okay, you're saying we're far enough past that that we can do this cleanup?
17:09:12	bauzas	dansmith: I think mid-term we can remove the sentinels
17:09:19	dansmith	I really didn't look closely other than to see it seemed to be missing the point of those being 0
17:09:20	dansmith	okay
17:09:21	bauzas	dansmith: but the problem is with an upgrade
17:09:23	stephenfin	mriedem: I'm not sure I get you?
17:09:37	mriedem	gibi: if you're still around, can you re-approve https://review.openstack.org/#/c/539300/ and the one after it
17:09:56	bauzas	dansmith: so we could potentially require to keep a bit of backwards compatibility logic
17:10:03	stephenfin	Oh, you want more than two pairs of eyes on it? Gotcha
17:10:08	mriedem	stephenfin: i'm not personally comfortable with disk over commit and allocation ratio stuff, i know jaypipes and bauzas are more knowledgeable about that
17:10:09	bauzas	dansmith: I'll discuss with maciejjozefczyk_ about the possible solutions
17:10:11	mriedem	stephenfin: yes
17:10:44	stephenfin	That's fair. I can bug them (y)
17:10:49	bauzas	maciejjozefczyk_: when you're up tomorrow, let's discuss and ping me
17:10:58	bauzas	I'm here
17:11:01	bauzas	no need to bug me
17:11:09	bauzas	what's the context ?
17:11:32	bauzas	btw. if anyone has some fakelibvirt expertise and functional testing for libvirt, raise a hand, please
17:11:48	bauzas	it will prevent me to spend a couple of hours trying to understand the code
17:11:50	stephenfin	bauzas: :) I'm looking for eyes on this backport https://review.openstack.org/#/c/530743/
17:11:51	mriedem	bauzas: https://review.openstack.org/#/c/538938/
17:11:58	mriedem	oops
17:12:00	stephenfin	The stable/ocata backport too, but baby steps
17:12:04	sean-k-mooney	gibi: yep that why at least one of the spec is written to assume nova will do the claim. i also have not really looked at them since november so cant rememeber all the deatils.
17:12:05	openstackgerrit	sahid proposed openstack/nova-specs master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/539605
17:12:24	stephenfin	bauzas: I might be able to help
17:12:37	stephenfin	w/ fakelibvirt, that is. What's up?
17:12:45	bauzas	stephenfin: my goal is to provide a specific test module for vGPU testing
17:13:09	bauzas	ie. mocking the virt driver to have mdevs and do a couple of server actions
17:13:23	bauzas	like we have for NUMA or SR-IOV testing
17:13:46	gibi	mriedem: done
17:13:50	bauzas	stephenfin: but let's punt that discussion to tomorrow, /me looking at your change
17:13:56	stephenfin	bauzas: Yup, that sounds fair. Have you looked at nova/tests/functional/libvirt/test_pci_sriov_servers.py ?
17:14:01	bauzas	I did
17:14:09	stephenfin	Ah, cool
17:14:40	bauzas	I probably need to only identify the best entrypoints to mock only the pieces of libvirt I want
17:15:19	stephenfin	Yeah, we can discuss tomorrow AM so, but fakelibvirt is basically the hardware-dependent aspects of libvirt mocked out. How those parts are determined, I'm not so sure
17:15:42	stephenfin	vladikr would be the person to ask tomorrow, assuming he's about/has time
17:15:58	bauzas	no worries, I'll dig into the code anyway
17:18:15	dansmith	tssurya: assume you don't yet have a bug for the host_manager issue right?
17:18:20	openstackgerrit	Marcin Juszkiewicz proposed openstack/nova master: Make sure that we have USB Host controller for USB tablet https://review.openstack.org/538003
17:18:55	hrw	mriedem, jaypipes: this version adds usb host controller ONLY if pointer device is 'usbtablet' so ps/2 mouse lovers are not touched
17:22:54	mriedem	hrw: that needs tests
17:23:45	tssurya	dansmith : no
17:23:49	tssurya	do you want me to open one ?
17:24:19	hrw	mriedem: I am aware. Will ask someone to write one for me as I know how get functionality working but completely out of ideas when it comes to tests.
17:24:20	dansmith	tssurya: I was thinking maybe you already had bugs for both of these things when I asked on the first review, but then realized maybe not
17:24:38	dansmith	tssurya: I think it'd be good to have the bugs coming from cern as backport justification, if you don't mind

Earlier   Later