| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-29 | |||
| 18:45:37 | mriedem | yeah ocata | |
| 18:45:44 | superdan | didn't work at all really | |
| 18:45:49 | mriedem | before that i think there were some random foreign key constraints that could mess it up for totally completing | |
| 18:45:57 | mriedem | plus you had to always specify the batch number | |
| 18:46:33 | cburgess | RAD... | |
| 18:46:50 | cburgess | So.. not as sad a panda as I was before, still work for me to do. Thanks. | |
| 18:47:20 | mriedem | also https://review.openstack.org/#/q/I77255c77780f0c2b99d59a9c20adecc85335bb18 | |
| 18:47:29 | mriedem | so going back to mitaka i think you can delete everything in batches | |
| 18:47:31 | mriedem | per dan's fix | |
| 18:48:46 | cburgess | Cool. | |
| 18:49:05 | cburgess | I doubt I'm going to enjoy backporting this to Icehouse. *sigh* | |
| 18:49:30 | melwitt | icehouse? ouch | |
| 18:49:42 | cburgess | melwitt Don't judge.... ok well judge. | |
| 18:50:01 | melwitt | not judging, just imagining the pain | |
| 18:50:08 | mriedem | cburgess: i expect it's actually not bad | |
| 18:50:14 | mriedem | since that code is isolated | |
| 18:50:21 | mriedem | and not a lot of changes over time | |
| 18:50:27 | melwitt | that reminds me, I wanted to resurrect my old patch to turn on FK constraint enforcement to sqlite | |
| 18:50:44 | cburgess | melwitt My world is pain.. nothing but pain. I'm a purveyor of fine vintage clouds (actually I purvey new ones, but I have to support vintage ones). | |
| 18:50:52 | melwitt | hah | |
| 18:52:52 | openstackgerrit | melanie witt proposed openstack/nova master: Make setenv consistent for functional and api_samples https://review.openstack.org/507976 | |
| 18:54:36 | openstackgerrit | melanie witt proposed openstack/nova master: Make setenv consistent for functional and api-samples https://review.openstack.org/507976 | |
| 18:57:51 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Add a regression test for bug 1718455 https://review.openstack.org/508590 | |
| 18:57:53 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Ensure instance can migrate when launched concurrently https://review.openstack.org/508591 | |
| 18:57:53 | openstack | bug 1718455 in OpenStack Compute (nova) "[pike] Nova host disable and Live Migrate all instances fail." [Medium,In progress] https://launchpad.net/bugs/1718455 - Assigned to Matt Riedemann (mriedem) | |
| 19:09:18 | mriedem | superdan: dead code now right? https://github.com/openstack/nova/blob/ae4b5d0147cb3e345bf57034221e9c8fedf3cad2/nova/conductor/manager.py#L261 | |
| 19:09:28 | mriedem | oh nvm | |
| 19:09:30 | mriedem | we're at 1.17 | |
| 19:09:44 | superdan | right | |
| 19:09:50 | superdan | we never bumped | |
| 19:10:10 | mriedem | we should remember to do that this release, across the board | |
| 19:10:11 | mriedem | we're due | |
| 19:10:27 | mriedem | and by we i mean you, because i'd just mess it up | |
| 19:11:30 | superdan | heh | |
| 19:16:12 | openstackgerrit | Dan Smith proposed openstack/nova master: Merge build requests into the sortmaster 9000 https://review.openstack.org/508595 | |
| 19:16:34 | superdan | mriedem: ^ probably needs a few more test cases, but you love pointing those out so I'll indulge you | |
| 19:17:11 | superdan | I'm trying to decide if I should parallelize fetching the buildrequests as well, to try to further lower the latency | |
| 19:17:31 | superdan | it'd be hard to prove that is worth it though, since it's hard to have many instances in that state for long without bugs | |
| 19:18:05 | mriedem | i'm currently doing a review of https://review.openstack.org/#/c/498948/ before it merges | |
| 19:18:28 | superdan | another favorite pasttime of yours | |
| 19:18:31 | mriedem | yeah the only way to do that really is via fixtures, to hold up the build requests | |
| 19:18:50 | superdan | well, I meant in a devstack type environment, but yeah | |
| 19:19:06 | mriedem | yeah i'm not sure how you'd reliably test that | |
| 19:19:18 | superdan | that's my point yeah | |
| 19:19:25 | mriedem | unless you booted so many at once, and scheduling was slow enough, that you could see a difference | |
| 19:19:33 | superdan | and probably not much gain for people | |
| 19:19:47 | mriedem | single node devstack is probably not going to work there | |
| 19:19:52 | mriedem | you'd have to fake out like 1000 computes or something | |
| 19:19:56 | mriedem | something that placement has to chew on | |
| 19:20:13 | superdan | nah, just shut down scheduler so we block on making that decision and then try to list before the timeout | |
| 19:20:17 | superdan | but still, not great | |
| 19:21:33 | mriedem | true, set the rpc timeout to 10 minutes :) | |
| 19:22:22 | superdan | the problem is, because we don't have real threads, we're already pegging the cpu just processing the results from the DBs as it is, so, not likely the even smaller overlap of operations is really going to help | |
| 19:22:42 | melwitt | how can we get real threads | |
| 19:23:06 | superdan | I'm not sure eventlet is threadsafe, so I'm not sure we can without bigger changes | |
| 19:23:39 | superdan | that was the problem with us using real threads for db workers ages ago, and it was never fixed, AFAIK, we just worked around it by moving to an all-python db driver | |
| 19:24:34 | superdan | in aggregate it's not as big of a deal because multiple requests will be running at once in our workers, so more overall work gets done with more cores, just not in a single-request sort of environment | |
| 19:25:00 | superdan | any environment that only has one concurrent request ever is either (a) dan's test box or (b) probably not worried about listing thousands of instances at a time :) | |
| 19:25:15 | melwitt | heh | |
| 19:29:06 | mriedem | superdan: some comments/questions in https://review.openstack.org/#/c/498948/ | |
| 19:29:27 | openstackgerrit | priyaduggirala proposed openstack/nova master: Rename parameters in call() of nova/image/glance.py https://review.openstack.org/508533 | |
| 19:29:33 | mriedem | not trying to block, just want to make sure i know what's going on with this stuff before it merges and i'm lost later | |
| 19:31:57 | superdan | mriedem: I thought we didn't do _LI( but we don't do _( at all anymore? | |
| 19:32:13 | mriedem | we don't translate log messages at all anymore | |
| 19:32:21 | superdan | really thought I was getting pep8 fails | |
| 19:32:31 | superdan | christ, I can never keep it straight | |
| 19:33:53 | mriedem | https://docs.openstack.org/oslo.i18n/latest/user/guidelines.html | |
| 19:34:02 | mriedem | i think that top paragraph is the new guideline | |
| 19:34:24 | mriedem | and https://docs.openstack.org/oslo.i18n/latest/user/guidelines.html#log-translation | |
| 19:37:17 | superdan | I believe you, I just can't keep track of it | |
| 19:37:51 | mriedem | i had to look it up too, wasn't sure about _() when you asked but was pretty sure | |
| 19:38:40 | superdan | I figure if I just pick some behavior I'll be right 20% of the time when we've circled back to that as the preferred one | |
| 19:39:10 | mriedem | depends on the current ibm corporate wide software guidelines at the time | |
| 19:39:43 | superdan | mriedem: so, this isn't in the gate yet so do you want me to fix the bottom patch or tack on to the end? this set is pretty fragile so if I do the bottom it'll likely percolate awesomeness up the stack pretty good | |
| 19:39:53 | superdan | and by "awesomeness" I mean "my tears" | |
| 19:40:16 | mriedem | was there anything major? the translation markers and simple logging stuff, plus docstring or whatever can all be done at the end | |
| 19:40:23 | mriedem | there was the one conditional block that i thought was dead code | |
| 19:40:43 | superdan | the else? | |
| 19:40:48 | superdan | the comment was just incorrect | |
| 19:40:52 | mriedem | oh | |
| 19:41:13 | mriedem | the bottom 2 are approved so i'd say just take a fixup change at the end of the series | |
| 19:41:38 | superdan | I really should just remove "on the source" from that one since it'll be used any time we need to revert the allocation regardless of why/where | |
| 19:42:13 | mriedem | the thing i wanted to be cautious of was overusing it like remove_provider_from_instance_allocation in the scheduler report client, | |
| 19:42:23 | mriedem | because remove_provider_from_instance_allocation was written really for cold migrate / resize + resize to same host, | |
| 19:42:41 | mriedem | but we've used it for other move operations, and there are some assumptions in there which don't always work for other move operatoins | |
| 19:42:49 | mriedem | i.e. | |
| 19:42:50 | mriedem | # allocation with our part subtracted | |
| 19:42:50 | mriedem | # are the only provider then we need to merge back in the doubled | |
| 19:42:50 | mriedem | # NOTE(danms): We are in a resize to same host scenario. Since we | |
| 19:43:05 | superdan | well, this really should apply to all of the types once we get it done because same/different, cold/live, they're all the same process since we don't have to worry about clashes since the migration uuid holds things | |
| 19:43:16 | mriedem | if so, | |
| 19:43:30 | mriedem | then heed my warning about assuming migration.source_node is set | |
| 19:43:32 | mriedem | HEED IT | |
| 19:43:44 | mriedem | because we don't even attempt to set that shit for live migration | |
| 19:43:45 | superdan | yeah, I saw, I need to go look | |
| 19:43:46 | mriedem | since there is no claim | |
| 19:43:56 | superdan | because I thought it was set there too | |
| 19:44:05 | mriedem | _live_migrate in conductor task manager | |
| 19:44:16 | mriedem | we set the compute attributes, but not the node ones | |
| 19:44:23 | mriedem | was just looking at using those yesterday for something else | |