Earlier  
Posted Nick Remark
#openstack-nova - 2018-08-03
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 sean-k-mooney cfriesen: isnt that what blazer is for
15:15:08 cfriesen leakypipes: my hypothetical guarantee to netflix that they can always burst by X
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 leakypipes cfriesen: we aren't a service provider. we're a placement service.
15:16:25 mdbooth melwitt: fwiw, I can't immediately see how that's possible.
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 openstack Launchpad bug 1785270 in OpenStack Compute (nova) "allow confirmation of resize/migration for migrations in "confirming" status" [Undecided,New]
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: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 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: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: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?
17:29:00 hansmoleman cfriesen: correct, but it does it before changing the instance task_state to 'migrating'
17:29:22 hansmoleman as opposed to where it was before https://review.openstack.org/#/c/401009/13/nova/compute/api.py@a4369
17:29:33 hansmoleman if we failed at ^ we'd leave the instance task_state stuck in 'migrating'
17:29:54 hansmoleman the scheduler (or conductor in the case of force) if the specific host is valid
17:30:37 hansmoleman seems like this should go upstream https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-77f9348ab09642ba46409b6828af4af0R3245
17:31:42 hansmoleman for https://review.openstack.org/#/c/401009/ we should really probably just have a @reverts_task_state decorator in compute api like we do in the manger
17:31:43 hansmoleman *manager
17:36:45 hansmoleman yeah so for evacuate,
17:36:45 cfriesen hansmoleman: about the live migration stuff...we wanted to ensure that any operation involving node selection actually went through the scheduler

Earlier   Later