| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-13 | |||
| 17:54:18 | johnthetubaguy | mriedem: yeah, it changes that case some, we spoke about needing a new attachment for the connector changed case, maybe... | |
| 17:54:34 | mriedem | but how do we know if the connector changed? | |
| 17:54:49 | mriedem | we don't - that's why we said at the ptg we'd just refresh when we have the chance, like during reboot | |
| 17:55:08 | mriedem | that was the alternative to adding a new admin-only API to force a refresh | |
| 17:55:42 | johnthetubaguy | mriedem: I am quite a fan of making that explicit, almost feels like volume migrate | |
| 17:55:49 | mriedem | i don't think we want to be randomly updating and completing attachments just to refresh the connection info | |
| 17:55:59 | johnthetubaguy | ++ | |
| 17:56:02 | mriedem | for a case that should rarely happen | |
| 17:56:19 | johnthetubaguy | yeah, its a whoops I broke my cloud, please help me case | |
| 17:56:26 | mriedem | we can still fix the bug for old style attachments like we talked about at the ptg, | |
| 17:56:33 | mriedem | but we'll likely have to think of something else for new style attachments | |
| 17:56:48 | johnthetubaguy | so I need to go and sort out food before sally looses the plot | |
| 17:57:02 | mriedem | yup, go go! | |
| 18:30:47 | superdan | mriedem: replied | |
| 18:30:51 | superdan | mriedem1: ^ | |
| 18:32:28 | mriedem | yeah it's just weird it's showing up in this change, | |
| 18:32:38 | mriedem | i.e. how did this pass the change that added this code in the py35 unit tests? | |
| 18:34:31 | superdan | oh jeez, yeah, this was in the wrong patch I see | |
| 18:34:49 | mriedem | https://www.youtube.com/watch?v=gGrNAB45CtY | |
| 18:34:56 | superdan | oh, I bet it's because we never get in here | |
| 18:35:01 | superdan | until this patch | |
| 18:41:35 | superdan | no that makes no sense | |
| 18:41:49 | superdan | the patch below didn't show a passing py35 so maybe it's broken there too | |
| 18:41:54 | superdan | running locally | |
| 18:42:01 | mriedem | oh | |
| 18:42:03 | mriedem | jeez | |
| 18:42:18 | superdan | yup | |
| 18:42:20 | superdan | breaks there | |
| 18:42:22 | superdan | mah bad | |
| 18:42:44 | mriedem | just putting my -1 stamp on here quick... | |
| 18:43:13 | mriedem | heh, when the gate is permabroken it's easy to assume there are no real failures | |
| 18:43:25 | superdan | yeah | |
| 18:43:59 | openstackgerrit | Dan Smith proposed openstack/nova master: Split get_allocations_for_instance() into useful bits https://review.openstack.org/511306 | |
| 18:44:00 | openstackgerrit | Dan Smith proposed openstack/nova master: Revert allocations by migration uuid https://review.openstack.org/498949 | |
| 18:44:00 | openstackgerrit | Dan Smith proposed openstack/nova master: Refactor resource tracker to account for migration allocations https://review.openstack.org/506419 | |
| 18:44:01 | openstackgerrit | Dan Smith proposed openstack/nova master: Make migration uuid hold allocations for migrating instances https://review.openstack.org/506420 | |
| 18:44:01 | openstackgerrit | Dan Smith proposed openstack/nova master: Make live migration hold resources with a migration allocation https://review.openstack.org/507638 | |
| 18:44:15 | superdan | mriedem: I hath done fixificated the brokennieal failboat | |
| 18:52:51 | mriedem | doneth | |
| 18:57:45 | superdan | woot | |
| 18:58:08 | superdan | are we merging things today or not? | |
| 18:58:13 | superdan | I have been otherwise focused and haven't noticed | |
| 19:13:27 | fried_rice | superdan Things were merging licketysplit this morning. But haven't seen anything in a while. | |
| 19:17:01 | superdan | figleaf: I thought I asked this last time but clearly didn't.. what is the reason for allocation_request being nullable in selection? | |
| 19:17:10 | superdan | figleaf: I guess maybe if we didn't have any alternates? | |
| 19:17:34 | figleaf | Because the selected host will have a null allocation_request | |
| 19:18:15 | figleaf | that's necessary for the conductor to be able to distinguish an instance that has already claimed its resources on the host | |
| 19:18:46 | figleaf | Without alternates it wouldn't be necessary | |
| 19:19:12 | superdan | oh no alternates means no selection .. duh | |
| 19:22:17 | superdan | figleaf: okay so I think mriedem is right about us not being able to break the cachingscheduler | |
| 19:22:37 | superdan | superdan: I really hate to put that mess in our shiny new object only to bridge the gap until we can nuke it, but we might not be able to avoid | |
| 19:22:39 | superdan | it | |
| 19:22:44 | superdan | lol, what is wrong with me | |
| 19:22:58 | superdan | figleaf: that said, I think I'm good with this, modulo that being discussed on monday and resolved | |
| 19:25:40 | openstackgerrit | Miguel Lavalle proposed openstack/nova-specs master: Use neutron's new port binding API https://review.openstack.org/375580 | |
| 19:30:14 | superdan | fried_rice: jenkins shat all over your patch | |
| 19:30:30 | fried_rice | superdan Yeah, I'm not done with UT, shouldn't have removed WIP just yet. | |
| 19:30:41 | superdan | okay | |
| 19:31:07 | fried_rice | superdan But the source side should be aight. | |
| 19:31:28 | superdan | I commented | |
| 19:38:02 | figleaf | superdan: yeah, let's all discuss it together and get this settled. I'm pretty sure Jay won't be around, though, and it was his idea to drop the field, and I know he had his reasons | |
| 19:38:27 | superdan | figleaf: okay I didn't see that conversation | |
| 19:38:33 | superdan | figleaf: you think jay won't be around on monday? | |
| 19:40:46 | figleaf | He said he was taking a couple of weeks off in between jobs | |
| 19:41:51 | superdan | seriously? | |
| 19:42:33 | figleaf | superdan: https://twitter.com/jaypipes/status/917561037980930048 | |
| 19:42:43 | mtreinish | man, what a slacker :) | |
| 19:43:03 | superdan | that's really unfortunate timing, for nrps and such | |
| 19:43:47 | mriedem | don't tell mlavalle | |
| 19:43:54 | mriedem | remember the 10/19 deadline | |
| 19:44:20 | mriedem | we also said we'd just merge everything now | |
| 19:44:39 | figleaf | superdan: well, let's just have fried_rice take over nested RPs | |
| 19:44:41 | mriedem | figleaf: superdan: i can pick up some review slack on the alternate hosts stuff on monday | |
| 19:45:38 | openstackgerrit | Dan Smith proposed openstack/nova master: Split get_allocations_for_instance() into useful bits https://review.openstack.org/511306 | |
| 19:45:39 | openstackgerrit | Dan Smith proposed openstack/nova master: Revert allocations by migration uuid https://review.openstack.org/498949 | |
| 19:45:39 | openstackgerrit | Dan Smith proposed openstack/nova master: Refactor resource tracker to account for migration allocations https://review.openstack.org/506419 | |
| 19:45:40 | openstackgerrit | Dan Smith proposed openstack/nova master: Make migration uuid hold allocations for migrating instances https://review.openstack.org/506420 | |
| 19:45:40 | openstackgerrit | Dan Smith proposed openstack/nova master: Make live migration hold resources with a migration allocation https://review.openstack.org/507638 | |
| 19:45:57 | mriedem | again? | |
| 19:45:58 | superdan | mriedem: ^ had to fix a test that was added underneath me after rebase | |
| 19:46:17 | superdan | mriedem: http://logs.openstack.org/19/506419/21/check/gate-nova-python27-ubuntu-xenial/5e75f1d/testr_results.html.gz | |
| 19:47:16 | mriedem | heh those were my tests :) | |
| 19:47:52 | superdan | yeah | |
| 19:49:44 | superdan | figleaf: who else needs to be around for the discussion other than jay? | |
| 19:49:49 | superdan | like can we hash it out now? | |
| 20:03:40 | figleaf | superdan: I guess anyone who knows what things people are doing with limits | |
| 20:04:07 | superdan | well, anyone that uses cachingscheduler and something like ramfilter will need that to be whole | |
| 20:04:30 | superdan | otherwise we guess in the caching scheduler with stale data, send to a compute node, and we don't even check to see if the thing can fit, right? | |
| 20:04:51 | figleaf | I had no idea that it was being used like that until mriedem brought it up | |
| 20:05:07 | superdan | that's how all the claiming on the compute node works, right? | |
| 20:06:43 | mriedem | i also fairly recently realized that myself, | |
| 20:07:04 | mriedem | that if the RamFilter isn't enabled, you don't get the memory_mb limit in the limits dict which means the claim in the RT doesn't check ram at all | |
| 20:07:22 | mriedem | same for vcpu and disk | |
| 20:07:55 | mriedem | for filter scheduler and placement it's cool beans since we filter and claim up front via placement | |
| 20:08:00 | figleaf | mriedem: so if deployers with caching scheduler add those filters, they will be ok? Or do they still need the limits sent down to compute? | |
| 20:09:01 | superdan | figleaf: no | |
| 20:09:19 | superdan | figleaf: the filter adds the limit, which makes it down to compute, which is what causes compute to actually check/claim for that thing | |
| 20:09:29 | superdan | figleaf: don't run ramfilter, you don't check ram on the compute | |
| 20:09:57 | superdan | figleaf: I mean, just adding the filter works _today_ | |
| 20:10:04 | figleaf | won't ramfilter check ram on the host state? If there isn't enough, it's discarded, no? | |