Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-19
15:39:46 efried aspiers: test_servers presumably?
15:39:48 aspiers turns out that tox -e flake8 pretends to do something useful but actually checks nothing at all ...
15:39:52 aspiers correct
15:40:06 aspiers stestr --test-path=./nova/tests/functional run -n nova.tests.functional.test_servers.TraitsTrackingTests.test_resource_provider_traits
15:40:16 aspiers if you want the quicker version
15:40:24 efried okay, thanks.
15:40:48 kashyap stephenfin: I'm still a bit squirmy about this whole muddling with s390x, and its console devices. Because both "sclp" and "sclplm" are for different purposes, per s390x maintainers. And I don't have access to a machine to test it all
15:40:54 efried aspiers: btw, if you install tox 3.1.1 (uh, which I guess I forced you to do anyway), tox -e functional -- test_resource_provider_traits should be almost as quick.
15:40:58 kashyap So I was just poking the code to see until it poked me back...
15:41:15 aspiers efried: yeah I figure that out, but I find that tox still adds unacceptable overhead
15:41:28 efried for test discovery?
15:41:30 aspiers the {posargs} trick is handy though
15:41:31 kashyap stephenfin: Anyway, so far from our code audit it is mergeable; so no need to belabour more on it now. </EOM>
15:41:38 aspiers not just test discovery
15:41:59 efried We got rid of the bytecode
15:42:19 aspiers efried: it takes ~2s on my machine to get to the point of launching stestr
15:42:44 aspiers it has to go through all the virtualenv stuff first
15:43:10 mdbooth mriedem: If you recall this one: https://review.openstack.org/#/c/626952/ . It looks like the commit message there is rubbish. I haven't been able to reproduce the underlying issue and I suspect it's actually been fixed by upgrading libraries. Haven't worked out which ones, though.
15:43:59 mdbooth That said, I still like this cleanup, and I suspect the approach is slightly more robust to similar issues. Is it worth rewriting the commit message and keeping it around?
15:44:23 mdbooth If there's no interest I'll just drop it. Or lyarwood will, anyway :)
15:45:02 mriedem i don't have a strong opinion
15:46:26 mdbooth mriedem: ack. I'll probably drop it then as it's likely to languish. Thanks.
15:46:36 mdbooth lyarwood: ^^^ Lets drop it.
15:49:35 openstackgerrit Adam Spiers proposed openstack/nova master: WIP: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498
15:49:52 aspiers efried: there's PS 11 with a working test which includes the reset()
15:50:38 efried aspiers: The test was working for me at ps10
15:51:30 aspiers efried: yeah but it didn't test the reappearance of the trait
15:52:01 aspiers efried: https://review.openstack.org/#/c/538498/10..11/nova/tests/functional/test_servers.py@2274
15:52:18 efried okay. It doesn't really matter; I just need something that's supposed to hit that fake_delete
15:52:25 aspiers good point
16:00:53 mriedem cdent: so the nova functional tests - they use the placement fixture from extracted placement right? not the in-tree placement code. so doing https://review.openstack.org/#/c/637892/ in nova would only be for runtime if we copied that
16:02:24 cdent yes
16:02:43 mriedem ok
16:05:57 cdent mriedem: plus that osa thing that m*naser was gunna set up
16:08:03 openstackgerrit sean mooney proposed openstack/os-vif master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610068
16:08:16 mriedem cdent: yeah i'm more concerned (right now anyway) on the subunit parser thing
16:11:36 bauzas efried: others, I found yet another issue with vgpu reshapes...
16:12:02 bauzas efried: others, given we need to recreate mdevs when rebooting, we need to pass allocations when init_host()
16:12:23 bauzas I wrote a bit of comment in the first change, but I'm working on a change that will do this
16:17:20 mdbooth lyarwood: https://review.openstack.org/#/c/623489/
16:17:39 mdbooth lyarwood: Just looking at the unit tests, but feel free to consider ^^^ anyway.
16:20:59 lyarwood mdbooth: ack and ack looking
16:24:41 kashyap BTW, sean-k-mooney: thanks for inadvertently reminding that this is a pending item a few weeks ago! Almost lost track of it: https://review.openstack.org/#/c/632507
16:26:07 sean-k-mooney kashyap oh the libvirt version bump ya
16:31:08 openstackgerrit Sylvain Bauza proposed openstack/nova master: libvirt: implement reshaper for vgpu https://review.openstack.org/599208
16:31:08 openstackgerrit Sylvain Bauza proposed openstack/nova master: Add functional test for libvirt vgpu reshape https://review.openstack.org/631559
16:56:46 sean-k-mooney so are we still going ahead with https://review.openstack.org/#/c/634949/ since the cinder volume test in tempest-full are continuosly failing.
16:59:35 mriedem what cinder volume tests?
17:00:39 mriedem we did do https://review.openstack.org/#/c/634970/ to hopefully help with the tooz connection errors
17:01:08 sean-k-mooney tempest.api.compute.volumes.test_attach_volume_negative.AttachVolumeNegativeTest.test_attach_attached_volume_to_same_server
17:02:08 sean-k-mooney i dont know if it sthe same two but i have notice 1-2 cinder volume attachment test filaing in a few reivews i looked at recently
17:03:09 sean-k-mooney usually either with a timeout or sometime with Invalid volue errors
17:03:16 sean-k-mooney like http://logs.openstack.org/15/620115/23/check/tempest-full/fcabb4b/testr_results.html.gz
17:03:35 smcginnis mriedem: I haven't noticed that tooz issue anymore. Have you seen any since that change?
17:04:44 mriedem smcginnis: http://status.openstack.org/elastic-recheck/#1810526
17:05:04 mriedem those could be stable branches, checking logstash
17:05:57 smcginnis Grenade on the first one, so maybe?
17:06:04 mriedem sean-k-mooney: you hit a nova bug http://logs.openstack.org/15/620115/23/check/tempest-full/fcabb4b/controller/logs/screen-n-cpu.txt.gz?level=TRACE#_Feb_19_14_49_49_277325
17:06:17 mriedem http://status.openstack.org/elastic-recheck/#1770211
17:06:25 mriedem WARNING nova.virt.block_device [None req-2c3d004a-05e7-43d3-af5e-ccac75bed5fd tempest-AttachVolumeNegativeTest-1375016298 tempest-AttachVolumeNegativeTest-1375016298] [instance: 4b50efcf-0d26-4b01-91f0-1b8b1e9eef0f] Guest refused to detach volume aea37477-6c0c-4727-8092-da3b3d2f7c5c: DeviceDetachFailed: Device detach failed for vdb: Unable to detach the device from the live config.
17:06:45 mriedem i remember cfriesen asking about this still being an issue the other day
17:07:08 mriedem smcginnis: yeah looks like it's hitting on grenade so it's just a stable branch issue with devstack at this poin,
17:07:09 mriedem *point
17:07:10 dansmith mriedem: I saw a ping from you fly by from last night.. can you link me again so I don't have to dig out mah logs?
17:07:16 mriedem i'll work on backporting those devstack / etcd changes
17:07:33 mriedem dansmith: https://review.openstack.org/#/c/635315/1
17:10:20 dansmith mriedem: nice
17:11:18 cfriesen mriedem: smcginnis: I was hitting this:https://bugs.launchpad.net/nova/+bug/1815949
17:11:19 openstack Launchpad bug 1815949 in OpenStack Compute (nova) "missing special-case libvirt exception during device detach" [Medium,Confirmed]
17:11:39 smcginnis Hmm, that's a new one to me.
17:12:02 sean-k-mooney ok ya that makes sense. im pretty sure there are other voluem attachemtn failures like https://bugs.launchpad.net/cinder/+bug/1814916 too which are unrelated to tooz
17:12:03 mriedem cfriesen: ok that looks different than the 'unable to detach from transient / live config'
17:12:04 openstack Launchpad bug 1814916 in Cinder "MessagingTimeout in cinder-api during volume attachment update due to VolumeAttachmentNotFound in cinder-volume" [Medium,Confirmed]
17:12:19 mriedem yeah i don't know what's up with that volume attachment not found one
17:12:31 mriedem the api finds the record and then c-vol blows up b/c it's gone from the db, so clearly a race somewhere
17:12:57 mriedem probably just need someone to trace requests in a log to see when the PUT request is made and when the DELETE request is made
17:12:57 cfriesen mriedem: smcginnis: but after fixing that I'm hitting the "Guest refused to detach" issue. I'm guessing it's related to stalls we're seeing in the guest, but still digging into causes.
17:14:26 openstackgerrit Adam Spiers proposed openstack/nova master: WIP: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498
17:15:11 aspiers mriedem, efried: I've just finished the first version of the tests which were missing for capabilities to traits: https://review.openstack.org/#/c/538498/12/nova/tests/functional/test_servers.py
17:15:28 mriedem etcd changes for devstack backported https://review.openstack.org/#/q/topic:bug/1810526+(status:open+OR+status:merged)
17:15:43 aspiers mriedem, efried: I'm sure you'll find plenty of things to improve, but hopefully this is a good base
17:16:21 aspiers not sure if I went overkill on the tests for standard vs. custom traits, and capabilities vs. update_provider_tree
17:22:42 aspiers mriedem: BTW I kept you as the author and added myself via Co-Authored-By - was that the right thing to do?
17:22:51 aspiers not sure what the convention is here
17:24:18 mriedem aspiers: yup
17:24:28 mriedem more testing > less testing
17:24:50 aspiers mriedem: also, should I put "related to blueprint expose-host-capabilities" in the commit message?
17:32:48 mriedem hmm, that's not approved https://blueprints.launchpad.net/nova/+spec/expose-host-capabilities but the change is essentially trying to solve that same problem
17:32:50 mriedem so sure
17:33:26 mriedem the spec for that bp predates traits https://review.openstack.org/#/c/222200/
17:33:35 mriedem so it was trying to solve it with something different
17:43:32 sean-k-mooney adrianc: o/ are you wokring on a new version of https://review.openstack.org/#/c/620115/
17:44:05 sean-k-mooney adrianc: if not i might start adressing stephenfin nits after i get something to eat.
17:54:27 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance to make place for port healing https://review.openstack.org/637953
17:54:28 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance (2) https://review.openstack.org/637954
17:54:28 openstackgerrit Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.openstack.org/637955
18:09:22 melwitt mriedem: omg, thank you. I was completely baffled by the 0'ed out instance uuid and could not imagine how that could happen
18:12:20 melwitt alex_xu: by unrelated, I meant that project_only=True isn't related to the instance target. the only thing that project_only=True does is enforce the request context project, not the instance project. so I was thinking that changing to use instance target is an unrelated change from removing project_only=True. if we remove project_only=True without changing instance target, we get the same behavior as today except that users choose to
18:12:20 melwitt enforce request context project via policy instead of hard-coded
18:16:36 efried aspiers: Still around?

Earlier   Later