Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-14
14:14:23 bauzas mriedem: just saw this morning that Queens will be on Extended Maintenance in 3 weeks, so maybe we should look at https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:stable/queens ?
14:15:09 dansmith mriedem: I guess I thought the point of the schema was so we didn't have to test for things that the schema would reject for us
14:15:15 dansmith well, one of the points of the schema
14:15:37 mriedem we still have to test that we defined the schema correctly
14:15:38 dansmith isn't that like kinda like silly tests that are actually only testing that mock is working?
14:15:46 dansmith okay
14:16:03 mriedem and i'd say to prevent regressions in later microversions on the same api
14:16:53 dansmith okay, that's fine it just seems inconsistent with what we do elsewhere, like we don't check that when you define an object field as int that a string will blow it up :)
14:17:54 mriedem i've seen and i'm pretty used invalid schema before adding tests to validate it so it's a more complicated thing than type checking
14:17:59 mriedem *pretty sure
14:18:06 dansmith ah dammit, I really wanted 2.80
14:18:44 dansmith also, I haven't had to write one of these in a long time, but it really sucks to have to do so much work if you miss your microversion
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 openstack Launchpad bug 1847759 in tempest "reboot_server_hard can trigger corrupted file system" [Undecided,New]
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: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 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:02:14 mriedem which was yours
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 image caching API for aggregates https://review.opendev.org/687140
15:14:27 openstackgerrit Dan Smith proposed openstack/nova master: Add cache_images() to conductor https://review.opendev.org/687139
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

Earlier   Later