| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-03 | |||
| 15:05:53 | melwitt | mdbooth: yes https://bugs.launchpad.net/nova/+bug/1774730 | |
| 15:05:53 | openstack | Launchpad bug 1774730 in OpenStack Compute (nova) "Compute node convert qcow2 to raw even if force_raw_images=false" [Undecided,New] | |
| 15:07:06 | mdbooth | melwitt: lemme have a quick dig | |
| 15:07:19 | cfriesen | mriedem: the first one you mentioned (15min ago) was flagged as upstreamable, checking if we ever actually tried | |
| 15:08:27 | leakypipes | cfriesen: if the exact same request to placement "works" (i.e. returns >0 results) in one moment, and then "fails" (returns 0 results) a short time after, that isn't a "failure of the service's SLA". | |
| 15:08:49 | leakypipes | cfriesen: it's not a failure to return 0 results. | |
| 15:09:26 | leakypipes | cfriesen: the capacity to meet that particular request may easily have been exceeded by the first "successful" request's claim of those resources. | |
| 15:10:21 | leakypipes | cfriesen: SLAs are for things like "mean time to recover" or "mean time to respond". not for everyday occurrences and normal business of a service. | |
| 15:11:33 | leakypipes | cfriesen: for instance, if WRS claimed to its customers that the placement service would always return a result within 50 milliseconds, and placement returned a result in 2 seconds, that would be a failure of the SLA. But if the placement service returns 0 results in 20 milliseconds, that's not a failure of the SLA. | |
| 15:12:49 | cfriesen | leakypipes: doesn't that depend what's in the SLA? If I'm Netflix, I could have an agreement with Amazon saying that I'll always be able to burst by X additional resources. | |
| 15:13:10 | leakypipes | cfriesen: that has nothing to do with the placement service, and you know it. :) | |
| 15:13:32 | fried_rice | oh, this conversation is happening. | |
| 15:13:45 | fried_rice | I just sent this in an email, prettymuch. | |
| 15:14:07 | cfriesen | leakypipes: true, but it's a failure to provide resources that are supposed to be available. it's not an exception in placement, but it's arguably exceptional for the provider. | |
| 15:14:30 | cfriesen | like I said in my email, I'm of two minds. | |
| 15:14:31 | fried_rice | ^ this exactly. | |
| 15:14:49 | leakypipes | cfriesen: who said the resources are "supposed to be available"? that's crazy talk, friend. | |
| 15:15:08 | cfriesen | leakypipes: my hypothetical guarantee to netflix that they can always burst by X | |
| 15:15:08 | sean-k-mooney | cfriesen: isnt that what blazer is for | |
| 15:15:15 | fried_rice | Nova certainly isn't in the business of enforcing, or even knowing about SLAs | |
| 15:15:23 | fried_rice | yeah, was gonna say, that's some service way above nova. | |
| 15:15:47 | leakypipes | fried_rice: or *multiple* services (running as a SaaS system or orchestrator of some sort or whatever) | |
| 15:15:54 | fried_rice | fosho | |
| 15:16:16 | leakypipes | cfriesen: nobody other than a service provider can or would make such a guarantee. | |
| 15:16:25 | mdbooth | melwitt: fwiw, I can't immediately see how that's possible. | |
| 15:16:25 | leakypipes | cfriesen: we aren't a service provider. we're a placement service. | |
| 15:16:26 | fried_rice | We're talking about FFDC where the second F is only a F from the perspective of something waaay above placement. | |
| 15:16:51 | cfriesen | fried_rice: okay, but now you have those services trying to figure out why the request couldn't be met, and I can see how it would be nice to have an exception object with nice logs in it rather than sending an operator digging through logs. | |
| 15:16:53 | melwitt | mdbooth: okay, that is odd. thank you for taking a look | |
| 15:17:01 | leakypipes | cfriesen, fried_rice: move this to #openstack-placement before we get told off... | |
| 15:17:24 | fried_rice | yuh, swhy I didn't notice the conversation until after I had sent my email. | |
| 15:17:35 | mdbooth | melwitt: I'd definitely want to see logs and config. Immediate suspect is conf error. | |
| 15:18:05 | melwitt | mdbooth: okay, that's helpful. I ask the reporter for more info | |
| 15:18:08 | melwitt | thanks | |
| 15:24:21 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Avoid live migrate to same host https://review.openstack.org/542689 | |
| 15:28:02 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] ensure_rc_cache only at start of process https://review.openstack.org/584086 | |
| 15:28:10 | cfriesen | mriedem: I don't see an upstream bug report. probably just got missed, so I opened one. https://bugs.launchpad.net/nova/+bug/1785270 | |
| 15:28:10 | openstack | Launchpad bug 1785270 in OpenStack Compute (nova) "allow confirmation of resize/migration for migrations in "confirming" status" [Undecided,New] | |
| 15:33:41 | mriedem | danke | |
| 15:34:39 | cfriesen | mriedem: I think we now have the ability to set RUN_ON_REBUILD to enforce validating the image on rebuild. I'm not aware of a similar thing to enforce always going through the scheduler for live migration, though I think I talked about it with dansmith. | |
| 15:36:45 | cfriesen | gotta step out for a bit....back later. | |
| 15:38:03 | mriedem | cfriesen_afk: i see you guys removed the force flag for live migrate so you can't do that, which means you'd go through the scheduler, but that *doesnt* apply to live migrations before the microversion that added the force flag because in those cases, simply specifying a host bypasses the scheduler | |
| 15:38:46 | mriedem | RUN_ON_REBUILD is only b/c we don't actually move hosts on rebuild | |
| 15:41:48 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Deprecate upgrade_levels options for deprecated/removed services https://review.openstack.org/588607 | |
| 15:41:52 | mriedem | dansmith: might want to get that into rocky ^ | |
| 15:41:54 | mriedem | to start the timer | |
| 15:41:59 | mriedem | melwitt: ^ you too given nova-consoleauth | |
| 15:43:51 | melwitt | ack | |
| 15:46:18 | dansmith | yar | |
| 15:49:55 | melwitt | mriedem: TYPO | |
| 15:50:03 | melwitt | in the reno | |
| 15:50:24 | dansmith | WUT? NO. | |
| 15:50:29 | melwitt | YUH HUH | |
| 15:50:31 | dansmith | zomg | |
| 15:50:43 | dansmith | let it be known on the third day of august, the year of our lord 2018... | |
| 15:53:13 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Deprecate upgrade_levels options for deprecated/removed services https://review.openstack.org/588607 | |
| 15:53:59 | mriedem | dansmith: you want to hit jichen's change below that also? | |
| 15:55:25 | dansmith | meh | |
| 15:56:13 | mriedem | i thought it was useful b/c at least one person thought "auto" could be applied to all | |
| 15:56:47 | dansmith | meh | |
| 15:57:10 | mriedem | MEH?! | |
| 15:57:16 | dansmith | MEH. | |
| 15:57:23 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Reno for notification-transformation-rocky https://review.openstack.org/588403 | |
| 15:57:24 | mriedem | so i guess +r has killed casual nick friday? | |
| 15:57:47 | dansmith | no | |
| 15:57:48 | dansmith | it has killed other things, but not casual friday | |
| 16:03:36 | leakypipes | sean-k-mooney: I'm good with https://review.openstack.org/#/c/587378 going into os-vif. I will leave it to the submitter to try and get a stable branch of nova to bring it in via requirements.txt though (0.00001% chance of that happening) | |
| 16:10:08 | fried_rice | finucannot: If [testenv] defines `commands` and [myenv] defines `commands`, does [myenv] actually execute testenv.commands + myenv.commands?? | |
| 16:10:47 | finucannot | fried_rice: No, [myenv] commands will override [testenv] commands | |
| 16:11:05 | fried_rice | finucannot: So that's what I thought, but snot the behavior I'm seeing :( | |
| 16:11:18 | finucannot | Got a paste? | |
| 16:12:25 | hansmoleman | cfriesen_afk: found it https://review.openstack.org/#/c/401009/ | |
| 16:13:22 | fried_rice | finucannot: agh, ignore me, pebcak | |
| 16:15:30 | fried_rice | jgwentworth: How did you manage that? Got password? | |
| 16:15:51 | jgwentworth | yeah | |
| 16:29:00 | cdent | have I got names right? hansmoleman is matt, jgwentworth is mel? | |
| 16:29:10 | jgwentworth | correct | |
| 16:40:12 | leakypipes | jgwentworth: weird... why do we have stable versions of dependent libraries when we follow a semver release model? | |
| 16:44:33 | mdbooth | dansmith: For interest, the fun LM bug we discussed earlier was sorta filed before https://bugs.launchpad.net/nova/+bug/1628606 . I don't think we appreciated the potential for the thing ending up running in 2 places at once, though. | |
| 16:44:33 | openstack | Launchpad bug 1628606 in OpenStack Compute (nova) "live migration does not clean up at target node if a failure occurs during post migration" [Low,Confirmed] | |
| 16:45:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove unused flavor_delete_info() method https://review.openstack.org/588621 | |
| 16:50:32 | leakypipes | jgwentworth: I suppose so we can backport stuff... | |
| 16:50:44 | leakypipes | (shows you how much I keep up with stable stuff...) | |
| 16:53:28 | mdbooth | I just added a comment to https://bugs.launchpad.net/nova/+bug/1628606 . I think it's pretty serious. | |
| 16:53:29 | openstack | Launchpad bug 1628606 in OpenStack Compute (nova) "live migration does not clean up at target node if a failure occurs during post migration" [Low,Confirmed] | |
| 16:53:52 | mdbooth | I can't update the importance, though, not that it matters all that much I guess. | |
| 16:56:43 | openstackgerrit | Lee Yarwood proposed openstack/nova master: fixtures: Track volume attachments within CinderFixtureNewAttachFlow https://review.openstack.org/587013 | |
| 16:56:45 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Add regression test for bug#1784353 https://review.openstack.org/587014 | |
| 16:56:46 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Recreate volume attachments during a reschedule https://review.openstack.org/587071 | |
| 17:03:41 | hansmoleman | lyarwood: did you talk to dansmith at all about re-creating the volume attachment record in conductor vs compute when rescheduling? ^ | |
| 17:04:05 | hansmoleman | https://review.openstack.org/#/c/587071/3/nova/compute/manager.py@1611 | |
| 17:05:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix host validity check for live-migration https://review.openstack.org/401009 | |
| 17:07:09 | jgwentworth | leakypipes: yeah, I don't know the nitty gritty on how or why it works but yeah, if we backport fixes to stable and release a new lib version from stable, people can receive fixes via the upper-constraints requirement bump if they're on an older release. I guess maybe it's more an artifact of how the deployment tools usually work? not sure | |
| 17:07:35 | lyarwood | hansmoleman: I did not, just had 30 mins to work on this now at the end of the day | |
| 17:09:03 | jgwentworth | mdbooth: will take a look. fyi to update importance of a bug, all you have to do is join the bugs team (open team) https://launchpad.net/~nova-bugs | |
| 17:09:25 | jgwentworth | being a team member gives permission to update importance | |
| 17:10:35 | jgwentworth | bug from 2016, still a thing? yeesh | |
| 17:25:32 | hansmoleman | cfriesen_afk: it's interesting you added this _await_volume_detached thing in compute https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-77f9348ab09642ba46409b6828af4af0R2649 - i thought os-detach in cinder was a synchronous operation, so what issues were you hitting that required that waiter? | |
| 17:26:39 | hansmoleman | unless maybe you made detach async on the cinder side...? | |
| 17:27:54 | cfriesen | hansmoleman: Isn't https://review.openstack.org/#/c/401009/ just about checking whether the specified host exists, not whether it satisfies filters? | |