Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-06
15:17:11 mriedem yeah i saw the novel
15:17:13 tssurya superdan: I can..
15:17:14 mriedem again, tl;dr
15:17:28 mriedem fried_rice: also, is that job supposed to actually run tests? http://logs.openstack.org/61/555961/3/check/openstack-tox-lower-constraints/91b6d17/job-output.txt.gz#_2018-04-06_13_19_18_865706
15:17:30 mriedem b/c it doesn't
15:17:35 superdan and we should change those docs, I imagine they're in that order for the same reason
15:18:23 mriedem fried_rice: so -1 on that
15:19:24 superdan tssurya: okay I'll tweak the doc
15:19:29 fried_rice mriedem: Okay. The requirements-check job sure works (cause that's what held up PS1 and PS2). But yeah, I don't know anything beyond that.
15:19:36 tssurya although mriedem says he prefers a "Add a from-queens script" to swapping
15:19:52 mriedem no i don't prefer that
15:20:04 mriedem i said, "Option #1 seems a bit shady, but option #2 seems excessive, especially if we're going to be changing things in the API DB in future releases."
15:20:19 mriedem in other words, i'm hedging
15:20:35 tssurya okay sorry so its the shady one then
15:21:16 superdan I don't think it's shady, I think it's been wrong for a long time, hidden by the fact that we run devstack (in the proper order) first before grenade
15:21:18 mriedem if we added a from-queens script, per grenade guidelines, we'd also need a nova release note in rocky saying you need to run nova-manage api_db sync before nova-manage db sync
15:21:20 jgwentworth heh, I think it was shady assuming there was a good reason for the current ordering, which there apparently isn't
15:21:31 superdan yeah
15:21:43 odyssey4me mriedem alright, I've pushed up an OSA patch to test out the shady option: https://review.openstack.org/#/c/559354/1/tasks/nova_db_setup.yml
15:21:54 tssurya superdan : should I do the docs in the same one then ?
15:22:03 odyssey4me that'll make api_db sync before before db
15:22:06 superdan tssurya: I'm doing the doc patch, if you can do grenade
15:22:16 tssurya superdan: okay :)
15:22:28 odyssey4me go.... TEAM! ;)
15:22:36 mriedem odyssey4me: that will affect both base install and upgrade?
15:22:46 odyssey4me mriedem yep
15:23:08 jgwentworth \o/
15:24:28 fried_rice mriedem: Looking over dhellmann's email again, it's possible that the no-op-ness of that job is intentional; to be switched on at some point in the future once the dust has settled. This is just setting up the framework.
15:24:56 mriedem fried_rice: well the commit message is clearly misleading then
15:25:17 fried_rice mriedem: But... I guess I'll let dhellmann respond to your -1. I was just trying to take over since he's got a few hundred of these up in the air.
15:25:29 jgwentworth so we set our constraints manually and the job makes sure all of the components work together with the versions they've required?
15:25:34 odyssey4me mriedem if install must do a different order to upgrade, then that's not awesome - but we can adjust... but as it stands now it looks like our api_db sync happened first on upgrade only, but the db sync didn't happen before the cell mapping... so I can adjust the sequence to just move when the db sync happens if that's more sensible
15:25:59 mriedem odyssey4me: this might be fine, we'll see; i was wondering why there were redundant api db syncs in there before
15:26:32 mriedem i guess the first one was trying to be sly
15:26:40 mriedem and a one time only thing on install
15:27:39 odyssey4me yeah, I believe there was a sequence difference between new environment vs upgrade
15:28:05 mriedem odyssey4me: left a comment, i think this might fail
15:28:08 mriedem we'll see
15:28:23 openstackgerrit Dan Smith proposed openstack/nova master: Clarify/correct the ordering of API and Cell database schema updates https://review.openstack.org/559357
15:28:26 superdan ooh, look how many words!
15:29:39 jgwentworth you dun good
15:30:46 odyssey4me mriedem question to clarify before I revise
15:30:51 odyssey4me (in review)
15:33:50 tssurya https://review.openstack.org/#/c/559358/
15:35:45 superdan tssurya: comments on the commit message
15:35:53 tssurya looking
15:36:02 superdan also probably need jgwentworth's sign-off on the final version before we put it in
15:36:14 superdan we usually try to require that for things like this in grenade
15:36:55 tssurya sure :)
15:37:04 jgwentworth I shall ack it
15:38:37 superdan tssurya: if my friday-speak wasn't clear enough on that review let me know and I'll try to plain it up a little
15:39:50 sususuryashines superdan: yes please
15:40:04 jgwentworth hah, good friday nick
15:40:14 sususuryashines for starters did you only want a change in explanation or the title also seems odd to you ?
15:40:30 superdan no, the title seems okay
15:40:33 sususuryashines jgwentworth: heh thanks ;)
15:40:39 superdan let me just write what I think it should be
15:41:55 mriedem sususuryashines: you could just lift from this https://review.openstack.org/#/c/559357/
15:42:47 sususuryashines mriedem: yes I thought so at first, but that commit message is a little different from superdan's recommendations on my commit message.
15:43:27 mriedem it's different in that it doesn't have all the meh and stuff :)
15:44:23 superdan sususuryashines: left a suggested block of text
15:44:52 sususuryashines superdan: historical :)
15:45:03 sususuryashines ack, will read and change
15:45:04 sususuryashines thanks
15:45:08 superdan sususuryashines: it's a lot like my doc patch, but a little more grenade-y.. feel free to re-write it in your words, I just want it to sound more like "oops, this was wrong all along" and not "we decided to change this when something broke"
15:45:29 sususuryashines superdan: ack
16:12:57 mriedem fried_rice: thanks for going over https://review.openstack.org/#/c/558001/ - i left some replies, will wait on you before making any changes there
16:13:06 fried_rice mriedem: ack
16:13:37 mriedem i think at this point it's likely easiest to say, "if you use OVS everywhere, just set this to True"
16:14:04 mriedem if you're mnaser and enjoy pain, then leave it False
16:14:10 mnaser hi
16:14:23 mriedem just making a little ODL joke
16:14:26 mriedem at your expense
16:14:54 mnaser oh
16:15:10 mnaser mriedem: if you're really into pain then you're run nova with multiple network backends
16:15:26 mnaser s/run/running/
16:15:29 mnaser s/running/trying to run/
16:15:41 mriedem yeah, that's what the new config option in that patch is for
16:15:56 mnaser thanks for the ping about it though
16:19:38 mriedem kashyap: ever seen this live migration failure? http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm-multinode-live-migration/8de6e74/logs/screen-n-cpu.txt.gz?level=TRACE#_Apr_05_21_48_43_258043 i've seen this in a few different live migration runs this week
16:19:43 mriedem VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8
16:19:53 mriedem error while loading state for instance 0x0 of device '0000:00:04.0/virtio-blk'
16:22:44 mriedem http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm-multinode-live-migration/8de6e74/logs/subnode-2/libvirt/qemu/instance-00000002.txt.gz
16:24:23 mriedem found https://bugzilla.redhat.com/show_bug.cgi?id=1450524
16:24:23 openstack bugzilla.redhat.com bug 1450524 in qemu-kvm-rhev "qemu-kvm: VQ 0 size 0x100 Guest index 0x2010 inconsistent with Host index 0x2171: delta 0xfe9f" [High,Closed: worksforme] - Assigned to jasowang
16:24:44 arvindn05 mriedem: i added comments to https://review.openstack.org/#/c/541507/9
16:24:56 fried_rice mriedem: Responded
16:25:30 arvindn05 also had a question on https://review.openstack.org/#/c/546357/ - Skip placement on rebuild in same host
16:26:00 arvindn05 why are we allowing the skipping placement given we know the image can now contain qualitative aspects?
16:26:46 arvindn05 also what if the qualitative aspects in the flavor changes? would we want to run placement in this case as well??
16:28:35 mriedem arvindn05: for one, we aren't yet allowing images with required traits
16:28:47 mriedem that patch fixes a bug which has to go back to pike
16:28:58 mriedem two, rebuild doesn't take a new flavor
16:29:28 arvindn05 ahh...missed that it was pike...
16:29:39 mriedem rebuild does take a new image, and the image meta could change, so we have to re-run some scheduler filters
16:29:49 mriedem this patch is master, but fixes a bug that was introduced in pike
16:30:11 arvindn05 for #2, it doesnt need to take a new flavor right? if the flavor was updated for the instance, then we might want to run placement
16:30:21 mriedem arvindn05: my point was, once we do start accepting images with required qualitative traits, the logic in this bug fix will likely need to change, as part of your blueprint
16:30:38 mriedem arvindn05: the flavor doesn't get updated for the instance unless you resize the instance
16:30:47 mriedem in which case you're not doing a rebuild, you're doing a cold migration with a new flavor

Earlier   Later