Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-31
15:49:51 mriedem that patch i just linked
15:50:15 bauzas yup, that
15:50:15 dansmith bauzas: I've been pinging you for two weeks to look at this, can you please look at it? https://review.openstack.org/#/c/532924/
15:50:23 bauzas dansmith: on it
15:50:46 bauzas dansmith: it was on an open tab
15:51:00 dansmith bauzas: okay well, never heard a peep so I didn't know
15:51:08 bauzas my bad
15:53:16 tssurya mriedem : thanks, so that means we do not agree to deleting the specs when deleting the instances right ?
15:53:43 hrw https://imgur.com/a/3b22r - graphical console on arm64 out of box (with https://review.openstack.org/#/c/538003/ applied) mriedem
15:55:34 mriedem tssurya: well, i don't agree with the assertion that if the instance fails to be deleted, losing the request spec is ok
15:55:49 mriedem because we have fallback code all over the place from the newton transition to reqspecs for old instances
15:56:05 mriedem as i said in that patch, a lot of that fallback code is best effort but shouldn't really be relied upon
15:56:11 bauzas maciejjozefczyk: dansmith: there could be a flip logic where some cloud could have computes nova.confs with allocation ratios equal to 0.0
15:56:45 bauzas maciejjozefczyk: dansmith: in that case, when upgrading to Queens, I guess we should still make sure to correctly normalize the ratios the other way, nope ?
15:57:11 maciejjozefczyk bauzas: hey
15:57:23 tssurya mriedem : right, makes sense
15:58:26 melwitt mriedem: ack
16:03:05 mriedem hrw: left some comments
16:03:23 maciejjozefczyk bauzas: I dont know, Its said that in Newton it should be moved to default values, and its Queens now.
16:03:53 bauzas maciejjozefczyk: yup, I'm just thinking about flipping the problem
16:03:53 hrw mriedem: thx
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

Earlier   Later