| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Change haproxy variable used to set security headers to haproxy_frontend_raw https://review.opendev.org/c/openstack/openstack-ansible/+/821814 | 03:41 |
|---|---|---|
| noonedeadpunk | damiandabrowski[m]: there're some problems, yes... And pretty huge ML thread regarding them becoming offical project due to this | 03:47 |
| noonedeadpunk | As they didn't want to use like oslo and invented their own way of doing things | 03:48 |
| noonedeadpunk | But I guess they agreed to adapt some things at the end | 03:51 |
| noonedeadpunk | Will see | 03:51 |
| jrosser_ | we really are very unlucky with the 'start Y cycle' patch | 07:44 |
| jrosser_ | it's failing already again | 07:44 |
| noonedeadpunk | damn | 07:45 |
| * jrosser_ wonders where the ara report has gone | 07:50 | |
| noonedeadpunk | it crashed while generating | 07:50 |
| jrosser_ | yes https://paste.opendev.org/show/811714/ | 07:51 |
| noonedeadpunk | oh and it fails everywhere now | 07:51 |
| noonedeadpunk | dmsimard: anything known? ^ | 07:51 |
| jrosser_ | is this subject to u-c? | 07:52 |
| jrosser_ | maybe something important is bumped and breaks it | 07:52 |
| noonedeadpunk | well i sounds like dynaconf ut it's not constrained | 07:53 |
| noonedeadpunk | (which is even worse) | 07:53 |
| noonedeadpunk | and released a week ago :D | 07:54 |
| noonedeadpunk | and they even dropped previous version from pypi... | 07:54 |
| noonedeadpunk | there's no 3.1.6 https://pypi.org/project/dynaconf/#history | 07:55 |
| jrosser_ | nice | 07:55 |
| jrosser_ | looking in the ara release notes same kind of thing has happened before | 07:55 |
| Brace | Probably not the right place to ask, but does anyone know Openstack (Victoria) is vulnerable to log4j? | 09:06 |
| jrosser_ | openstack itself is python, not java | 09:08 |
| jrosser_ | if you surround your openstack with other external tools, like an ELK stack for log collection for example, then you'd defiantly need to address that. | 09:10 |
| Brace | jrosser_: that's kinda what I thought, thank you for confirming | 09:37 |
| *** sshnaidm|afk is now known as sshnaidm | 10:54 | |
| *** dviroel|out is now known as dviroel|rover | 11:26 | |
| dmsimard | noonedeadpunk: not aware of an issue but I've also been a bit out of the loop, it wouldnt be the first time dynaconf breaks ara | 12:09 |
| dmsimard | I'm not fully awake yet, could I ask you to create an issue on github ? I will look today | 12:09 |
| noonedeadpunk | sure | 12:23 |
| jamesdenton | good morning, all | 13:31 |
| damiandabrowski[m] | hey! | 13:32 |
| dmsimard | noonedeadpunk, jrosser_: I have other stuff I need to look at but I glanced briefly at the issue and I don't see a recent release of dynaconf ? Looks like last version dates back to september | 13:43 |
| noonedeadpunk | facepalm | 13:44 |
| noonedeadpunk | yes, sorry... I read september as december | 13:45 |
| noonedeadpunk | hm, which means it's smth different.... | 13:45 |
| noonedeadpunk | Sorry, was pretty busy, will make up bug report a bit later | 13:45 |
| dmsimard | np, not saying there is no bug but I was wondering if I was missing something obvious | 13:46 |
| dmsimard | I will take another look later | 13:46 |
| jrosser_ | noonedeadpunk: dmsimard its perhaps this https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L448 | 14:28 |
| jrosser_ | we've run jobs today on stable/xena which install django 2.2.24 and generate a report ok, but from master we pick up the master version of upper-constraints and get 3.2.10 | 14:30 |
| noonedeadpunk | well https://github.com/ansible-community/ara/blob/master/setup.cfg#L64 | 14:31 |
| noonedeadpunk | We should somehow avoid u-c for ara I guess | 14:32 |
| dmsimard | oh yeah, ara isn't tested with django 3.2 yet | 14:32 |
| noonedeadpunk | for some reason I thought they're not used even... | 14:32 |
| dmsimard | ara is meant to use the 2.2 LTS for now but there is an issue to upgrade to django 3.2 which is the next LTS | 14:33 |
| dmsimard | good catch | 14:33 |
| jrosser_ | should it be respecting setup.cfg when we install? | 14:33 |
| jrosser_ | if it were i'd expect it to conflict with whats in u-c and fail | 14:34 |
| noonedeadpunk | so that's how we install it https://opendev.org/openstack/openstack-ansible/src/branch/master/scripts/scripts-library.sh#L204-L210 | 14:34 |
| noonedeadpunk | question is what's in PIP_OPTS | 14:34 |
| jrosser_ | ahh i see | 14:34 |
| dmsimard | that pin on dynaconf can also go away | 14:34 |
| dmsimard | it was to avoid 3.1.3 but it's since been excluded from ara: https://github.com/ansible-community/ara/blob/master/setup.cfg#L70 | 14:35 |
| noonedeadpunk | I guess we add u-c here https://opendev.org/openstack/openstack-ansible/src/branch/master/scripts/scripts-library.sh#L71 | 14:36 |
| jrosser_ | /opt/ansible-runtime/bin/pip install --isolated --index-url http://mirror.bhs1.ovh.opendev.org/pypi/simple --trusted-host mirror.bhs1.ovh.opendev.org --extra-index-url http://mirror.bhs1.ovh.opendev.org/wheel/ubuntu-20.04-x86_64 --constraint global-requirement-pins.txt --constraint file:///opt/ansible-runtime-constraints-f5dcb1d64534feb5720400c81089bd2b0765e2c3.txt 'ara[server]' 'dynaconf<3.1.3' | 14:38 |
| jrosser_ | for example | 14:38 |
| jrosser_ | feels like the issue is that we install ansible-runtime according to u-c (maybe unnecessary now?) | 14:39 |
| jrosser_ | so then coming along later to install ara without u-c might change a bunch of stuff | 14:39 |
| dmsimard | if django is the only issue maybe you can pin it to https://github.com/ansible-community/ara/blob/f366c9f9f2a06311dd67449f1124dca0674563c2/setup.cfg#L64 like you did with dynaconf | 14:40 |
| dmsimard | I don't suspect you'd install django for another reason than ara in the runtime venv -- I guess the u-c on it is for horizon | 14:40 |
| jrosser_ | it was ok for dynaconf as that doesnt appear in u-c | 14:41 |
| noonedeadpunk | I'd expect to see pip conflicting because of that... | 14:41 |
| jrosser_ | tbh really all we put in ansible-runtime venv is ansible now | 14:41 |
| jrosser_ | there used to be the openstack client and stuff but not any more | 14:42 |
| jrosser_ | so maybe this is just legacy and we'd be better sticking with our own global-pins here | 14:42 |
| dmsimard | noonedeadpunk: ah, my u-c is rusty :) | 14:42 |
| jrosser_ | with older pip it would have been ok | 14:42 |
| noonedeadpunk | Then I wonder if we should put ansible dependencies like jinja inside our pins | 14:42 |
| jrosser_ | but now with the new resolver if you have two differing constraints for the same thing it fails | 14:43 |
| noonedeadpunk | as nasty htings might happen when new jinja lands for same osa for instance | 14:43 |
| noonedeadpunk | and I think it's not only thing that we might want to lock | 14:44 |
| jrosser_ | right - and then we are in the same problem as jinja2 is also in u-c | 14:44 |
| jrosser_ | it amost says that we want our own controlled constraints file for the ansible-runtime venv | 14:44 |
| jrosser_ | as it's not really a co-installable openstack thing, just internal to OSA | 14:44 |
| noonedeadpunk | well, I guess while it's unctrained in u-c we might be fine not having it locally? | 14:45 |
| noonedeadpunk | *while it's constrained | 14:45 |
| noonedeadpunk | What I meant is that we likely want to have ansible dependencies constrained somehow anyway | 14:45 |
| jrosser_ | well, if we want to constrain the django version then we can't use u-c | 14:46 |
| noonedeadpunk | and it's more matter if we want to maintain that or not | 14:46 |
| jrosser_ | without a bunch of filtering mess in boostrap-ansible to remove some things | 14:46 |
| noonedeadpunk | or we can just drop U-C when installing ara... Yeah, that could bring us some mess in venv in CI though | 14:47 |
| jrosser_ | jinja2 in u-c -> good / django in u-c -> bad from ansible-runtime POV, we're a little stuck | 14:47 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Do not add u-c to PIP_OPTS https://review.opendev.org/c/openstack/openstack-ansible/+/821988 | 14:50 |
| noonedeadpunk | jrosser_: wdyt? ^ | 14:50 |
| noonedeadpunk | doh.... | 14:51 |
| jrosser_ | it would be possible to use global-pins and a new ansible-runtime-pins for that | 14:51 |
| jrosser_ | so that we have the same setuptools / virtualenv / .... everywhere from global-pins | 14:51 |
| jrosser_ | then specifically we can put the jinja2 version (and anything else just for the runtime venv) in ansible-runtime-pins | 14:52 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Do not add u-c to PIP_OPTS https://review.opendev.org/c/openstack/openstack-ansible/+/821988 | 14:52 |
| noonedeadpunk | I didn't really understood but sounds interesting :) | 14:53 |
| jrosser_ | :) | 14:53 |
| jrosser_ | you were concerned about the jinja2 version being unconstrained | 14:53 |
| noonedeadpunk | just in case setuptools are now in u-c | 14:53 |
| jrosser_ | and i agree there that there is a risk of wierdness for stable branches | 14:54 |
| noonedeadpunk | well it wasnt only about jinja... | 14:54 |
| noonedeadpunk | PyYAML is also constrained for example | 14:55 |
| noonedeadpunk | and cryptography | 14:55 |
| noonedeadpunk | https://github.com/ansible/ansible/blob/devel/requirements.txt is quite small though:) | 14:55 |
| jrosser_ | hah i was just looking at exactly the same file | 14:55 |
| noonedeadpunk | and packaging btw in u-c as well. so the only unconstrained thing now is resolvelib | 14:56 |
| noonedeadpunk | and I kind of wonder if collections do install required modules to venv as well.... | 14:56 |
| jrosser_ | well idk - do we use some horrible grep to pull the necessary lines out of u-c? we have the file in /opt now | 14:57 |
| jrosser_ | but it does make me wonder why this all doesnt break more often - i'm forever making a new venv and pip install ansible into it | 14:58 |
| noonedeadpunk | I believe that collections do not install modules they need... | 14:59 |
| *** dviroel|rover is now known as dviroel|rover|lunch | 15:51 | |
| opendevreview | Merged openstack/openstack-ansible master: Start Yoga development cycle https://review.opendev.org/c/openstack/openstack-ansible/+/821476 | 16:29 |
| noonedeadpunk | finally.... | 16:30 |
| *** dviroel|rover|lunch is now known as dviroel|rover | 16:42 | |
| opendevreview | Merged openstack/openstack-ansible master: Change haproxy variable used to set security headers to haproxy_frontend_raw https://review.opendev.org/c/openstack/openstack-ansible/+/821814 | 18:55 |
| opendevreview | Merged openstack/openstack-ansible master: [doc] Add Xena compatible OS https://review.opendev.org/c/openstack/openstack-ansible/+/821676 | 18:55 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible stable/xena: [doc] Add Xena compatible OS https://review.opendev.org/c/openstack/openstack-ansible/+/822020 | 18:58 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible stable/xena: Change haproxy variable used to set security headers to haproxy_frontend_raw https://review.opendev.org/c/openstack/openstack-ansible/+/822021 | 18:59 |
| noonedeadpunk | would be great if we could fast merge these backports ^ | 18:59 |
| noonedeadpunk | regarding ara - this works https://review.opendev.org/c/openstack/openstack-ansible/+/821988 but I didn't catch alternative. Maybe you can pus patch jrosser_ with what you was suggsting? | 19:00 |
| jrosser_ | oh well basically an extra pins file just for the runtime venv | 19:01 |
| jrosser_ | so it gets global_pins + ansibl_pins | 19:01 |
| spatel | jamesdenton around? | 19:31 |
| opendevreview | Merged openstack/openstack-ansible stable/xena: Add documentation of security improvements made to Openstack Ansible https://review.opendev.org/c/openstack/openstack-ansible/+/821529 | 19:47 |
| opendevreview | Merged openstack/openstack-ansible stable/xena: [doc] Add Xena compatible OS https://review.opendev.org/c/openstack/openstack-ansible/+/822020 | 19:47 |
| *** dviroel|rover is now known as dviroel|out | 21:21 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!