| opendevreview | yatin proposed openstack/devstack master: Fix name for neutron tempest uwsgi job https://review.opendev.org/c/openstack/devstack/+/880587 | 07:32 |
|---|---|---|
| opendevreview | Ade Lee proposed openstack/devstack master: Modify devstack-base to allow for fips https://review.opendev.org/c/openstack/devstack/+/871606 | 08:43 |
| opendevreview | Ade Lee proposed openstack/tempest master: Simplify definition of fips jobs https://review.opendev.org/c/openstack/tempest/+/873697 | 08:44 |
| opendevreview | yatin proposed openstack/devstack master: Fix name for neutron tempest uwsgi job https://review.opendev.org/c/openstack/devstack/+/880587 | 11:17 |
| opendevreview | Lukas Piwowarski proposed openstack/tempest master: [WIP] Add cleanup for create_containers() https://review.opendev.org/c/openstack/tempest/+/880630 | 13:30 |
| opendevreview | Lukas Piwowarski proposed openstack/tempest master: [WIP] Add cleanup for create_containers() https://review.opendev.org/c/openstack/tempest/+/880630 | 13:35 |
| opendevreview | Lukas Piwowarski proposed openstack/tempest master: [WIP] Add cleanup for create_containers() https://review.opendev.org/c/openstack/tempest/+/880630 | 13:37 |
| ykarel | gmann, kopecmartin when you get chance please check https://review.opendev.org/c/openstack/devstack/+/880533 | 13:57 |
| opendevreview | Lukas Piwowarski proposed openstack/tempest master: [WIP] Add cleanup for create_containers() https://review.opendev.org/c/openstack/tempest/+/880630 | 15:51 |
| frickler | gmann: to you want to wait on nova for https://review.opendev.org/c/openstack/hacking/+/874516 or drop that dep and keep the test job n-v for now? | 17:07 |
| gmann | frickler: nova does not need to be fixed before hacking new version as hacking is capped always https://github.com/openstack/nova/blob/01ffb6df85ad895bfe94cc46a3be958dbd266a7a/test-requirements.txt#L5 | 17:13 |
| gmann | artom: ^^ can you remove the depends-on and add nova job in gate pipeline also | 17:13 |
| artom | gmann, "also"? | 17:15 |
| artom | Oh | 17:15 |
| artom | Right, we don't need depends-on because hacking in Nova is capped, and we need to add the job to the hacking gate as well | 17:16 |
| gmann | artom: thanks | 17:16 |
| opendevreview | Artom Lifshitz proposed openstack/hacking master: Fix nova integration job and make it voting https://review.opendev.org/c/openstack/hacking/+/874516 | 17:17 |
| opendevreview | Artom Lifshitz proposed openstack/hacking master: Fix nova integration job and make it voting https://review.opendev.org/c/openstack/hacking/+/874516 | 17:29 |
| artom | Looks like we need the Depends-on :) | 17:30 |
| artom | Should we poke some nova cores to get https://review.opendev.org/c/openstack/nova/+/874517 landed? | 17:30 |
| gmann | artom: let me release hacking new version and then nova can also bump hacking to latest so that we can verify the nova changes | 17:32 |
| gmann | artom: frickler and once nova fix then we can get 874517 in | 17:33 |
| gmann | ykarel: done | 18:17 |
| opendevreview | Merged openstack/devstack master: [ovs] Reload ovs kernel module always https://review.opendev.org/c/openstack/devstack/+/880533 | 20:58 |
| gmann | kopecmartin: frickler: artom: releasing hacking new version https://review.opendev.org/c/openstack/releases/+/880686 | 22:26 |
| gmann | frickler: artom: and on rethinking on making nova job voting, I think this is not good idea to make it voting which will block all incompatible/new checks to be added until we fix things in advance in Nova https://review.opendev.org/c/openstack/hacking/+/874516, | 22:28 |
| artom | I suppose that's true | 22:28 |
| artom | But I'd really like a way to avoid this sort of "catch up" patch | 22:29 |
| artom | ... but maybe I need to change my mind about that, and we're fine periodically "fixing" Nova as hacking evolves | 22:29 |
| artom | This whole thing started because our own internal CI failed a pep8 check on a line > 80 characters, and I went down the rabbit whole of how did upstream CI miss it | 22:30 |
| clarkb | I tried to capture this on a requirements change recently but historically the idea was you would really only ever change the versions of linters at the beginning of a cycle | 22:43 |
| clarkb | with the expectation that everyone would just need to take a day and catch up. Because ultimately that becomes the easiest way to handle this for everyone | 22:44 |
| clarkb | otherwise you end up needing complicated synchronization if you try to avoid breaking people. | 22:44 |
| gmann | yeah, latest hacking can be adopted any time with required changes. may be you can pin hacking in internal CI too as master/new version hacking can break them any time | 22:54 |
| gmann | same way we do in upstream | 22:56 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!