Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-25
16:04:23 jaypipes edleafe: we'd need more robust concurrent update handling in the conductor, then.
16:04:24 edleafe jaypipes: sp the conductor would make num_instances calls to the scheduler, instead of 1?
16:04:32 jaypipes edleafe: I'm spitballing.
16:04:49 edleafe We'd also have to run the host queries num_instances times instead of once
16:05:05 jaypipes edleafe: right.
16:05:06 openstackgerrit Matt Riedemann proposed openstack/nova master: Exclude deleted service records when calling hypervisor statistics https://review.openstack.org/467220
16:05:16 edleafe you're spitballing; I'm poking holes
16:05:19 edleafe :)
16:05:24 mriedem Kevin_Zheng: ^ i updated the commit message and re-wrote the test a bit
16:05:25 jaypipes edleafe: I'm thinking out loud.
16:05:29 mriedem with a bunch of comments to explain it
16:05:45 edleafe me too
16:05:58 edleafe I've thought about these a lot already, though :)
16:06:07 sdague mriedem: I'm confused about your comment on https://review.openstack.org/#/c/467995/ about implications for versioned objects
16:06:28 sdague maybe that's where we need dansmith poking
16:07:39 openstackgerrit Ed Leafe proposed openstack/nova master: Pass the number of hosts to return explicitly https://review.openstack.org/465767
16:07:40 openstackgerrit Ed Leafe proposed openstack/nova master: Remove selecting host based on host_subset_size https://review.openstack.org/465174
16:07:40 openstackgerrit Ed Leafe proposed openstack/nova master: Return multiple hosts from select_destinations https://review.openstack.org/465768
16:08:01 edleafe jaypipes: ^^ The series is ready for review. I can switch the passing of UUIDs if needed
16:08:08 jaypipes edleafe, dansmith: for retries, do we ever retry the entire list of instances (in a num_instances > 1 case) or do we just retry the launch of one of them?
16:08:36 edleafe jaypipes: if we retry the whole list, that would be very dumb
16:08:52 edleafe since some could have already been successful
16:09:00 jaypipes edleafe: well, it all depends on how "atomic" we view the num_instances > 1 case, right?
16:10:05 dansmith jaypipes: we've lost scope of the others by the time we're retrying any of them
16:10:11 dansmith jaypipes: and they might've scattered across cells
16:10:23 dansmith jaypipes: as you've pointed out, the api implies atomicity, and we guarantee almost none
16:10:25 mriedem sdague: yes, that's my call for dan
16:11:01 edleafe the min_count and max_count were supposed to provide a go/no-go atomicity
16:12:54 sdague mriedem: ok, cool. Jenkins is currently a happy camper, so there is at least that
16:13:38 jaypipes dansmith, edleafe: ok, random idea here... what if we triggered claims in the scheduler only if num_instances == 1? at least for right now... and let the num_instances > 1 case be handled in the same wonky claim-on-compute way it is now?
16:13:56 dansmith oh please god no
16:14:03 cdent what would that gain?
16:14:12 dansmith jaypipes: nobody wants to claim on compute right?
16:14:31 jaypipes it would mean we would solve the 80% case now. and come up with a solution for the 20% case later.
16:14:34 edleafe jaypipes: yeah, that sounds terrible
16:15:04 edleafe the only thing missing to solve 100% of the claims is the instance UUIDs.
16:15:20 edleafe As long as we pass those in some form to the scheduler, we are good
16:15:38 edleafe the only question is what is the best way to pass them
16:15:47 jaypipes edleafe: right, but what I'm saying is we solve that later and for the first patch(es), we bite off what we can chew for right now.
16:16:00 jaypipes instead of trying to solve everything at once.
16:16:17 edleafe IMO the patches are bite-sized
16:16:42 jaypipes edleafe: the patches might be. the debate isn't. :)
16:16:50 mriedem pass them over rpc
16:16:54 mriedem don't store them in the db
16:16:58 mriedem i thought that was clear?
16:17:07 dansmith mriedem: me too
16:17:10 jaypipes mriedem: nobody has suggested storing them in the DB.
16:17:13 edleafe mriedem: well, if that's the decision, then everything is ready for review
16:17:18 dansmith jaypipes: perhaps we can nail this down quicker in a hangout?
16:17:22 dansmith jaypipes: edleafe did :)
16:17:28 jaypipes he did?
16:17:31 mriedem if you put them in the reqspec they go in the db unless you monkey the object to not persist
16:17:35 mriedem but that seems wrong
16:17:39 edleafe I suggested putting them in the reqspec
16:17:51 jaypipes ok.
16:17:54 edleafe so I guess DB storage is inevitable :)
16:17:59 mriedem i mean sure you can throw any attribute on an object and it won't persist
16:18:07 mriedem if it's not in the model
16:18:09 jaypipes right
16:18:12 edleafe jaypipes: to be fair, you suggested the same thing :)
16:18:18 jaypipes that's what I thought we were going to do..
16:18:24 edleafe me too
16:18:40 jaypipes edleafe: not store in the DB. I suggested just tacking instance_uuids as a field on the object, since that would avoid an RPC API change.
16:18:43 mriedem it seems very not intuitive
16:18:51 dansmith jaypipes: it doesn't avoid an rpc change
16:18:55 mriedem 2 years from now someone is going to ask, wtf, why are these on this object but not in the db?
16:18:59 dansmith yeah
16:19:03 dansmith it's silly to do that
16:19:16 cdent there's nothing wrong with an rpc api change, and it is semantically clean. let's just do that.
16:19:17 jaypipes fine. call me silly. I don't care.
16:19:33 edleafe I've done it both ways, so I don't care either :)
16:19:33 cdent "that" == add a param
16:19:34 dansmith jaypipes: you know you're just generally silly anyway :)
16:19:38 jaypipes indeed.
16:19:54 jaypipes ok, follow on question...
16:20:37 jaypipes let's say we pass an instance_uuids param to the scheduler. cool, fine by me. But what about the whole "alternate destinations" thing that is designed to solve the no-cell-upcall issue?
16:20:46 jaypipes are we still going for that?
16:21:10 dansmith ...
16:21:22 dansmith have there been other suggestions on how to resolve that other than doing the alternates thing?
16:22:06 edleafe jaypipes: have you seen https://review.openstack.org/#/c/465767/ ?
16:22:21 cdent I gotta run, if there's a summary of this, can someone let me know somehow later this evening?
16:22:31 edleafe cdent: will do
16:22:36 cdent thanks
16:23:02 jaypipes dansmith: not that I'm aware of. was just trying to catch up my thoughts on this series.
16:23:08 dansmith okay
16:23:23 edleafe Adding alternates changes the result of select_destinations() from a list of hosts to a list of a list of hosts
16:24:12 jaypipes edleafe: and you/we are OK with that, yes?>
16:24:39 edleafe It wasn't my preference, no
16:24:52 edleafe But it was a big request from operators, so...
16:25:11 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/468089
16:25:20 mriedem alex_xu: oomichi: we're kind of at an impass with some of the new cinder attachment reviews - john and i are the only reviewers on these but i'm also working on the patches too, so we need a 3rd core to help move some stuff along, can you help review the 3 bottom changes in this series which already have a +2 from john? https://review.openstack.org/#/c/456896/
16:25:32 mriedem *impasse
16:29:35 jaypipes edleafe: is there a reason you undid Sylvain's changes from patch 10 on https://review.openstack.org/#/c/460177/10..11/nova/compute/resource_tracker.py?
16:29:57 jaypipes edleafe: I'd asked him to change the dict comprehension into a simple tracked_keys = set(self.tracked_instances.keys())
16:30:03 jaypipes edleafe: and you undid that.
16:30:26 jaypipes edleafe: and changed instance_uuid -> allocation_uuid.
16:30:31 edleafe jaypipes: probably a rebase screw-up
16:30:34 jaypipes edleafe: just a case of rebase screw up?
16:30:40 jaypipes edleafe: jinx :)
16:30:46 edleafe I rebased my series on master, and his is in the series

Earlier   Later