| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-23 | |||
| 09:49:24 | openstackgerrit | Alex Xu proposed openstack/nova master: Add _get_provider_ids_with_any_trait method https://review.openstack.org/511184 | |
| 09:49:25 | openstackgerrit | Alex Xu proposed openstack/nova master: placement: rewrite AllocationCandidates.get_by_filters https://review.openstack.org/479766 | |
| 09:49:25 | openstackgerrit | Alex Xu proposed openstack/nova master: Add get_resource_provider_with_any_resource method https://review.openstack.org/514197 | |
| 09:49:26 | openstackgerrit | Alex Xu proposed openstack/nova master: Add ProviderSummaryList object https://review.openstack.org/514198 | |
| 09:49:26 | openstackgerrit | Alex Xu proposed openstack/nova master: Add more caches for the ProviderSummary https://review.openstack.org/514199 | |
| 09:49:27 | openstackgerrit | Alex Xu proposed openstack/nova master: Add AggregatedProviderSummary and AggregatedProviderSummaryList objects https://review.openstack.org/514200 | |
| 09:52:15 | openstackgerrit | zhangyanxian proposed openstack/nova-specs master: Sriov-bond https://review.openstack.org/463526 | |
| 10:02:22 | bauzas | stephenfin: hi, sorry about the delay | |
| 10:02:31 | bauzas | stephenfin: I have a plumber at home | |
| 10:02:38 | bauzas | (not mario FTW) | |
| 10:02:45 | bauzas | how can I help you ? | |
| 10:06:37 | sahid | ygl: we use qemu-kvm, but that through libvirt | |
| 10:07:34 | ygl | sahid: thanks very much | |
| 10:17:59 | stephenfin | bauzas: I _think_ I might be OK for now but stay away from the mushrooms til I know for sure ;) | |
| 10:50:45 | openstackgerrit | Merged openstack/nova stable/pike: Add live.migration.force.complete to the legacy notification whitelist https://review.openstack.org/508877 | |
| 10:50:49 | openstackgerrit | Merged openstack/nova stable/ocata: Make conductor create InstanceAction in the proper cell https://review.openstack.org/511307 | |
| 10:50:54 | openstackgerrit | Merged openstack/nova stable/ocata: Target context for build notification in conductor https://review.openstack.org/511325 | |
| 10:51:05 | openstackgerrit | Merged openstack/nova master: propagate OSError to MigrationPreCheckError https://review.openstack.org/469779 | |
| 10:51:11 | openstackgerrit | Merged openstack/nova stable/ocata: Handle keypair not found from metadata server using cells https://review.openstack.org/500954 | |
| 11:00:15 | efried | alex_xu Good evening, you still around? | |
| 11:13:42 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements https://review.openstack.org/511035 | |
| 11:51:48 | efried | cdent Ready for a lunchtime spitballing session? | |
| 11:51:59 | cdent | one moment please caller | |
| 11:55:59 | openstackgerrit | Eric Fried proposed openstack/nova master: Include /resource_providers/uuid/allocations link https://review.openstack.org/499826 | |
| 11:58:37 | cdent | efried: k, was just finishing up an email about correcting a draft of my will. what’s up? | |
| 11:58:52 | efried | heh, that seems fairly important. | |
| 11:59:21 | efried | cdent I was reviewing your 'limit allocation candidates' patch and it occurred to me that the 'randomize' conf setting should apply whether we're limiting or not. | |
| 11:59:40 | efried | Left a comment to that effect, but wanted to brainstorm with you and see if you agree. | |
| 12:00:43 | cdent | I’m guessing you’re thinking: if we’re going to randomize at all, it should be whether there is a limit or not, and if it going to happen it should happen in one place, not in multiple clients? | |
| 12:00:59 | efried | cdent Javol | |
| 12:01:10 | efried | Were we randomizing from the scheduler somehow? | |
| 12:01:27 | cdent | we were leaving todos about needing to decide if/how to select from too many candidates | |
| 12:02:10 | efried | Oh, then yeah, IMO this is that decision, and this is the sensible place to do it. | |
| 12:02:18 | cdent | the belief is that most people will not want to randomize, as that will tend to spread, which is apparently not a common desire (I don’t actually know how certain or true that is) | |
| 12:02:35 | cdent | yeah, I think you’re right. | |
| 12:03:06 | efried | Okay, that answers the other point of whether we should default to True - sounds like no. | |
| 12:03:49 | cdent | I think we should, but apparently that would change behaviors in an unacceptable way | |
| 12:04:10 | efried | Even though the order of candidates is undefined today. | |
| 12:04:12 | cdent | and bias in favor of the user rather than ops or something | |
| 12:04:22 | cdent | it is undefined, but semi-static | |
| 12:04:34 | efried | But if we've ascertained that the general preference is pack vs. spread, we should indeed preserve that behavior. | |
| 12:04:40 | cdent | the database will do its own ordering, with some bias | |
| 12:04:55 | efried | Which will be deterministic, but not really predictable by a human. | |
| 12:05:26 | cdent | however, I expect that the complexity of the queries thes days, and the inclusion of usage informatin throws off a lot of that ordering | |
| 12:05:51 | cdent | but it was deemed an important part of the plan when discussed in denver | |
| 12:06:02 | efried | cdent Also, just a point of curiosity, were we planning to use the limit param from the scheduler? I would think so - it should be fairly simple to come up with a number that would always give us enough candidates. And that number would be pretty small, too, like on the order of a dozen or so. | |
| 12:06:17 | cdent | so I reckon the change is fairly simple: if not limit and conf thing true: random.shuffle(allocs) | |
| 12:06:45 | cdent | efried: yes, that’s eventual hope: that the scheduler would retrieve much less data | |
| 12:07:21 | cdent | some math of needed instances X needed alternates X fudge factor | |
| 12:07:41 | efried | Yeah, cause at this point we haven't chosen a cell yet, right? | |
| 12:08:11 | efried | Once we pick a cell we get down to three alternates (per instance) | |
| 12:08:13 | cdent | the cell is chosen based on the “claimed” destination | |
| 12:08:25 | cdent | three isn’t static is it, that comes from conf, yeah? | |
| 12:08:32 | efried | edleafe ^ ? | |
| 12:08:52 | efried | In any case, that would make the math simple. #alternates * #instances | |
| 12:08:54 | cdent | needed x retries x cells | |
| 12:09:15 | efried | Okay. Not critical right now, but it's on the radar - cool. | |
| 12:09:34 | cdent | if we don’t include X cells, we may not end up with enough space to pick from | |
| 12:09:48 | cdent | yeah, on the radar - cool | |
| 12:09:54 | cdent | glad you though of that | |
| 12:11:10 | cdent | efried: if you want another thing to do with with your copious free time, I’ve got some microversion_parse changes that need some thinking about and there are few people who are aware of all the bits of context, you might be a good reviewer: https://review.openstack.org/#/c/496212/ and https://review.openstack.org/#/c/495356/ | |
| 12:11:33 | cdent | no rush on that (at all) just stuff I’m sort of rolling around for the cool radar | |
| 12:11:59 | efried | For my part, I got started on numbered groupings in GET /allocation_candidates | |
| 12:12:13 | efried | We've got like a 5-way race to placement microversion 1.11. | |
| 12:13:28 | cdent | Is it only 5? | |
| 12:44:43 | efried | dtantsur|brb I'd like to be invited to the discussion of ironic traits vs. configurables if possible. Thanks! | |
| 12:47:49 | openstackgerrit | Jan Zerebecki proposed openstack/nova master: Only log not correcting allocation once per period https://review.openstack.org/508262 | |
| 12:48:52 | openstackgerrit | jichenjc proposed openstack/nova master: Remove duplicate error info https://review.openstack.org/510719 | |
| 12:56:52 | cdent | maybe we should put traits in etcc and make them watchable | |
| 12:56:59 | cdent | jk/2 | |
| 12:57:15 | cdent | s/etcc/etcd/ | |
| 13:01:05 | openstackgerrit | Stephen Finucane proposed openstack/nova master: zuul: Move legacy jobs to project https://review.openstack.org/514309 | |
| 13:12:13 | bauzas | efried: traits are not boolean | |
| 13:12:41 | efried | bauzas In the sense that they're True if they're present and False if they're absent, kinda? | |
| 13:12:45 | bauzas | efried: turning off a capability means we remove the trait | |
| 13:13:02 | efried | oh, no, I'm pretty sure that's the entire bone of contention here. | |
| 13:13:13 | bauzas | lemme respond on the ML thread | |
| 13:13:36 | efried | Though to be precise, you're correct: if we remove a *capability* (which is different from turning off a setting), we should remove the trait from that RP. | |
| 13:13:52 | efried | bauzas Which is consistent with what I said, though I should have been explicit about it. | |
| 13:13:56 | cdent | removing and turning off not the same thing | |
| 13:14:08 | efried | Right. | |
| 13:14:24 | efried | If I make it so the RP can no longer do the thing, that should come with removing the trait. | |
| 13:14:38 | efried | If the RP is still capable of doing the thing, and I just switch it off, I should leave the trait in place. | |
| 13:15:02 | efried | But even capable vs. on/off is a sticky thing with ironic. | |
| 13:15:36 | efried | Should more precisely say "capable of being turned on during spawn". | |
| 13:16:00 | bauzas | cdent: a trait just means "we support that capability" | |
| 13:16:14 | bauzas | if we don't support it, then we remove the trait | |
| 13:16:24 | cdent | yes, that’s what I was saying | |
| 13:16:26 | bauzas | we couldn't support it because we had turned off something | |
| 13:16:42 | bauzas | but then, if we turn off something, then we delete the trait | |
| 13:16:44 | bauzas | that's MHO | |
| 13:17:02 | bauzas | exactly like a CPU feature | |
| 13:17:13 | efried | bauzas Agree, as long as "we" is e.g. "the admin", not something that can be turned on via the spawn process. | |
| 13:17:15 | cdent | hmm, I suspect it depends on what is doing the action, and whether changing it can be automated | |
| 13:17:22 | efried | cdent ++ | |
| 13:17:24 | cdent | jinx-ish | |
| 13:18:27 | efried | I think we're all in agreement here. Just needs to be spelled out carefully. | |
| 13:21:43 | openstackgerrit | Jan Zerebecki proposed openstack/nova master: Only log not correcting allocation once per period https://review.openstack.org/508262 | |
| 13:24:30 | alex_xu | efried: hi, i'm here | |
| 13:25:12 | efried | alex_xu I wanted to coordinate with your refactoring of AllocationCandidates.get_by_filters. | |