| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-07 | |||
| 11:44:31 | asettle_ | Give me the afternoon to poke around :) I just gotta scoot out for lunch before afternoon meetings | |
| 12:05:03 | sdague | stephenfin / asettle_ another one of those subpages is here - https://review.openstack.org/#/c/490994/ | |
| 12:05:23 | sdague | I think I pushed that after you all had kicked off for the weekend | |
| 12:24:14 | stephenfin | sdague: done | |
| 12:24:56 | openstackgerrit | Stephen Finucane proposed openstack/python-novaclient master: tools: Remove dead script https://review.openstack.org/480138 | |
| 12:26:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tools/xenserver: Remove 'cleanup_sm_locks' https://review.openstack.org/416520 | |
| 12:27:43 | stephenfin | Couple of trivial "remove dead files" patches here, were anyone looking for easy +2s https://review.openstack.org/#/q/topic:trivial+owner:%22Stephen+Finucane+%253Cstephenfin%2540redhat.com%253E%22+status:open | |
| 12:34:40 | cdent | jaypipes: your hip/back/whatever any better? | |
| 12:41:21 | maciejjozefczyk | Hello, im trying to create own periodic task outside upstream nova code (like nova.compute.manager tasks). Shouldn't it be registered the way like custom nova scheduler filters are ( option scheduler_available_filters in nova.conf)? Is it even possible to use both custom and generic periodic tasks in compute manager? | |
| 12:48:04 | cdent | stephenfin: do you consider https://review.openstack.org/#/c/490952/ done now? It’s sort of hard to tell/know and review other than “sure, lgtm” | |
| 12:50:22 | bauzas | gibi: looking | |
| 12:54:32 | bauzas | cdent: cdent: just to make sure, the -1s are about comments, right? | |
| 12:55:09 | cdent | bauzas: yes, as I tried to say on the comment: the code fix looks right, but the comments are misleading enough that they ought to be fixed | |
| 12:55:17 | bauzas | cdent: okay | |
| 12:55:48 | bauzas | cdent: tbc, we still need to use the ReqSpec record in case we don't have the instance list | |
| 12:56:02 | cdent | yes, that’s what my rewrite says | |
| 13:05:05 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Fix migrate single instance when it was created concurrently https://review.openstack.org/491439 | |
| 13:08:29 | jaypipes | cdent: yes, it is, thanks for asking. :) | |
| 13:09:05 | jaypipes | cdent: well, you might still have to shoot me, just not for that. | |
| 13:09:21 | cdent | have you seen our new exciting bug(s) for today? | |
| 13:09:39 | cdent | bauzas already fixed it, but it gives me dread | |
| 13:09:44 | jaypipes | cdent: the resize big flavor one from gibi? | |
| 13:10:01 | cdent | jaypipes: no, https://bugs.launchpad.net/nova/+bug/1708961 | |
| 13:10:02 | openstack | Launchpad bug 1708961 in OpenStack Compute (nova) "migration of single instance from multi-instance request spec fails with IndexError" [Critical,In progress] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 13:10:18 | cdent | I started doing some by hand testing over the weekend, bumped into that | |
| 13:10:45 | jaypipes | cdent: eww. :( | |
| 13:11:00 | cdent | jaypipes: also bumped up against this question (not quite a bug, but an issue) https://bugs.launchpad.net/nova/+bug/1708958 | |
| 13:11:00 | openstack | Launchpad bug 1708958 in OpenStack Compute (nova) "disabling a compute service does not disable the resource provider" [Low,Confirmed] | |
| 13:11:50 | jaypipes | cdent: that's definitely not a bug. and frankly, we cover that in the scheduler's integration with the "service group API". | |
| 13:11:58 | bauzas | jaypipes: remember the discussion we had in the review about being conservative with num_instances ? then, kaboom. :) | |
| 13:12:07 | cdent | jaypipes: it’s not a bug for nova | |
| 13:12:28 | jaypipes | cdent: hold up, I have a senior pug wandering around looking suspiciously prone to going the bathrooom.. | |
| 13:12:32 | bauzas | jaypipes: about the compute disabling, like I said in the comment, we have ComputeFilter for this | |
| 13:12:43 | jaypipes | fuck. too late. | |
| 13:12:46 | cdent | jaypipes: but it implies a reality mismatch between available resources | |
| 13:12:48 | cdent | :( | |
| 13:13:13 | bauzas | jaypipes: but we could possibly reduce the number of passed RPs to the scheduler if we have a way to know if the RP is stale | |
| 13:13:27 | bauzas | so, like 50% a bug, and 50% a feature to me | |
| 13:13:55 | bauzas | cdent: actually, pushing the bug to Wishlist | |
| 13:14:56 | cdent | bauzas: that’s fine with me, it was mostly me fishing for information on how we expect things to be represented. that it is not currently breaking anything is groovy | |
| 13:15:40 | jaypipes | cdent, bauzas: sorry, back from picking up poop :( | |
| 13:15:52 | jaypipes | cdent, bauzas: lemme discuss one thing at a time. | |
| 13:15:54 | asettle_ | THanks sdague - looking now | |
| 13:15:59 | cdent | same day different poop | |
| 13:16:07 | bauzas | cdent: I'm fine too, I'm just putting it to Wishlist to make sure we remember it | |
| 13:16:39 | bauzas | jaypipes: hah, fortunately for you that's a pug poop :) | |
| 13:17:08 | jaypipes | bauzas: well, it is diarrhea this morning since 5:45am. | |
| 13:17:29 | jaypipes | anyway, enough about poop. | |
| 13:17:46 | jaypipes | cdent, bauzas: so, which bug to discuss first? | |
| 13:17:48 | bauzas | jaypipes: arf | |
| 13:18:03 | cdent | jaypipes of the two I mentioned, I think we’re done already | |
| 13:18:03 | bauzas | jaypipes: honestly, just the critical one bug | |
| 13:18:14 | cdent | 1st is fixed, 2nd is not immediately relevant | |
| 13:18:18 | bauzas | +1 | |
| 13:19:22 | cdent | the implication, however, of the 1st, matt’s comments about summing instead of maxing, and some of alex comments about evacuate, suggests we have a bit more work todo to nail it all down | |
| 13:19:25 | cdent | but progress is being made | |
| 13:20:49 | jaypipes | cdent: ya. | |
| 13:30:11 | edleafe | Scheduler subteam meeting in 30 minutes in #openstack-meeting-alt | |
| 13:30:23 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Raise NoValidHost if no allocation candidates https://review.openstack.org/491491 | |
| 13:31:26 | gibi | cdent, jaypipes, bauzas: my naive bugfix for the bug 1708637 | |
| 13:31:28 | openstack | bug 1708637 in OpenStack Compute (nova) "nova does not properly claim resources when server resized to a too big flavor" [High,In progress] https://launchpad.net/bugs/1708637 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 13:31:44 | gibi | cdent, jaypipes, bauzas: https://review.openstack.org/491491 | |
| 13:31:53 | bauzas | gibi: looking | |
| 13:34:27 | bauzas | gibi: unfortunately, that won't work | |
| 13:34:43 | bauzas | gibi: just one word : CachingScheduler (actually, two) | |
| 13:35:15 | bauzas | oh, fuck, nevermind | |
| 13:35:16 | gibi | bauzas: I might need more words than two to understand the reason | |
| 13:35:36 | bauzas | we're already under the USES_ALLOC_CANDIDATES conditional | |
| 13:35:53 | bauzas | gibi: CachingScheduler isn't using Placement | |
| 13:36:15 | bauzas | gibi: but on the other hand, it still runs the legacy filters | |
| 13:36:51 | bauzas | but like I said, we're under the conditional that asserts us that we already use placement | |
| 13:37:00 | gibi | OK, I think I see | |
| 13:37:21 | gibi | but then CoreFilter is still needed for the CachingScheduler. isn't it? | |
| 13:39:55 | bauzas | correct | |
| 13:40:05 | bauzas | well, if of course the operator wants it | |
| 13:40:15 | bauzas | any filter can be disabled | |
| 13:40:18 | gibi | sure | |
| 13:40:35 | gibi | it just mean an infinite overallocation on such resource | |
| 13:41:54 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Raise NoValidHost if no allocation candidates https://review.openstack.org/491491 | |
| 13:42:28 | jaypipes | gibi: did you run all the func tests for that patch? | |
| 13:42:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Raise NoValidHost if no allocation candidates https://review.openstack.org/491491 | |
| 13:44:03 | gibi | jaypipes: yes, I did and passed for me | |
| 13:44:15 | gibi | jaypipes: most of the functional tests using CachingScheduler as far as I know | |
| 13:44:31 | jaypipes | gibi: really? I don't think so... | |
| 13:46:04 | gibi | jaypipes: hm, my bad, it is the ChanceScheduler not the CacheScheduler | |
| 13:46:29 | gibi | s/CacheScheduler/CachingScheduler/ | |
| 13:46:30 | jaypipes | gibi: if that's the case, that's a very serious bug in our functional tests. | |
| 13:46:39 | cdent | the PlacementFixture was turned on functional test-wide recently | |
| 13:46:56 | gibi | jaypipes: I'm trying to find the place it is set... | |
| 13:46:56 | cdent | sorry, meant to add a ? on that ^ | |
| 13:47:01 | jaypipes | gibi: the ChanceScheduler is worthless. | |
| 13:49:42 | bauzas | jaypipes: people use chancescheduler for very simple functional tests involving the scheduler | |
| 13:49:54 | bauzas | only a very few use filterscheduler | |
| 13:51:58 | jaypipes | bauzas: since chance scheduler doesn't use placement, that's a mistake IMHO. | |
| 13:52:26 | jaypipes | we're not covering a large portion of our functional tests for no good reason. | |
| 13:53:22 | bauzas | jaypipes: if we run only one compute and want to boot one instance, why should we run filterscheduler and placement ? | |
| 13:53:22 | gibi | bauzas: do you know where the ChanceScheduler is set in the functional test env? | |
| 13:53:45 | bauzas | gibi: just look at self.flags(driver='chance_scheduler', group='scheduler') | |
| 13:53:45 | jaypipes | bauzas: because placement is now required. | |
| 13:54:34 | jaypipes | bauzas: we will never be able to get rid of the code in the compute node that does "claiming" if the chance scheduler is allowed to keep on existing. same for caching scheduler, frankly. | |