Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-14
14:50:59 mriedem i noticed that the rocky one was added in stein https://review.opendev.org/#/c/589972/
14:51:33 dansmith mriedem: right, that wiki link means like "in rc2 when we know we're not going to be adding anything else to the rpc api"
14:51:43 gmann mriedem: true. initially i added name change as part of other policy changes but then we dropped that as it was changing every policies. i agree that doing it separately is not so much gain.
14:51:51 dansmith mriedem: I think after auto came on the scene we got a little lax about that
14:52:16 dansmith mriedem: and certainly people using a numbered version that has nothing to do with "train", that word means not very much to them
14:52:28 openstackgerrit Nicolas Belouin proposed openstack/nova master: Add support for Xen PVH VM Mode in libvirt driver https://review.opendev.org/687827
14:54:38 mriedem ok i'd push the patch but i'm rebasing this cross-cell series which will take awhile,
14:54:42 mriedem if someone else wants to push it i'd +2
14:56:14 dansmith ack I can do it
14:56:26 dansmith waiting for that conductor patch to land before rebasing mine
14:58:37 openstackgerrit Dan Smith proposed openstack/nova master: Update compute rpc version alias for train https://review.opendev.org/688418
14:58:46 dansmith eff, conductor patch failed, might as well rebase now I guess
15:00:32 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor rebuild_instance https://review.opendev.org/688419
15:00:42 dansmith hmm, I don't see that 2.80 patch in the queue
15:01:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: Allow evacuating server with port resource request https://review.opendev.org/688387
15:02:00 mriedem it's #3 in the gate but the #1 spot just failed
15:02:14 mriedem which was yours
15:02:14 efried alex_xu, stephenfin, gibi: I updated the slides to have no Denver info in them (I think) and filled out a few easy ones including the microversion table.
15:04:15 stephenfin mriedem: It's low priority (because 3rd party CI, at a minimum), but I'm going to need your help on the remove python2 patch at some point. I haven't a clue how to tell the two remaining legacy jobs to use python3
15:04:51 mriedem devstack jobs?
15:05:09 mriedem https://review.opendev.org/#/c/649097/
15:05:18 mriedem depends-on that?
15:05:35 mriedem i'll be annoyed if we drop py2 and have to define USE_PYTHON3=True everywhere
15:09:21 efried mriedem: I haven't been following https://blueprints.launchpad.net/nova/+spec/add-user-id-field-to-the-migrations-table -- see patches +A this morning, is that the last of it? Can we mark complete (when merged)?
15:11:51 gmann stephenfin: mriedem or you can use d-g var for legacy if not writing directly on localrc - DEVSTACK_GATE_USE_PYTHON3. But moving the devstack default to py3 and keep py2 setting in devstack on demand if anyone needed is something we should do first. I will review mriedem patch (not sure it does the same).
15:14:06 dansmith mriedem: yeah it wasn't showing up on dash for me at the time, but is now.. hadn't run anything so must've just been queued or something
15:14:27 openstackgerrit Dan Smith proposed openstack/nova master: Add cache_images() to conductor https://review.opendev.org/687139
15:14:27 openstackgerrit Dan Smith proposed openstack/nova master: Add image caching API for aggregates https://review.opendev.org/687140
15:15:11 dansmith mriedem: conductor patch was just rebased to kick it out of the gate right away and get in line behind the 2.80 one ^
15:15:14 mriedem efried: no, there is still a novaclient change
15:15:20 gmann stephenfin: mriedem FYI. fully dropping py2 from devstack or other common tooling/lib/oslo etc will be the last once all projects drop py2. We discussed the plan in TC for that and i will send the same on ML also, further and final plan/discussion will be on 24th TC office hour.
15:15:37 efried mriedem: ack thx
15:16:12 mriedem gmann: can't change the default on DEVSTACK_GATE_USE_PYTHON3 in d-g since it's branchless, unless we add branch logic in d-g for that like we did for using neutron by default back in i think newton or ocata
15:16:44 mriedem this https://github.com/openstack/devstack-gate/blob/master/devstack-vm-gate-wrap.sh#L199
15:18:28 gmann mriedem: yeah, legacy jobs and d-g need branch handling.
15:18:35 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove unused 'nova-dsvm-base' job https://review.opendev.org/688389
15:18:36 openstackgerrit Stephen Finucane proposed openstack/nova master: zuul: Make functional job inherit from openstack parents https://review.opendev.org/688425
15:19:03 mriedem one question is going to be grenade, since if grenade train side starts with py2 and upgrades to ussuri and starts using py3 packages, but https://review.opendev.org/#/c/649097/ should have hit that
15:19:30 dansmith mriedem: is that what we'll do? or just go py3-py3 on both sides?
15:19:54 dansmith I feel like staying on py3 on both sides is more in line with what we've done before with ubuntu upgrades, but not very realistic of couse
15:20:04 mriedem since https://review.opendev.org/#/c/649097/ isn't doing anything else i expect grenade starts with py2 and the new side is py3
15:20:16 mriedem yeah it's definitely not realisitc,
15:20:19 mriedem *realistic
15:20:39 mriedem we - or someone that cares enough, like a distro - should make sure that people can upgrade from py2 in train to py3 in ussuri
15:21:18 mriedem this came up a long time ago of course when the tc was talking about py2 deprecation and the only thing i remember really coming up was maybe some oslo libraries, like messaging, maybe having some compat issues
15:21:24 dansmith mriedem: why is that patch causing a switch?
15:21:32 gmann that should be tested as past of py2.7 jobs + py3 testing on train
15:21:51 mriedem dansmith: because the old side of grenade in that run would run with py2 by default - since it's running from stable/n-1
15:21:59 dansmith mriedem: oh you mean the grenade testing of that patch in isolation, not once that patch is merged?
15:21:59 gmann mean both version testing make sure train code can run on both py version so does upgrade is no issue
15:22:08 mriedem dansmith: both
15:22:32 mriedem gmann: not really
15:22:47 mriedem say you have multi-node grenade where one compute is left at n-1 (train),
15:22:59 gmann mriedem: but we will keep only grenade-py3 in ussuri which will be py3->py3
15:23:04 mriedem i would expect that job to start with py2, upgrade controller services and one compute to py3 ussuri and leave the n-1 compute at py2
15:23:09 mriedem and everything, like rpc, should continue to work
15:23:18 dansmith mriedem: oh, devstack has branched, d-g does not I see, yeah
15:23:23 mriedem yup
15:23:55 mriedem gmann: if we don't have something like what i described above with multinode grenade we're not really testing upgrades from py2 to py3
15:24:26 mriedem e.g. what happens if a py3 conductor sends serialized json rpc to a py2 compute?
15:24:34 gmann how that will be different than testing compute node for both version in separate jobs
15:24:51 gmann ohk
15:25:10 dansmith mriedem: one *could* argue that we don't care to test that sort of thing
15:25:15 mriedem sure
15:25:25 mriedem this isn't going to be my fight in ussuri
15:25:27 dansmith mriedem: as you say, leave it to thedistros, but not specifically test or care about a platform change related problem
15:25:31 mriedem if it blows up i'll laugh
15:25:38 gmann this came up in denver PTG (previous one) also
15:26:00 mriedem gmann: lots of things come up
15:26:16 mriedem idk if anyone (the tc?) documented test plans for this
15:26:22 mriedem or statements about testing this kind of upgrade
15:26:38 mriedem if there was previous agreement from the tc and/or qa or whatever that we as a community don't care about testing that scenario, then fine
15:27:05 gmann http://lists.openstack.org/pipermail/openstack-dev/2018-September/134592.html
15:27:32 mriedem yeah that's the thread i was thinking about when i said this came up earlier
15:30:41 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove unused 'nova-dsvm-base' job https://review.opendev.org/688389
15:30:41 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop testing Python 2 https://review.opendev.org/687954
15:30:42 openstackgerrit Stephen Finucane proposed openstack/nova master: zuul: Make functional job inherit from openstack parents https://review.opendev.org/688425
15:30:47 gmann mriedem: i think there was agreement 'community don't care ' but documented anywhere
15:31:08 mriedem that's what doug seems to be saying http://lists.openstack.org/pipermail/openstack-dev/2018-September/134655.html
15:31:14 mriedem so *shrug*
15:31:28 gmann * not documented anywhere
15:33:44 gmann I think we can add that in TC doc/resolution. i will add that part as part of 24th TC office hour discussion
15:48:25 openstackgerrit Chris Dent proposed openstack/nova master: single pass instance info fetch in host manager https://review.opendev.org/623558
15:58:05 melwitt mriedem: I thought you might be interested in this, I wrote a regression test for the "run online_data_migrations twice fails" in the post test hook and a different fix on top https://review.opendev.org/688205
15:58:49 mriedem that would get around the mysql in functional test thing yeah
15:59:05 mriedem get your power back?
16:03:18 melwitt yeah, restored friday evening
16:03:50 melwitt nice to have internet again
16:03:54 mriedem heh, i bet
16:06:46 melwitt and yeah, I couldn't find another way to exercise the bug and explained briefly why in the commit message. lmk if you think the explanation could use more info, or if there are alternatives that I missed
16:07:14 openstackgerrit Merged openstack/nova master: Avoid using image with kernel in BDM large request func test https://review.opendev.org/688132
16:08:45 efried stephenfin: Does https://review.opendev.org/#/c/688249/ look right to you?
16:10:04 stephenfin sure does
16:11:44 efried stephenfin: cool, I've got a few similar ones...
16:11:46 efried thanks
16:13:18 melwitt zzzeek: I would appreciate your review on this fix I proposed related to the questions I asked you on friday https://review.opendev.org/688206
16:13:38 zzzeek melwitt: yah, saw the link, will look now
16:13:46 melwitt (and thanks again for helping me out with that)
16:15:02 efried https://review.opendev.org/#/c/688250/ https://review.opendev.org/#/c/688235/ https://review.opendev.org/#/c/688087/ if you care stephenfin
16:17:22 cdent mriedem: my to do list has just reminded me to prompt folk about https://review.opendev.org/#/c/623558/ which is jay's patch to improve instance info fetch in the host manager. A while back I added some unit tests and did the tweaks that eric requested

Earlier   Later