| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-15 | |||
| 17:22:58 | bauzas | oops, jaypipes too ^ | |
| 17:23:57 | dansmith | my only concern would be the dependent specs, if people want those landed first | |
| 17:24:01 | dansmith | but I don't mind either way really | |
| 17:24:55 | stephenfin | mriedem: I think you identified what he was looking for, which was different to what I thought. Given that the caching scheduler is deprecated (I didn't know that), we don't need to worry about IMO | |
| 17:25:42 | mriedem | bauzas: it is certainly possible to know if we're doing a first schedule or a reschedule, | |
| 17:25:48 | mriedem | RequestSpec.retry has that information | |
| 17:26:00 | bauzas | mriedem: for a reschedule yes | |
| 17:26:05 | bauzas | mriedem: for a move operation, nope | |
| 17:26:08 | edleafe | bauzas: that's cool. At least there has been some discussion since my comment | |
| 17:26:11 | mriedem | bauzas: that's because https://review.openstack.org/#/c/505771/ | |
| 17:26:49 | mriedem | well, the issue in ^ confuses the fact that you're doing a reschedule or a move | |
| 17:26:57 | bauzas | shit | |
| 17:27:26 | bauzas | how many times will I regret to not have thought more on persisted fields for the RequestSpec object ? | |
| 17:27:47 | openstackgerrit | Claudiu Belu proposed openstack/nova master: compute: Cleans up allocations after failed resize https://review.openstack.org/543971 | |
| 17:27:57 | jaypipes | bauzas: hold please. | |
| 17:27:58 | cdent | bauzas: feel free to +w the spec if there's been enough feedback | |
| 17:28:00 | jaypipes | still reviewing | |
| 17:28:01 | mriedem | i thought that would be an easy fix but then second guessed myself, and need to write a functional test to be sure | |
| 17:28:07 | cdent | bauzas: except for jay :) | |
| 17:28:26 | bauzas | jaypipes: ack | |
| 17:29:52 | efried | Could rebase it on top of the other spec | |
| 17:31:29 | dansmith | or someone could slam it in: https://review.openstack.org/#/c/544694/ | |
| 17:31:42 | dansmith | it's really simple, has a lot of +1s from stakeholders and only needs a +W | |
| 17:31:50 | mriedem | looking | |
| 17:32:04 | mriedem | i will ram this down your throat like obamacare to the republicans | |
| 17:32:18 | mriedem | lemme call nancy quick | |
| 17:32:25 | dansmith | lolol | |
| 17:33:01 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: mirror nova host aggregates to placement API https://review.openstack.org/545057 | |
| 17:34:21 | dansmith | apparently by "lots" I meant "two" but.. you know | |
| 17:34:53 | mriedem | consider it rammed | |
| 17:35:03 | mriedem | thanks obama | |
| 17:35:19 | mriedem | the two that matter | |
| 17:38:51 | jaypipes | dansmith: cern doesn't use the cachingscheduler does it? | |
| 17:39:08 | mriedem | tssurya: ^ | |
| 17:39:24 | dansmith | jaypipes: presumably not because they're working through placement issues right now | |
| 17:39:34 | jaypipes | ak | |
| 17:40:50 | openstackgerrit | Merged openstack/nova-specs master: Support member_of param for allocation candidates https://review.openstack.org/544694 | |
| 17:42:05 | tssurya | mriedem, jaypipes, dansmith : no we don't | |
| 17:42:25 | mriedem | excellente | |
| 17:47:19 | gibi | dansmith: I also left some comments / questions on https://review.openstack.org/#/c/544585 just now | |
| 17:51:39 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Extending delete_cell --force to delete instance_mappings https://review.openstack.org/540073 | |
| 17:52:54 | bauzas | gibi: dansmith: I got the name. Let's call it "scheduler transformers" and name the first one "autobot" | |
| 17:53:07 | dansmith | gibi: replying | |
| 17:53:08 | mriedem | gibi: i cleaned up the commit message on this and added a simple unit test for detach failing, see if you still like it ^ | |
| 17:53:09 | mriedem | oops | |
| 17:53:13 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Detach volumes when VM creation fails https://review.openstack.org/528385 | |
| 17:53:15 | mriedem | gibi: ^ | |
| 17:53:28 | bauzas | please folks, don't tell me about Shia LaBeouf or anything stupid like the movies | |
| 17:53:39 | gibi | mriedem: looking | |
| 17:53:55 | bauzas | they killed my childhood | |
| 17:58:58 | mriedem | gibi: and left a comment | |
| 17:59:09 | mriedem | deleting the volume before we reschedule is kind of dumb | |
| 17:59:24 | mriedem | let's say i boot from volume with a pre-existing volume, | |
| 17:59:32 | gibi | mriedem: oops, +Wd it | |
| 17:59:36 | mriedem | spawn on the first host fails after i've attached the instance to the volume, | |
| 17:59:47 | mriedem | we then detach and delete the volume, and reschedule, | |
| 17:59:55 | mriedem | then we get to the 2nd host, and attach will fail b/c the volume is gone | |
| 18:00:05 | mriedem | well i was +2, | |
| 18:00:08 | mriedem | and might still be, | |
| 18:00:27 | mriedem | because this is a latent thing that's always been in here, but i just don't think it's ever worked because of the bug he's fixing | |
| 18:00:51 | gibi | mriedem: I see. I guess this is a new bug report then | |
| 18:02:40 | gibi | mriedem: we fixed something that allowed another latent bug to manifest itself | |
| 18:03:02 | mriedem | at least delete_on_termination defaults to False... | |
| 18:03:15 | mriedem | this is also kind of why i didn't like the spec proposed for doing delete_on_termination with ports | |
| 18:03:22 | mriedem | since nova is not good at orchestrating this | |
| 18:04:28 | gibi | I also think that nova should only delete these if nova was the one that created them in the first place. But it would be even better if nova would never create these things | |
| 18:04:43 | mriedem | yeah that's the exact thing i was thinking | |
| 18:04:51 | mriedem | and we handle that with ports by storing a flag if nova created the port or not | |
| 18:05:00 | mriedem | in the nw info cache | |
| 18:05:33 | mriedem | because if nova did create this volume and attach it, then we fail and reschedule but don't delete it, we'll create another volume on the next host we try | |
| 18:05:38 | mriedem | and never cleanup the old one | |
| 18:06:04 | mriedem | and given enough retries, you could also hit quota limits on creating volumes | |
| 18:06:32 | mriedem | oh, well we do know if nova created it actually, | |
| 18:06:38 | mriedem | if source_type=volume, it's pre-created | |
| 18:08:26 | mriedem | ok i left some notes in the review so we can remember this conversation 2 years from now | |
| 18:08:30 | mriedem | when it's still a bug :) | |
| 18:09:23 | imacdonn | was something fixed recently-ish w.r.t. ports on reschedule .... seems I've seen issues with an exception, something like PortInUse, when an instance creation fails and gets rescheduled on another compute node, but that probably was with Ocata | |
| 18:09:25 | openstackgerrit | Merged openstack/nova-specs master: Add placement-req-filter spec https://review.openstack.org/544585 | |
| 18:10:42 | mriedem | imacdonn: that's pretty vague | |
| 18:10:43 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM: Test LM with encrypted volumes https://review.openstack.org/536350 | |
| 18:10:47 | mriedem | https://github.com/openstack/nova/commit/08d24b733ee9f4da44bfbb8d6d3914924a41ccdc went into newton | |
| 18:10:52 | gibi | mriedem: thanks for that note | |
| 18:10:52 | mriedem | *mitaka | |
| 18:11:15 | mriedem | imacdonn: i have this https://review.openstack.org/#/c/520248/ | |
| 18:11:21 | mriedem | but might not be what you're asking about | |
| 18:11:29 | imacdonn | mriedem: yeah, I know ... I'd have to try to come up with a way to reproduce it ... but it's likely that the port was not created by nova, in my case .. because I use heat a lot, and usually create the port separately there | |
| 18:11:31 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/pike: DNM: Test LM with encrypted volumes https://review.openstack.org/545074 | |
| 18:12:36 | mriedem | imacdonn: in that case nova shouldn't try to delete the port | |
| 18:12:40 | mriedem | just unbind it | |
| 18:12:52 | gibi | dansmith: thanks for the reply on the request filter spec. I have a better view now, so I'm +1 | |
| 18:12:56 | mriedem | if nova didn't unbind it and a reschedule tried to bind that host to another host, that would fail | |
| 18:13:03 | dansmith | gibi: np, thanks for those comments | |
| 18:13:35 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Detach volumes when VM creation fails https://review.openstack.org/544144 | |
| 18:14:06 | imacdonn | mriedem: yeah. I'm fairly sure I've seen this with Ocata .. but it's one of those things that only happens when something else goes wrong (to cause the initial creation failure), so it never got hot enough for me to really dig into ... you just reminded me of if when you mentioned ports above | |
| 18:15:34 | mriedem | at the risk of angering the gods, i think we actually do a relatively decent job of managing ports and cleaning up after ourselves | |
| 18:15:39 | mriedem | with volumes, not so much | |
| 18:16:16 | imacdonn | heh. I'll try to find time to attempt to reproduce it ... but my "round tuit" supply is low | |
| 18:16:38 | mriedem | i understand | |
| 18:18:22 | imacdonn | I guess you really can by ANYTHING on Amazon! https://www.amazon.com/Round-TUIT-Tokens-Multi-Pack-Encouragement/dp/B00J8KVHLY | |
| 18:18:45 | mriedem | heh, find me a hang in there poster with a kitten that doesn't suck | |