Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-28
16:58:38 openstackgerrit Sean Dague proposed openstack/nova master: Add cinder keystone client opts to config reference https://review.openstack.org/488530
16:59:17 mriedem superdan: leave what? the part of my patch that returns if the source node isn't in the current allocations?
16:59:39 mriedem the point was really just safe guarding against that and providing logging in case it happens
16:59:43 superdan mriedem: leave it like not apply your patch
16:59:49 mriedem oh
16:59:51 mriedem yeah
16:59:58 mriedem i figured we'd sort that out later
17:00:04 superdan you said this morning something indicating you might want to not commit this patch
17:00:07 superdan I think we should but...
17:00:27 mriedem i think it would be ok to do it - it's not going to impact performance by pulling the allocations again, because this code only runs from the compute periodic
17:00:52 mriedem i intentionally didn't pass the rp uuid in from the scheduler so the scheduler won't double check
17:01:09 superdan okay
17:03:54 mriedem leakypipes: superdan: cdent: here is the other bug https://bugs.launchpad.net/nova/+bug/1707256
17:03:54 openstack Launchpad bug 1707256 in OpenStack Compute (nova) "Scheduler report client is not account for shared resource providers" [High,Confirmed]
17:04:04 mriedem omg me fail english
17:04:08 superdan is not account?
17:04:10 superdan oh
17:04:10 superdan mah
17:04:11 superdan god
17:04:17 superdan one for the record books kids
17:04:31 superdan let it be known henceforth that mriedem is not perfect
17:04:35 mriedem i was surrounded by a whirlwind of 6 year old in pink
17:04:41 mriedem rattled me
17:05:24 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove compatibility code for flavors https://review.openstack.org/460377
17:08:55 cdent you reall do have my disease mriedem : “compute node things it needs”
17:09:07 sdague mriedem: for one glorious moment, 0 bugs in New state - https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
17:09:15 mriedem o.O
17:09:31 mriedem sdague: did you just invalidate everything? :)
17:09:53 cdent leakypipes: [t 3rxI] [t 3edk]
17:09:53 purplerbot <leakypipes> cdent: precisely the case for determining if the compute node was associated to providers of shared resources. [2017-07-28 16:50:19.034601] [n 3rxI]
17:09:53 purplerbot <cdent> so is it of use in one of these two bugs? [2017-07-28 16:50:43.278883] [n 3edk]
17:10:17 sdague I read every new bug, moved a bunch of them to Incomplete with specific questions, found all the ones that really were going to need specs and linked them to the specs process and put them in Opinion
17:10:20 sdague duped a few
17:10:25 leakypipes cdent: yes, the latter.
17:10:28 sdague found some that had been fixed
17:10:31 mriedem sdague: thanks
17:10:42 sdague so, it's mostly a legit cleaning of the New state
17:11:02 cdent cool, thanks leakypipes, I figured as much but wanted to be sure
17:11:54 sdague also... evacuate bugs... zomg
17:11:59 melwitt sdague: you are a champion
17:12:31 cdent gerrit hates me
17:13:15 cdent voila
17:13:18 superdan cdent: hates everyone apparently
17:13:23 superdan *it hates
17:13:29 cdent s/://
17:13:37 superdan well, I suspected, but
17:13:49 melwitt yeah, gerrit hates us all. it's not you
17:15:21 cfriesen_ review.openstack.org is down?
17:15:52 cfriesen_ never mind, just saw the note
17:19:46 cfriesen_ sdague: arguably bug 1669054 is not opinion...if CONF.allow_resize_to_same_host is False and we do a resize then a subsequent rebuild/evacuate, it will continue to ignore the original host.
17:19:46 openstack bug 1669054 in OpenStack Compute (nova) "RequestSpec.ignore_hosts from resize is reused in subsequent evacuate" [Undecided,Opinion] https://launchpad.net/bugs/1669054
17:20:09 cfriesen_ sdague: the only "might" is around exactly where to do the fix
17:23:55 openstackgerrit Peter Hamilton proposed openstack/nova-specs master: Add support for certificate validation https://review.openstack.org/488541
17:26:34 openstackgerrit melanie witt proposed openstack/nova master: Detach device from live domain even if not found on persistent https://review.openstack.org/488545
17:34:27 openstackgerrit Peter Hamilton proposed openstack/nova-specs master: Add support for certificate validation https://review.openstack.org/488541
17:40:16 openstackgerrit Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766
17:54:28 openstackgerrit Dan Smith proposed openstack/nova master: Add some more cellsv2 doc goodness https://review.openstack.org/487183
17:59:50 sdague cfriesen_: Opinion often means bring it back in via the specs process. Did I not do that with this one?
18:00:11 sdague cfriesen_: if you want it confirmed / medium, that's fine as well, but that ends up being kind of a different black hole.
18:00:49 sdague cfriesen_: trying to make every open bug actionable
18:01:00 sdague might and may are not really actionable
18:01:11 openstackgerrit Jay Pipes proposed openstack/nova master: remove source provider allocs in confirm_resize() https://review.openstack.org/488510
18:01:30 leakypipes superdan, figleaf: updated &
18:01:33 leakypipes ^^
18:02:24 openstackgerrit Dan Smith proposed openstack/nova master: Add some more cellsv2 doc goodness https://review.openstack.org/487183
18:02:25 superdan leakypipes: fixed ^
18:04:01 leakypipes superdan: +2
18:04:06 superdan tys
18:10:58 cdent ah buckets, dan gets in the revision while I’m reviewing the cellsv2 doc goodness
18:11:04 melwitt superdan: thanks for writing that up, complete with diagrams! since I've been thinking about consoles, I'm thinking maybe I can add onto that with mention of nova-consoleauth and the websocketproxies similar to "Neutron Metadata API proxy"?
18:54:17 cfriesen_ jaypipes: would https://review.openstack.org/#/c/339715 still be an issue with the new placement/allocations stuff? (i.e should I bother refreshing it or will it be handled already?)
18:55:32 cfriesen_ sdague: in this case the "might" was for a possibly way to fix it. The bug exists, that is not in question.
19:00:12 leakypipes cfriesen_: no, I don't think so. different issue.
19:00:33 leakypipes cfriesen_: I think you can revamp that patch, address the comments from Matt.
19:12:30 openstackgerrit Ed Leafe proposed openstack/nova master: Handle hash ring rebalancing in ironic flavor migration https://review.openstack.org/487954
19:14:07 openstackgerrit Eric Fried proposed openstack/nova master: nova.utils.get_endpoint_data() https://review.openstack.org/488137
19:34:40 fried_rice mriedem https://review.openstack.org/#/c/488034/ (g-r bump) is verified now.
19:41:14 mriedem mgagne: https://bugs.launchpad.net/nova/+bug/1707284
19:41:14 openstack Launchpad bug 1707284 in OpenStack Compute (nova) "Extend attached volume fails with "VolumePathsNotFound: Could not find any paths for the volume." in os-brick iscsi connector" [Medium,Confirmed]
19:41:28 mgagne mriedem: hi
19:47:18 mgagne mriedem: could it be a redheering ? I'm not familiar with os-bricks and friends but right above, you can read "iscsiadm: No active sessions" and u'target_discovered': False in the bdm dump. that's what I found at first glance
19:53:17 hongbin hi folks, i want to confirm that if i create an instance with an existing port and a security group, the security group should be added to the existing port or not?
19:55:18 hongbin or the security group should override the port's security group?
20:03:37 mgagne mriedem: I'm having a hard time debugging the logic, there are missing debug logs from os-brick, especially around calls to _iterate_all_targets from _get_potential_volume_paths in os_brick/initiator/connectors/iscsi.py
20:05:36 openstackgerrit Jay Pipes proposed openstack/nova master: placement: don't allocate on compute nodes https://review.openstack.org/488595
20:06:01 leakypipes mriedem, superdan, figleaf, bauwser: mind blown.... ^
20:06:51 leakypipes mriedem: and that takes care of https://bugs.launchpad.net/nova/+bug/1707256 actually. :)
20:06:51 openstack Launchpad bug 1707256 in OpenStack Compute (nova) "Scheduler report client does not account for shared resource providers" [High,Confirmed] - Assigned to Jay Pipes (jaypipes)
20:07:13 superdan leakypipes: um, what?
20:07:24 superdan leakypipes: who un-doubles the move allocation?
20:07:29 leakypipes mriedem: by removing the compute node/resource tracker from all allocation operations, we kind of just remove the whole "is this shared or not" problem on the compute node.
20:07:43 leakypipes superdan: that's done in the dependent patch.
20:07:58 leakypipes superdan: https://review.openstack.org/#/c/488510/3
20:08:25 leakypipes superdan: so that's the only place on the compute node that will update allocations.
20:08:33 superdan ...okay
20:09:04 superdan leakypipes: so while we're upgrading,
20:09:35 superdan ocata computes will alter/delete the scheduler allocation, and we'll never heal it on pike computes, right? so how do we ensure it heals if it gets damaged?
20:09:46 leakypipes superdan: "mind blown" was referring to my own mind being blown. :) Basically, the patch makes the resource tracker look like what I wanted it to look like once placement-claims was complete. i.e. don't have it mucking with claims/allocations at all.
20:10:07 superdan yeah, I got it
20:10:14 superdan still not sure we can go that far yet

Earlier   Later