Earlier  
Posted Nick Remark
#openstack-nova - 2017-11-09
13:24:28 openstackgerrit Balazs Gibizer proposed openstack/nova stable/ocata: WIP: Functional test for regression bug #1713783 https://review.openstack.org/505160
13:24:29 openstack bug 1713783 in OpenStack Compute (nova) ocata "After failed evacuation the recovered source compute tries to delete the instance" [High,Triaged] https://launchpad.net/bugs/1713783
13:26:56 openstackgerrit Balazs Gibizer proposed openstack/nova stable/ocata: Functional test for regression bug #1713783 https://review.openstack.org/505160
13:26:57 openstack bug 1713783 in OpenStack Compute (nova) ocata "After failed evacuation the recovered source compute tries to delete the instance" [High,Triaged] https://launchpad.net/bugs/1713783
13:42:40 openstackgerrit Balazs Gibizer proposed openstack/nova stable/ocata: Set error state after failed evacuation https://review.openstack.org/518733
13:43:43 jianghuaw jaypipes, are you around?
14:00:46 jianghuaw jaypipes, do you have time to have a quick look at the comment at here:https://review.openstack.org/#/c/518294/1/nova/compute/resource_tracker.py@795
14:01:33 jianghuaw basically I think we can remove _resource_change() which is to check if resources changed in compute_node.
14:02:28 openstackgerrit Marco Chiappero proposed openstack/nova master: Add a communication channel for power management support https://review.openstack.org/512815
14:06:50 jianghuaw jaypipes, I guess we defer the checking to self._provider_tree.has_inventory_changed: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L602
14:07:24 jianghuaw If my understand is correct, I think we can totally resource_tracker.py@remove _resource_change()
14:08:06 jianghuaw totally resource_tracker.py@remove _resource_change()
14:09:12 jianghuaw sigh! => totally remove resource_tracker.py@_resource_change()
14:33:49 openstackgerrit Balazs Gibizer proposed openstack/nova master: Functional test: cold migrate to compute down https://review.openstack.org/496280
14:34:26 openstackgerrit Balazs Gibizer proposed openstack/nova master: Functional test: evacuate with no compute https://review.openstack.org/498482
14:34:35 efried jaypipes https://github.com/jaypipes/articles/pull/17
14:36:28 jaypipes jianghuaw: I'm here now.
14:38:18 jianghuaw jaypipes, do you think we can remove resource_tracker.py@_resource_change()?
14:38:22 jianghuaw and defer the checking to self._provider_tree.has_inventory_changed: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L602
14:38:51 jaypipes jianghuaw: we should be able to do that, yes.
14:39:38 jianghuaw jaypipes, cool. I will rework this patch https://review.openstack.org/#/c/518294 to cover this part.
14:40:09 jaypipes jianghuaw: sounds good.
14:42:37 jianghuaw jaypipes, is nested resource provider supported by allocation_candidate?
14:42:41 jianghuaw I guess not.
14:43:14 jaypipes jianghuaw: no, not yet. I am trying my best to get this series merged before having n-r-p do allocation candidates: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:refactor-alloc-cands-get-by-filters
14:43:17 jianghuaw But I'm not if we already have in-progress patches for that.
14:43:29 jaypipes jianghuaw: I would hold off a week
14:43:49 jaypipes jianghuaw: besides reviews from alex_xu, haven't been able to get many reviews on the series this week due to the summit.
14:44:01 jaypipes alex_xu: ty, btw for your reviews and your patience with me :)
14:44:26 jianghuaw jaypipes, understood. I will have a look the series of patches also. thanks.
14:44:34 jaypipes jianghuaw: ty sir!
14:45:49 jianghuaw :-)
14:49:52 openstackgerrit David Wahlstrom proposed openstack/nova stable/pike: Fix changes-since search filter https://review.openstack.org/518740
15:00:22 efried jaypipes Would like to discuss a couple of design points with you when you have a sec.
15:00:31 jaypipes efried: shoot.
15:00:56 jaypipes efried: hangout?
15:01:11 efried jaypipes Could do.
15:01:36 efried jaypipes You'll have to set it up, though.
15:01:42 jaypipes efried: np, one sec.
15:02:34 jaypipes efried: https://hangouts.google.com/call/NveOHfR-Vd1PJXV8V2SEAAEE
15:02:48 efried jaypipes http://paste.openstack.org/show/625946/
15:09:58 efried jaypipes Here's what that guy is *currently* returning: http://paste.openstack.org/show/625947/
15:26:02 efried jaypipes https://review.openstack.org/#/c/518123/ <= bottom of test refactor & adds
15:46:52 snasir Hi is there a way to delete a nova hypervisor manually ? I deleted a node but something went wrong and the hypervisor did not get removed... Can anybody assist . Thanks
17:07:26 efried jaypipes About to push that test case into https://review.openstack.org/#/c/517119/6 -- you got local revs on that series?
17:07:54 jaypipes efried: nope, go for it.
17:08:10 openstackgerrit Eric Fried proposed openstack/nova master: handle traits with sharing providers https://review.openstack.org/517119
17:08:13 efried jaypipes hecho
17:08:55 jaypipes efried: -1 on the bottom patch of your test series...
17:11:21 efried jaypipes Responded - I didn't change it.
17:12:36 jaypipes efried: ugh...
17:12:53 efried Do I get the sense that the base class shouldn't have been NoDB?
17:13:05 jaypipes efried: that reminds me of why I didn't like how these func tests were written in the first place...
17:13:12 jaypipes efried: yes. :(
17:13:20 jaypipes efried: ok, never mind. change in future patch.
17:13:26 efried ack
17:14:39 efried jaypipes I got the impression that the fixture was mocking the database-ness in some way different than the main TestCase base .
17:15:14 jaypipes efried: I hate the whole USES_DB_SELF crap.
17:15:28 jaypipes along with NoDBTestCase... just doesn't make logical sense.
17:17:22 efried jaypipes Well, FWIW, NoDB+USES_DB_SELF seems to run 19-23% faster (CPU vs. wallclock)
17:17:37 efried (sample size: 1)
17:17:58 jaypipes efried: I just hate the incongruence.
17:18:02 efried mm
17:20:52 efried jaypipes Appears same effect could be achieved by inheriting from TestCase, setting USES_DB = False, and also setting USES_DB_SELF = True.
17:21:14 openstackgerrit Murali Annamneni proposed openstack/nova master: Enables MySQL Cluster Support for Nova https://review.openstack.org/446643
17:21:29 jaypipes efried: USES_DB_SELF is a terribly-named class variable.
17:21:37 jaypipes efried: I mean, wtf does that even mean? :(
17:22:15 efried USES_a_DB_that_i_will_configure_mySELF_so_dont_do_it_for_me ?
17:24:08 efried The code that consumes those vars looks pretty simple; *and* they appear to be mutually exclusive, so the base class(es) could toggle the one based on the other. Then we could come up with better names, and jaypipes is a happy bear.
17:24:20 efried bbiab
17:40:18 jaypipes efried_afk: number of requests for you in https://review.openstack.org/#/c/518124/
18:13:46 snasir Hi Nova people. I have this error in Nova-conductor logs (using Newton Release), when I try to spawn a baremetal node . Changed the compute_driver to ironic driver and ironic_host_manager in nova.conf to do so. https://thepasteb.in/p/Vmh0yPQz56GC4
18:14:15 snasir Desperately need some help. I dont see any other logs to indicate why nova cannot schedule.. Any help would be greatly appreciated, Thanks
18:18:22 snasir Is anyone here ?
18:33:56 snasir Anybody ?
18:36:36 openstackgerrit Mike Lowe proposed openstack/nova master: live-mig: keep disk device address same https://review.openstack.org/518022
18:39:37 jaypipes snasir: not many people here due to people being in Sydney at the OpenStack summit...
18:40:01 jaypipes snasir: have you asked on the #openstack-ironic channel and/or the openstack@ mailing list?
18:41:35 jaypipes snasir: compute-0: (ComputeCapabilitiesFilter) capability is missing
18:41:52 jaypipes snasir: there is a capability that compute-0 doesn't have that the flavor you are booting requires.
19:00:42 snasir jaypipes: oh ok, No the problem is with the other node, which just fails at Retry
19:07:57 jaypipes snasir: I'm telling you that the logs are pointing out why a NoValidHost is being returned. Compute-0 is being filtered out of the results because it's missing a required capability.
19:41:38 openstackgerrit Elod Illes proposed openstack/nova master: Transform instance-live_migration_pre notification https://review.openstack.org/482070
20:13:48 efried jaypipes Module-level using rp.context -- does rp have a .context or just a ._context?
20:14:03 jaypipes efried: yeah, sorry, rp._context
20:14:19 efried jaypipes You're okay with me using a private member for the sake of making the method module-level?
20:14:27 jaypipes efried: yes sir
20:14:29 efried ight.
20:18:42 openstackgerrit Merged openstack/nova master: Extract allocation candidates functional tests https://review.openstack.org/518123
20:28:23 jmlowe jaypipes: got a sec?
20:28:36 jaypipes jmlowe: yessir
20:31:13 jmlowe so I gave that test another try, I think it should work but it doesn't seem to update the xml like I expect it to, is there some obvious gross conceptual error on my part?
20:31:15 jmlowe http://logs.openstack.org/22/518022/7/check/openstack-tox-py27/104cb93/testr_results.html.gz
20:37:24 jaypipes jmlowe: looking....
20:45:28 jaypipes jmlowe: gawd I hate dealing with XML... :( the only thing I'm guessing is maybe because the host list is a sub-element one level further down from the address element, that maybe the copy-destination-element thing isn't working properly? Try changing the alias element, which *is* at the same level as the address element and seeing if that works.
20:46:50 jmlowe on the upside if it can't do nested then it's probably a bug, there are certainly storage systems where the sub elements can and should change over time
20:55:58 jaypipes jmlowe: ack. I'm just grasping at straws really :)
20:56:22 jmlowe I'm trying to find where the alias is generated
21:08:00 jmlowe so I can't actually locate where the alias is generated, but I'm thinking it's generated from the address which isn't supposed to change
21:36:49 openstackgerrit Marco Chiappero proposed openstack/nova master: Add a communication channel for power management support https://review.openstack.org/512815

Earlier   Later