| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-26 | |||
| 15:15:35 | dansmith | we're still talking about restricting the limits to the ones we know about | |
| 15:15:40 | dansmith | we just can't get rid of them just yet | |
| 15:15:43 | jaypipes | dansmith: ok. | |
| 15:16:08 | jaypipes | dansmith: but we're only keeping them for the caching scheduler users, *not* because of out of tree filters. correct? | |
| 15:16:20 | edleafe | dansmith: question: if SchedulerLimits is already part of the reqspec object, why is it needed in the Seleciton object at all? | |
| 15:16:21 | dansmith | jaypipes: that's what his comment is saying | |
| 15:16:26 | jaypipes | dansmith: ok. | |
| 15:16:34 | dansmith | edleafe: because it differs per host | |
| 15:17:06 | dansmith | edleafe: and because we have to pass at least ten copies of limits to the compute node or we lose our heavyweight championship title | |
| 15:18:15 | edleafe | dansmith: more is better! | |
| 15:18:29 | dansmith | obvi | |
| 15:21:13 | jaypipes | dansmith, mriedem: so I'm confused. if the RequestSpec and legacy filter properties are always passed to the compute service during a build operation, and those things contain the limits cruft, why do we want to pass limits information in the Selection object? | |
| 15:21:15 | mriedem | sorry, was trying to cleanup reqspec madness in compute while it's fresh in my mind - sounds like we're all good? | |
| 15:21:28 | mriedem | jaypipes: different limits per alternate | |
| 15:21:33 | dansmith | that ^ | |
| 15:21:36 | jaypipes | mriedem: gah. ok. | |
| 15:21:39 | jaypipes | ack | |
| 15:21:46 | mriedem | plus, the request spec is not passed back to the cell conductor during reschedules, | |
| 15:21:51 | mriedem | so it won't be there for alternates | |
| 15:21:54 | mriedem | i'm just noticing... | |
| 15:22:00 | jaypipes | k, another good point, thanks. | |
| 15:22:11 | mriedem | i'm going to polish some turds this morning | |
| 15:23:46 | mriedem | oh i forgot, | |
| 15:23:49 | mriedem | dansmith: :) | |
| 15:24:02 | mriedem | limits are also passed as a direct kwarg from conductor to compute.build_and_run_instance | |
| 15:24:03 | dansmith | ? | |
| 15:24:09 | mriedem | 1. requestspec.limits | |
| 15:24:14 | mriedem | 2. filterproperties.limits | |
| 15:24:16 | mriedem | 3. direct limits kwarg | |
| 15:24:22 | mriedem | 4. selection.limits | |
| 15:24:24 | dansmith | and once per alternate | |
| 15:24:29 | dansmith | because we rock | |
| 15:24:36 | mriedem | * 4. selection.limits * max_attempts | |
| 15:24:51 | dansmith | actually it's max_attempts +1 I think | |
| 15:24:56 | dansmith | well, maybe not | |
| 15:24:57 | dansmith | whatever | |
| 15:24:59 | dansmith | too fucking many | |
| 15:25:01 | mriedem | i mean seriously, can i just get some limits please | |
| 15:25:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: proper fix for Quobyte CI https://review.openstack.org/515447 | |
| 15:25:08 | mriedem | unlimited ways to get the limits | |
| 15:25:09 | artom_ | kaisers_, still around? | |
| 15:25:10 | dansmith | we should limit our limits | |
| 15:25:31 | mriedem | "nova: blowing up your rpc queue with limits since 2014" | |
| 15:27:46 | efried | mriedem If your req spec turd polishing overlaps with https://review.openstack.org/#/c/515223/2/nova/scheduler/utils.py please let me know. | |
| 15:28:15 | mriedem | right now it doesn't | |
| 15:28:22 | mriedem | just going to try and clean up some things in the compute | |
| 15:28:47 | mriedem | so that maybe by S we can stop passing at least limits and filter_properties down to the compute | |
| 15:29:38 | kaisers_ | artom: yep, few mins | |
| 15:29:46 | kaisers_ | artom: saw the cl | |
| 15:30:54 | kaisers_ | artom: I'll check that out in detail tomorrow | |
| 15:31:48 | artom | kaisers_, aha, thanks! This is very very very preliminary | |
| 15:32:09 | artom | kaisers_, but if we could get a quobyte CI run against that without dynamic_ownership = 0, it would be a first step | |
| 15:32:30 | artom | And ideally a way to recheck, still without dynamic_ownership = 0 | |
| 15:32:51 | kaisers_ | artom: exactly. I'll spin up a manual instance and run tests, etc. | |
| 15:33:21 | kaisers_ | that related to the previous comment... :) | |
| 15:35:24 | kaisers_ | artom: not sure about the automated recheck, I'll comment in the CL | |
| 15:35:35 | artom | kaisers_, fantastic, thanks | |
| 15:36:00 | artom | To be honest it might fail Jenkins CI | |
| 15:36:31 | artom | So maybe wait for that to at least be sure we can still boot generic VMs with that patch ;) | |
| 15:50:42 | mriedem | bauzas: why does RequestSpec._from_hints turn the key=value from filter_properties into a key=[value] ? | |
| 15:53:06 | openstackgerrit | Merged openstack/nova master: Move project_id and user_id to Allocation object https://review.openstack.org/500410 | |
| 15:54:27 | mriedem | i guess because you can pass in hints like key=value1 key=value2 and the CLI will convert those to a key=[value1,value2] | |
| 15:55:43 | mriedem | seems that _validate_instance_group_policy in the compute manager doesn't handle the hint value being a list at all | |
| 15:56:42 | mriedem | oh becaues the 'group' hint schema only allows a string value | |
| 15:57:00 | mriedem | https://github.com/openstack/nova/blob/d36dcd52c24c32418fd358d245688c86664025d5/nova/api/openstack/compute/schemas/scheduler_hints.py#L21 | |
| 15:57:20 | mriedem | fun, all of this being undocumented... :) | |
| 16:18:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use the RequestSpec when getting scheduler_hints in compute https://review.openstack.org/515461 | |
| 16:18:28 | mriedem | bauzas: here you go ^ i'm helping! | |
| 16:22:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use the RequestSpec when getting scheduler_hints in compute https://review.openstack.org/515461 | |
| 16:31:37 | cdent | jaypipes: thanks for the review on the stack leading to POST /allocations. No, nobody suggested I split things up, I did that to try and keep things a bit smaller, led in part by the stack that is adding last-modified to lots of things, all under the same microversion | |
| 16:32:16 | jaypipes | cdent: sorry, I may have missed the last-modified thing... I don't see that anywhere in this patch series? | |
| 16:32:20 | cfriesen | In _post_live_migration() at https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L6075 why are we calling self._update_scheduler_instance_info() rather than self._delete_scheduler_instance_info() ? | |
| 16:32:39 | cdent | jaypipes: it’s a different series, but has the same split behavior of docs/reno coming later | |
| 16:33:16 | jaypipes | cdent: ack. I'd like to see all public API-modified changes in a single commit please. even if it leads to large commits. | |
| 16:33:22 | cfriesen | One of our devs thinks that this is causing issues with the server group affinity filter by causing the scheduler to get out-of-date with the compute nodes. | |
| 16:33:41 | jaypipes | cdent: just enables us to keep our "this single commit changes the API and in these ways" behaviour. | |
| 16:33:49 | jaypipes | dansmith: thoughts on ^? | |
| 16:34:00 | cdent | I thought we had relaxed some of that in favor of being able to review things a bit more discreetly? | |
| 16:34:17 | sean-k-mooney | cfriesen: oh hi since your about do you know if the patches to fix live migration with vnic=macvtap were ever merged | |
| 16:34:17 | jaypipes | cdent: I'm not aware of such a relaxation... | |
| 16:34:26 | dansmith | yeah, we can't | |
| 16:34:31 | jaypipes | cdent: but of course, I very easily could be wrong :) | |
| 16:34:32 | cdent | it’s doable of course, but will require a fair bit of reordering on the last-modified stuff | |
| 16:34:37 | cdent | which is fine | |
| 16:34:45 | dansmith | the only way around it is adding dead code in a commit, then turning it on later when you add the microversion | |
| 16:34:57 | dansmith | but we can't add real functionality separate from the microversion itself | |
| 16:35:14 | cdent | I’m not _not_ adding the microversion, just not doccing it | |
| 16:35:31 | cdent | which perhaps should be considered the same thing? /me shrugs | |
| 16:35:40 | dansmith | oh, I thought it was asserted that you were | |
| 16:35:45 | cfriesen | sean-k-mooney: I don't think so....see https://review.openstack.org/#/c/136077/ and https://review.openstack.org/#/c/251387/ | |
| 16:36:26 | cdent | dansmith: no I’m starting a microversion and then adding different pieces of functionality or docs that are within that microversion in subsequent patches | |
| 16:36:30 | cdent | so for example | |
| 16:36:42 | cdent | https://review.openstack.org/#/c/495380/ | |
| 16:36:46 | dansmith | cdent: that's the same thing as adding the functionality before the microversion, | |
| 16:37:00 | sean-k-mooney | cfriesen: ok cool ill assume its stil broken then. ill try to make sure we can handel it properly in the multiple port binding work im doing | |
| 16:37:01 | dansmith | although with the latter you can keep it dead until the microversion which is what you'd have to do | |
| 16:37:22 | sean-k-mooney | cfriesen: i might not actully fix it but ill make sure not to break it more | |
| 16:37:29 | cfriesen | sean-k-mooney: :) | |
| 16:37:35 | cdent | dansmith: I’m not sure I’m fully parsing “that's the same thing as adding the functionality before the microversion," | |
| 16:37:46 | dansmith | cdent: opening a microversion in one commit and extending it in another defeats the point of it, in that clients can't depend on the functionality you're adding when the microversion is exposed | |