Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-22
16:44:21 openstackgerrit Eric Fried proposed openstack/nova master: Clarify `resources` query param for /r_p and /a_c https://review.openstack.org/547065
16:44:31 efried jaypipes, mriedem, dansmith: There's that clarification you asked for ^
16:44:45 mriedem you missed your reference again
16:45:06 jaypipes lolol
16:45:22 efried the faah?
16:45:31 mriedem efried: but thanks for actually following up with my complaints
16:45:38 mriedem karma points abound
16:45:51 efried High impact:work ratio
16:46:20 mriedem the guy that died via sexual asphyixiation?
16:46:29 jaypipes rofl, no
16:46:30 mriedem oh the white haired guy
16:46:30 efried oy vay, you people.
16:46:35 jaypipes yes
16:46:45 jaypipes thanks goodness I wasn't sipping coffee just nopw
16:46:54 mriedem i was thinking carradine
16:46:57 mriedem isn't that how he died?
16:47:00 jaypipes yes, I got that.
16:47:01 mriedem he's dead right?
16:47:03 jaypipes yes
16:47:08 mriedem ok, whew
16:47:10 openstackgerrit Eric Fried proposed openstack/nova master: Clarify `resources` query param for /r_p and /a_c https://review.openstack.org/547065
16:47:19 efried Updated commit msg, sheesh ^
16:48:05 openstack Launchpad bug 1750790 in OpenStack Compute (nova) "resources on target host aren't released if resize fails" [Undecided,New]
16:48:05 bauzas dansmith: https://bugs.launchpad.net/nova/+bug/1750790 should be marked as Wontfix, right?
16:48:18 bauzas dansmith: as it's a Pike bug, and you fixed that in queens
16:49:19 dansmith um
16:49:41 kashyap bauzas: BTW, once distributions upgrade to Linux 4.14 kernel, this will cease to be "Low" priority
16:49:55 kashyap It'll definitely bite us, and cause nuisance
16:50:16 dansmith bauzas: I'm not sure why we wouldn't fix it in pike just because we fixed it in queens
16:50:52 efried dansmith: bauzas may be basing that statement on something I said at 5am. This is about duplicate allocations on source & target.
16:50:53 bauzas dansmith: no worries, I'll leave the bug open
16:51:11 bauzas I'm way off reviewing specs, and I need to
16:51:16 dansmith efried: okay
16:51:18 bauzas so I'll stop looking at bugs
16:51:27 dansmith I expect it's fixed in queens because of migration allocations
16:51:32 efried I didn't know whether we punted fixing that in pike because too complicated, and just fixed it in Queens with cdent's POST allocations business
16:51:32 mriedem bauzas: that's likely a bug that claudiub has a fix up for
16:51:34 dansmith but we probably need a fix for pike still
16:51:43 mriedem dansmith: bauzas: not necessarily
16:51:46 mriedem depends on where the failure happens
16:51:52 efried yeah. But I also didn't know whether resize ~= migration in this case
16:52:02 mriedem resize = cold migrate
16:52:13 efried but still subject to duplicate allocations mriedem?
16:52:25 efried i would spect so
16:52:27 mriedem bauzas: dansmith: this https://review.openstack.org/#/c/543971/
16:52:37 dansmith mriedem: um, what? we only need a fix depending on where it happens?
16:52:50 mriedem efried: all move operations require an allocation on the source and dest hosts,
16:53:06 efried makes sense.
16:53:07 mriedem pre-queens, we just doubled those rather than split them
16:53:11 bauzas mriedem: excellent, tz
16:53:17 bauzas will close the bug as duplicate
16:53:21 mriedem dansmith: if prep_resize fails, we cleanup the allocations
16:53:31 mriedem if resize_instance fails, we don't, which is https://review.openstack.org/#/c/543971/
16:53:42 mriedem there are 10 places you can blow off your foot with resize
16:53:57 dansmith sure, sounded like you were disagreeing with me that we need a fix
16:54:24 mriedem i think we're talking about different things
16:54:33 mriedem or different failure scenarios
16:54:36 bauzas right
16:54:56 bauzas anyway, I'm done with triaging bugs for that week
16:55:02 mriedem bauzas: i don't know if it's a duplicate, depends on where it fails
16:55:18 mriedem where does resize fail for missing ssh host keys?
16:55:25 bauzas mriedem: anyhow, the bug was reported because the user forgot to provide SSH keys
16:55:35 bauzas while we ask for that
16:55:45 mriedem ok let's assume it's the same problem then :)
16:55:52 mriedem if it's not, they can re-open
16:55:57 bauzas zactly
17:02:35 openstackgerrit Merged openstack/nova stable/queens: Add functional test for deleting BFV server with old attach flow https://review.openstack.org/546803
17:02:51 openstackgerrit Merged openstack/nova stable/queens: Ensure attachment_id always exists for block device mapping https://review.openstack.org/546804
17:03:57 mriedem +2 on claudiub's fix now https://review.openstack.org/#/c/543971/
17:09:39 mriedem gdi i'm annoyed that we run several tempest jobs for docs changes
17:09:55 mriedem and that irrelevant-files isn't overridable
17:12:57 mriedem mdbooth: are you around?
17:13:16 mdbooth mriedem: I am!
17:13:30 mriedem mdbooth: can you take a look at https://review.openstack.org/#/c/542646/ ? it's related to a restriction / validation you put into the api
17:15:21 openstackgerrit Eric Fried proposed openstack/nova master: Make _get_sharing_providers more efficient https://review.openstack.org/547008
17:15:21 openstackgerrit Eric Fried proposed openstack/nova master: rp: GET /resource_providers?required= https://review.openstack.org/546837
17:15:23 efried edleafe: ^^
17:15:39 efried I mean ^
17:15:55 efried Anyone else have an IRC client that converts emoticons to graphics?
17:18:57 mdbooth mriedem: So it's my understanding that your reproducer *should* fail.
17:19:26 efried That *would* be an awkward dict situation
17:19:28 mdbooth mriedem: I have always taken min_disk to mean: the stuff this image does requires at least this much space.
17:20:05 mdbooth Which is obviously different to the image size.
17:22:37 mriedem mdbooth: i don't think that's the original image min_disk though
17:23:04 mriedem we say that's the min_disk b/c of the flavor root_gb
17:23:06 mdbooth mriedem: Reading back a bit more I was just going to ask exactly that.
17:23:30 mdbooth It sounds to me like the bug is in the setting of min_disk in the first place, then.
17:23:36 mdbooth It should be the min_disk of the original image.
17:23:57 mriedem so on my devstack right now, the single cirros image has min_disk=0
17:24:11 mriedem i can create a 1GB volume as the boot disk for my server that has that image in it,
17:24:21 mriedem snapshot it, and nova says the min_disk for the snapshot is now equal to the flavor.root_gb
17:24:27 mriedem 20 in my case
17:24:30 mriedem 20GB
17:25:01 mdbooth IMHO the bug is " and nova says the min_disk for the snapshot is now equal to the flavor.root_gb"
17:25:02 mriedem lemme create a volume from the image and see what the image meta shows in the volume
17:25:09 mriedem i agre
17:25:10 mriedem *agree
17:25:36 mdbooth IOW, I think the bug happens before the proposed fix
17:26:04 claudiub mriedem: regarding your comment on https://review.openstack.org/#/c/543971/5/nova/compute/manager.py , you mean the docstring which is on finish_resize (L4444), or a new one explaining the allocation cleanup part?
17:26:21 mriedem mdbooth: ok so i created a 1GB volume from a cirros image in devstack http://paste.openstack.org/show/682285/

Earlier   Later