| *** ysandeep|out is now known as ysandeep | 01:14 | |
| *** dviroel|afk is now known as dviroel | 01:16 | |
| *** dviroel is now known as dviroel|out | 01:22 | |
| *** ysandeep is now known as ysandeep|afk | 01:40 | |
| *** akahat is now known as akahat|rover | 05:29 | |
| *** ysandeep|afk is now known as ysandeep | 07:09 | |
| *** amoralej|off is now known as amoralej | 07:28 | |
| *** akahat|rover is now known as akahat|lunch | 08:30 | |
| *** ysandeep is now known as ysandeep|lunch | 08:36 | |
| *** akahat|lunch is now known as akahat|rover | 09:22 | |
| *** ysandeep|lunch is now known as ysandeep | 10:04 | |
| ralonsoh | hi folks, is gerrit today a bit slow? or is just me that I dind't pay my Interner connection? | 10:16 |
|---|---|---|
| *** dviroel|out is now known as dviroel|ruck | 10:46 | |
| frickler | ralonsoh: I don't see any issue. might have been only temporarily or really a local problem? | 10:55 |
| ralonsoh | frickler, is just that any time I try to open a review, it takes several seconds | 10:56 |
| ralonsoh | this could be something local, for sure | 10:56 |
| frickler | ralonsoh: might be your v4 is broken with fallback to v6 or the other way round? | 10:58 |
| ralonsoh | I'll check that | 10:58 |
| *** rlandy|out is now known as rlandy|ruck | 11:10 | |
| *** ysandeep is now known as ysandeep|mtg | 11:17 | |
| elodilles | hi, i think the following patch introduced some new gate / periodic job failures for really old branches (queens and pike): https://review.opendev.org/c/zuul/zuul-jobs/+/827588 | 11:36 |
| elodilles | some example: https://zuul.opendev.org/t/openstack/builds?job_name=build-openstack-sphinx-docs&project=openstack%2Fnova&project=openstack%2Fneutron&project=openstack%2Fironic&branch=stable%2Fqueens&skip=0 | 11:38 |
| *** ysandeep|mtg is now known as ysandeep | 12:02 | |
| frickler | elodilles: can't we finally retire these more than 2 years after py2 went eol? | 12:26 |
| elodilles | frickler: well, some projects already EOL'd their old branches, but some still accept patches | 12:32 |
| elodilles | i wouldn't say that the amount of patches are high though | 12:32 |
| elodilles | so probably yes, that is one option. but on the other hand i don't think this is the best approach to do it | 12:35 |
| frickler | well projects can still accept patches, but testing them with python2 no longer seems reasonable. actually I see that those jobs use ubuntu-xenial, we should have dropped supporting that image even before dropping centos8 | 12:35 |
| frickler | oh, wait, that's 18.04, not 16.04, so it would have one more year | 12:37 |
| elodilles | 18.04 is bionic | 12:38 |
| elodilles | so if we think the same way then ussuri, train and stein would have 1 year at most | 12:41 |
| elodilles | surely there are vendors / operators who would use those for some more years | 12:43 |
| frickler | surely then those vendors / operators will soon show up here and work on keeping the CI alive | 12:58 |
| elodilles | good point :) | 13:01 |
| sean-k-mooney | elodilles: by they regarding pip | 13:20 |
| sean-k-mooney | using pip form ubuntu is broken | 13:20 |
| sean-k-mooney | *by the way | 13:20 |
| sean-k-mooney | it will istall the packages and devstack can stack but ubuntu's pip cannot uninstall them | 13:21 |
| sean-k-mooney | or upgrade them | 13:21 |
| sean-k-mooney | it complains that they are not in env /usr | 13:21 |
| sean-k-mooney | so the recent chagne to devstack while it work it only works once | 13:22 |
| sean-k-mooney | on your local dev system you will need to revert to pip form pypi | 13:22 |
| fungi | that sounds like another new pip behavior | 13:31 |
| elodilles | sean-k-mooney: oh, thanks for the info. i haven't noticed that yet | 13:32 |
| fungi | elodilles: any reason those old branches can't use the available python3 to build their documentation, even if they still do other testing with python2? | 13:32 |
| fungi | preserving the ability to use python2 to build documentation seems like it's not all that important | 13:33 |
| sean-k-mooney | fungi: it appearntly has been a thing in ubuntu since 18.04 or possibel earlier based on stack overflow | 13:33 |
| sean-k-mooney | we are only seeing that now with devstack since we stopt usign pip from pypi | 13:34 |
| sean-k-mooney | fungi: i was also seeing issue with pbr | 13:34 |
| fungi | sean-k-mooney: yes, earlier versions of pip also refused to uninstall things which were installed by distro packages | 13:34 |
| sean-k-mooney | i could not get pip install -e to work properly | 13:34 |
| sean-k-mooney | nova could not find the version wehn it started up | 13:34 |
| fungi | a minimal reproducer would probably help us to have a clearer discussion about the behavior, or change thereof | 13:35 |
| sean-k-mooney | i can try doing it in a docker container | 13:35 |
| sean-k-mooney | and see if that repoduces | 13:35 |
| fungi | well, more like the minimal number of steps required to create the problem, without one of the steps being "install and run devstack" | 13:35 |
| *** dasm|off is now known as dasm | 13:36 | |
| fungi | like "install this package, then uninstall it, observe an error" that sort of ting | 13:36 |
| sean-k-mooney | fungi: its just git clone nova, sudo pip install nova, sudo pip uninstall nova | 13:36 |
| sean-k-mooney | the devstack connection is devstack uses sudo | 13:37 |
| fungi | ahh, okay, so pip is refusing to uninstall a package it has installed. and which version of pip specifically? | 13:37 |
| fungi | 22.x or something earlier? | 13:37 |
| sean-k-mooney | this was on my other laptop let me grab it | 13:37 |
| sean-k-mooney | ill see if i can repodcue in a doceker file too brb | 13:37 |
| fungi | and is it specifically only if you `sudo pip install -e ...` and then try to `sudo pip uninstall ...`? | 13:38 |
| sean-k-mooney | you do not need -e | 13:38 |
| sean-k-mooney | but i think its only with sudo | 13:38 |
| fungi | okay, you mentioned editable mode, so i was curious if it only happened with editable installs | 13:38 |
| sean-k-mooney | oh so my normal workflow | 13:38 |
| sean-k-mooney | is to have a second copy of the repos in /opt/repos | 13:39 |
| fungi | yeah, so for a while pip has refused to uninstall things which were installed by distro packages using distutils instead of setuptools | 13:39 |
| sean-k-mooney | and i sudo pip install -e . and restart the service | 13:39 |
| sean-k-mooney | when i want to work on a change | 13:39 |
| fungi | but pip refusing to uninstall something it installed is a new one on me | 13:39 |
| sean-k-mooney | it was python3-pip version 20.0.2-ubuntu1.6 | 13:41 |
| sean-k-mooney | i did a clean install form iso yesterday in this vm and just insalled the latest pip but i saw this on a could image last week too | 13:41 |
| fungi | okay, so not a behavior related to a new pip release | 13:42 |
| fungi | pip --version reports 20.0.2? | 13:42 |
| fungi | worth noting that the actual installed pip version may not be the same as what the distro package manager thinks is there if devstack did a `sudo pip install --upgrade pip` or similar | 13:42 |
| sean-k-mooney | ill have to reinstall it but ill check | 13:43 |
| sean-k-mooney | so ya its reporting as 20.0.2 not 22* | 13:46 |
| sean-k-mooney | 22* from pypi could uninstall things but pbr was kind of borked let me see if i can create a docker file that repoduces the issue and ill past bin it | 13:47 |
| elodilles | fungi: i'll try to debug the py35 based doc gen if i'll get there. i guess that should be doable | 13:49 |
| *** ysandeep is now known as ysandeep|mtg | 13:59 | |
| sean-k-mooney | fungi: odd in the contianer it works as i expect | 14:03 |
| sean-k-mooney | i wonder if i am some how getting a mix | 14:03 |
| sean-k-mooney | like coudl this be related to safe path and python -m pip vs pip | 14:03 |
| sean-k-mooney | with sudo | 14:03 |
| sean-k-mooney | in the contaienr i also dont get the warnign about you shoudl not use pip as sudo | 14:06 |
| sean-k-mooney | so im not convince its the same | 14:06 |
| sean-k-mooney | fungi: if i figure out what caused it on my laptop ill let you konw i think it might be the setuptoos dist utis flag different https://paste.opendev.org/show/812526/ | 14:23 |
| sean-k-mooney | the isntall is how devestack would do it | 14:23 |
| sean-k-mooney | btu it seams to just work when i use podman to buidl it so dont really know what to say at this pint | 14:23 |
| fungi | yeah, i'll try to keep an eye out for the problem | 14:24 |
| sean-k-mooney | i have hit it on 2 vms in the last week 1 ubuntu 20.04 cloud the other ubuntu 20.04 arm form iso | 14:24 |
| fungi | thanks for the heads up | 14:24 |
| sean-k-mooney | maybe i should go back to running devstack in a contaienr :) | 14:25 |
| sean-k-mooney | cause appently contaier fix everythign these days :P | 14:25 |
| fungi | magic container pixie dust | 14:26 |
| sean-k-mooney | in other new devstack/openstack appear to work runing in a 6G ubuntu vm on a mac book air | 14:27 |
| sean-k-mooney | the slightly concerning things is it installes faster then on my work laptop or home server | 14:28 |
| sean-k-mooney | there are a few things i need to go fix however. like not using x86 cirros on arm hosts | 14:29 |
| sean-k-mooney | you can overidee that in the local.conf but it would nice if it just worked out of the box | 14:29 |
| frickler | sean-k-mooney: seems the effort to produce a CI job for that have stalled, but maybe you want to take a look https://review.opendev.org/q/topic:story%252F2007196 | 14:33 |
| sean-k-mooney | if i keep using the mac ya perhaps | 14:39 |
| sean-k-mooney | i really dont like osx but i have been puting of replacing my dell xps 13 for 2 years and picked up the cheapest referbished m1 model just to see if i could live with osx | 14:41 |
| sean-k-mooney | i have to say the hardware is nice but really wish the linux support was a little more advanced | 14:41 |
| sean-k-mooney | frickler: for context on a clean vm i was getting a sub 5 minute devstack install | 14:42 |
| sean-k-mooney | total runtime 244sec speedup of 1.5 ish from parallel | 14:43 |
| frickler | wow, that's impressive. but I assume that that includes have local repo copies and also pre-cached wheels available? | 14:43 |
| sean-k-mooney | nope | 14:44 |
| sean-k-mooney | pulled directly form the internet over wifi | 14:44 |
| sean-k-mooney | well actlly 244 was a second stack | 14:44 |
| sean-k-mooney | the first one with the conles was a little longer | 14:44 |
| sean-k-mooney | but not much | 14:44 |
| sean-k-mooney | im not a fan of the lack of repairablity or 0 upgrade path but integrating everyting on an soc has some advandagtes for sure | 14:46 |
| *** ysandeep|mtg is now known as ysandeep|out | 14:53 | |
| opendevreview | Merged openstack/project-config master: Add cirros/cirros project https://review.opendev.org/c/openstack/project-config/+/827719 | 14:59 |
| *** dviroel|ruck is now known as dviroel|ruck|lunch | 15:17 | |
| *** akahat|rover is now known as akahat|dinner | 15:45 | |
| *** markzijdemans_ is now known as markzijdemans | 15:46 | |
| *** dviroel|ruck|lunch is now known as dviroel|ruck | 16:22 | |
| *** rlandy|ruck is now known as rlandy|ruck|brb | 16:30 | |
| clarkb | ralonsoh: frickler: we do notice appreciable slowdowns after a gerrit restart as cache data is flushed. There is work upstream to change the cache implementation to make it more persistent to alleviate that. But other than that situation I am not aware of anything that should be slowing down gerrit currently. We didn't restart recently either | 16:44 |
| ralonsoh | clarkb, thanks for the info! | 16:45 |
| ralonsoh | in this is better now. This morning, just for me, everything was working fine except gerrit | 16:45 |
| fungi | gerrit's webui relies on lots of rest api calls, which if sufficiently serialized could be very sensitive to round-trip latency | 16:48 |
| *** rlandy|ruck|brb is now known as rlandy|ruck | 16:54 | |
| *** amoralej is now known as amoralej|off | 17:41 | |
| *** akahat|dinner is now known as akahat|rover | 17:59 | |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Test that pbr.json is included in sdists https://review.opendev.org/c/openstack/pbr/+/827913 | 18:40 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Correctly evaluate whether we're in a dist context https://review.opendev.org/c/openstack/pbr/+/827914 | 18:40 |
| sean-k-mooney | fungi: will ^ fix pbr so that it can support -e again | 18:49 |
| fungi | sean-k-mooney: i dunno, did it not support -e? | 18:49 |
| fungi | it fixes the missing pbr.json files in sdists/wheels | 18:49 |
| sean-k-mooney | that was also broken with my weird pip issue | 18:49 |
| sean-k-mooney | pbr was fine but the version discorver when you started nova was broken | 18:50 |
| sean-k-mooney | saying that it must be a sdist of git tree | 18:50 |
| fungi | yeah, missing pbr.json metadata was a regression in pbr 5.8.0, so if your problem went away with a downgrade to building with pbr 5.7.0 then that change will likely fix it | 18:51 |
| fungi | it only just came to my attention earlier today, but trying to knock it out asap | 18:51 |
| fungi | the sooner we fix it, the fewer releases we'll publish without git data | 18:52 |
| sean-k-mooney | https://paste.opendev.org/show/812529/ | 18:53 |
| sean-k-mooney | that is the error i got when i did -e | 18:53 |
| sean-k-mooney | and restarted nova | 18:53 |
| sean-k-mooney | so that is broken in 5.8.0 | 18:54 |
| sean-k-mooney | let me check the pbr version i have | 18:54 |
| sean-k-mooney | ya 5.8.0 | 18:55 |
| clarkb | it is odd that would break when using -e since that should rely on the git install | 18:55 |
| clarkb | I would expect it to be broken without -e and not the other way around | 18:55 |
| sean-k-mooney | sudo pip install was fine since it built the sdist | 18:55 |
| sean-k-mooney | but -e didnt work for some reason | 18:55 |
| sean-k-mooney | also with -e i could not do pip show | 18:56 |
| sean-k-mooney | the package did not show as installed system properly | 18:56 |
| sean-k-mooney | so i think this broke the discover | 18:56 |
| sean-k-mooney | fungi: did ye pull that form pypi? | 18:57 |
| fungi | pull what from pypi? | 18:57 |
| sean-k-mooney | mark it as not discoverable | 18:57 |
| sean-k-mooney | i was wonderign if that is why i could not repoduce my other git issues in the container | 18:57 |
| fungi | oh, yank the release? i think that might break projects which require pbr>=4.8 for pep 517 builds | 18:57 |
| sean-k-mooney | i was going to see what version of pbr the contaienr had | 18:57 |
| clarkb | I don't think it has been pulled. I'm not sure pulling is appropriate here since it would berak ya | 18:57 |
| fungi | er, pbr>5.8 | 18:58 |
| fungi | i can't type. it must be friday | 18:58 |
| sean-k-mooney | ya its not good to yank things | 18:58 |
| sean-k-mooney | just wondering if that is why i could not repocue my other pip issue sould like no | 18:58 |
| fungi | 5.8.0 added a feature, so projects depending on that feature would be broken if we yanked it | 18:58 |
| sean-k-mooney | i assume we are going to exclude it in global requirements | 18:59 |
| sean-k-mooney | since its a knonw broken release | 18:59 |
| clarkb | sean-k-mooney: you can't. PBR is a setup_requiers so doesn't work that way | 18:59 |
| sean-k-mooney | ah right | 18:59 |
| clarkb | if all of openstack switch to pep 517 then you could control the version per project in pyprojcet.toml | 19:00 |
| fungi | it's basically already installed and used to build other things before you reach the point where you'd be applying constraints | 19:00 |
| clarkb | but otherwise you get what easy_install resolves to which is whatever you have already installed or latest | 19:00 |
| sean-k-mooney | ya | 19:00 |
| fungi | anyway, we should have it fixed and released forthwith, early next week at the latest | 19:01 |
| sean-k-mooney | the contaienr had 5.8.0 as well anyway | 19:02 |
| sean-k-mooney | fungi: the fact that pip install -e was broken was my original issue | 19:03 |
| sean-k-mooney | as i said previoul my workflow is to run stack.sh then pip install -e /opt/repos/nova | 19:03 |
| sean-k-mooney | and restart the nova services | 19:04 |
| clarkb | fungi: any projects tht are worried about their sdists can bump the bug number and make new releases on the previous commits too | 19:04 |
| clarkb | but I agree fixing quickly is desireable | 19:04 |
| fungi | yep | 19:04 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Test that pbr.json is included in sdists https://review.opendev.org/c/openstack/pbr/+/827913 | 19:33 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Correctly evaluate whether we're in a dist context https://review.opendev.org/c/openstack/pbr/+/827914 | 19:33 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Correctly evaluate whether we're in a dist context https://review.opendev.org/c/openstack/pbr/+/827914 | 20:06 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Test that pbr.json is included in sdists https://review.opendev.org/c/openstack/pbr/+/827913 | 20:50 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Correctly evaluate whether we're in a dist context https://review.opendev.org/c/openstack/pbr/+/827914 | 20:50 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Import pbr.util directly to break import loops https://review.opendev.org/c/openstack/pbr/+/827922 | 20:50 |
| elodilles | fungi: i've tried to 'quick fix' the sphinx-docs tox target locally without py27, using py35 on stable/queens (nova) and it's quite complex as there are requirement conflicts, and multiple doc changes that were added in rocky (for py3 compatibility and other updates) so i haven't succeded with it yet. and this is only one repo and one branch but there are multiple repos and branches that are | 20:55 |
| elodilles | failing due to lack of py27 support for sphinx | 20:55 |
| elodilles | so it's not that trivial to use py35 based sphinx-docs instead of py27 based one... (for old stable branches) | 21:00 |
| fungi | elodilles: next question... what's the importance of continuing to build docs for new patches to those branches? is anyone fixing/updating the docs there? | 21:16 |
| elodilles | well, probably not that important, and for EM it is said that CI support might be downgraded. so i guess that's the easiest option if sphinx-docs jobs will be removed for queens and pike branches where it fails now | 21:19 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Test that pbr.json is included in sdists https://review.opendev.org/c/openstack/pbr/+/827913 | 21:38 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Always write pbr.json https://review.opendev.org/c/openstack/pbr/+/827927 | 21:38 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Always write pbr.json https://review.opendev.org/c/openstack/pbr/+/827927 | 21:47 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Break pbr() recursion via alternative method https://review.opendev.org/c/openstack/pbr/+/827930 | 21:58 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Avoid recursive calls into SetupTools entrypoint https://review.opendev.org/c/openstack/pbr/+/827931 | 21:58 |
| *** dviroel|ruck is now known as dviroel|out | 22:06 | |
| *** dasm is now known as dasm|off | 22:13 | |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Avoid recursive calls into SetupTools entrypoint https://review.opendev.org/c/openstack/pbr/+/827931 | 23:36 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!