Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-08-17
14:52:45 gibi dansmith: hi! Could you check the bugfix for the missing cleanup at evacuation https://review.openstack.org/#/c/493037/ ? Jay is +2 about it.
14:58:04 dansmith gibi: this is another thing we need for pike I guess?
14:58:15 dansmith sorry I hadn't noticed this yet
14:58:36 cdent gibi: why is remove_provider… what is wanted there? is the instance destroyed globally, or just on the compute node?
14:59:06 cdent “evacuate” is a very confusing term
14:59:54 cdent ah, I see from the tests, we want some allocations left over
15:00:23 gibi dansmith: I guess this is something that worked in Ocata but doesn't in Pike RC1 so yes we need a backport
15:00:50 gibi cdent: we want to remove the allocation from the source host of the allocation
15:00:57 gibi cdent: we want to remove the allocation from the source host of the evacuation
15:01:17 gibi cdent: so the source host will be the removed provider
15:01:47 cdent gibi: yeah, I figured that out after looking at the tests. I was struggling to remember the meaning of evacuate
15:02:09 gibi cdent: I agree that evacuate should be renamed to recreate
15:02:22 gibi dansmith: we have a similar bug in shelve offload https://bugs.launchpad.net/nova/+bug/1710249
15:02:23 openstack Launchpad bug 1710249 in OpenStack Compute (nova) "nova doesn't clean up the resources after shelve offload" [High,In progress] - Assigned to Balazs Gibizer (balazs-gibizer)
15:02:34 dansmith gdi gibi stop finding bug! :)
15:02:36 dansmith *bugs
15:03:08 gibi dansmith: I don't want to make you mad but I'm currently looking at soft delete + periodic reclaim and that seems buggy as well...
15:03:15 cdent woot!
15:03:25 dansmith gibi: nooooo :P
15:04:20 gibi dansmith: but on the plus side simple migrate confirm / revert works based on https://review.openstack.org/#/c/493865/
15:04:29 dansmith that's cool
15:04:48 openstackgerrit Maciej Jozefczyk proposed openstack/nova master: Remove host filter for _cleanup_running_deleted_instances periodic task https://review.openstack.org/491808
15:06:16 gibi dansmith: but I will be on vacation for a week starting at next Tuesday so my bug flow will decrease ;)
15:08:24 dansmith gibi: good :)
15:08:30 dansmith gibi: can you propose that against pike?
15:08:50 cdent gibi: I rebased matt’s https://review.openstack.org/#/c/490733/ yesterday, and because of all your bug finding and fixing it needs a pretty manual rebase, but once we finally get going with shared providers, it will be handy
15:09:48 gibi dansmith: do you mean the evacuate one or both the evac and the shelve offload patches?
15:10:00 dansmith jaypipes: still around?
15:10:37 dansmith gibi: the evacuate one for now since it's on the way to the gate. I'm looking at the shelve one now
15:10:48 gibi cdent: ack, I will review that
15:11:03 gibi dansmith: OK
15:12:08 jaypipes dansmith: yyup
15:12:10 maciejjozefczyk dansmith: I've updated https://review.openstack.org/#/c/491808 ; looks good now?
15:12:29 dansmith jaypipes: can you go over this one too? I'm doing so as we speak: https://review.openstack.org/#/c/493834
15:12:37 dansmith maciejjozefczyk: will look in a sec
15:13:01 jaypipes dansmith: ah, yeah, I owed gibi a re-review on that one. doing it now.
15:13:32 dansmith jaypipes: pretty sure you owe gibi a kidney or something by now, but.. yeah thanks
15:13:57 jaypipes dansmith: indeed :)
15:16:17 gibi I have two health kindeys but maybe we can freeze them for later use :)
15:16:55 dansmith gibi: now, but later you may need one unexpectedly
15:17:15 dansmith gibi: or did you mean freeze the one jaypipes owes you?
15:17:30 dansmith because yeah, another ten years of crunchy bars and his'll be useless
15:17:34 dansmith so good idea to freeze now
15:17:43 gibi dansmith: yeah, exaxtly
15:17:59 dansmith good call
15:19:19 gibi English is hard
15:19:48 jaypipes dansmith, gibi: k, +2 from me on that one.
15:19:59 dansmith heh
15:20:09 jaypipes the patch, not the freezing part :)
15:20:15 dansmith jaypipes: got one more for you in just a sec
15:20:32 jaypipes k
15:20:46 dansmith jaypipes: https://review.openstack.org/#/c/491808
15:20:58 dansmith jaypipes: you were +2, I just had some comments on test coverage, but looks good to me now
15:21:13 dansmith maciejjozefczyk: I'm assuming we should put that into pike as well
15:21:33 jaypipes ah, maciejjozefczyk and dpawlik's patch
15:21:54 cdent I’m in a quandry: If I want to keep jay’s kidneys healthy, for the sake of gibi, then I shouldn’t deliver crunchie bars.
15:22:15 dansmith heh
15:22:23 gibi cdent: or, we have to freeze that kindey before you deliver
15:22:32 jaypipes dansmith: k, +Wallaby'd maciejjozefczyk's patch.
15:22:54 dansmith thanks
15:23:09 dansmith gibi: +W on the shelve patch, so please propose that for pike too
15:23:24 gibi dansmith: thank. I will do it
15:23:28 maciejjozefczyk jaypipes: dansmith thx
15:24:21 dansmith maciejjozefczyk: you too for pike
15:24:48 gibi dansmith: what is the policy? Only propose the bugfix on stable or both the functional test and the bugfix in two separate patches or maybe squash them?
15:25:14 dansmith gibi: never squash unless you have to,
15:25:25 dansmith gibi: but are you talking about your "replace chance" patch?
15:26:09 gibi dansmith: nope. both the evac and the offload fix consist of two patches one for the functional test and one for the bugfix
15:26:31 dansmith gibi: oh and the functional test are already in tree, right?
15:26:49 gibi dansmith: for the shelve it is still on review https://review.openstack.org/#/c/493062/
15:27:02 gibi dansmith: the evac test is in the master but not on stable pike
15:27:04 dansmith oh heh, I see now, I was confusing
15:27:21 dansmith gibi: for both just backport all the patches as they are
15:27:36 gibi dansmith: OK
15:28:00 dansmith gibi: I was looking at that shelve test in the shelve fix and thinking "oh I didn't see this go in, but this is nice"
15:28:01 dansmith didn't realize there was another below it
15:28:28 gibi dansmith: yeah, too many patches
15:28:37 dansmith jaypipes: you on that one?
15:30:55 jaypipes dansmith: looking...
15:33:29 gibi just a note, previously I mentioned a possible bug in soft_delete + periodic reclaim. It turned out that it was a missing _run_periodics() in the test case.
15:36:51 jaypipes dansmith: k, done.
15:37:06 jaypipes I'm heading out now...
15:38:17 cdent gibi: no kidney for you!
15:39:12 gibi cdent: but then jaypipes-afk can eat more crunchies :)
15:55:08 efried cdent Thanks for https://review.openstack.org/489537
15:55:33 cdent seemed it would save some trouble
15:56:06 efried cdent Depends how urgent their bug is. I'm not sure mine is gonna move until I've got the q bp approved.
15:56:53 cdent true. but also: I’ve got mixed feelings about interface types...
15:57:38 efried cdent Feel free to comment in my review. Though I may just wind up refereeing while you & mordred slog it out.
15:58:22 cdent efried: I don’t think the fight is warranted or necessary: This is another one of those cases where reality is up to no good and I’m on the idealism side.
15:58:35 cdent it keeps happening
15:59:06 efried tbh, I really don't have any of the history wrt interfaces, so I'm just doing what I'm told there.
15:59:25 mordred efried, cdent : oh - so ... my only fight is that this isn't quite friendly enough
15:59:51 mordred we added interface as a list for a reason -so that the default could be ['internal', 'public'] meaning that almost nobody would ever have to change the value
15:59:53 mordred BUT
16:00:07 mordred if we can't get that plumbed in all the way for now - I'm totally on board with teh default for ironic eing internal
16:00:38 mordred end-goal should be to be able to sanely use the list so that most operators never have to touch the setting at all
16:01:26 mordred oh. hah. that's what cdent was saying already isn't it?
16:01:56 efried I actually don't know what cdent was referring to by "mixed feelings about interface types" :)
16:02:30 cdent mordred: no, my position is more idealistic than that: there shouldn’t be any such thing in the service catalog as an interface type. there should be one and only one service url per service

Earlier   Later