Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-07-18
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)
17:45:25 openstackgerrit Merged openstack/nova master: API: add support to abort queued live migration in microversion 2.65 https://review.openstack.org/573136
17:45:49 sean-k-mooney mriedem: for the antiafinity filter... should this be false based on the comment ? https://github.com/openstack/nova/blob/eb4f65a7951e921b1cd8d05713e144e72f2f254f/nova/scheduler/filters/affinity_filter.py#L99
17:49:25 sean-k-mooney im steping through your regrssion test in pycharm but i think that is a latent bug.
17:51:50 sean-k-mooney also running the regression under the debugger it also very clear we only ever use the uuid of the first instance in the list.
18:05:10 openstackgerrit Merged openstack/nova master: Address nit in 79dac41fee178dabb547f4d7bc10609630767131 https://review.openstack.org/583212
18:07:52 mriedem melwitt: ok, idk, i'm really half assing trying to understand that problem atm
18:08:23 mriedem sean-k-mooney: it's a double negative
18:08:29 mriedem "must not return the source as a non-possible destination"
18:08:40 mriedem meaning, must return the source as a possible destination
18:08:42 mriedem for resize to same host
18:09:11 sean-k-mooney right. so we want to allow resize to same host
18:09:14 mriedem yes
18:09:14 sean-k-mooney ?
18:09:19 mriedem which is what that was added for
18:09:19 sean-k-mooney ok
18:09:23 mriedem and there is a related functional test somewhere for it
18:10:32 sean-k-mooney well in the multi create case this cases the second instance to pass on the first host because we use the same request spec for all instances and there for the same uuid
18:11:08 sean-k-mooney so for both instance both hosts pass
18:11:12 flwang1 mriedem: hello, i have a question about this nova/bin/privsep-helper
18:11:43 flwang1 mriedem: could you please help me understand if it's still used?
18:11:45 flwang1 thanks
18:13:34 sean-k-mooney flwang1: as far as i am aware teh privsep-helper is till used to spawn the privesep deamon
18:13:51 flwang1 can anybody help me understand where can I get the privsep-helper? we're using an old version of Nova, and recently after a re packaging, we can't find the file
18:14:14 flwang1 sean-k-mooney: thanks, do you know how is it installed? by os-brick?
18:15:36 mriedem sean-k-mooney: yes that's the bug
18:16:00 openstackgerrit Hongbin Lu proposed openstack/nova master: [DNM] Test neutron change https://review.openstack.org/583687
18:16:17 mriedem sean-k-mooney: but i'm not sure why my functional test wouldn't recreate that issue if the first weighed host is going to be picked for both instances

Earlier   Later