Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-17
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
16:19:33 mriedem *folk
16:19:58 johnthetubaguy sorry, I missed all that chat there
16:20:11 cburgess johnthetubaguy Welcome to the party!
16:20:38 cburgess johnthetubaguy Wait its after 4PM on a Friday there... why are you at the pub?
16:20:47 cburgess Sorry why aren't you
16:20:47 cfriesen my concern about just moving to cast is that if one of those gets lost we're stuck with a migration in progress
16:20:59 cburgess cfriesen Yes thats the rub.
16:21:02 johnthetubaguy heh, I am around for a few hours yet
16:21:17 johnthetubaguy got band rehersal before I get close to a pub anyways!
16:21:20 cburgess cfriesen We would have to be able to cancel it. Could the migration records accomplish that?
16:21:24 cdent figleaf I think that's inevitable unless we want solely use the external interface of the compute manager (which might be fine), but even with there would still need to be something to causing the period job to run, and to call the external interface
16:21:29 mriedem cfriesen: cburgess: so i just looked at oslo.messaging, and yeah it looks trivial to pass a new timeout in when constructing the client
16:21:42 cfriesen I wonder if the existing live migration abort API would be sufficient
16:21:59 figleaf cdent: yeah, I guess I'm just too idealistic :)
16:21:59 cburgess mriedem I don't even think you have to do it when constructing the client. I think with an existing client its just an arg you can pass on call.
16:22:05 johnthetubaguy mriedem: I thought that was a per call thing we can tweak?
16:22:14 mriedem cburgess: oh that's even better b/c we cache the clients
16:22:21 johnthetubaguy yeah, what cburgess said
16:22:22 cdent figleaf: no, you just are trying to apply principles that might work elsewhere, here
16:22:34 cburgess cfriesen Right thats what I'm thinking. If we know the state is "we made the cast to run pre live migration" then we should be able to cancel that by making the right call to abort it.
16:22:36 johnthetubaguy cburgess: I am +1 increasing the timeout for the lots of volumes case
16:22:44 figleaf cdent: like I said, too idealistic
16:23:04 superdan mriedem: no caching of the client anymore right?
16:23:09 superdan well, for compute anyway
16:23:23 cburgess johnthetubaguy Some type of equation you thjink? Before call is made look at size of BDM and make some type of auto-adjust? Or just a new config value for pre-live timeout?
16:23:31 cfriesen mriedem: I think there's an example of the per-call timeout in nova/cells/rpcapi.py
16:23:34 superdan well, sometimes in compute actually
16:23:38 johnthetubaguy cburgess: just a large one I think
16:23:51 mriedem yeah i see the timeout kwarg to the client.prepare method
16:23:53 johnthetubaguy cburgess: its only there as a "oh dear, you must have given up" kind of timeout
16:23:58 johnthetubaguy mriedem: yeah, thats the one
16:24:04 cburgess johnthetubaguy Just an arbitrary "This call can suck, wait 10 minutes" type thing?
16:24:11 johnthetubaguy mriedem: I thought we used that already for something, I can't remember now
16:24:13 superdan it'd be nice if we had a per-call heartbeat mechanism,
16:24:17 superdan which o.msg could provide for us
16:24:27 superdan send a "still working" reply to the reply queue which would reset the timer
16:24:29 cburgess johnthetubaguy The timeout would be a stop gap really. I think mriedem and cfriesen idea about moving to cast is the right solution but probably going to take more effort.
16:24:31 johnthetubaguy superdan: thats the "task" framework in my head
16:24:37 cburgess superdan OMG yes
16:24:40 superdan johnthetubaguy: no, I mean something at the o.msg layer
16:24:47 superdan johnthetubaguy: we could solve it in nova with a task too
16:24:50 johnthetubaguy superdan: yeah, check if job is progressing, and you know the owner
16:24:54 mriedem cctxt = self.client.prepare(timeout=timeout)
16:24:54 mriedem arg_p = jsonutils.to_primitive(arg)
16:24:54 mriedem def ping(self, context, arg, timeout=None):
16:24:57 mriedem we do have something using it
16:25:00 superdan but it'd be nice for lots of things if o.msg would heartbeat a particular call
16:25:11 johnthetubaguy superdan: oh I see what you mean now
16:25:29 cfriesen mriedem: you can set it in the client init but also in the cctxt.call()
16:25:32 superdan johnthetubaguy: you could just send something to the reply queue like "this isn't the reply, but I ain't dead yet"
16:25:50 mriedem cfriesen: i don't actually see the timeout kwarg in the rpc client call() method in oslo.messaging
16:25:50 cburgess mriedem cfriesen johnthetubaguy superdan: So 1 bug and 1 spec here? bug = set a "large" timeout for the pre_live call today, spec = move to casting?
16:25:51 johnthetubaguy superdan: yeah, like a "continue" or whatever
16:25:53 mriedem it's in the prepare() method
16:26:18 superdan johnthetubaguy: or lease renewal
16:26:31 mriedem cfriesen: http://git.openstack.org/cgit/openstack/oslo.messaging/tree/oslo_messaging/rpc/client.py#n178
16:26:45 mriedem cfriesen: call() doesn't use a timeout kwarg http://git.openstack.org/cgit/openstack/oslo.messaging/tree/oslo_messaging/rpc/client.py#n151
16:27:16 cfriesen mriedem: we're using it in nova/cells/rpcapi.py, line 332
16:27:40 johnthetubaguy superdan: yeah, reset the timeout timer
16:27:45 mriedem cfriesen: that looks like a mistake

Earlier   Later