Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-03
14:59:47 melwitt can someone sanity check me on this? when configured to use qcow2 images with libvirt, the backing file on each compute host is expected to be raw format (not qcow2) being that each instance created on the compute will be a COW copy of it?
15:00:07 openstack Launchpad bug 1774730 in OpenStack Compute (nova) "Compute node convert qcow2 to raw even if force_raw_images=false" [Undecided,New]
15:00:07 melwitt I'm trying to triage this https://bugs.launchpad.net/nova/+bug/1774730
15:01:07 mriedem cfriesen: i could have sworn we had a patch up for this upstream too https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-516904cc81cade24a9122ecf96707bf0R4226
15:03:41 melwitt mdbooth: if you're around, question about force_raw_images=False and images_type=qcow2, the backing file is expected to be raw format right? since each instance is a COW copy of it? ^
15:04:35 mdbooth melwitt: I *think* the backing file is allowed to be qcow2 in that case
15:04:45 mdbooth We done some sanity checking on it when we import it
15:04:53 mdbooth So it's not allowed to have a backing file iirc
15:05:30 melwitt mdbooth: oh, hm okay. then we might be a bug there. thank you for the info
15:05:38 mdbooth qcow2 can have a backing file of qcow2
15:05:42 mdbooth melwitt: Got a link?
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:05:53 melwitt mdbooth: yes https://bugs.launchpad.net/nova/+bug/1774730
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 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

Earlier   Later