*** KeithMnemonic has quit IRC | 00:30 | |
*** lbragstad has quit IRC | 01:24 | |
*** evrardjp has quit IRC | 04:33 | |
*** evrardjp has joined #openstack-requirements | 04:33 | |
*** udesale has joined #openstack-requirements | 04:39 | |
*** mnasiadka_ is now known as mnasiadka | 06:42 | |
*** ccamacho has joined #openstack-requirements | 06:55 | |
*** e0ne has joined #openstack-requirements | 07:17 | |
*** tosky has joined #openstack-requirements | 07:26 | |
*** e0ne has quit IRC | 08:04 | |
*** dtantsur|afk is now known as dtantsur | 08:11 | |
*** tosky has quit IRC | 08:32 | |
*** rakhmerov has joined #openstack-requirements | 09:19 | |
rakhmerov | hi, I have a question on requirements. The Ussuri version of "mistral" is not compatible with the latest mistral-lib (2.2.0). But in the requirements.txt there's still "mistral-lib>=1.4.0" | 09:19 |
---|---|---|
rakhmerov | I'm wondering how to best fix it | 09:19 |
rakhmerov | would it be right to just do https://review.opendev.org/#/c/739169/ that constrains "mistral-lib" version (<2.2.0) and make the same change in global-requirements.txt | 09:20 |
rakhmerov | both for ussuri branch | 09:20 |
rakhmerov | although the older branches are also affected.. | 09:20 |
*** tosky has joined #openstack-requirements | 09:22 | |
rakhmerov | would appreciate a hint | 09:24 |
*** e0ne has joined #openstack-requirements | 10:20 | |
*** udesale_ has joined #openstack-requirements | 11:09 | |
*** udesale has quit IRC | 11:11 | |
*** e0ne_ has joined #openstack-requirements | 12:25 | |
*** e0ne has quit IRC | 12:25 | |
openstackgerrit | Elod Illes proposed openstack/requirements stable/stein: Bump subunit to 1.4.0 in train too https://review.opendev.org/739222 | 12:32 |
hberaud | rakhmerov: o/ I think your approach is good, but another POV than mine on this topic could be worth | 13:02 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/requirements master: update constraint for os-traits to new release 2.4.0 https://review.opendev.org/739225 | 13:05 |
smcginnis | rakhmerov: Something else is going on there. Stable/ussuri mistral should not be using mistral-lib 2.2.0. | 14:28 |
smcginnis | rakhmerov: https://opendev.org/openstack/requirements/src/branch/stable/ussuri/upper-constraints.txt#L498 | 14:28 |
smcginnis | rakhmerov: Likely you have a broken job or broken tox.ini that isn't using constraints like it should. | 14:29 |
smcginnis | rakhmerov: Looks like at least most of the tox jobs are using constraints. I don't see any job failures on stable/ussuri patches though, so not sure where this is an issue. | 14:31 |
rakhmerov | smcginnis: it happens for people who just use pip | 14:41 |
rakhmerov | if they install mistral separately | 14:41 |
rakhmerov | in OpenStack CI all is good, yes | 14:41 |
rakhmerov | hberaud: ^ | 14:41 |
smcginnis | rakhmerov: Installing from pip still needs to use the upper-constraints for the given stable branch. | 14:42 |
rakhmerov | hm... really? You mean PIP is somehow aware of the upper constraints? | 14:42 |
rakhmerov | I just don't know that mechanism | 14:42 |
smcginnis | That's the -c that we put in our tox files and elsewhere. That's not a tox thing, that's a pip thing. | 14:43 |
smcginnis | If you want to install a stable version of something, you need to use that to make sure you get compatible versions of the packages. | 14:43 |
smcginnis | Even master, really. | 14:43 |
rakhmerov | ooh, I see what you mean.. yes. But it's not so obvious for someone who just found a package in PIP and wants to install it | 14:44 |
rakhmerov | ok, so | 14:44 |
smcginnis | Yeah. Thankfully I don't think it's too common that someone just randomly tries to pip install a service, but it is an implicit requirement if they do so. | 14:45 |
rakhmerov | ok, gotcha | 14:45 |
rakhmerov | I got a complaint from our users on that | 14:45 |
rakhmerov | we're used to all these machinery (upper-constraints etc) but there are people really who just use Pip | 14:46 |
smcginnis | They are likely to have a lot more suprises if they think they can just pip install and be done. ;) | 14:46 |
rakhmerov | smcginnis: so I'm thinking if we can still do something to make it better | 14:46 |
rakhmerov | smcginnis: so do you just recommend to mention in the docs maybe? | 14:47 |
smcginnis | Tracking upper-constraints really is that thing that was done. We used to try to cap specific versions, then have a bot that would update every single project that referenced that package. But that was unmaintainable. | 14:47 |
smcginnis | So yeah, adding some documentation definitely wouldn't hurt to try to make sure folks are aware of how that needs to work. | 14:48 |
rakhmerov | yeah-yeah... I remember that transition | 14:48 |
smcginnis | If you are coming across users that try this often. | 14:48 |
rakhmerov | hm.. ok | 14:48 |
rakhmerov | alright, thanks! I'll put the corresponding info somewhere in the docs and make sure it's visible enough | 14:49 |
smcginnis | Great, thanks rakhmerov. | 14:50 |
rakhmerov | have a good one | 14:50 |
hberaud | smcginnis++ | 15:03 |
*** markmcclain has quit IRC | 15:06 | |
*** markmcclain has joined #openstack-requirements | 15:08 | |
*** dtantsur is now known as dtantsur|afk | 15:20 | |
smcginnis | prometheanfire: Commenting here since I doubt the necessary folks are around (like fungi, who I hope is happily vacationing). The nightly generate constraints job is failing yet: https://aa3f5bd002bc3471eaeb-0ee3eeb68aa256c74f1e35f60c262d61.ssl.cf5.rackcdn.com/periodic/opendev.org/openstack/requirements/master/propose-updates/519e935/job-output.txt | 15:21 |
smcginnis | The issue appears to be that this job needs to run under py3.6 through py3.8 to generate the constraints. | 15:21 |
smcginnis | It creates a venv for each one, runs the commands, then gets the output from each. | 15:21 |
smcginnis | The issues is venv is not installed for each environment. | 15:22 |
smcginnis | I had switched the command to run "python -m venv" instead of "virtualenv ..." thinking that would help since venv is standard lib and virtualenv is not. | 15:22 |
smcginnis | But on ubuntu they break out python3-venv into a separate package that is not installed. | 15:23 |
smcginnis | So either we need a way to get that installed, or we need to revert my change and go back to virtualenv, and also figure out how the ensure-virtualenv role would need to be updated so we can give it each python version that we need to have virtualenv installed under. | 15:24 |
*** otherwiseguy_ has joined #openstack-requirements | 15:24 | |
smcginnis | Something like the ensure_pip_from_upstream_interpreters option in ensure-pip. | 15:24 |
smcginnis | That does not exist today. | 15:24 |
fungi | not here, but the options for that are similar to what we discussed earlier in #openstack-infra when i thought that was the failure it was hitting (i guess i remembered the job correctly after all, we just weren't getting that far yet and so the problem was masked by a different error) | 15:24 |
smcginnis | Yeah, now I see what you were thinking about. ;) | 15:24 |
* smcginnis isn't here either. | 15:25 | |
*** otherwiseguy has quit IRC | 15:25 | |
*** dhellmann has quit IRC | 15:25 | |
smcginnis | Talking this through, I wonder if we can just switch the job to run on a RH image so there isn't a separate package to install for python3-venv. | 15:25 |
*** dhellmann has joined #openstack-requirements | 15:26 | |
fungi | so anyway, could extent ensure-pip to have a multi-interpreter option for its distro packages logical branch, or could switch the job to install pip from pypi via get-pip.py (though i don't know if the latter will *actually* get you a working venv module, that's part of stdlib) | 15:26 |
smcginnis | It doesn't look like it. | 15:26 |
smcginnis | Is there an ansible role we can just use directly that installs system packages under a given python version? | 15:27 |
smcginnis | Something like a: - role name: install-package package: python3.6-venv | 15:28 |
smcginnis | Though it looks like bionic only has python3.6-venv and python3.7-venv, so I'm not sure how 3.8 would be handled. | 15:28 |
smcginnis | So maybe easier going back to virtualenv so we can just pip install it. | 15:28 |
fungi | there is a separate ensure-python role | 15:30 |
fungi | which can install arbitrary pythons, not limited to the ones provided by the distro | 15:30 |
smcginnis | Is there a way to tell that to include venv? | 15:31 |
fungi | there is a 3.8 venv in bionic too: https://packages.ubuntu.com/bionic-updates/python3.8-venv | 15:32 |
smcginnis | Ah, I was looking under bionic, not bionic-updates. | 15:32 |
fungi | you can search most easily with https://packages.ubuntu.com/python3.8-venv and it will turn up all instances of that package name across every suite | 15:33 |
smcginnis | So I guess we need an ensure-venv to go along with ensure-virtualenv. One that includes the version to install? | 15:33 |
*** udesale has joined #openstack-requirements | 16:23 | |
*** udesale_ has quit IRC | 16:25 | |
*** udesale has quit IRC | 16:49 | |
fungi | ensure-pip installs the separate venv package if distro packaging is used, but doesn't (yet) have a way to say install for more than one distro packaged python interpreter version so only uses the default python3: https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-pip/tasks/Debian.yaml | 16:54 |
fungi | my vote would be to extend install-pip and always use it if you need to make sure venv is present | 16:54 |
fungi | but that's a discussion for #zuul | 16:55 |
openstackgerrit | Merged openstack/requirements stable/stein: Bump subunit to 1.4.0 in train too https://review.opendev.org/739222 | 17:01 |
*** e0ne_ has quit IRC | 17:21 | |
openstackgerrit | Sean McGinnis proposed openstack/requirements master: DNM: Test propose-updates fix https://review.opendev.org/739276 | 18:43 |
*** e0ne has joined #openstack-requirements | 19:56 | |
*** e0ne has quit IRC | 20:00 | |
*** e0ne has joined #openstack-requirements | 20:06 | |
*** e0ne has quit IRC | 20:10 | |
*** e0ne has joined #openstack-requirements | 20:30 | |
*** e0ne has quit IRC | 20:35 | |
*** e0ne has joined #openstack-requirements | 20:55 | |
*** e0ne has quit IRC | 21:00 | |
*** e0ne has joined #openstack-requirements | 21:19 | |
*** e0ne has quit IRC | 21:24 | |
*** e0ne has joined #openstack-requirements | 21:57 | |
*** e0ne has quit IRC | 22:01 | |
openstackgerrit | Ghanshyam Mann proposed openstack/requirements master: Temporarily cap setuptools<48.0.0 https://review.opendev.org/739290 | 22:26 |
gmann | smcginnis: prometheanfire ^^ i know this is not recommended for setuptools but this is the quick way to unblock the gates - http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015781.html | 22:30 |
gmann | i have filed bug on devstack side also, at least to revert back the cap at the end, so this is temporary to gate unblock. | 22:30 |
prometheanfire | gmann: yep, I reviewed it (with questoins) | 22:32 |
prometheanfire | glad you mentioned a revert plan | 22:33 |
*** e0ne has joined #openstack-requirements | 22:34 | |
gmann | prometheanfire: replied too | 22:36 |
prometheanfire | thanks | 22:36 |
prometheanfire | given the holiday I'm not gonna wait for smcginnis | 22:36 |
gmann | sure, thanks | 22:37 |
*** e0ne has quit IRC | 22:39 | |
prometheanfire | gmann: what I'll probably do is propose the patch to revert with DNM on just so I don't forget | 22:40 |
gmann | prometheanfire: +1 make sense. | 22:40 |
*** e0ne has joined #openstack-requirements | 22:46 | |
*** tosky has quit IRC | 22:50 | |
*** e0ne has quit IRC | 22:51 | |
*** e0ne has joined #openstack-requirements | 23:10 | |
*** e0ne has quit IRC | 23:15 | |
*** e0ne has joined #openstack-requirements | 23:23 | |
*** e0ne has quit IRC | 23:27 | |
*** e0ne has joined #openstack-requirements | 23:35 | |
*** e0ne has quit IRC | 23:40 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!