Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-17
15:18:21 melwitt leakypipes: oh, hm, lemme check again
15:18:32 edmondsw mriedem_afk ^ I was tagging mriedem...
15:19:29 melwitt leakypipes: you didn't reply on that, the last reply I see from you was about the lack of a parent-child relationship of the tables
15:19:51 leakypipes doh, melwitt it was a draft comment never submitted... fuug
15:20:55 edleafe kashyap: yes, I checked, and they were exactly as you said
15:21:02 edleafe oops, my manners
15:22:54 melwitt leakypipes: a-ha!
15:25:40 johnthetubaguy melwitt: yeah, I was trying to remember what I mean in there too
15:25:52 melwitt heh :)
15:26:35 johnthetubaguy melwitt: I think it was fine before, just trying to remember what I was worried before
15:42:17 openstackgerrit Thomas Stewart proposed openstack/nova master: Add lan9118 as valid nic for hw_vif_model property for qemu https://review.openstack.org/393489
15:45:32 jsheeren hi all
15:46:25 jsheeren i'm seeing this in my nova-compute log since today: INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Socket close
15:46:48 jsheeren the nova-compute service get's marked down by the controllers for a minute or two, then it recovers
15:46:56 jsheeren has anyone seen this behaviour before,
15:46:57 jsheeren ?
15:48:20 leakypipes mhenkel: looks like you still need to address those unit test failures, though. let us know if you need assistance.
15:50:48 sneti johnthetubaguy, I've updated the base patch for policy. can you please check this: https://review.openstack.org/#/c/434842/
15:52:54 mriedem superdan: some easy test fixups in https://review.openstack.org/#/c/447009/
15:53:07 efried mriedem (aka Swamp Thing) your influence has spread: https://review.openstack.org/#/c/445667/2/nova_powervm/tests/virt/powervm/volume/test_iscsi.py@53
15:53:13 mriedem superdan: our next release of novaclient is going to be a major version bump, so we'll want to backport that bug fix to stable/ocata
15:54:06 mriedem efried: cool
15:54:33 mriedem superdan: but then after the bug fix i think we should just remove those deprecated arguments
15:54:50 efried mriedem BTW, yesterday I looked through nova-powervm to see what it would take to retrofit the whole project accordingly. Yeeeaaaahhh, prolly not gonna do that wholesale any time soon.
15:55:12 mriedem retrofit for what? autospec?
15:55:15 efried yeah.
15:55:27 efried But at least we can implement it moving forward.
15:55:40 efried And the in-tree driver will be clean.
15:55:56 mriedem warning on autospec, claudiub has experience with that https://review.openstack.org/#/c/339232/
15:56:01 mriedem it does take a performance hit on the test run
15:56:19 superdan mriedem: I guess I missed the point at which we started having stable branches for clients
15:56:25 mriedem superdan: years ago
15:56:48 mriedem so we could backport the fix to ocata and release 7.1.1
15:56:52 efried That's interesting - the docs on autospec claim it's lazy out of the box.
15:56:59 superdan mriedem: regardless of when, I guess I missed it
15:57:02 mriedem so your customer can pick that up w/o the backward incompatible changes that will be in 8.0.0 in pike
15:57:45 mriedem we needed stable branches on all of the clients and libraries just to get fixes back, plus we needed it at times to unscrew the gate back before upper-constraints
15:59:16 claudiub ooh, autospec
15:59:20 claudiub i'm actually working on it
15:59:29 claudiub I want it to become a permanent thingy
16:00:05 claudiub mriedem: something like this should do the trick: https://github.com/testing-cabal/mock/pull/394
16:00:33 claudiub there's still an issue with mock.patch autospecing, on which i'm working on.
16:00:53 mriedem cool
16:01:38 efried claudiub Second sentence here claims it's already lazy: https://docs.python.org/3/library/unittest.mock.html#autospeccing
16:02:02 efried claudiub So you've discovered that's a false claim under certain conditions?
16:02:21 claudiub it is a false claim. :)
16:02:42 claudiub efried: https://github.com/testing-cabal/mock/issues/393
16:02:45 efried claudiub Down a page or so, more explicitly: "Because the speccing is done “lazily” (the spec is created as attributes on the mock are accessed) you can use it with very complex or deeply nested objects (like modules that import modules that import modules) without a big performance hit."
16:02:55 efried Imagine my disappointment.
16:03:12 claudiub i know, right? :)
16:04:04 claudiub anyways, the only thing that specing / autospecing does at the moment, is ensure that your mock only have the same attributes / members as the spec itself, raising an AttributeError if non-existent attributes are accesed.
16:04:11 claudiub so, there's at least that.
16:04:19 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Move detach logic from manager into driver BDM https://review.openstack.org/439520
16:04:19 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Only destroy BDMs after successful detach call https://review.openstack.org/440693
16:04:32 efried claudiub That issue doesn't look related to performance/laziness
16:04:33 lyarwood mdbooth: ^ remove_volume_connection behaviour should remain the same now
16:05:05 melwitt claudiub, efried: well, it's expensive when you go and autospec every possible attribute, which is what you're doing right?
16:05:07 claudiub efried: but, you can give my PR i've linked above a try. it fixes this issue. check the added unit tests. There are still some unit tests failing for pypy, because the unittests themselves are faulty.
16:05:13 mdbooth lyarwood: Thanks, will look.
16:05:50 claudiub melwitt: actually, the way mock works, is create a child mock when a mock's attrbute is accessed, and it wasn't accessed before, and then caches it.
16:06:25 claudiub so, what I've done, is ensure that that child mock is properly spec'ed when created.
16:06:45 claudiub so, it won't autospec everything, it will only autospec accessed attributes / methods.
16:07:41 melwitt claudiub: okay, but you don't use every child mock in every test, right? or did you only spec the childs that are going to be asserted in tests?
16:08:40 openstackgerrit Dan Smith proposed openstack/python-novaclient master: Fix aggregate_update name and availability_zone clash https://review.openstack.org/447009
16:09:01 claudiub right, only spec the childs that are going to be asserted in the tests.
16:10:18 claudiub anyways. will try out some new experiments on nova with mock autospecs. will see then the performance impact.
16:11:17 claudiub and if it's a reasonable impact, autospecs should be used pretty much everywhere in openstack. :)
16:11:31 melwitt okay, cool
16:11:50 cfriesen so going back to the issue I raised yesterday about RPC timeouts during live migration waiting for large images to download from glance to the compute node...is this just a case of "we don't support that"?
16:12:02 mriedem cfriesen: did you see my reply?
16:12:57 cfriesen mriedem: yes, though that was dealing with a service token. in my case it's an RPC timeout that's the issue, not authentication
16:13:20 cfriesen if it takes more than 60 seconds to download the glance image, pre_live_migration() times out
16:13:51 figleaf cdent: regarding https://review.openstack.org/#/c/427309 - it seems like you are also doing a lot of stuff manually, like telling RT to update usages, etc. Do you think it would be possible to more directly simulate the actual processes in order to ensure that the right code paths get executed?
16:13:58 mriedem cfriesen: ok so https://docs.openstack.org/developer/nova/api_microversion_history.html#id31 won't help
16:14:16 openstackgerrit Dan Smith proposed openstack/python-novaclient master: Fix aggregate_update name and availability_zone clash https://review.openstack.org/447009
16:14:21 cfriesen mriedem: nope.
16:14:22 mriedem cfriesen: i'd ask tdurakov,
16:14:23 cburgess cfriesen Worse if *anything* takes more then 60 seconds. lets says you have an instance with 10 volumes all using iscsi + multipath, that can take 2 or 3 minutes to build all the luns.
16:14:52 mriedem i'd think that we could make conductor rpc cast to the compute to do pre-live migration, and have the compute cast back to conductor when it's done
16:15:38 cburgess mriedem That might work. The problem right now is we have to set the RPC timeout to a very large value, like 5-10 minutes in some AZs to work around this. Honestly I would like to see that become async like you just described or have a seperate timeout for just that operation.
16:15:44 cdent figleaf: my intent was to start narrow and then get more broad
16:16:08 figleaf cdent: understood, but it feels sorta unit test-y
16:16:31 mriedem cburgess: i'd have to dig into the oslo.messaging internals to find out how easy it is to adjust the rpc timeout on the fly like that for a single operation
16:16:43 cfriesen mriedem: it's easy
16:16:47 cburgess mriedem Just pass it as an arg
16:17:01 cburgess I think we might have to expand one nova wrapper class to support the arg but otherwise its just an arg to the call to change the timeout for that specific call.
16:17:32 cfriesen mriedem: but the thing is that you don't necessarily know up front what a reasonable value is since it depends on the IO load on your computes and glance-api
16:17:46 cfriesen and other stuff like cburgess pointed out
16:17:56 cburgess mriedem cfriesen But a change to have conductor/compute cast to/from each other and simply take action once the call comes in rather then waiting on it and forcing it to take some fixed amount of time is a way way better solution.
16:18:23 cburgess cfriesen Right... which is why I think moving everything to cast calls to/from conductor is way better.
16:18:31 cfriesen cburgess: mriedem: agreed...would we need to change the handling of the overall migration completion timeout? (checking code)
16:18:56 cburgess cfriesen Not sure if that timer starts during pre flight.
16:19:07 mriedem the timer is while it's moving data right?
16:19:14 cfriesen cburgess: mriedem: looks like the migration completion timeout is just a libvirt thing
16:19:15 mriedem to kill it if it gets stuck
16:19:17 cburgess mriedem I thought that timer was going away?
16:19:23 mriedem cburgess: i believe it is
16:19:27 cfriesen cburgess: the progress timer is going away
16:19:31 mriedem johnthetubaguy and the osic fok are looking at that
16:19:32 cburgess Ahhh

Earlier   Later