| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-07 | |||
| 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 | |
| 10:28:40 | bauzas | markus_z: tbc, unless you're upgrading a newton cloud, you now need to stop using single_cell_setup and rather use map_cell0, then discover_hosts() | |
| 10:31:11 | markus_z | bauzas: Do I need to configure that in Devstacks local.conf? As said, it's for our CI. | |
| 10:34:46 | bauzas | markus_z: what do you mean by local.conf ? | |