| *** soniya29|rover is now known as soniya29|rover|brb | 07:12 | |
| *** soniya29|rover|brb is now known as soniya29|rover | 08:15 | |
| *** jpena|off is now known as jpena | 08:21 | |
| *** soniya29|rover is now known as soniya29|rover|lunch | 09:16 | |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Add Opensearch dashboards backup script; add dashboards objects https://review.opendev.org/c/openstack/ci-log-processing/+/860811 | 09:40 |
|---|---|---|
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Ensure that important files are downloaded https://review.opendev.org/c/openstack/ci-log-processing/+/864905 | 10:02 |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Add Opensearch dashboards backup script; add dashboards objects https://review.opendev.org/c/openstack/ci-log-processing/+/860811 | 10:09 |
| opendevreview | Merged openstack/ci-log-processing master: Change container image tag to latest; remove basepython from tox.ini https://review.opendev.org/c/openstack/ci-log-processing/+/869542 | 10:09 |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Add Opensearch dashboards backup script; add dashboards objects https://review.opendev.org/c/openstack/ci-log-processing/+/860811 | 10:11 |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Ensure that important files are downloaded https://review.opendev.org/c/openstack/ci-log-processing/+/864905 | 10:12 |
| *** soniya29|rover|lunch is now known as soniya29|rover | 10:44 | |
| *** rlandy|out is now known as rlandy | 11:14 | |
| *** dviroel|out is now known as dviroel | 11:44 | |
| *** dasm|off is now known as dasm | 14:07 | |
| *** soniya is now known as soniya|rover | 14:34 | |
| *** dviroel is now known as dviroel|lunch | 15:28 | |
| *** soniya|rover is now known as soniya|rover|out | 15:52 | |
| *** dviroel|lunch is now known as dviroel | 16:35 | |
| fungi | clarkb: stephenfin: does the problem described in the commit message for https://review.opendev.org/870844 seem at all familiar, and if so what have other projects done to address it? | 16:58 |
| clarkb | fungi: I think when it installs the project itself | 17:01 |
| clarkb | fungi: our tox logs should be verbose enough to pinpoint when it happens | 17:01 |
| clarkb | iirc tox installs deps first into he venv. THen it installs the project itself. When it installs the project itself it still uses pip install -U which can upgrade a previously constrained dep | 17:02 |
| fungi | unfortunately tox v4's logs are not verbose at all. they say "i'm performing these various steps" followed by "these are the versions i installed" | 17:04 |
| fungi | you don't get the intermediate version info | 17:05 |
| fungi | clarkb: do you happen to know if the patch there is the way other projects might have already addressed it? | 17:06 |
| clarkb | yes I think that is a common appraoch | 17:06 |
| fungi | putting constraints into tox.install_command instead of testenv.deps, or in addition to? | 17:07 |
| clarkb | I think I've seen both | 17:08 |
| clarkb | but not sure if pip will complain about -c being set twice? | 17:08 |
| fungi | i think the tricky situation for that solution is when some testenvs need a different constraints list (lower constraints jobs, or a loca | 17:08 |
| fungi | l python 2.7 constraints list like swift uses) | 17:08 |
| fungi | since tox.install_command is global and can't be overridden on a per-env basis | 17:09 |
| clarkb | use nox? (only half joking, nox gives you far more control over things like this) | 17:10 |
| clarkb | I'm not sure how to address that. Maybe if you set the lower constraints env var in the env for a test env that will sufficientl override things? | 17:11 |
| fungi | oh, right, i keep forgetting the url is only used for local runs | 17:12 |
| fungi | so if it does break, zuul will probably mask it | 17:12 |
| clarkb | right would likely only be a local issue | 17:13 |
| *** jpena is now known as jpena|off | 17:26 | |
| timburke | clarkb, given the frequency of breakage recently, "use nox" is kind of appealing -- would we need to get https://governance.openstack.org/tc/reference/pti/python.html updated, though? | 18:43 |
| timburke | given the general python-community movement toward pyproject.toml, we should probably re-evaluate that anyway -- it seems unlikely that we want to stick with setup.py indefinitely | 18:45 |
| clarkb | timburke: yes, the TC would need to get involved and a bunch of tooling thatassumes tox would need to be modified to also handle nox. I did some of the porting in zuul-jobs already and so far the porting has been straightforward just needs work | 18:47 |
| clarkb | timburke: I think gmann was suggesting this could be something that is discussed at the PTG | 18:47 |
| clarkb | as far as pyproject.toml goes that is a separate issue | 18:47 |
| timburke | 👍 | 18:47 |
| clarkb | At this point there are a handlful of "standard" python tools that can roughly approximate what PBR does. The big missing feature is semver understanding in predicting versions | 18:48 |
| clarkb | PBR does also attempt to support pyproject.toml via the setuptools shim stuff so leaving PBR shouldn't be required to use prproject.toml | 18:48 |
| clarkb | but I think there is potential for streamlining in that conversion should it happen | 18:49 |
| fungi | yes, i have a project which uses a pyproject.toml instead of setup.cfg with pbr just fine | 18:51 |
| JayF | I dug into nox somewhat for research | 18:52 |
| JayF | and I'm on the nox train | 18:52 |
| JayF | I reimplemented the entire ironic-python-agent test suite in nox in ~1 hour | 18:52 |
| JayF | https://www.youtube.com/watch?v=cAkMVIBTFbQ (I did it during my office hours so it's actually on video) | 18:53 |
| JayF | I really, really like the tagging of environments to run groups of 'em | 18:53 |
| clarkb | JayF: yup, and the way it handles python versions is really nice too | 18:54 |
| clarkb | its more explicit and less implied which I prefer for CI where you really want to be explicit and only run under a specific version | 18:54 |
| JayF | yeah basically I had a list of "but it needs X" and the more I learned the more I could strike off the list | 18:56 |
| *** Tengu7 is now known as Tengu | 18:59 | |
| opendevreview | Merged openstack/project-config master: Add FIPS job for ubuntu https://review.opendev.org/c/openstack/project-config/+/867112 | 19:45 |
| *** rlandy is now known as rlandy|brb | 19:50 | |
| ianw | ade_lee: the zuul-jobs fips stuff looks ok to me, but i do have a question about the enable flag pointed out by fungi | 19:53 |
| ianw | we haven't generally accepted "we don't think anyone uses this" for making backwards incompat changes, so i feel like it's better if we don't invert the enable flag. is there a strong reason to? | 19:54 |
| *** dviroel_ is now known as dviroel|afk | 19:57 | |
| fungi | i think it's so that the job can be a parent (many generations deep) of lots of jobs the majority of which don't need that feature, so only the few which do need to be edited to turn it on | 20:08 |
| fungi | e.g. all devstack/tempest jobs | 20:09 |
| fungi | the problem is that the changes it needs to make and reboot it performs when enabled have to happen very, very early in pre-run, so getting it into that position relative to all the other parents/children either means it needs to be in the ancestry of a majority of those jobs, or needs a completely parallel set of job definitions separately parented to it | 20:10 |
| ianw | ... ok ... why wouldn't the job just do like "include_role: enable-fips" with a when: based on a variable? like why always include the role? | 20:11 |
| fungi | that seems like a viable alternative. it doesn't solve the ancestry issue making it need to be disabeld by default though | 20:12 |
| ianw | that is a fair point though about the earliness of it all | 20:12 |
| fungi | it's an unfortunate inflexibility of zuul's onion inheritance model | 20:13 |
| fungi | and teh fact that we never figured out how to properly do mix-ins | 20:13 |
| ianw | ohhh, i see, that enable_fips is an argument to the pre playbook | 20:14 |
| fungi | right | 20:15 |
| ianw | i'll have to double think about it, but yeah i get more an idea what's going on now | 20:16 |
| fungi | it's a head-scratcher. if you have better ideas, i'm all for them | 20:17 |
| *** rlandy|brb is now known as rlandy | 20:43 | |
| clarkb | ianw: fungi: should I hold off on reviewing/+2'ing the change then if we are tring to come up with a better solution? | 21:05 |
| fungi | i'd at least wait for ianw to finish reviewing it | 21:11 |
| ianw | ok, i've reviewed more fully and come down at -1 pending a bit more clarity on what's going on. my objection is that it seems to be intended that you parent to -fips versions of jobs, but have a foot-gun loaded in that this won't actually enable fips ... | 22:26 |
| fungi | yes, i saw and concur with your analysis. at the very least, if the idea is to have devstack-base reparented to openstack-multinode-fips then that needs to be spelled out in the commit message | 22:34 |
| fungi | (right now devstack-base's parent is multinode from zuul-jobs) | 22:35 |
| opendevreview | Ian Wienand proposed openstack/project-config master: linaro-us : set max-servers to 0 https://review.opendev.org/c/openstack/project-config/+/870876 | 23:41 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!