Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-11-19
15:17:31 sean-k-mooney we just need to fix any gaps in devstack on centos 8
15:17:32 gmann my bad and sorry for not considering the setup.cfg min py version things during composing the plan/goal
15:17:45 tosky gmann: and the requirements too :)
15:17:51 gmann yeah :(
15:18:11 stephenfin gmann: Not your fault. I never thought about the DevStack default thing when putting that together
15:18:40 mriedem stephenfin: your patch depended on the devstack default switch after i mentioned it, and then you dropped the depends-on
15:18:54 mriedem likely because we could just set USE_PYTHON3=True in our jobs
15:19:05 stephenfin yup, exactly because of that :(
15:19:40 stephenfin I thought the depends on was an optimization to avoid us having to set that stuff manually
15:19:48 stephenfin TIL
15:19:56 tosky gmann: no problem, really; it happens, let's improve the process and continue
15:20:14 mriedem slaweq: do you have a bug for this yet so i can track it in e-r
15:20:15 mriedem ?
15:20:54 slaweq mriedem: no, I didn't open any bug for this
15:21:10 slaweq I just checked here that You're already talking about it so I didn't report a bug
15:21:14 corvus i think the thing to watch out for in future reviews is: when setting a devstack option, is it something that is intrinsic to the specific job (okay in nova) or is it something that is recommended/required for any devstack users (should be in devstack). if all the nova devstack jobs have an option, it's almost certainly the latter.
15:23:50 stephenfin makes sense
15:29:17 dansmith stephenfin: https://review.opendev.org/#/c/695007/3
15:29:23 dansmith efried: mriedem ^
15:31:37 stephenfin dansmith: LGTM
15:32:04 efried dansmith: so you've changed your mind on readding a minimal py2 job?
15:32:23 dansmith efried: no, you must not have followed all of that, and.. did you read my wall of text?
15:32:27 efried I did
15:32:52 dansmith efried: all I care about is that we're testing the devstack default.. if the default is changing, I'm cool with sticking with py3 only and letting py2 issues creep in
15:32:58 sean-k-mooney efried: im guessing your askign since this patch does not add the minimal job
15:33:03 dansmith efried: if the default is not changing, I think we have to test and validate the default
15:33:36 efried what sean-k-mooney said. since this patch doesn't depend on the "switch the default to py3" patch, and there's no telling how long it will be until that actually merges, we have The Hole.
15:34:00 mriedem you have a gentlemans agreement for about the next 24 hours
15:34:00 dansmith efried: gmann said they'd merge it today
15:34:11 efried okaaay
15:34:11 mriedem after that courtney love shows pu
15:34:12 mriedem *up
15:34:14 dansmith we could block on that, but we're blocking a bunch of other people
15:34:35 efried yah, seems like it would have been easy to add one line to .zuul.yaml in that patch, but mebbe not.
15:34:44 dansmith gmann: don't f*ck me over, okay?
15:34:45 efried anyway, it's on the way
15:34:47 mriedem for me it's not about ease
15:34:48 dansmith efried: well, I'm fine with that if you want
15:34:50 sean-k-mooney efried: nova-dsvm-multinode-base is still python 2 i think
15:35:01 mriedem sean-k-mooney: that's not a ojb
15:35:02 mriedem *job
15:35:04 mriedem that's a base
15:35:12 sean-k-mooney so nova-live-migration will by python 2
15:35:16 sean-k-mooney ya i know
15:35:16 mriedem it's not
15:35:19 efried nope
15:35:31 stephenfin sean-k-mooney: it can't be. if it was, it wouldn't work for us :)
15:35:33 mriedem hi https://review.opendev.org/#/c/694787/
15:36:07 sean-k-mooney im looking at https://github.com/openstack/nova/blob/master/.zuul.yaml and i dont see python 3 enabled
15:36:08 efried because https://opendev.org/openstack/nova/src/branch/master/playbooks/legacy/nova-live-migration/run.yaml#L50 rite?
15:36:16 mriedem it's in the legacy playbook
15:36:17 mriedem yes that
15:36:37 mriedem cue sean-k-mooney saying we should really move those jobs to zuulv3
15:36:41 stephenfin mriedem: on that, you need to keep the sphinx on py2 line in doc/requirements.txt
15:36:50 stephenfin i tried removing it and got the same thing you're seeing
15:36:53 stephenfin the tool is dumb
15:37:17 sean-k-mooney ah ok
15:37:22 gmann ? anything changed ?
15:37:44 dansmith gmann: no, we're just taking bets on whether or not you're really going to merge the devstack change today
15:37:52 openstackgerrit Matt Riedemann proposed openstack/nova master: FUP to Ie1a0cbd82a617dbcc15729647218ac3e9cd0e5a9 https://review.opendev.org/694787
15:38:17 dansmith gmann: efried and I will have to meet on the playground after school if not, and he'll kick my ass
15:38:28 gmann ok :)
15:43:20 openstackgerrit Merged openstack/nova master: functional: Make '_wait_for_state_change' behave consistently https://review.opendev.org/689180
15:47:02 gmann mriedem: sean-k-mooney for legacy jobs i am explicitly setting py3 via d-g var for other projects. waiting to move them to zuulv3 +py3 might take time.
15:49:31 gmann stephenfin: on requirement changes. I am removing the py2 only req also for other projects and if any project break anyone (which is rare case for all non-core/small projects) then we revert otherwise keep dropping those.
15:50:01 stephenfin ack
15:50:17 mriedem stephenfin: i'm going to drop the misleading comment on https://review.opendev.org/#/c/694789/2/playbooks/legacy/nova-grenade-multinode/run.yaml@35
15:50:45 stephenfin fine by me
15:52:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Drop neutron-grenade-multinode job https://review.opendev.org/694789
15:52:27 openstackgerrit Matt Riedemann proposed openstack/nova master: Drop neutron-grenade-multinode job https://review.opendev.org/694789
16:00:44 openstackgerrit Pavel Gluschak (scsnow) proposed openstack/nova master: Don't delete compute node, when deleting service other than nova-compute https://review.opendev.org/694756
16:02:10 openstackgerrit Archit Modi proposed openstack/nova stable/pike: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693236
16:05:39 openstackgerrit Archit Modi proposed openstack/nova stable/pike: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693236
16:15:14 artom sean-k-mooney, FWIW, I'm not going to hassly you about the softer wording stuff in your NUMA rebuild patches. There's still enough stuff there to warrant a respin on both (albeit the top one is just typos)
16:15:17 artom *hassle
16:18:24 openstackgerrit Stephen Finucane proposed openstack/nova master: functional: Unify '_build_minimal_create_server_request' implementations https://review.opendev.org/695024
16:18:24 openstackgerrit Stephen Finucane proposed openstack/nova master: functional: Make '_IntegratedTestBase' subclass 'InstanceHelperMixin' https://review.opendev.org/689182
16:20:52 sean-k-mooney artom: i am going ot resping them for the typos yes
16:21:18 artom And the unit tests :)
16:21:24 artom Mostly the unit tests
16:24:01 sean-k-mooney i actully intionally did not add them but yes im going to add some for the neew fucntion
16:25:00 sean-k-mooney mainly because functional tests and exsiting test provide equal or better coverage in general but as noted ill add the test for the function you highlighted
16:29:31 openstackgerrit Thierry Carrez proposed openstack/nova master: Start README.rst with a better title https://review.opendev.org/695025
16:32:35 mgoddard mriedem: hi. The more I pick at this thing (rebalance) the more it comes apart :)
16:32:43 openstackgerrit Merged openstack/nova master: (Temporarily) readd bare support for py27 https://review.opendev.org/695007
16:33:11 gmann everyone, sent the ML for making devstack py3 default and other suggestion we agreed today- http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010938.html
16:33:35 mgoddard mriedem: I have a few related but separable changes, and a functional tests. Does nova tend to prefer separate commits where possible, or shall I bung it all in one?
16:34:29 mriedem mgoddard: i can't speak for all of nova but i prefer separate commits if possible - easier to review, easier to revert if necessary
16:34:49 mgoddard mriedem: sure.
16:35:01 mriedem mgoddard: and i'm not surprised rebalance has issues since it's never had functional testing
16:35:16 kashyap mgoddard: On separate commits, this is a good reminder: https://wiki.openstack.org/wiki/GitCommitMessages#Structural_split_of_changes
16:35:24 mriedem the only way i found the race bug in the first place was digging into ironic multinode grenade logs looking for some other issue
16:35:29 kashyap (Bearing in mind things like bisectability, etc)
16:35:41 mgoddard mriedem: separate commits should be quite neat as each will fix a different part of the functional test
16:36:20 bauzas gibi: mriedem: do you think it would be worth inspecting the args when calling PlacementFixture ?
16:36:44 bauzas (related to the microversion/version issue)
16:37:15 mgoddard thanks kashyap. I generally prefer them, although it's not universal
16:39:32 efried bauzas: can you point me to the change in question please?
16:39:44 efried (It's somewhere on my list, been meaning to weigh in, but don't want to dig it up rn)
16:40:39 efried if this is a functional test, the PlacementFixture should be doing the right thing with its kwargs. And there should usually not be a reason to (re-)mock a method on the fixture.

Earlier   Later