Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-11-19
15:06:34 sean-k-mooney gmann: it was planned for m2 in febuary
15:06:38 stephenfin We should probably switch over sooner than that then
15:06:39 sean-k-mooney well by m2
15:07:02 stephenfin We need to keep clients and libraries on python 2 for longer to let the services switch everything over
15:07:05 dansmith honestly, switching the default in devstack at m2 seems crazy late to me
15:07:08 dansmith just for our cycle
15:07:25 stephenfin so we should be switching devstack now to let the services fix whatever they need to fix
15:07:34 stephenfin IMO, of course
15:07:36 dansmith that makes more sense to me for sure
15:07:38 dansmith break early
15:07:40 gmann stephenfin: yeah and all services has to switch before m-2
15:07:52 stephenfin dansmith: we also have Xmas to worry about
15:07:53 gmann +1.
15:08:00 dansmith stephenfin: not nova's X-mas! :P
15:08:09 dansmith but yeah I get that for sure
15:08:18 dansmith so, just tobe clear,
15:08:40 dansmith even if we push the devstack default, we need the partial revert so that py2-only projects can still install nova in their jobs
15:08:54 sean-k-mooney dansmith: yes
15:08:58 openstackgerrit Mark Goddard proposed openstack/nova master: Add functional regression test for bug 1853009 https://review.opendev.org/695012
15:08:58 openstack bug 1853009 in OpenStack Compute (nova) "Ironic node rebalance race can lead to missing compute nodes in DB" [Undecided,In progress] https://launchpad.net/bugs/1853009 - Assigned to Mark Goddard (mgoddard)
15:08:58 dansmith so we could push the default in devstack now, then revert our can-use-py2 part at m2 as the hard deadline yeah?
15:09:12 gmann stephenfin: are you rebasing the mriedem patch and remove neutron-grenade job also in same patch to pass the gate
15:09:14 stephenfin sean-k-mooney: why?
15:09:43 dansmith stephenfin: so that trove (example) can still run py2 devstack jobs with nova
15:09:51 sean-k-mooney why? so that if neutron need to keep a job on py2 for a day or two to fix it they can
15:09:57 dansmith right
15:10:02 gmann dansmith: they has to move as soon as any dependencies fail their gate
15:10:42 stephenfin But unless they're setting USE_PYTHON3=False in jobs, they'll inherit the default (now python3), no?
15:10:44 dansmith yeah
15:10:45 dansmith that's my point, if nova can't run on py2 anymore (default or not) then they can't run jobs
15:10:52 slaweq sean-k-mooney: what py2 job in neutron You are talking about?
15:11:03 dansmith stephenfin: right, I'm sayingsome project that needs another month to be able to run devstack in default py3
15:11:12 stephenfin ohhhh
15:11:15 stephenfin gotcha
15:11:20 dansmith if we don't revert the minimum change, they physically can't install nova in unsupported py2
15:11:23 sean-k-mooney slaweq: none it was just an example of a big project with many jobs that often need nova in them
15:11:26 stephenfin okay
15:11:35 slaweq sean-k-mooney: ahh, ok :)
15:11:37 gmann for client lib which will happen later make sense to keep nova install-able on py2 , for service not
15:11:46 stephenfin then I'm also onboard with that
15:12:05 dansmith stephenfin: that all hinges on gmann being willing to pull the trigger
15:12:20 sean-k-mooney by the way os-vif is currently broken as we have not swaped all the jobs to python 3
15:12:22 stephenfin so, revert the change to nova, merge the Python 3-ification patch to DevStack, wait a month and re-revert that change to nova
15:12:39 dansmith stephenfin: just the half-revert
15:12:40 sean-k-mooney we can trivially but we need to wait as a lib project
15:12:42 gmann revert only setup.cfg and req right ?
15:12:51 gmann yeah what dansmith mentioned
15:13:04 dansmith stephenfin: revert the min, default devstack to py3, later un-revert the minimum
15:13:12 gmann +1
15:13:31 stephenfin what about your concerns that we could accidentally break Python2 support in that time?
15:13:36 stephenfin don't they still hold?
15:13:39 dansmith stephenfin: those aren't my concerns
15:13:50 dansmith stephenfin: my concerns are that we break the _default_ config in devstack
15:13:58 dansmith if the default changes, I'm good
15:13:59 stephenfin ah
15:14:39 corvus i agree with dansmith (that's my concern too). but it's unclear to me whether we can immediately change the default. is that something we can do today?
15:14:52 stephenfin corvus, tosky: have you been following along or do you need a recap?
15:14:54 stephenfin whoops
15:14:55 dansmith sounds like gmann is willing
15:14:58 gmann stephenfin: you are updating devstack patch? or should i do
15:15:15 gmann gate will be fixed by nova revert
15:15:20 stephenfin gmann: I can...if you tell me what needs to be done?
15:15:24 dansmith corvus: we're going to do the half revert now as well, which I think will eliminate the actual devstack breakage immediately anyway
15:15:26 gmann so default change happen today or tomorrow should be ok
15:15:28 sean-k-mooney corvus: i think we can change the default today
15:15:31 tosky stephenfin: a bit swamped with meetings, I think I may have got the gist of it though
15:15:37 gmann stephenfin: sure, i will comment on patch
15:15:41 tosky like: some reverting will land for now
15:15:50 corvus there was a bunch of devstack centos7 stuff earlier that i didn't understand, but if people who do understand agree that's all doable, then cool. :)
15:15:51 tosky and some other work is needed
15:15:56 sean-k-mooney if it cause gate failure then project can set it back to false in each job that broke
15:16:00 tosky which is a bit generic summary but I'm sure it fits :)
15:16:12 stephenfin tosky: got it in one
15:16:20 dansmith stephenfin: I can summarize on the half-revert patch and +2, you can come back and +W when you're done with the devstack thing okay?
15:16:27 stephenfin ack
15:16:41 gmann corvus: i pushed patch to add centos8 job so i think we can drop centos7 completely
15:17:02 sean-k-mooney corvus: centos ships with python 3.4 so it need to have py 3.6 installed form eple or we need to swap master jobs to centos 8
15:17:26 corvus and centos8 is ready?
15:17:28 stephenfin gmann shows up and fixes everything for us. This is excellent \o/
15:17:28 tosky gmann: see on #openstack-qa: some work is needed on centos 8, frickler was working on it
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

Earlier   Later