| *** mhen_ is now known as mhen | 02:46 | |
| opendevreview | Ivan Anfimov proposed openstack/freezer master: wip https://review.opendev.org/c/openstack/freezer/+/974399 | 08:13 |
|---|---|---|
| opendevreview | Ivan Anfimov proposed openstack/freezer master: wip https://review.opendev.org/c/openstack/freezer/+/974399 | 08:17 |
| opendevreview | Ivan Anfimov proposed openstack/freezer master: wip https://review.opendev.org/c/openstack/freezer/+/974399 | 08:21 |
| opendevreview | Ivan Anfimov proposed openstack/freezer master: docs: fix few mistakes https://review.opendev.org/c/openstack/freezer/+/974399 | 08:22 |
| opendevreview | Ivan Anfimov proposed openstack/freezer master: docs: fix few mistakes https://review.opendev.org/c/openstack/freezer/+/974399 | 08:31 |
| noonedeadpunk | huh, seems that smth is off with devstack.... | 10:25 |
| noonedeadpunk | I'm really not sure if it's the freezer issue or just devstack in general | 10:27 |
| noonedeadpunk | like we haven't merged anything which would make API to fail to start I'd say | 10:29 |
| noonedeadpunk | https://zuul.opendev.org/t/openstack/build/9cb2365018b7402aa9b4d985c6a92b37/log/controller/logs/screen-freezer-api.txt\ | 10:29 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/freezer-api master: Use SSL and authentication for elasticsearch https://review.opendev.org/c/openstack/freezer-api/+/974411 | 11:59 |
| mhen | noonedeadpunk: yea that looks really strange, I have no explanation either | 12:09 |
| mhen | I compared to the logs of my running instance on my devstack and even the "UNABLE to load uWSGI plugin" at the top is there so that is not the culprit | 12:10 |
| mhen | otherwise it looks pretty similar up until "unable to load app 0" | 12:11 |
| mhen | no clue | 12:11 |
| noonedeadpunk | My guess was that some dependency was updated in u-c, but I have not figured out which ones | 12:13 |
| noonedeadpunk | (like flask or smth) | 12:13 |
| noonedeadpunk | btw, elasticsearch driver seems way more broken then anticipated. It also seems not really compatible with python library version after the upgrade | 12:14 |
| noonedeadpunk | trying to figure this out now | 12:14 |
| noonedeadpunk | mhen: I think this is the reason: https://opendev.org/openstack/requirements/commit/be5dd6e6b69ef23d6a2ba87041dbc2c39f555750 | 13:32 |
| noonedeadpunk | https://opendev.org/openstack/oslo.db/commit/4a29bee924bdf1636e797151ce79a05daddd51f7 -> freezer-api relises on this still | 13:34 |
| noonedeadpunk | I think for elastic to work, we actually need to significantly refactor it.... | 13:58 |
| mhen | noonedeadpunk: currently looking into making the naming of resources consistent, especially the temporary ones; what do you think about naming the final restored resources? The glance mode prepended "restore_" but cinder and nova tried to replicate the original name; I'm thinking about "original-name" vs. "original-name (restored) here. | 14:56 |
| mhen | The "restore_" could be confused with the temporary resource prefix, so I wouldn't want to use that for the final resources | 14:57 |
| mhen | naming them the same as the original resources can get confusing if the original ones still exist | 14:58 |
| noonedeadpunk | I think I'd avoid using brackets or spaces potentially, but not sure | 14:58 |
| noonedeadpunk | but also description can help to distinguish | 14:59 |
| mhen | problem is I realized that glance images have no description field D: | 14:59 |
| mhen | so I had to drop that idea | 14:59 |
| mhen | and glance images are used a lot as temporary resources | 15:00 |
| mhen | I could do it for servers and volumes but I want to achieve consistency across the board here | 15:00 |
| noonedeadpunk | ok, right | 15:02 |
| noonedeadpunk | I'd say that having also the backup ID from which it was restored might be useful then? | 15:02 |
| mhen | difficult; I think backups do not have an ID per se, only an optional name | 15:04 |
| mhen | I think the most reliable and meaningful thing would be the backup timestamp | 15:05 |
| noonedeadpunk | ah... becauys API is optional, and it's different also for elastic/mysql? | 15:09 |
| noonedeadpunk | as I opriginally looked at https://opendev.org/openstack/freezer-api/src/branch/master/freezer_api/db/sqlalchemy/models.py#L180 | 15:09 |
| mhen | I'm looking at freezer-agent isolated; it does not have the notion of a backup id when used directly | 15:10 |
| noonedeadpunk | I kind of dunno about restoration name. not that I have some opinion there tbh. | 15:10 |
| noonedeadpunk | as it can be confusing both ways. | 15:11 |
| noonedeadpunk | like you could easily do multiple restores in attempt to look for some valid ones | 15:11 |
| noonedeadpunk | and having 5 restored resources with the same name would be also confusing | 15:11 |
| mhen | I think "<name>@<timestamp>" would be the most clear way to differentiate actual different instances of a restored resource and help identifying its origin at a glance (due to the timestamp) | 15:13 |
| mhen | as in timestamp of the point in time the backup was created | 15:15 |
| noonedeadpunk | yeah, just be super carefull with dividers I'd say | 15:22 |
| noonedeadpunk | so that there was no need for some kind of urlsafe things for clients/autopmation/etc | 15:23 |
| mhen | fair point | 15:31 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/freezer-api master: Remove LegacyEngineFacade https://review.opendev.org/c/openstack/freezer-api/+/974447 | 15:58 |
| noonedeadpunk | hopefully this will fix CI ^ | 15:59 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/freezer-api master: Remove LegacyEngineFacade https://review.opendev.org/c/openstack/freezer-api/+/974447 | 16:05 |
| opendevreview | Markus Hentsch proposed openstack/freezer master: Consistent & meaningful OpenStack resource naming https://review.opendev.org/c/openstack/freezer/+/974483 | 17:04 |
| -opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline momentarily while we restart it onto new images after an update to the build toolchain | 18:01 | |
| *** gmaan is now known as gmaan_afk | 19:39 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!