Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-07
09:12:00 gcb johnthetubaguy, let me find out the discussion
09:12:37 johnthetubaguy gcb: yeah, I think I remember that now. It would be good to add that context in the git commit message, so others all know why it was done
09:13:38 gcb johnthetubaguy, will update it now
09:13:54 johnthetubaguy gcb: seriously though, we disable them because mox3 was failing randomly, I would rather do the mox conversion before we enabled them
09:16:39 gcb johnthetubaguy, what's the reason ? mox3 or usage of mox3
09:18:05 johnthetubaguy gcb: basically mox3 assertions seemed to fail randomly with py3, we never got to the root cause, but we decided to remove all mox from our tests to avoid hitting this issue: https://blueprints.launchpad.net/nova/+spec/remove-mox-pike
09:18:18 johnthetubaguy gcb: I think sdague might remember the details more
09:18:33 openstackgerrit xianming.mao proposed openstack/nova-specs master: Add support for volume online-migrate when backend has RBD https://review.openstack.org/430131
09:18:45 johnthetubaguy gcb: a tiny bit more context is here: https://blueprints.launchpad.net/nova/+spec/remove-mox
09:18:54 gcb johnthetubaguy, thanks
09:22:13 gcb johnthetubaguy, make removing mox/mox3 as a community goal ? :)
09:23:13 johnthetubaguy gcb: possibly, although all the slots are full for pike right now
09:23:47 johnthetubaguy gcb: not sure how many projects actually use mox, that might be an interesting thing to check (it might just be Nova!)
09:24:57 gcb johnthetubaguy, http://codesearch.openstack.org/?q=mox3&i=nope&files=&repos= Nova and horizon use a lot of them :)
09:25:14 johnthetubaguy its probably an age thing
09:25:34 robcresswell Mox makes us sad :(
09:25:40 robcresswell (Horizon, that is)
09:26:03 johnthetubaguy robcresswell: you are not alone in that
09:26:06 gcb then we can retire mox3 from oslo side
09:26:11 johnthetubaguy I never like the record/reply pattern
09:27:10 robcresswell I've just dealt with far too many cryptic failures. Testing with mox should not be *that* much more difficult than writing your actual logic.
09:27:26 openstackgerrit John Garbutt proposed openstack/nova master: Default live_migration_progress_timeout to off https://review.openstack.org/429798
09:27:34 robcresswell That said, its generally been "good enough" so we've never actually removed it. There's always been higher priority issues.
09:27:57 gcb The third party mock module doesn't seem to be maintained anymore, suggest use unittest.mock on Python 3
09:28:38 gcb I try to use unittest.mock on Python 3 , there is an example https://review.openstack.org/#/c/429196/
09:28:51 sfinucan gcb: We do that anyway on Python3, no?
09:28:58 sfinucan ...and fall back to mock from pip for Python2.7
09:29:10 sfinucan (seeing as Python2.7 doesn't have it)
09:29:35 gcb mock works well for python 2.7, just use unittest.mock on Python 3
09:29:53 johnthetubaguy gcb: I thought thats what we did, but not 100% sure
09:30:28 johnthetubaguy gcb: it might be that mock got ahead of the py3 lib at one point, but I don't 100% remember now
09:31:02 gcb oslotest add this for six in https://github.com/openstack/oslotest/blob/master/oslotest/__init__.py
09:31:35 johnthetubaguy gcb: ah, so we don't use the standard one, I see now
09:31:42 johnthetubaguy gcb: yeah, thats worth doing then
09:31:58 gcb johnthetubaguy, yeah
09:32:25 sfinucan ah, they're different imports. oops
09:32:34 sfinucan Yeah, definitely worth doing
09:32:42 sfinucan though lower than mox->mock :)
09:32:45 johnthetubaguy gcb: FWIW, its when mock looked like it was getting into python we totally stopped allowing more mox tests
09:32:55 johnthetubaguy sfinucan
09:32:59 sfinucan johnthetubaguy: We're ok to go merge stuff again, right?
09:33:01 johnthetubaguy sfinucan: that was news to me too
09:33:16 sfinucan i.e. trivial mox->mock stuff
09:33:20 johnthetubaguy sfinucan: ish, so the limitation is we don't want to make backports too hard, for the next week or so
09:33:31 sfinucan ah, I'll hold off on those so
09:33:50 sfinucan lest anyone want to backport tests too
09:36:08 johnthetubaguy sfinucan: yeah, its worth waiting a week I think
09:36:19 gcb let me add one item on https://etherpad.openstack.org/p/community-goals later, then we can start to move and set the the target in following cycle
09:37:23 johnthetubaguy gcb: it feels like part of the prep for py3, so its probably a good stepping stone I guess
09:37:48 johnthetubaguy gcb: although I honestly think it would be quicker to get the functional tests passing on py3, before we get all the unit tests passing on py3
09:37:56 johnthetubaguy for Nova that is
09:40:03 gcb johnthetubaguy, I added gate-nova-tox-db-functional-py35-ubuntu-xenial as non-voting, maybe we can make it votable
09:40:25 johnthetubaguy gcb: I think that would be a good thing to try
09:41:10 johnthetubaguy gcb: you can always to a tempest skip list, like we have for cellsv1: https://github.com/openstack/nova/blob/master/devstack/tempest-dsvm-cells-rc
09:41:40 johnthetubaguy i.e. get a job that passes creating at least one instance, then slowly enable more goodness as the fixes go in
09:42:19 gcb I will be back after dinner :)
09:44:45 openstackgerrit John Garbutt proposed openstack/nova-specs master: WIP: Spec idea on the future of quotas for Nova https://review.openstack.org/429678
10:05:21 lyarwood mdbooth: https://review.openstack.org/#/c/427364/ - I added the comments you requested btw, any chance of a quick review if you have time this morning?
10:05:56 mdbooth lyarwood: Got my head in something right now. Is there a chance of follow-on core review?
10:06:19 mdbooth (iow: will my review achieve anything this morning)
10:07:25 lyarwood mdbooth: ah, np, I was going to ask around now that we are past RC but don't go out of your way if you're in the middle of something
10:19:57 mdbooth Should we be logging authentication tokens?
10:19:59 mdbooth e.g.:
10:20:10 mdbooth application/json" -H "X-Auth-Token: {SHA1}dfc5e07945c13b29514dd78d29b374cf2e5d3a1f" _http_log_request /usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py:347
10:20:10 mdbooth 2017-02-06 16:37:53.021 [n-api.log] 29609 DEBUG cinderclient.v2.client [req-f47e58e1-65a9-44b3-b9ea-90959d0255ab tempest-TestVolumeSwap-787392718 tempest-TestVolumeSwap-787392718] REQ: curl -g -i -X GET http://10.24.164.111:8776/v2/72077d0aec734621ad21d12d3ffbc0e9/volumes/b4c90b8c-fac7-4bfd-b4be-a641ac137a1c -H "X-Service-Token: {SHA1}161c3fe7af35615c3f7a8136153d893316c4afa5" -H "User-Agent: python-cinderclient" -H "Accept:
10:20:55 mdbooth What's the lifetime of one of those tokens?
10:20:58 markus_z bauzas: Do you have a minute?
10:21:05 markus_z bauzas: It's about https://review.openstack.org/#/c/420079/1
10:21:10 bauzas markus_z: sure, but I'm a bit off this week
10:21:20 rpodolyaka mdbooth: we specifically store a hash of a token, so that it (i.e. a valid token) does not show up in logs, don?
10:21:25 rpodolyaka * don't we
10:21:49 bauzas markus_z: mmm, I should abandon this change
10:21:50 mdbooth rpodolyaka: Well the above it a cut/paste from my logs
10:21:51 rpodolyaka but you still can track usage of a particular token in logs
10:21:58 rpodolyaka but it's a hash
10:22:00 rpodolyaka not a token itself
10:22:07 rpodolyaka or I am missing something obvious? :)
10:22:14 markus_z bauzas: I was wondering about the alternatives to this change.
10:22:19 mdbooth rpodolyaka: I'm wondering the same thing :)
10:22:32 mdbooth If it's the thing we send to cinder, does it matter if it's a hash or not?
10:22:45 mdbooth Does it, eg, include a nonce component so it changes every time?
10:22:50 markus_z bauzas: Our s390 CI is broken because of "No hosts found to map to cell, exiting." and I don't find a solution for that.
10:22:58 rpodolyaka mdbooth: it's not what goes over the wire
10:23:09 rpodolyaka it's just the way it's shown in logs
10:23:25 rpodolyaka i.e. a sha1 hash
10:23:42 mdbooth rpodolyaka: Ah... so that's logging an sha1 of what went over the wire?
10:23:45 openstack Launchpad bug 1656276 in OpenStack Compute (nova) "Error running nova-manage cell_v2 simple_cell_setup when configuring nova with puppet-nova" [Undecided,In progress] - Assigned to Sylvain Bauza (sylvain-bauza)
10:23:45 bauzas markus_z: see the bug https://bugs.launchpad.net/nova/+bug/1656276
10:23:53 rpodolyaka mdbooth: yep
10:24:02 bauzas markus_z: that's the consensus now https://git.openstack.org/cgit/openstack/puppet-nova/commit/?id=dc2f3a358663c0fb97795666b16dec63cfcc3872
10:24:03 mdbooth Are you sure about that? Seems kinda weird we wouldn't just elide it.
10:24:42 mdbooth In other places we replace passwords with ***
10:25:08 rpodolyaka mdbooth: strace of `nova list` http://paste.openstack.org/raw/597914/
10:25:19 rpodolyaka well, the relevant part of it :)
10:25:49 mdbooth rpodolyaka: Cool, that doesn't look like an sha1 :)
10:25:53 mdbooth rpodolyaka: Thanks
10:25:56 rpodolyaka np!
10:27:14 bauzas markus_z: also http://docs.openstack.org/developer/nova/cells.html#first-time-setup now differs from http://docs.openstack.org/developer/nova/cells.html#upgrade-minimal
10:27:21 markus_z bauzas: We see that issue when we setup devstack (with devstack-gate). I'm not sure how that change applies to that situation.
10:28:24 openstackgerrit Bob Ball proposed openstack/nova master: XenAPI: fix memory usage miscalculation https://review.openstack.org/394857

Earlier   Later