Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-07-18
15:33:02 mriedem efried: not working how?
15:33:08 mriedem are you using the admin_api client?
15:33:47 efried mriedem: http://paste.openstack.org/show/726208/
15:33:53 efried Probably not :)
15:35:12 efried mriedem: Same thing via the admin_api
15:35:22 efried Looking at the func test that actually does this...
15:35:57 mriedem neo huh
15:35:57 mriedem /home/efried/Neo/nova/.tox/functional
15:36:00 mriedem tsk tsk
15:36:22 efried mriedem: swhat our project used to be called before it was called NovaLink
15:36:59 mriedem oh i know
15:37:19 mriedem i knew about neo before it couldn't be talked about openly
15:37:25 mriedem i'm a neo hipster really
15:39:06 efried 'cept you can't grow a beard
15:39:09 mriedem i don't see anything special in the os-hypervisors api samples functional tests for the statistics call
15:39:19 mriedem hipster bears are on their way out
15:39:23 mriedem *beards
15:39:27 efried mriedem: Me neither. I thought it might be the json headers, but I tried adding those and it didn't help.
15:39:44 efried So what you're saying is you were a beardless hipster before it was cool.
15:40:43 efried ya know, it's possible I'm injecting unintended side effects by using remote_pdb. Lemme try unwinding that...
15:41:11 mriedem efried: you just blew my mind
15:43:24 melwitt mriedem: we have a bug where the libvirt driver will unconditionally destroy disks even on shared storage during a rebuild failure, and we're looking at how to write the fix in such a way that it's backportable. what we really need to know in the libvirt driver spawn() is whether recreate=True or destroy_disks_on_failure should be True/False. would such a change to the spawn method signature be banned for a backport?
15:43:28 efried mriedem: That was it, though I don't know why.
15:44:15 melwitt mriedem: this is the WIP of the change, avoiding the method signature change, and it duplicates code from compute manager's default rebuild impl into the libvirt driver https://review.openstack.org/578846
15:45:01 mriedem melwitt: i had a change related to that same bug which did the logic in the spawn method based on the instance.task_state
15:45:07 melwitt mdbooth ^
15:45:49 mriedem https://review.openstack.org/#/c/288109/1/nova/virt/libvirt/driver.py
15:45:52 mriedem i told mdbooth about that 2 weeks ago
15:46:00 mriedem and he was aware of my old attempt
15:47:51 mriedem melwitt: i would hack something backportable into the driver spawn() based on task_state and/or active evac migration record (as cfriesen_ noted in my change), and then make the driver signature change on master only
15:48:40 mdbooth So, the driver signature change would be something like adding destroy_disks_on_failure to spawn().
15:49:10 mdbooth Although as noted in my comment there's scope to make the libvirt driver cleverer still.
15:49:40 mdbooth mriedem: So... task state for the backport only?
15:50:18 mriedem mdbooth: if the change could be confined to a tactical fix in the spawn() method itself then that's easier than making interface changes (even though that's allowed and unversioned)
15:50:41 mriedem but as i said, cfriesen_ made a point about needing to know if we're evacuating or not, which you can only know based on the task_state + active migration record
15:50:49 mriedem because evac uses the same task_states as evacuate (i think)
15:51:19 mdbooth mriedem: Yeah, task_state is a bit wild west.
15:51:37 mriedem well, evac/rebuild is a wild west
15:51:44 mdbooth mriedem: Heh, also true.
15:51:44 mriedem because it's munged into a single turducken
15:51:45 cdent evac != evacuate ?
15:52:19 melwitt I think he meant evacuate uses same task_states as rebuild
15:52:44 mdbooth turducken is an awesome word.
15:55:54 openstackgerrit sean mooney proposed openstack/os-vif master: add upper_constraints support https://review.openstack.org/583582
15:59:05 mriedem efried: https://bugs.launchpad.net/nova/+bug/1782393
15:59:06 openstack Launchpad bug 1782393 in OpenStack Compute (nova) "hypervisor local_gb_used still reports usage even with volume-backed instances after fix for bug 1469179" [Medium,Triaged]
15:59:09 mriedem pooja_jadhav: ^
16:02:44 mriedem i'm now overwhelmed with the amount of stuff i could be or should be working on
16:07:51 mriedem kashyap: now that you've reminded me, did you ever get a chance to look at the changes to https://review.openstack.org/#/c/560317/ with the extra cpu flags?
16:08:11 openstackgerrit Eric Fried proposed openstack/nova master: Func test for improper cn local DISK_GB reporting https://review.openstack.org/583646
16:08:23 efried mriedem: Done and done ^
16:09:01 mriedem ack; need to write something to the ML quick and then i'll get back on it
16:09:07 mriedem and add the move fixes for dan's patch
16:14:38 mriedem melwitt: http://lists.openstack.org/pipermail/openstack-dev/2018-July/132329.html
16:21:04 melwitt mriedem: ack thanks
16:21:21 kashyap mriedem: /me clicks
16:21:40 kashyap Oh, this one
16:22:09 kashyap Yes, I did add a few comments here: https://review.openstack.org/#/c/560317/19/nova/virt/libvirt/driver.py
16:22:26 kashyap I need to take a fresher look at it; was buried in some urgent downstream work the past weeks :-(
16:30:09 mriedem melwitt: tssurya: are we having a cells meeting today?
16:31:07 melwitt I don't have anything
16:31:51 mriedem reviewing tssurya's series for down cell is obviously top priority,
16:32:02 mriedem and i have https://review.openstack.org/#/c/582412/ for https://review.openstack.org/#/c/582342/ for some up-call bugs
16:32:13 mriedem the latter fixes the bfv cross_az_attach up-call
16:33:06 melwitt I have the instance group bug (still) which I think could be supported by gibi's tempest tests but also needs a func test for the multi cell case, IIRC?
16:34:33 mriedem i would have to look in detail again, but i'd rather we have a functional multi-cell test case for that than unit tests
16:34:36 mriedem given the complexity
16:34:42 mriedem and logic issues i found in the unit test
16:35:30 melwitt yeah, I'm going to ditch the unit tests
16:45:50 melwitt I was having difficulty with the func test, need to attack it again
16:48:12 sean-k-mooney does anyone have a doc or pointers on running nova tests under a debugger beyond pdb
16:50:36 stephenfin sean-k-mooney: What do you mean "beyond pdb"?
16:51:33 sean-k-mooney i can get pdb to work but im trying to get visual studio code or pycharm to work
16:52:13 stephenfin Oh, that I've no idea about
16:52:29 stephenfin mdbooth _might_ be able to help you. I hear he uses those things
16:52:50 openstackgerrit Stephen Finucane proposed openstack/nova master: Add functional tests for numa-aware-vswitches https://review.openstack.org/583288
16:52:51 openstackgerrit Stephen Finucane proposed openstack/nova master: scheduler: Start utilizing RequestSpec.network_metadata https://review.openstack.org/564452
16:52:52 openstackgerrit Stephen Finucane proposed openstack/nova master: Assorted cleanups from numa-aware-vswitches series https://review.openstack.org/582651
16:53:11 sean-k-mooney stephenfin: im trying to step through https://review.openstack.org/#/c/583339 to figure out what it does not trigger the bug
16:53:45 stephenfin mriedem, gibi: I know you're busy right now but that's my first attempt at functional tests above for when you do have time ^
16:54:51 stephenfin sean-k-mooney: I only use pdb or printf debugging so I'm no help, unfortunately
16:55:35 sean-k-mooney stephenfin: no worries i used to have pycharm work for this but new dev setup so all that gone.
16:55:47 mriedem sean-k-mooney: i thought efried_rollin wrote something about that in the dev docs
16:56:10 mriedem https://docs.openstack.org/ironic/queens/contributor/dev-quickstart.html#debugging-unit-tests
16:58:03 sean-k-mooney mriedem: that will partly work. it will give you a pdb console but i was hoping to get it working in an ide.
16:58:27 openstackgerrit Balazs Gibizer proposed openstack/nova master: Use placement 1.28 in scheduler report client https://review.openstack.org/583667
16:58:43 mriedem https://www.youtube.com/watch?v=nksiGORLDZw ?
17:00:30 sean-k-mooney mriedem: watching... its not a big deal but its nice to have.
17:08:39 melwitt thinking about the rebuild destroy_disks_on_failure thing again, I have the same question as cfriesen_ from the old review, it seems like we shouldn't destroy disks on any rebuild failure, shared or not. if rebuild didn't complete, shouldn't the disk remain?
17:19:20 mdbooth sean-k-mooney: I tend to use pdb, tbh
17:20:08 sean-k-mooney mdbooth: well apparent the process is now. install pycharm, turn on gevent suport then rightclick the test file you want and select debug
17:20:39 sean-k-mooney not sure how to doe it with vscode but since pycharm is working im happy
17:21:22 mdbooth sean-k-mooney: Interesting. Never even attempted to get a visual debugger working with Nova tests.
17:21:51 sean-k-mooney mdbooth: if you kickout 1 infinity loop in nova compute it works for the main agent too
17:33:29 mriedem melwitt: sure, but w/o changes to the spawn method, you need to check if there is an active evacuate migration record for the instance to know if you're rebuilding or evacuating
17:33:38 mriedem since the task_state only tells you doing one of those
17:33:51 mriedem *you're
17:34:35 mriedem efried_rollin: i've got the move cases handled for dansmith's is_bfv change, and functional test written to show it works, but of course there are a billion unit tests that blow up for unmocked thigns
17:36:20 melwitt mriedem: but does it matter whether we're rebuilding vs evacuating? I was thinking destroy_disks_on_failure=False if rebuild or evac, both
17:39:20 melwitt checking the task_state makes sense, just not seeing why we need to differentiate between rebuild and evac (though I do understand your point that checking the migration record is needed if we do need to differentiate)

Earlier   Later