Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-31
16:04:20 bauzas maciejjozefczyk: say we have a pike compute, and a queens cloud
16:04:49 bauzas maciejjozefczyk: the old pike compute would store in its DB the unnormalized ratios, ie. 0.0, right?
16:04:53 hrw mriedem: will reply
16:05:04 maciejjozefczyk bauzas: right
16:05:08 bauzas maciejjozefczyk: in that case, what works now that we normalize those ratios by the object layer
16:05:34 bauzas maciejjozefczyk: if we cut that logic and just takes what we get from the DB, then we need to be careful about those pike nodes
16:06:15 bauzas maciejjozefczyk: I'm trying to evaluate hard https://review.openstack.org/#/c/532924/6/nova/objects/compute_node.py@185 and its impact with a pike node
16:06:56 maciejjozefczyk bauzas: you're right
16:07:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Mention required traits in the flavors user docs https://review.openstack.org/539300
16:07:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix nits in support traits changes https://review.openstack.org/537351
16:07:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Add functional tests for traits-based scheduling https://review.openstack.org/539310
16:07:19 mriedem efried: fixed that comment ^
16:07:20 mriedem thanks
16:07:35 mriedem efried: also, your two irc nicks in here is driving me nuts
16:07:52 cfriesen design question...now that we have objects.Service.get_minimum_version(), does the RPC version really serve any purpose anymore?
16:08:09 efried mriedem: sorry, was keeping the old one around for logs. Guess there's no reason to keep it logged in, tho.
16:08:21 bauzas maciejjozefczyk: wait, I'm not saying we have a problem yet
16:12:39 maciejjozefczyk bauzas: In this particular case when pike compute has in db 0.0 _from_db_object() method will change 0.0 to default value from oslo.config
16:12:53 maciejjozefczyk L185 so the effect would be the same
16:13:34 bauzas maciejjozefczyk: right, I just left a comment
16:14:18 bauzas maciejjozefczyk: if people started to touch their nova.conf, whatever it's Pike or Queens, we take that conf value
16:14:19 maciejjozefczyk bauzas: The only thing for now is the topic on openstack-dev: What about aggregation groups and its metadatas?
16:14:19 openstackgerrit Claudiu Belu proposed openstack/nova master: hyper-v: Logs tips on PortBindingFailed https://review.openstack.org/539584
16:15:09 efried jaypipes, cdent: Heads up, here's a really weird failure that may point to an intermittent placement bug. But I have no idea how it happened, how to reproduce it, etc.
16:15:20 efried jaypipes, cdent: http://logs.openstack.org/17/535517/15/check/nova-tox-functional/b841731/testr_results.html.gz
16:15:30 bauzas maciejjozefczyk: can you please give me the link ?
16:16:15 maciejjozefczyk bauzas: https://bugs.launchpad.net/nova/+bug/1742747 and http://lists.openstack.org/pipermail/openstack-operators/2018-January/014748.html
16:16:17 openstack Launchpad bug 1742747 in OpenStack Compute (nova) "RT overrides default allocation_ratios for ram cpu and disk" [Undecided,In progress] - Assigned to Maciej Jozefczyk (maciej.jozefczyk)
16:16:27 maciejjozefczyk jaypipes: and mgagne was thing about that use-case
16:16:47 bauzas maciejjozefczyk: ah right, can we please punt that topic for now ?
16:17:06 bauzas maciejjozefczyk: I'm trying to identify whether your change will work on a rolling-upgrade :)
16:17:13 maciejjozefczyk bauzas: yea sure :)
16:17:25 efried jaypipes, cdent: If you look at time stamp 2018-01-30 20:31:43,675 you can see that we successfully created the CUSTOM_BANDWIDTH resource class. Then the next log shows creating the inventory that uses it. That also succeeds, which it wouldn't have if the resource class didn't exist. And there's no subsequent removal of that resource class. But the failure claims the resource class didn't come back in GET /resource_cla
16:17:36 maciejjozefczyk bauzas: I need to go anyway.
16:17:42 maciejjozefczyk bauzas: thanks for checkign it
16:17:55 bauzas ++
16:18:27 jaypipes efried: this is repeatable?'
16:18:55 efried jaypipes: No. I haven't been able to repro it locally, and it also didn't repro in the py35 version of that same test for that same run on that same patch in zuul.
16:19:09 efried jaypipes: That's what scares me the most
16:19:51 jaypipes efried: clowns are what scare me most.
16:20:37 cdent puppet clowns
16:24:30 efried cdent, jaypipes: So do I just pretend this didn't happen? I can't think of a way to track it down without being able to reproduce it.
16:24:30 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Make sure that we have USB Host controller for tablet https://review.openstack.org/538003
16:24:44 hrw mriedem: please check
16:24:59 jaypipes efried: clowns are indeed slippery like that.
16:25:05 cdent efried: if you're in the middle of doing other important stuff I'd say don't let it distract you for now
16:25:09 jaypipes efried: I would forget it happened for now.
16:25:16 jaypipes cdent++
16:25:17 efried okeydokeythen.
16:25:19 cdent I'm looking at the test now to see if anything leaps out
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.

Earlier   Later