Earlier  
Posted Nick Remark
#openstack-nova - 2017-09-06
21:03:19 mnaser for me it's the fact that it makes it more comfortable to backport this sort of thing (which i hope we can do to stable/pike)
21:03:21 dansmith so putting more things in that basket when we already have an instance created in a real cell seems wrong to me
21:03:26 dansmith mnaser: right, so,
21:03:29 dansmith I was going to suggest:
21:03:42 dansmith how about we let mnaser do the simpler but uglier thing of only mapping if we hit that quota check,
21:03:44 melwitt dansmith: yeah, agreed
21:03:54 mriedem and then collapse the loops in queens only
21:03:56 mriedem i like that
21:03:57 dansmith backport that mofo' and then do this cleanup separately with a functional test to get rid of the two loop
21:04:00 dansmith yeah
21:04:24 mnaser i think that would be best: so that stable can remain stable and you have plenty of time to review a much bigger change like that :>
21:04:28 mnaser and you're not worried about stable breaking
21:04:42 mriedem mnaser: btw, how is it that vexxhost is already on pike code?
21:04:47 dansmith I think that's reasonable
21:05:05 dansmith mriedem: you mean "thank you for already being on pike" right?
21:05:06 mnaser mriedem puppet+rdo packages, trusting the openstack CI and puppet-openstack-integration we use
21:05:07 mnaser aha
21:05:12 mriedem dansmith: yes
21:05:26 dansmith thought so
21:05:27 dansmith :)
21:05:29 mriedem i'm just impressed and happy i mean
21:05:35 mnaser honestly it was an easy upgrade
21:05:37 melwitt yeah, it's awesome ppl are running pike
21:05:42 mnaser newton->ocata was a bit of uh a mess
21:05:56 mnaser 400,000 records being mapped in the new default cell?
21:05:59 mriedem well, placement and cells v2
21:06:01 mnaser takes a little while :p
21:06:18 mnaser i backported the placement puppet manifests so we had placement running in newton so it was *one less thing* to worry about
21:06:27 mriedem smart
21:07:02 dansmith https://twitter.com/get_offmylawn/status/905537805903941633
21:07:22 mnaser :>
21:07:30 melwitt f yeah
21:08:02 mnaser also well
21:08:10 mnaser running vanilla openstack means we don't much around a lot :)
21:09:17 jaypipes mnaser: ++ :)
21:09:28 mnaser so do we come to quorum to leave things as is except call set cell mapping in the exception handling code?
21:09:37 melwitt running vanilla openstack is the way to go. I have been part of running custom openstack and regretted doing it that way
21:09:39 dansmith mnaser: yeah
21:10:24 mnaser or i'll add a note as well
21:11:11 mriedem TODO i'd say
21:11:19 mnaser damn
21:11:21 mnaser um
21:11:21 mriedem you'll also have to keep track of which cells each instance goes into
21:11:23 mnaser i dont know what cell
21:11:24 mnaser yeah
21:11:32 mnaser i'll have to figure out a clean way to do that
21:11:36 mriedem just save that into a dict in the first loop
21:11:44 mnaser alright
21:12:47 mriedem everything already goes into that instances list variable, and is sometimes None for things that failed, but for things that did get mapped, i think you could map the instance uuid to the cell in a dict and then use those 2 variables to do the mapping in the failure block
21:12:57 mriedem s/mapped/created/
21:13:57 mriedem hmm, i think i just realized another bug here
21:14:03 dansmith um
21:14:06 dansmith hah yesh
21:14:12 mriedem we're always mapping to the last cell
21:14:14 dansmith yeah
21:14:17 mriedem :)
21:14:27 dansmith oof
21:15:27 dansmith mnaser: so you might want to stack your change on top of the fix for that bug
21:15:35 dansmith which I can cook up
21:15:54 mnaser okay cool, ill work on the stuff to set mappings
21:17:45 dansmith mriedem: I'm guessing that this would have uncovered that if I had ever finished it: https://review.openstack.org/#/c/452006/
21:18:41 dansmith ah, no,
21:18:44 mriedem https://bugs.launchpad.net/nova/+bug/1715493
21:18:44 dansmith that's the migrate one
21:18:45 openstack Launchpad bug 1715493 in OpenStack Compute (nova) "Instances always get mapped into the last processed cell in conductor" [High,Triaged]
21:19:55 dansmith I guess this bug came from splitting that loop amirite?
21:19:58 mriedem yup
21:20:11 mriedem so when we combine we can remove both workarounds
21:20:17 dansmith yeah
21:20:24 openstackgerrit Chris Dent proposed openstack/nova master: WIP: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073
21:20:25 melwitt ugh :(
21:20:25 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Allow _set_allocations to delete allocations https://review.openstack.org/501051
21:20:35 mriedem plus, if mnaser's patch creates a instance -> cell mapping dict to keep track, the 2nd loop could use that too
21:20:43 dansmith yeah
21:20:52 openstackgerrit Dan Smith proposed openstack/nova master: Track which cell each instance is created in and use it consistently https://review.openstack.org/501452
21:21:02 dansmith gonna work on tests, but pushed this up in case I have to run ^
21:25:16 dansmith hmm, we kinda have a test for this, I'm not sure why it's not failing
21:29:32 mnaser dansmith is it okay that when i try to do git review with your patch below mine, it mentions that it will submit two commits?
21:29:44 dansmith mnaser: yep
21:29:49 mnaser okay cool
21:29:53 openstackgerrit Mohammed Naser proposed openstack/nova master: Ensure instance mapping is updated in case of quota recheck fails https://review.openstack.org/501408
21:30:05 mnaser oh it didnt send both, nice. that's leveraging your cell_instance_cache
21:30:15 mnaser oh i should update the commit msg
21:30:22 melwitt mnaser: I usually double check to make sure the commit hash of the dependent change is the same as what shows on the review being rebased upon
21:30:41 melwitt that's how you can tell whether it will push more than just your change
21:30:51 mnaser melwitt oh, if it matches it wont submit it? i'm just terrified of the embarassement that happens sometimes when an irc channel gets spammed :p
21:31:10 mriedem mnaser: git review -R also avoids the rebase of the base changes
21:31:19 melwitt mnaser: yeah. if the hash hasn't changed it won't submit it. so you can know before you do it
21:31:28 mriedem melwitt: btw i think i figured out the git review / rebase author change thing,
21:31:36 mriedem it happens when rebasing on a series that involves a merge conflict,
21:31:46 mriedem so you rebase, merge conflict, fix, git add / commit, git rebase continue
21:31:50 mriedem and that has changed the author
21:32:05 openstackgerrit Mohammed Naser proposed openstack/nova master: Ensure instance mapping is updated in case of quota recheck fails https://review.openstack.org/501408
21:32:19 melwitt weird. I feel like I've rebased other ppl's changes with merge conflict and it didn't change the author before
21:32:32 mnaser there, that should have most of it covered
21:32:34 melwitt but, that's great data to go on. I'll pay attention next time
21:33:31 dansmith okay, the test I thought we had was build not schedule_and_build
21:33:42 dansmith I have to board soon, but I can work on tests for this on the plane unless someone else wants to?
21:34:28 mnaser i'd help but it sits outside my relm of knowledge :) have a safe flight though dansmith
21:35:14 dansmith mnaser: np, thanks

Earlier   Later