Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-31
16:25:42 jaypipes efried: you need to rebase that anyway
16:26:17 efried jaypipes: Yeah, but I need to wait until the bottom of the series merges now. Otherwise would need re-+Ws on those bottom five, and lose their headway in the gate.
16:26:29 efried jaypipes: I have it rebased locally.
16:26:58 jaypipes ack
16:27:10 hrw mriedem: I hope that new commit message and replies to comments make it simpler to understand
16:27:18 sean-k-mooney ralonsoh__: gibi ah ok i have asked one of the other teams at intel to contiue this item but we have not got confirmation they will. we would like to yes. we should know if intel can work on it by the ptg
16:28:54 gibi sean-k-mooney: thanks for the info
16:28:58 sean-k-mooney gibi: if you want to reporpose it then go ahead but it if not we will likely do it in the next week or two. my team however is nolonger resoced to work on it
16:30:24 efried reporpoise (ftfy). A marine mammal, again.
16:30:35 gibi sean-k-mooney: we are currently trying to understand the next steps with this feature. If we reach the point to have something solid before intel repropose then we will propose it
16:31:13 openstackgerrit Dan Smith proposed openstack/nova master: Make service all-cells min version helper use scatter-gather https://review.openstack.org/539590
16:31:29 dansmith tssurya: mriedem ^
16:31:39 dansmith see if you buy my logic in those comments :D
16:32:22 sean-k-mooney gibi: well i think the main step would be to start modeling network backends a placement resouse providers of bandwith. we were intending to have neutron create those RPs but how we model numa will obviosly effect it.
16:33:03 sean-k-mooney gibi: the reason for neutron doing it and not nova was so nova does not have know how to discover things like network bandwith for every neutron backend
16:33:20 mriedem jaypipes: mdbooth: i'd prefer not to land https://review.openstack.org/#/c/462521/ at this point in queens
16:33:59 gibi sean-k-mooney: yeah, that part seems to be clear. The first real roadblock we hit was that which component will allocate from those RPs, nova or neutron
16:34:14 sean-k-mooney nova
16:34:38 jaypipes mriedem: ack. I'm still +2 on it. but you want to -W it?
16:34:50 sean-k-mooney gibi: that said i wanted neutron to pass a request for bandwith as part of the neuton port
16:34:53 gibi ralonsoh__: btw, could you please just simply un-abandon (restore?) the spec patch so we can publish some comments there in the meantime?
16:34:58 mriedem jaypipes: done
16:35:01 jaypipes mriedem: done.
16:35:06 jaypipes lol, jinx
16:35:41 gibi sean-k-mooney: I also feel that nova should do the claim based on the request coming from the port from neutron
16:36:03 gibi sean-k-mooney: but it seems mriedem has a different view based on the ptg etherpad https://etherpad.openstack.org/p/nova-ptg-rocky L145
16:36:37 sean-k-mooney gibi: just looking now
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

Earlier   Later