Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-05
16:05:54 mriedem 2. superconductor:resize_instance -> compute:prep_resize -> cellconductor:resize_instance
16:05:54 mriedem 1. superconductor:schedule_and_build_instances -> compute:build_and_run_instance -> cellconductor:build_instances
16:06:07 mriedem well, looking at https://review.openstack.org/#/c/511358/29/nova/compute/manager.py
16:06:18 mriedem it looks like it would be a matter of passing host_list to prep_resize in the compute
16:07:01 mriedem and like what you have here in conductor manager (this is cell conductor at this point during a reschedule):
16:07:04 mriedem https://review.openstack.org/#/c/511358/29/nova/conductor/manager.py@517
16:07:46 mriedem you would have to do the same for the resize reschedule here https://review.openstack.org/#/c/511358/29/nova/conductor/api.py@87
16:07:53 edleafe ok, next question: should I add that all to the existing patches, or split it into two?
16:08:01 mriedem now, we could arguably do the build and resize + alternates in separate patches
16:08:05 mriedem heh
16:08:14 mriedem split is obviously easier for review
16:08:20 mriedem it would mean 2 compute rpc version bumps
16:08:29 mriedem but service version bumps are free, so i don't think that's a big deal
16:08:33 mriedem dansmith: ^ agree?
16:09:55 edleafe ok, so I'll leave return_alternates=False in the current patch, and then flip it when in a new patch that bumps the compute RPC again.
16:10:07 mriedem makes sense
16:10:13 edleafe ok
16:11:26 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix doubling allocations on rebuild https://review.openstack.org/521662
16:11:28 mriedem jaypipes: ^ is that cve fix (now disclosed) with the bug link and a release note; melwitt can you also look at ^
16:12:40 melwitt mriedem: sure
16:13:09 dansmith mriedem: I like to avoid bumps of both rpc and service version when possible, and it usually is.. but yes, they're free
16:24:28 bauzas mriedem: just +2d the cve fix
16:24:42 mriedem bauzas: thanks
16:24:52 bauzas now the bug is disclosed, we can move on
16:25:13 bauzas sorry for having paid a lot of attention for that bug tho, but the overall direction looked good to me a while ago
16:25:20 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix doubling allocations on rebuild https://review.openstack.org/523214
16:25:20 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Add regression test for rebuild with new image doubling allocations https://review.openstack.org/523213
16:25:31 bauzas ie. using the hints for passing whether it's a rebuild or not
16:30:04 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix doubling allocations on rebuild https://review.openstack.org/523214
16:32:51 mriedem sdague: can you hit https://review.openstack.org/#/c/523194/ again? alex had pointed out something so i lost your +2
16:46:32 openstackgerrit Ed Leafe proposed openstack/nova master: Refactor the code to check for sufficient hosts https://review.openstack.org/520242
16:46:32 openstackgerrit Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239
16:46:33 openstackgerrit Ed Leafe proposed openstack/nova master: Move the to_dict() method to the Selection object https://review.openstack.org/523492
16:46:33 openstackgerrit Ed Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver https://review.openstack.org/495854
16:46:34 openstackgerrit Ed Leafe proposed openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/516707
16:46:34 openstackgerrit Ed Leafe proposed openstack/nova master: Modify select_destinations() to return objects and alts https://review.openstack.org/510159
16:46:35 openstackgerrit Ed Leafe proposed openstack/nova master: Make conductor pass and use host_lists https://review.openstack.org/511358
16:46:35 openstackgerrit Ed Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils https://review.openstack.org/511357
16:46:39 edleafe mriedem: ^^ addresses your concerns
16:47:11 edleafe mriedem: I'll start on the migrate/resize patch next
16:47:27 jaypipes mriedem: cool, will look shortly, soon as I finish up a rebase of efried_cya_wed's series
16:48:21 mriedem edleafe: ok
17:11:32 melwitt mriedem: now that we're pulling in the dependent os-brick changes, I'm +2 on https://review.openstack.org/#/c/400384
17:32:40 jaypipes cdent: still around?
17:32:53 cdent yessir, still fighting with this grenade stuff
17:33:28 jaypipes cdent: so I don't believe those comments on the API ref thing on the nested resource providers work are correct...
17:33:51 cdent was just reading your responses, one sec
17:34:50 jaypipes I'm also getting sort of annoyed with this :)
17:35:04 cdent jaypipes: I think the confusion is whether what’s listed at /resource_providers is the full rep or not
17:35:17 cdent and up to now it has been: generation, uuid, name, links
17:35:37 cdent https://developer.openstack.org/api-ref/placement/#list-resource-providers
17:35:43 jaypipes no, up until now it's been incorrect. it lists resource_providers (the collective attribute), along with the singular attirbutes
17:36:06 cdent which “it” do you mean?
17:36:21 jaypipes GET /resource_providers response
17:36:48 cdent so you’re saying that for the past 13 microversions what we’ve had at that link above (expand the response example) has been wrong?
17:37:17 jaypipes cdent: I don't see how listing *both* resource_providers (the collective attribute) AND the singular attributes at the same time can be correct.
17:37:38 cdent it’s a list of resource provider objects:
17:37:45 jaypipes yes...
17:37:49 jaypipes and that's all
17:37:55 cdent https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/resource_provider.py#L110
17:38:15 cdent and the api_ref is set up to list anything, not just the top level things
17:38:25 jaypipes cdent: since when?
17:38:30 cdent since the dawn
17:38:36 cdent we have made expections in the past
17:38:44 jaypipes cdent: why bother having the top-level element at all then? that's just silly IMHO
17:39:06 jaypipes cdent: with no indication of the "level" the attribute is expected to appear at
17:39:07 cdent don’t look at me man, I think the rules on the api-ref are … weird
17:40:02 cdent there has been work done in the nova api-ref (I think?) to indicate path.to.attribute but we’ve not picked it up in placement
17:41:02 jaypipes meh, screw it, I'll just make the damn changes (again, again)
17:41:28 openstackgerrit Dan Smith proposed openstack/nova master: Make live migration hold resources with a migration allocation https://review.openstack.org/507638
17:42:11 cdent jaypipes: I think the descending paths thing was worked on near: https://review.openstack.org/#/c/464277/ but I’m not sure if it got anywhere
17:42:29 jaypipes cdent: so is Takashi asking me to put a required: true line in for parent_provider_uuid/root_provider_uuid but only in the response parameter listings?
17:43:55 cdent my read was that he wants the response body to be fully described and the usual way to do that in the case when it is optional is the request body is to inherit the yaml anchor and changed required: false to true
17:44:34 cdent jaypipes: I think it would probably be okay to punt it to a followup (one that perhaps someone else did)
17:45:09 jaypipes cdent: I just don't know what is being asked of me.
17:45:11 cdent jaypipes: the reasons require: true isn’t marked on those guys is because required is the default, isn’t it?
17:45:45 cdent in that case I’d say let’s punt and do it in a followup so it can be looked at separately and more clearly understood
17:45:57 jaypipes cdent: I think he's saying that the *response* always has parent_provider_uuid and therefore the *response* parameter list should have required: true.
17:46:04 cdent my brain is not in that frame right now so can’t tell you something clear and straightforward
17:46:23 cdent effectively yes
17:47:30 cdent I’ve changed my vote for now, in case that helps move things along
17:49:46 openstackgerrit Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215
17:49:47 openstackgerrit Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
17:49:47 openstackgerrit Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
17:49:48 openstackgerrit Jay Pipes proposed openstack/nova master: SchedulerReportClient._get_providers_in_tree https://review.openstack.org/520663
17:49:48 openstackgerrit Jay Pipes proposed openstack/nova master: Scheduler set_inventory_for_provider does nested https://review.openstack.org/520643
17:49:49 openstackgerrit Jay Pipes proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756
17:49:49 openstackgerrit Jay Pipes proposed openstack/nova master: SchedulerReportClient._get_providers_in_aggregates https://review.openstack.org/521097
17:49:50 openstackgerrit Jay Pipes proposed openstack/nova master: WIP: ComputeDriver.update_provider_tree() https://review.openstack.org/521187
17:49:50 openstackgerrit Jay Pipes proposed openstack/nova master: Scheduler[Report]Client.get_provider_tree https://review.openstack.org/521098
17:49:51 openstackgerrit Jay Pipes proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246
17:52:04 jaypipes cdent: would you mind looking at https://review.openstack.org/#/c/377215/ and making sure I've added everything you wanted please?
17:54:52 cdent jaypipes: I think your rebase has gone funk as ps70 has the same stuff as ps62 (in the test file), but there were changes in the middle :(
17:55:29 jaypipes god damn this.
17:57:18 jaypipes I am so fucking sick of this bullshit sliced up and frankensteined set of patches at this point.
17:58:03 jaypipes all this to try and get Eric's WIP patches aligned with what's already been merged. :(
17:58:36 edleafe jaypipes: welcome to my world :)
17:59:03 jaypipes edleafe: how's that? doesn't your series only have like 4 patches in it? are there 7 different branches of that series?
18:00:00 jaypipes cdent: also, it's not ps62. it was fine in ps69 and then ps70 undid all that work :(*
18:01:01 jaypipes clarkb: you had a shortcut for how to essentially revert just the last revision on a series... can you tell me what that was again?

Earlier   Later