| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-19 | |||
| 14:43:55 | corvus | sean-k-mooney: right, i'm just suggesting that given the importance of devstack, that we should endeavor to keep it working | |
| 14:44:08 | dansmith | I'm coming into this late, but what is the controversy? | |
| 14:44:27 | dansmith | whether or not we continue to work on py2 at all via a test? | |
| 14:44:36 | stephenfin | dansmith: we've marked nova as python3 only, but devstack defaults to installing stuff in python2 mode | |
| 14:44:43 | corvus | stephenfin: i'm really puzzled -- i don't understand why there is so little concern about whether devstack works | |
| 14:44:46 | stephenfin | so anyone that doesn't override the defaults is broken | |
| 14:44:57 | dansmith | so how is this even a question? | |
| 14:45:19 | stephenfin | dansmith: It's not, we're reverting the part that broke everyone | |
| 14:45:43 | dansmith | reverting what? the dropping of a py2 job? | |
| 14:45:49 | corvus | but there are no current plans to have tests to ensure that it doesn't happen again (and even the revert is only tested indirectly with a depends-on patch) | |
| 14:45:54 | stephenfin | dansmith: https://review.opendev.org/#/c/695007/ | |
| 14:46:24 | dansmith | corvus: yeah, then you and I agree. | |
| 14:46:34 | sean-k-mooney | dansmith: we had a require-pyton >= 3.6 line in setup config that prevented nova installing on less then our new supported version | |
| 14:46:37 | dansmith | what's the argument for not having a py2 test until the devstack default switches? principle? | |
| 14:47:00 | stephenfin | mostly, yeah | |
| 14:47:04 | corvus | dansmith: https://review.opendev.org/694891 is the full revert which seems to be losing mindshare | |
| 14:47:19 | dansmith | stephenfin: I'm not on board with that | |
| 14:47:51 | sean-k-mooney | dansmith: that beeing testing py2 out of principal? | |
| 14:47:58 | sean-k-mooney | or breaking the devstack default | |
| 14:48:07 | sean-k-mooney | because im really hoping we change that today | |
| 14:48:45 | dansmith | sean-k-mooney: I'm not on board with us not testing nova in the default devstack config, and not okay with *not* doing that because of the principle that py2 is (soon) out of support | |
| 14:48:46 | dansmith | if we change the devstack default, then fine not testing py2 | |
| 14:48:51 | dansmith | if we don't, then we *have* to, IMHO | |
| 14:49:22 | sean-k-mooney | ok that is a clear statement | |
| 14:50:48 | dansmith | what is the blocker for the devstack py3 default? | |
| 14:50:50 | sean-k-mooney | the devstack defautl in that case need to be change in the next 23 days or we cant drop py2 testing by m1 in nova per the tc plan | |
| 14:51:03 | stephenfin | I figured someone needs to lead the way on this and it didn't seem anyone else was doing it. I also don't get why DevStack can't just change their default | |
| 14:51:27 | dansmith | sean-k-mooney: I totes don't care about the tc's schedule as much as I care that devstack works out of the box | |
| 14:51:44 | dansmith | (I don't care about the TC's schedule at all actually, but.. :P) | |
| 14:51:58 | dansmith | I know mriedem was on top of the devstack py3 default, | |
| 14:52:19 | dansmith | but he approved the switch prior to that being ready, which surprises me | |
| 14:53:06 | mriedem | i didn't know that the nova change meant you couldn't install nova on py2 anymore | |
| 14:53:23 | mriedem | i thought it was (a) what we tested against and (b) classifiers / support statement | |
| 14:53:27 | dansmith | ack | |
| 14:54:05 | gmann | mriedem: stephenfin dansmith tosky removing condition from setup.cfg should be ok as and add that once all projects moved to py3-only. | |
| 14:54:14 | dansmith | mriedem: from the two patches and the votes, it looks like you want to re-allow install on py2, but not test it, yeah? problem is "it" is the "default devstack arrangement" right? | |
| 14:54:15 | stephenfin | and I didn't know that this would break other people. I thought we were safe since we were consumers (a service), rather than the consumed (libs, clients). Didn't think of the DevStack implications | |
| 14:54:23 | gmann | if nova is breaking on py2 by code then we do not need to fix and ask consumer to move to py3-only | |
| 14:54:53 | dansmith | gmann: it's a matter of devstack working out of the box.. nothing to do with python versions, IMHO | |
| 14:55:07 | mriedem | dansmith: correct | |
| 14:55:08 | dansmith | if we're not testing devstack in remotely default form, that's a problem, IMHO | |
| 14:55:11 | gmann | my argument for devstack move to py3 by default can migrate all py2 jobs to py3 which is planned before schedule, like library etc | |
| 14:55:23 | mriedem | dansmith: i want more people to give a shit | |
| 14:55:29 | mriedem | and pain is usually how that happens | |
| 14:55:42 | stephenfin | ^ that, sadly | |
| 14:55:49 | dansmith | mriedem: so you want it to break to prove a point? :) | |
| 14:56:12 | mriedem | that's assuming we're going to land nova changes that break on py2 in the next what, 3-4 weeks? | |
| 14:56:15 | efried | ? | |
| 14:56:15 | dansmith | I still haven't heard why devstack's default can't move yet | |
| 14:56:15 | efried | - Re-add one py2 job, which can be a pretty small/basic one afaiac | |
| 14:56:15 | efried | - Re-enable py2 (revert setup.cfg and requirements changes) | |
| 14:56:15 | efried | Does anybody object to | |
| 14:56:21 | mriedem | i've asserted above that if we do, it's a bug and we just fix it | |
| 14:56:33 | stephenfin | dansmith: see gmann's comment above | |
| 14:56:37 | mriedem | but i don't think we have high risk of landing non-py2 code in the next 3-4 weeks | |
| 14:56:40 | mriedem | i still use six everywhere | |
| 14:56:41 | stephenfin | and on the review | |
| 14:56:56 | efried | I agree with all of that, but "we probably won't break it" has never been a good reason not to test "it". | |
| 14:57:05 | stephenfin | that is my preferred direction, by far | |
| 14:57:06 | dansmith | yeah, probably won't break it doesn't work for me | |
| 14:57:13 | stephenfin | (switching DevStack to Python 3) | |
| 14:57:18 | gmann | i do not prefer nova or any project keep py2 job. but did not thought about min condition on setup.cfg | |
| 14:57:21 | efried | are we objecting to re-adding a py2 job because we're worried about gate resources? | |
| 14:57:25 | dansmith | that's like turning off gating for a bit because we'll be careful | |
| 14:57:34 | efried | ^ this | |
| 14:57:56 | dansmith | stephenfin: I still don't really understand.. gmann is saying we can't switch the default because a lot of jobs don't specify and would break on py3? | |
| 14:58:10 | mriedem | efried: we don't gate on ceph or ironic and yet people care about those right? | |
| 14:58:11 | sean-k-mooney | for what its worth that is why iw as suggesting fixing py3 on centos7 instad of disabling cento7 job untill cento 8 works | |
| 14:58:20 | gmann | yeah but it is deadlock seems and need to tradeoff with either one | |
| 14:58:35 | stephenfin | dansmith: I think so, yeah | |
| 14:58:47 | dansmith | well, the tradeoff, is, IMHO, what efried said, which is add back a single py2 devstack job | |
| 14:58:47 | efried | mriedem: Agreed that we can't test everything in the world. But a minimal canary to make sure devstack doesn't just shit all over itself seems appropriate. | |
| 14:59:00 | mriedem | and when can that be removed? | |
| 14:59:07 | dansmith | mriedem: when the default switches | |
| 14:59:09 | mriedem | when the tc fairy shows up in january to tell us we're ok? | |
| 14:59:11 | efried | when devstack is py3 by default and we can do the minimum thing. | |
| 14:59:23 | dansmith | mriedem: I don't care about the date, I care about the default | |
| 14:59:30 | stephenfin | Can we just make devstack py3 by default? | |
| 14:59:32 | efried | ("the minimum thing" => restore the py3 minimum in setup.cfg) | |
| 15:00:02 | stephenfin | We know there's going to be some degree of pain here. By reverting anything in nova, we're kicking the can down the road | |
| 15:00:05 | mriedem | then just efried and dansmith should approve ianw's revert | |
| 15:00:05 | efried | stephenfin: That's mriedem's patch, yes? I rechecked that a bit ago to see if it works yet. If so, maybe we can just pull the trigger. | |
| 15:00:07 | gmann | default switch was planned for ~Jan | |
| 15:00:21 | gmann | ok, let's move devstack to py3 and then if anyone need py2 testing (only lib and testing tools) can explicitly mention the py2 need | |
| 15:00:23 | efried | though the predecessor also would need to go. | |
| 15:00:26 | stephenfin | Switching to Python 3 by default is at least forward-looking pain | |
| 15:00:29 | dansmith | gmann: right so if the default flip is coming, I don't see what the big deal is | |
| 15:00:32 | gmann | except swift everyone has to switch to py3-only in ussuri | |
| 15:00:45 | mriedem | dansmith: that devstack patch of mine has been on top of another patch that has been around since april | |
| 15:00:49 | stephenfin | then lets do that now | |
| 15:01:03 | dansmith | stephenfin: I would agree except I don't know how many things will insta-fail on projects with few people working on them | |
| 15:01:04 | gmann | i have patches upnfor all the projects (except clieent, testing tool and lib) so project can merge thsoe | |
| 15:01:13 | dansmith | mriedem: I know | |
| 15:01:23 | dansmith | mriedem: I'm not a py3 bigot, so I'm really in no rush :) | |
| 15:01:34 | stephenfin | dansmith: those projects are going to insta-fail at some point though | |
| 15:01:59 | dansmith | stephenfin: yep, so if the TC wants to schedule that, and it's in Jan, I would be fine waiting and moving then as long as it happens | |
| 15:02:14 | dansmith | but, also fine now, I just don't want the disjoint default.. like I said, the date doesn't matter to me | |
| 15:02:57 | gmann | dansmith: but it can be blocked other projects too and two times effort to get rid of py2. so i am ok to move devstack first | |
| 15:03:23 | mriedem | dansmith: then just approve this https://review.opendev.org/#/c/694891/ | |
| 15:03:55 | gmann | because if nova or any other project say min version is py3 then it is fair because reno said the same. | |