Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-07
14:29:34 mriedem not sure i understand the question
14:30:01 mriedem gibi: i tend to agree with your point that we should handle a failure in the conductor (NoValidHost) the same as it's being handled in the compute when a claim fails or the spawn fails on the dest node,
14:30:03 gibi mriedem: I agree that rebuild after failed evac is not a major use case but I know about users depending on it. So I don't really want to prevent it
14:30:11 mriedem which is set the migration status to a state such that _destroy_evacuated_instances on the source node doesn't process it,
14:30:15 mriedem and delete the dest node allocation
14:31:02 gibi mriedem: OK. then I think we can set the migration to failed, and then nova will not try to delete source allocation either after the source compute is brought up
14:31:04 mriedem gibi: given that rebuild does not allocate resources or make a claim, i think in that case it's actually preferrable to *not* attempt to delete the source node allocations if the evacuate failed,
14:31:16 gibi mriedem: totally agree
14:31:17 mriedem because if the evac fails and you want to rebuild the instance on the source node after it comes back up, then the allocations are still there
14:31:37 gibi I think that we are on the same page now :)
14:31:49 mriedem and if the evac fails on the dest node, regardless of location (conductor or compute), we put the migration status into a state such that the source node won't process it
14:31:53 mriedem when it's restarted
14:32:06 gibi mriedem: agreee
14:32:17 mriedem yeah, so drop your -1 on https://review.openstack.org/#/c/499237/ and i'll +1 that
14:32:26 gibi mriedem: OK
14:33:17 gibi mriedem: done
14:33:35 gibi mriedem: this also means I have nothing agains the force evacuate test cases any more
14:33:48 mriedem yay
14:33:52 gibi mriedem: so I'm going to drop -1 there too
14:33:55 jaypipes ffs, delta wants $3700 to change my wife's flight.
14:34:32 mnaser that's outrageous.
14:34:47 jaypipes mnaser: welcome to price gouging. :)
14:35:03 mnaser don't know if it's any help but apparently jetblue's doing $99 flights -- dont know how much of those are still available (and im sure you heard of them)
14:35:22 mriedem when i was looking at flights to china in may, the price changed in one hour and went up like $7K
14:35:26 jaypipes mnaser: they want to charge me $800 for a single 50-minute flight from Columbus, OH to Atlanta, GA.
14:36:01 jaypipes looks like there's a possibility I might miss Denver... :(
14:36:49 jaypipes latest European ensemble is terrible... https://twitter.com/cajunweatherman/status/905792235656138753/photo/1
14:38:09 alex_xu do we have wiki or etherpad for all the sessions and schedule in the PTG? I remember we have something in previous PTG
14:38:47 jaypipes alex_xu: I think ttx was putting together an ethercalc.
14:40:00 openstackgerrit Takashi NATSUME proposed openstack/nova master: List/show all server migration types (1/2) https://review.openstack.org/430608
14:40:24 alex_xu jaypipes: ah, let me try to find it
14:40:34 mriedem alex_xu: https://etherpad.openstack.org/p/nova-ptg-queens
14:40:42 mriedem oh http://ptg.openstack.org/
14:40:45 mriedem ^ is the home page
14:41:39 alex_xu mriedem: ah, thanks, surprise the home page change like that
14:41:50 mriedem well, it's the home page for devs
14:41:56 mriedem it's not the marketing glitzy homepage
14:42:47 mriedem gibi: don't forget this one https://review.openstack.org/#/c/499877/
14:43:09 gibi mriedem: I'm in the process of changing my vote there :)
14:43:14 mriedem whew
14:43:15 mriedem ok
14:43:48 mriedem i have to modify something in the 2nd to bottom patch for sylvain so i was waiting to do that
14:47:35 gibi I'm OK with the first 4 patches in that series and just started reading the 5th
14:55:46 dtantsur hi folks! I'm afraid to imagine how often you've heard this question, but.. what's the difference between nova migrate and nova evacuate?
14:55:54 dtantsur I'm figuring out which one fits better into https://review.openstack.org/449155
14:56:50 edleafe dtantsur: http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-confuse-us-all/
14:57:11 dtantsur thanks!
14:58:00 edleafe dtantsur: I keep that one handy, because after all these years it's still confusing
15:00:07 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Add documentation for emulator_thread_policy https://review.openstack.org/501721
15:00:55 stephenfin sahid, bauzas, gibi: ^ addressed sahid's comments
15:00:58 stephenfin I think...
15:03:12 gibi stephenfin: I think so too
15:04:15 bauzas stephenfin: +Wiiii
15:08:49 bauzas mriedem: so, 2 points
15:09:11 bauzas mriedem: just remove the upgrade reno and then I'll +2 https://review.openstack.org/#/c/499399/6
15:09:41 bauzas mriedem: also, about your skip_filters thoughts, just remember that we already have something called force_hosts
15:09:51 bauzas of course, that field is terribly named
15:10:22 bauzas but we could just not add yet again a new RPC API parameter, and rather just use the RequestSpec object for that
15:10:25 gibi stephenfin: I made an answer to your comment in https://review.openstack.org/#/c/463946/9/nova/tests/functional/notification_sample_tests/test_keypair.py@20
15:10:34 openstackgerrit Merged openstack/nova-specs master: Convert consoles code to use objects framework https://review.openstack.org/500975
15:11:03 bauzas mriedem: like, we could create a new field (and deprecate the legacy one) called forced_destination
15:11:12 bauzas having a Destination value
15:11:37 bauzas and so, if you pass a forced host, then the scheduler would claim
15:13:06 mriedem efried: ok is the first half of wednesday to your liking? https://etherpad.openstack.org/p/nova-ptg-queens
15:13:54 mriedem bauzas: i prefer an rpc parameter to select_destinations rather than hiding things in the already super confusing RequestSpec object
15:14:19 mriedem because force_hosts, requested_destination, and then a forced_destination would be even more complicate
15:14:20 mriedem *complicated
15:14:34 mriedem skip_filters in the rpc api parameters is pretty clear
15:18:42 gibi cores: there is a notification transformation patch only needs a second +2 if you are bored https://review.openstack.org/#/c/417882/
15:20:17 bauzas mriedem: I tend to prefer passing versioned objects than parameters on RPC APIs because I think it's clearer, you know
15:20:30 bauzas mriedem: the fact is that I agree with you, we should get rid of forced_hosts
15:20:52 bauzas mriedem: but I was just proposing to only use 2 fields : one for requesting the scheduler filters, one for not
15:21:02 bauzas that could be a comment in the object
15:21:17 mriedem i guess it will probably come down to whether or not we need to persist that information for later
15:21:26 bauzas we already have a long list of explicit parameters in the API method, and I'm not sure it's cool
15:21:40 bauzas mriedem: we have an helper method for that in the object
15:21:51 bauzas mriedem: and there are fields that aren't persisted already
15:22:08 bauzas so, maybe the work consists of making the line clearer in between what requires to be persisted and what's not
15:22:24 bauzas I could do that
15:22:31 stephenfin sdague: Nice little doc cleanup here, if you're interested https://review.openstack.org/#/c/501342/
15:23:33 mriedem def select_destinations(self, ctxt, spec_obj, instance_uuids):
15:23:36 mriedem bauzas: ^ is a long list?
15:24:42 bauzas mriedem: you know we had a problem with instance_uuids being different from what we have in the spec object, so I'd say one parameter is maybe too much
15:25:16 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove dest node allocation if evacuate MoveClaim fails https://review.openstack.org/499878
15:25:30 bauzas mriedem: the real crux of the problem is that I never explicited whether the RequestSpec object you pass is either the original spec or the amended spec in case of a move
15:26:01 mriedem gdi now my git review push failed
15:26:20 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove dest node allocation if evacuate MoveClaim fails https://review.openstack.org/499878
15:26:20 openstackgerrit Matt Riedemann proposed openstack/nova master: Pass migration from API to conductor for evacuate https://review.openstack.org/500176
15:26:21 openstackgerrit Matt Riedemann proposed openstack/nova master: Add a test to make sure failed evacuate cleans up dest allocation https://review.openstack.org/499877
15:26:22 openstackgerrit Matt Riedemann proposed openstack/nova master: Add recreate test for evacuate claim failure https://review.openstack.org/499874
15:26:22 openstackgerrit Matt Riedemann proposed openstack/nova master: Create allocations against forced dest host during evacuate https://review.openstack.org/499399
15:26:23 openstackgerrit Matt Riedemann proposed openstack/nova master: Refactor out claim_resources_on_destination into a utility https://review.openstack.org/499718
15:26:23 openstackgerrit Matt Riedemann proposed openstack/nova master: Modernize set_vm_state_and_notify https://review.openstack.org/499799
15:26:39 bauzas do folks agree with the fact that we should disable reschedules if someone is requesting a destination when cold migrating ?
15:26:43 mriedem the bottom change there is going to need to be re-approved
15:26:54 bauzas mriedem: ack will do
15:27:31 mriedem don't we already restrict reschedules like that in some other case?
15:28:17 bauzas mriedem: we don't reschedule for both evacuate and live-migrate
15:28:28 bauzas we only reschedule for two cases : boot and resize
15:28:38 mriedem well, we do reschedule for live migrate

Earlier   Later