| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-31 | |||
| 16:36:38 | ralonsoh__ | gibi: sure | |
| 16:36:43 | gibi | ralonsoh__: thanks a lot | |
| 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. | |