| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-14 | |||
| 14:18:45 | mriedem | bauzas: join the party i guess, it's usually a party of 1 | |
| 14:19:12 | dansmith | I wish we could do something better there | |
| 14:20:10 | mriedem | i don't thinking the microversion stuff can be reasonably automated | |
| 14:20:12 | mriedem | *think | |
| 14:20:23 | mriedem | coffee hasn't kicked into my brain yet | |
| 14:20:34 | dansmith | well, it would take some changes in our workflow I think | |
| 14:20:39 | dansmith | I know it's not trivial | |
| 14:29:21 | efried | o/ nova | |
| 14:30:12 | efried | alex_xu, stephenfin, gibi: I copied the Denver proj update to a new google slide thingy. PM me whatever email address you have a google account for and I'll add you to editors. | |
| 14:35:22 | dansmith | gmann: can you help me decipher mriedem's request here? or point me at what something new looks like that I can copy? https://review.opendev.org/#/c/687140/5/nova/tests/unit/test_policy.py@312 | |
| 14:39:03 | gmann | dansmith: yeah, we can use the new naming standard for new policy. EX -https://github.com/openstack/nova/blob/master/nova/policies/server_topology.py#L19 | |
| 14:39:45 | dansmith | gmann: oh meaning just s/os-// ? | |
| 14:40:13 | mriedem | decipher :/ | |
| 14:40:26 | mriedem | i said "compute:aggregates:images" or "compute:aggregates:images:cache" | |
| 14:40:37 | dansmith | okay, I dunno what I was thinking last week, but reading it this morning he *did* tell me what to type | |
| 14:40:52 | gmann | "compute:aggregates:images:cache" seems perfect | |
| 14:41:01 | dansmith | mriedem: yeah I dunno, sorry I read that a couple times last week and it seemed like you were waffling on what you thought it should be and my eyes glazed over | |
| 14:41:34 | mriedem | i was only waffling on making it specific to the cache action for future actions like purge | |
| 14:42:10 | dansmith | I probably didn't see that the os- was removed, so it looked like what I had and I assumed I was missing something bigger | |
| 14:42:31 | bauzas | mriedem: sure, will do | |
| 14:42:32 | frickler | mriedem: did you see the thing I noticed last week? I'm assuming you might like that one, too ;) https://bugs.launchpad.net/tempest/+bug/1847759 | |
| 14:42:32 | openstack | Launchpad bug 1847759 in tempest "reboot_server_hard can trigger corrupted file system" [Undecided,New] | |
| 14:42:51 | dansmith | having one operation in aggregates be different from the rest seems unhelpful to admins, but I'm more than happy to just do whatever as I don't know anything about this stuff | |
| 14:43:22 | mriedem | dansmith: i believe gmann has an approved blueprint to re-write all of those policy rules so it's just less work when he does | |
| 14:43:30 | dansmith | ack | |
| 14:43:36 | mriedem | frickler: i didn't | |
| 14:44:16 | gmann | naming change for existing policy we dropped from policy improvement spec but for new one we can follow the new naming standard | |
| 14:44:58 | gmann | at least not part of scope+new read-only defaults spec | |
| 14:45:03 | mriedem | frickler: i've definitely seen this in the gate jobs that have ssh failures "cp: write error: No space left on device" | |
| 14:45:17 | mriedem | frickler: http://status.openstack.org/elastic-recheck/#1808010 | |
| 14:47:22 | frickler | mriedem: yes, the "no space left" is pretty generic, though, this one seems directly tied to hard reboots and the resulting corruption causing kernel panics | |
| 14:47:46 | gmann | but yes, i wanted to change all old name but that is something needs to be discussed if worth to do or not from operator perspective. this will be separate spec | |
| 14:48:18 | mriedem | dansmith: so we haven't done this for train yet - https://review.opendev.org/#/c/642599/ - does that need to be in train? | |
| 14:48:26 | mriedem | or is ok for just ussuri? | |
| 14:48:28 | mriedem | *is it | |
| 14:49:02 | frickler | mriedem: so I'd say it is not a duplicate, but a specific subset of it, tied to a single test scenario | |
| 14:49:03 | mriedem | gmann: renaming all of the old policy rules seems like a ton of churn for not much gain | |
| 14:49:09 | mriedem | frickler: ack | |
| 14:50:16 | dansmith | mriedem: it'd be nice for it to be in train eventually in case anyone sets their train level to train in an attempt to bump to current | |
| 14:50:37 | dansmith | mriedem: really they should unpin or use auto, but you can imagine setting train to train meaning current making sense to people | |
| 14:50:39 | mriedem | https://wiki.openstack.org/wiki/Nova/ReleaseChecklist says "Ideally add the RPC version alias just before opening the next release" | |
| 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 | |