| *** mhen_ is now known as mhen | 02:49 | |
| opendevreview | Markus Hentsch proposed openstack/freezer master: Fix Glance integration https://review.opendev.org/c/openstack/freezer/+/973623 | 08:35 |
|---|---|---|
| opendevreview | Markus Hentsch proposed openstack/freezer master: Replace cinderclient with SDK and fix osbrick https://review.opendev.org/c/openstack/freezer/+/973627 | 08:36 |
| opendevreview | Markus Hentsch proposed openstack/freezer master: Fix Nova integration and change clients to SDK https://review.opendev.org/c/openstack/freezer/+/973625 | 08:36 |
| opendevreview | Josephine Seifert proposed openstack/freezer master: Default to identity version 3 https://review.opendev.org/c/openstack/freezer/+/973615 | 08:56 |
| opendevreview | Ivan Anfimov proposed openstack/freezer master: Bump hacking https://review.opendev.org/c/openstack/freezer/+/972797 | 08:56 |
| opendevreview | Ivan Anfimov proposed openstack/freezer master: WIP https://review.opendev.org/c/openstack/freezer/+/972797 | 08:56 |
| mhen | what is this RETRY_LIMIT Zuul keeps running into for openstack-tox-py313 on my recent patchsets? | 09:05 |
| mhen | oh seems like it's the bindep thing being addressed in https://review.opendev.org/c/openstack/freezer/+/972797 | 09:12 |
| opendevreview | Ivan Anfimov proposed openstack/freezer master: WIP https://review.opendev.org/c/openstack/freezer/+/972797 | 09:18 |
| opendevreview | Ivan Anfimov proposed openstack/freezer master: CI: fix problems with Debian 13 and MySQL packages https://review.opendev.org/c/openstack/freezer/+/972797 | 09:26 |
| opendevreview | Markus Hentsch proposed openstack/freezer master: Replace cinderclient with SDK and fix osbrick https://review.opendev.org/c/openstack/freezer/+/973627 | 09:29 |
| opendevreview | Markus Hentsch proposed openstack/freezer master: Fix Nova integration and change clients to SDK https://review.opendev.org/c/openstack/freezer/+/973625 | 09:50 |
| noonedeadpunk | aha, ok, makes sense to merge it first then | 11:00 |
| noonedeadpunk | but that looks not great in terms of deb... | 11:01 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/freezer master: CI: fix problems with Debian 13 and MySQL packages https://review.opendev.org/c/openstack/freezer/+/972797 | 11:03 |
| noonedeadpunk | I hope this would work | 11:04 |
| noonedeadpunk | and we can just recheck once it merges, to avoid rebases | 11:04 |
| opendevreview | Merged openstack/freezer master: CI: fix problems with Debian 13 and MySQL packages https://review.opendev.org/c/openstack/freezer/+/972797 | 12:23 |
| opendevreview | Merged openstack/freezer-api master: Fix devstack installation of elasticsearch https://review.opendev.org/c/openstack/freezer-api/+/973462 | 13:02 |
| opendevreview | Merged openstack/freezer master: Remove inconsistent no_incremental option https://review.opendev.org/c/openstack/freezer/+/973219 | 14:19 |
| noonedeadpunk | #startmeeting freezer | 15:00 |
| opendevmeet | Meeting started Mon Jan 19 15:00:55 2026 UTC and is due to finish in 60 minutes. The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'freezer' | 15:00 |
| noonedeadpunk | #topic rollcall | 15:01 |
| noonedeadpunk | o/ | 15:01 |
| Luzi | o/ | 15:01 |
| mhen | o/ | 15:01 |
| noonedeadpunk | I'd assume nobody else will show up anyway | 15:03 |
| noonedeadpunk | #topic office hours | 15:03 |
| noonedeadpunk | I personally failed again to invest time into active development of things I was supposed to | 15:03 |
| noonedeadpunk | Right now I am testing the horizon plugin fix, and I think this patch does the trick mainly | 15:04 |
| noonedeadpunk | #link https://review.opendev.org/c/openstack/freezer-web-ui/+/961314 | 15:04 |
| noonedeadpunk | I will finish tests and land this one if it solves the issuer | 15:04 |
| noonedeadpunk | will also review client replacement patches, they look good in general after a quick look | 15:05 |
| noonedeadpunk | it's really a nice work, thanks mhen for taking time for it | 15:06 |
| mhen | while working on it, I also fixed the osbrick engine for Cinder but to be honest I'm not happy about it | 15:10 |
| mhen | the osbrick implementation requires OpenStack admin rights, local sudo (for mounting) and makes a lot of assumptions: the volume has exactly 1 partition and is ext4 | 15:11 |
| mhen | do we need to keep supporting it at all costs or could we consider deprecating and eventually removing it? | 15:12 |
| noonedeadpunk | we don't have to keep it, if it makes limited sense | 15:12 |
| noonedeadpunk | though I can imagine how to refactor it, to make it useful | 15:13 |
| mhen | I mean it depending on a host that has direct access to Cinder's backend for osbrick attachment and all the admin/root rights don't sit quite well with me | 15:13 |
| noonedeadpunk | ie - spawn a separate "service" VM, attach a volume, use fsarchiver | 15:13 |
| noonedeadpunk | doing that on localhost is really weird assumption for sure | 15:13 |
| noonedeadpunk | I think fsarchiver supports reasonable set of filesystems to make it useful, but now looking at the project repo, it kinda feels either feature-complete, or dead... | 15:15 |
| noonedeadpunk | #link https://github.com/fdupoux/fsarchiver | 15:15 |
| mhen | would that 'service VM' have any benefit over making a glance image from the volume, downloading and extracting that via freezer-agent? (Freezer can already do that) | 15:16 |
| mhen | "Freezer can already do that" <- sans the extraction part I mean | 15:16 |
| noonedeadpunk | that is a good question | 15:17 |
| noonedeadpunk | except saving cycles/reducing load on glance? | 15:17 |
| noonedeadpunk | I think you have 1 more data transfer this way | 15:17 |
| noonedeadpunk | volume -> image -> download -> upload | 15:18 |
| noonedeadpunk | vs volume -> upload | 15:18 |
| noonedeadpunk | so 2 times more data transfers | 15:18 |
| noonedeadpunk | given that volume->snapshot->volume are all COW | 15:19 |
| mhen | sure but if I think about central scheduler/agent approach, accessing the API is easier than a VM's floating IP, isn't it? | 15:19 |
| noonedeadpunk | well, I mean... octavia/trove/magnum do that kinda? | 15:20 |
| noonedeadpunk | it could be service network as well | 15:20 |
| noonedeadpunk | so we don't have to leave the driver and can drop it, but there is a universe where it may make sense I guess | 15:21 |
| mhen | I guess we need to deprecate it for a few cycles first? | 15:21 |
| noonedeadpunk | yes, sure | 15:22 |
| noonedeadpunk | and maybe you're right, and it would be more clean to make a new driver instead | 15:22 |
| noonedeadpunk | as a replacement | 15:22 |
| mhen | aside from some minor potential improvements, there are two other major things I noticed during my testing: | 15:27 |
| mhen | firstly, the engine vs. mode situation seems really weird to me | 15:27 |
| mhen | there are only a couple of valid (and sensible) combinations one may choose, it's not like you can freely mix and match them (as in use any backup mechanism with any backup source) | 15:28 |
| mhen | some combinations are even leading to unexpected behavior (like freezer-agent doing nothing) | 15:29 |
| mhen | the validation implementation for this seems really spotty | 15:29 |
| mhen | I'd like to revise this a bit to have a fixed matrix of valid combinations that can be validated against and put in the docs | 15:29 |
| noonedeadpunk | tha's really valid concern, I looked quickly through the code and indeed it's a mess | 15:30 |
| noonedeadpunk | I'd even question if both of these 2 things are really needed | 15:30 |
| mhen | yes that also came to my mind | 15:30 |
| mhen | I haven't looked deep enough yet but I did feel like we could maybe reduce this to one option | 15:31 |
| noonedeadpunk | probably they do... Just `mode` is very confusing as a name | 15:31 |
| noonedeadpunk | but not sure really | 15:32 |
| mhen | I think I'll look into it while the other patchsets are still under review | 15:33 |
| noonedeadpunk | it feels like it might be better to have an engine, and then some config parameters per engine or smth, which would be uniqe for it | 15:33 |
| mhen | (look into it on a conceptual level I mean) | 15:33 |
| noonedeadpunk | ++ sure | 15:33 |
| mhen | when I have some research results, we can discuss further in the next meeting I think | 15:34 |
| noonedeadpunk | I will take time for reviews and hopefully do some coding for central scheduler part | 15:34 |
| mhen | and secondly, I noticed that many modes/engines do create temporary resources like images, volumes and volume snapshots | 15:35 |
| mhen | but the cleanup (especially in error cases) seems spotty and also oftentimes those temporary resources do not get a name and description assigned - making cleanup difficult | 15:35 |
| noonedeadpunk | I was thinking to get better testing for the suite overall, and that seems a good candidate to test kinda | 15:36 |
| noonedeadpunk | and then check if clean-up calls are issued in case of exceptions and negative tests? | 15:38 |
| noonedeadpunk | as I'm not sure how to approach this otherwise | 15:38 |
| mhen | sounds good | 15:38 |
| mhen | I would like to start by adding proper names and descriptions to all temporary resources | 15:38 |
| noonedeadpunk | I'm not sure if that should be done in tempest or just unit tests... | 15:38 |
| noonedeadpunk | I would care about descriptions less, but names should be proper and obvious enough indeed | 15:39 |
| mhen | Having a `restore_<uuid>` with a description like `Temporary snapshot created by Freezer` would help both cloud users and operators immensely in identifying those resources as not user-created, I think. | 15:40 |
| mhen | There is an off chance that a cloud user could also opt for calling one of their resources `restore_`. | 15:41 |
| noonedeadpunk | yeah, sure | 15:41 |
| noonedeadpunk | I'd be having also `freezer` suffix/prefix tbh | 15:42 |
| noonedeadpunk | or make that configurable through config | 15:42 |
| mhen | that would be even better | 15:42 |
| mhen | `restore_` currently exists in the code | 15:42 |
| mhen | if you think it's okay to change it | 15:42 |
| noonedeadpunk | thankfully names are not unique though | 15:42 |
| mhen | I would vastly prefer `freezer_` | 15:42 |
| noonedeadpunk | well, it can be freezer_restore_ or freezer_backup_ | 15:43 |
| mhen | true | 15:43 |
| noonedeadpunk | as from what I saw in osbrick, is that it creates resources not only for restore, but also for backups | 15:43 |
| noonedeadpunk | so might be good to distinguish these as well | 15:43 |
| mhen | same goes for volumes | 15:44 |
| noonedeadpunk | but eventually, if suffix is configurable, we can easily change that, and suggest users to flip the config setting to presrve previous behavior | 15:44 |
| mhen | good point | 15:45 |
| noonedeadpunk | * change that to jsut freezer_ | 15:45 |
| noonedeadpunk | *suggest in release notes | 15:45 |
| noonedeadpunk | and then we can say in description the purpose actually | 15:48 |
| noonedeadpunk | is that backup, restore, else, whatever | 15:48 |
| noonedeadpunk | so yeah< I agree about description part as well :) | 15:48 |
| noonedeadpunk | sounds like a plenty of work to do :) | 15:48 |
| * noonedeadpunk needs to start catching up | 15:49 | |
| mhen | I think we can close the meeting thenj | 16:00 |
| mhen | or is there anything else? | 16:00 |
| noonedeadpunk | nah, that was it :) thanks for working on the project and taking time for the meeting! | 16:00 |
| noonedeadpunk | #endmeeting | 16:00 |
| opendevmeet | Meeting ended Mon Jan 19 16:00:36 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/freezer/2026/freezer.2026-01-19-15.00.html | 16:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/freezer/2026/freezer.2026-01-19-15.00.txt | 16:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/freezer/2026/freezer.2026-01-19-15.00.log.html | 16:00 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/freezer-web-ui master: Fix devstack horizon pllugin enablement https://review.opendev.org/c/openstack/freezer-web-ui/+/973872 | 17:07 |
| noonedeadpunk | Luzi: it would be awesome if you could check if this fixes the devstack for you ^ | 17:08 |
| opendevreview | Merged openstack/freezer-web-ui master: Fix for various mistakes in phrases https://review.opendev.org/c/openstack/freezer-web-ui/+/961247 | 17:23 |
| opendevreview | Merged openstack/freezer-web-ui master: Migrate setup configuration to pyproject.toml https://review.opendev.org/c/openstack/freezer-web-ui/+/960324 | 17:23 |
| noonedeadpunk | though I see now 500 from API.... | 17:29 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/freezer-api master: Ensure all_projects are defined for get_search_query https://review.opendev.org/c/openstack/freezer-api/+/973886 | 18:41 |
| noonedeadpunk | so, it seems it's quite non-trivial to make elasticsearch to actually work in devstack.... | 19:31 |
| noonedeadpunk | as it really needs auth today, in addition to TLS | 19:31 |
| opendevreview | Ivan Anfimov proposed openstack/freezer-web-ui master: Remove information about removed option "--remove-older-then" https://review.opendev.org/c/openstack/freezer-web-ui/+/961311 | 19:45 |
| opendevreview | Ivan Anfimov proposed openstack/freezer-web-ui master: Remove information about removed option "--remove-older-then" https://review.opendev.org/c/openstack/freezer-web-ui/+/961311 | 19:45 |
| opendevreview | Ivan Anfimov proposed openstack/freezer-web-ui master: Remove information about removed option "--remove-older-then" https://review.opendev.org/c/openstack/freezer-web-ui/+/961311 | 19:47 |
| opendevreview | Ivan Anfimov proposed openstack/freezer-web-ui master: disaster_recovery complete replace to freezer_ui https://review.opendev.org/c/openstack/freezer-web-ui/+/961314 | 19:49 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!