Earlier  
Posted Nick Remark
#openstack-nova - 2017-09-06
14:17:43 mdbooth e.g. by setting task_state
14:17:53 mdbooth I expect I just missed it, though.
14:18:14 mdbooth Do you happen to know if there is any locking around that method?
14:19:00 mdbooth If there isn't, the save/restore xml after a long-running rebase mechanism would be potentially pretty bad.
14:19:14 kashyap mdbooth: I read your comment this morning, and did find your task exclusion observation interesting
14:19:25 gibi mriedem: could you confirm that we want to delete the allocation of the instance during _destroy_evacuated_instances if the instance failed an evacuation?
14:19:35 gibi mriedem: context is in https://review.openstack.org/#/c/499237/
14:19:36 kashyap Hmm, although the patch is a strict improvement as-is, now I wonder about your comment - where is the bug lurking...
14:19:50 dansmith mriedem: I'm going to be in an airport when the cells meeting is going on
14:19:57 dansmith mriedem: I can try to run it from there, but no promises
14:20:03 alex_xu kashyap: thanks!
14:20:25 mriedem dansmith: let's just skip
14:20:35 dansmith mriedem: cool
14:20:56 gibi mriedem: I'm asking because then a subsequent rebuild needs to allocate resources again
14:22:56 mriedem gibi: hmm, and a rebuild to the same host won't do a claim, and the RT won't auto-heal the allocations on the node
14:23:05 mriedem and rebuild (not evacuate) bypasses the scheduler
14:23:22 mriedem that's a good point
14:23:39 gibi mriedem: yes, that is my fear
14:24:03 gibi mriedem: in the other hand we could put the instance to error state after the failed evac and keep the allocation
14:24:17 gibi mriedem: this way the rebuild doesn't need to allocate
14:24:23 mriedem i'm in the middle of something and will have to digest the replies in that review later
14:24:30 mriedem gibi: we might also just have to leave this until the ptg
14:24:37 gibi mriedem: sure
14:24:59 mriedem could you add it to the ptg etherpad in case it has to wait until next week?
14:25:10 gibi mriedem: adding...
14:26:23 hogepodge mriedem: initial schedule is up, let me know if times work for you, leave notes if things need to be shuffled. It's all preliminary right now and subject to change. https://etherpad.openstack.org/p/InteropDenver2017PTG
14:27:52 mriedem hogepodge: ok thanks
14:32:31 gibi mriedem: I added it to the etherpad
14:36:40 mriedem gibi: thanks
14:40:14 hogepodge dtantsur|afk: ^^
14:41:46 openstackgerrit Hongbin Lu proposed openstack/nova master: Handle exception on adding secgroup https://review.openstack.org/465173
14:41:51 openstackgerrit Merged openstack/nova master: rbd: Remove unnecessary 'encode' calls https://review.openstack.org/412356
14:42:32 stephenfin Hurrah ^
14:44:13 openstackgerrit Merged openstack/nova master: Remove qpid description in doc https://review.openstack.org/499087
14:54:19 dansmith mriedem: dtantsur|afk: see this ironic migration thing? https://review.openstack.org/#/c/501025/2
14:56:57 mriedem now i do
14:58:31 esberglu I'm getting the following unauthorized command error from nova-rootwrap intermittently
14:58:32 esberglu http://paste.openstack.org/show/620547/
14:58:58 mriedem sdague: looks like https://review.openstack.org/#/c/457636/ is happy - the devstack patch to install the osc-placement plugin
14:59:01 mriedem http://logs.openstack.org/36/457636/9/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/ad2b234/logs/pip2-freeze.txt.gz
14:59:08 esberglu In /etc/nova/rootwrap.d/compute.filters I have the following line
14:59:09 esberglu tee: CommandFilter, tee, root
14:59:25 esberglu Anyone have any idea why sometimes that filter is failing to match?
15:03:25 sdague mriedem: yep
15:07:41 stephenfin sdague: Is the RXTX factor flavor key still applicable with a neutron backend?
15:08:23 sdague stephenfin: I thought it was nova net (and maybe xen) only. But I don't know.
15:08:30 mriedem hmm, did we ever say in the pike release notes that conductor now needs it's nova.conf to have the [placement] section filled in?
15:08:44 mriedem stephenfin: no, i plan on deprecating that out of the api
15:08:49 mriedem just need to write the spec
15:09:05 mriedem and yes, it's really only nova net + xen
15:09:20 stephenfin mriedem: Excellent. I'm going to put that in the docs and mark bug 1688054 as invalid
15:09:21 openstack bug 1688054 in openstack-manuals "Flavors in Administrator Guide - confusing description for rxtx factor" [Medium,Confirmed] https://launchpad.net/bugs/1688054
15:09:46 mriedem stephenfin: that doesn't make the bug invalid
15:09:53 mriedem if the docs are wrong for how it's used today
15:09:57 sdague esberglu: where in the code is that called?
15:10:13 stephenfin Yeah, that's a good point. OK, I'll clarify the intent a little better so
15:10:25 stephenfin ...and join the flavor/flavor2 files
15:10:28 stephenfin #RefactoringFTW
15:13:55 efried esberglu IT or OOT? SDE or traditional? Is it a snapshot operation that's being tested?
15:13:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test resource allocation during soft delete https://review.openstack.org/495159
15:13:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: Moving more utils to ServerResourceAllocationTestBase https://review.openstack.org/499539
15:16:26 efried Okay, I think I answered my own questions esberglu
15:17:39 efried sdague: This is being done as part of the snapshot operation in our OOT driver: https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/mgmt.py#L97-L100
15:19:49 esberglu Sorry got pulled away for a few
15:19:56 esberglu efried: Yeah this is OOT snaphot
15:20:17 efried esberglu And presumably this is causing the test to fail.
15:20:26 esberglu efried: Yep
15:20:50 efried But the _tee_as_root doesn't raise, right? We just fail to find the disk in the next part of the code?
15:24:03 esberglu efried: The nova-rootwrap command raises when trying to execute that tee command
15:24:15 efried esberglu Oh. Boo.
15:24:34 esberglu efried: https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/mgmt.py#L58
15:24:57 esberglu It calls that execute which goes into the rootwrap filters and should match the tee line
15:25:15 esberglu But sometimes it isn't matching that tee filter
15:25:22 efried Which rootwrap filter?
15:25:51 esberglu tee: CommandFilter, tee, root
15:26:07 esberglu in /etc/nova/rootwrap.d/compute.filters
15:26:49 esberglu That line should allow tee to be run as root with any parameters
15:27:24 efried esberglu Sorry, I mean are we using RootwrapDaemonHelper or RootwrapProcessHelper?
15:30:25 openstackgerrit Matt Riedemann proposed openstack/nova master: Add release note for force live migration allocations https://review.openstack.org/501314
15:30:26 mriedem bauzas: here you go ^
15:30:59 bauzas mriedem: roger. just in a meeting now
15:31:21 openstackgerrit Matt Riedemann proposed openstack/nova master: Add release note for force live migration allocations https://review.openstack.org/501314
15:31:33 efried esberglu Can you try setting `use_rootwrap_daemon` to True in the compute conf and see if the problem magically disappears?
15:31:57 efried esberglu That's in the [DEFAULT] section
15:32:01 esberglu efried: Yeah that isn't set currently. I can give it a try
15:32:23 efried esberglu Though if non-daemon is busted, that seems like it oughtta be a bug to nova.
15:34:05 openstackgerrit Merged openstack/nova master: Trim the fat from InstanceInfo https://review.openstack.org/471146
15:34:31 sdague efried: yeh, though the real fix would be to get rid of it entirely for privsep
15:34:39 sdague be aware, that mikal's patch series is doing that
15:34:44 efried sdague "it" which?
15:34:58 efried The Process version?
15:35:13 sdague https://review.openstack.org/#/c/489438
15:35:20 sdague that's 5 patches in
15:35:44 sdague and it will probably take some time to land, but rootwrap for tee is removed at that point
15:36:21 sdague efried: the tee call at all
15:37:18 efried sdague Mm. And the resolution is to decorate my function with this privsep gizmo and then do a regular ol `with open(): write()` ?
15:37:27 sdague yep
15:37:41 sdague but his first patch has to land before that will work
15:38:36 efried esberglu ^^ FYI. Need to add that to the watchlist so we can react when it lands.
15:39:54 esberglu efried: Will do

Earlier   Later