| opendevreview | Maxim Sava proposed openstack/glance master: Add tests with selective store deletion and invalid store https://review.opendev.org/c/openstack/glance/+/973736 | 12:47 |
|---|---|---|
| croelandt | #startmeeting glance | 14:00 |
| opendevmeet | Meeting started Thu Feb 26 14:00:37 2026 UTC and is due to finish in 60 minutes. The chair is croelandt. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'glance' | 14:00 |
| croelandt | #topic roll call | 14:00 |
| croelandt | #link https://etherpad.openstack.org/p/glance-team-meeting-agenda | 14:00 |
| croelandt | o/ | 14:00 |
| mhen | o/ | 14:00 |
| sakumbha | o/ | 14:00 |
| * fungi waves | 14:01 | |
| abhishekk | o/ | 14:01 |
| croelandt | #topic Release/periodic job updates | 14:02 |
| croelandt | All good \o/ | 14:02 |
| abhishekk | cool | 14:02 |
| croelandt | Regarding jobs, tehre is apparently an issue with the client jobs right now | 14:02 |
| croelandt | so patches will fail the checks on gerrit | 14:02 |
| abhishekk | I hope issue is not at our end | 14:02 |
| croelandt | it is due to a tox upgrade, this should be fixed soon, and applies to all projects | 14:03 |
| abhishekk | gr8 | 14:03 |
| croelandt | #topic Image encryption | 14:03 |
| croelandt | One big development for image encryption is that dansmith has a PoC for inspecting encrypted images | 14:03 |
| croelandt | mhen: I commented on the spec to make sure this becomes part of it | 14:03 |
| croelandt | we want to keep Glance as the first line of defense, even with LUKS encrypted images | 14:04 |
| croelandt | does that make sense? | 14:04 |
| mhen | given the CVE history so far I guess we don't have any other choice, do we? | 14:05 |
| abhishekk | nope | 14:05 |
| fungi | do you have a link for the poc, or is it not up for review yet? | 14:06 |
| fungi | i'm not immediately finding it | 14:06 |
| abhishekk | no its not up yet | 14:06 |
| croelandt | fungi: no, dansmith has been working on it offline btu it's not ready to beshared | 14:06 |
| fungi | is it just about checking plaintext headers, or decrypting the images prior to validation? | 14:07 |
| croelandt | mhen: I think dansmith may provide the implementation, so on your end it would be a matter of updating the spec and thtat's it | 14:07 |
| croelandt | fungi: I think the PoC decrypts the image to validate it like it would an unencrypted one | 14:07 |
| fungi | got it, so glance will need access to the decryption keys for images | 14:08 |
| croelandt | I think it will access them through Barbican, right? | 14:08 |
| mhen | yea it already can | 14:08 |
| fungi | presumably, i just mean it's one more place the keys end up | 14:08 |
| croelandt | Or was there a proposal to make the keys unavailable to Glance? | 14:08 |
| mhen | because of secret consumers and key deletion policy stuff | 14:08 |
| croelandt | mhen: yes, it is my understanding that it had access to the keys already | 14:08 |
| fungi | ah, okay, i missed that detail. thanks | 14:09 |
| croelandt | mhen: Ok so I'll re-review the spec once you remove the bit I commented | 14:09 |
| fungi | if glance already needed access to the keys anyway then it doesn't seem like any additional security risk | 14:09 |
| croelandt | yes | 14:09 |
| mhen | I am not thrilled about Glance being an in-the-middle between the actual image producers and connsumers that can actually fully decrypt the image and has access to the keys but I understand it is necessary because of several reasons (key_deletion_policy stuff and the defender) | 14:10 |
| croelandt | we're also thinking of allowing users to tell the OSC: "hey, this is my unencrypted image, please upload it to Glance with this key" and that would maybe be an additional risk | 14:10 |
| croelandt | mhen: it's a bit of a tradeoff | 14:10 |
| mhen | so if we deem this method (dansmith's PoC) feasible and functional, you would want it to be part of both the existing spec and the implementation patchsets for image encryption, correct? | 14:11 |
| croelandt | so the spec mentions it *cannot* be done, so this part should at least be removed | 14:12 |
| croelandt | as for the implementation, I think dansmith would contribute his PoC rather than have you write it yourself | 14:12 |
| mhen | sure | 14:12 |
| croelandt | especially as this is not trivial | 14:12 |
| mhen | that would be much appreciated | 14:12 |
| croelandt | so maybe it's two patches, maybe you work on the same patch | 14:12 |
| croelandt | we should ask him in about 2 hours when he's on :D | 14:13 |
| mhen | feel free to ping me | 14:13 |
| croelandt | I *think* it would probably be one more function call in the current flow | 14:13 |
| croelandt | so nothing super disruptive | 14:13 |
| croelandt | ok I think we can move on | 14:13 |
| croelandt | #topic Bridging the Gap: Flamingo Cycle Retrospective | 14:14 |
| croelandt | fungi: ^ you got the microphone | 14:14 |
| fungi | ildiko posted openstack-wide 2025.2 (flamingo) cycle retrospective contributor/maintainer survey results and metrics to openstack-discuss at the end of last year: | 14:14 |
| fungi | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/XZZYFHMUCB3IZU5AXM366AY7WJXQMTBX/ Bridging the Gap Flamingo Cycle Retrospective Survey Results | 14:14 |
| fungi | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/FD4JALJN7OB2YNBUVWCPZZ6YNJMIL2JT/ Bridging the Gap Flamingo Cycle Retrospective Metrics Analysis | 14:14 |
| fungi | i and the other community managers on the openinfra foundation staff have also been digging into team-specific details and i'm doing a round of outreach similar to last cycle, to go over how things may have changed | 14:15 |
| fungi | the glance team had 3 contributor survey responses (and no maintainers), so while it could be better this is still more engagement than we saw for the epoxy retrospective surveys | 14:15 |
| fungi | 2 of the contributors self-identified as established while the other considered themself new to glance, with all contributing to 2 or more other open source projects | 14:15 |
| fungi | average ratings on the contributor survey questions were positive overall, with useful automated testing results coming in highest at 4.33 out of 5 and timely reviews the lowest with 3.00 (typical of overall openstack response averages) | 14:15 |
| fungi | it's worth noting that the new contributor ranked everything a 5 out of 5, which pushed the averages up a bit, but implies they had a very positive experience so that definitely counts for something | 14:15 |
| fungi | the biggest challenges reported by contributors were getting reviewer attention to changes, scope creep requested by reviewers, and apparent lack of consensus between reviewers, as well as struggling to implement cross-project features | 14:15 |
| fungi | the new survey questions about priorities indicated all of them (3/3) followed prioritization from irc and mailing list discussions, and most (2/3) looked at specs, but then there was a long tail (1/3) for every other option too | 14:16 |
| fungi | as for metrics, active reviewer count fell by 12% and active maintainer count was down 33% in flamingo as compared to epoxy, but both were about at the same level as they were a few cycles earlier in caracal | 14:16 |
| fungi | average (mean) time to first review and merge improved slightly in flamingo, but median times for both increased, indicating review activity may have become more consistent overall while struggling to deal with the team shrinkage | 14:16 |
| fungi | glance maintainers closed a whopping 30% more changes than were opened during the flamingo cycle, however, far better than any of the prior 5 cycles (next best was 21% over during antelope) | 14:16 |
| fungi | the community managers have been distilling feedback from last year's discussions, and are working on compiling a concise set of techniques/recommendations for improving communication and efficiency, which i can get into more another week | 14:16 |
| fungi | we're also hoping to get some case studies done in concert with successful contributors and maintainers to highlight how specific practices and behaviors help them achieve better throughput, in hopes of being able to replicate them | 14:17 |
| fungi | anyway, that was a quick dump, i know it's a lot to take in but i didn't want to eat up too much of your meeting, so i'll put this on the agenda again in two weeks to give everyone time to digest and come up with questions or ideas | 14:17 |
| fungi | though i'm happy to answer any immediate feedback now if there's time | 14:17 |
| croelandt | Is there a link to Glance-specific results/metrics? | 14:17 |
| abhishekk | we need time to process it :D | 14:17 |
| croelandt | yeah I'll have to read that in details | 14:18 |
| fungi | i don't have sanitized team-specific breakdown documents like the openstack-wide ones, but i can put some more specific details together for glance if that's desirable | 14:18 |
| fungi | or if there are specific numbers you want to know i can paste those in now | 14:18 |
| croelandt | you said "glance maintainers closed a whopping 30% more changes than were opened during the flamingo cycle" so I thought you had them | 14:18 |
| fungi | yeah, just a sec | 14:19 |
| croelandt | if we keep closing more than we open, we might be done with the backlog around 2035 | 14:19 |
| croelandt | #hope | 14:19 |
| fungi | in the flamingo cycle, there were 153 changes opened for glance repositories and 199 closed | 14:19 |
| fungi | as opposed to epoxy where 159 were opened and 161 closed | 14:20 |
| fungi | so the team is more than keeping up with incoming review volume, even with fewer maintainers active during the cycle | 14:20 |
| croelandt | interesting, since I keep feeling like I'm drowning in reviews | 14:20 |
| fungi | that's part of why we analyze this stuff, perception is often different from reality (though both have a valid basis) | 14:21 |
| croelandt | yes | 14:21 |
| fungi | it's helpful to try to dig into why people feel buried in work even when they're more than keeping up | 14:21 |
| croelandt | thanks a lot, I'll dive into the emails linked above later | 14:21 |
| abhishekk | also @croelandt can you dump this in etherpad? | 14:22 |
| croelandt | One must imagine Sisyphus happy | 14:22 |
| fungi | and yeah, as i said, feel free to ask me more detailed questions whenever you think of them | 14:22 |
| abhishekk | ack | 14:22 |
| fungi | and i'll bring it up on the agenda again in two weeks (i have something conflicting next week at this time or i'd cover it then) | 14:22 |
| croelandt | abhishekk: just dumped comments by fungi | 14:22 |
| croelandt | thanks a lot fungi | 14:23 |
| croelandt | moving on | 14:23 |
| fungi | yw | 14:23 |
| croelandt | #topic Open Discussion | 14:23 |
| abhishekk | thanks | 14:23 |
| croelandt | amnik: you got the mic | 14:23 |
| amnik | hello, I want to share an idea with you before any specs | 14:23 |
| abhishekk | go ahead | 14:24 |
| amnik | In interoperable image import we apply configured plugins for all request | 14:24 |
| amnik | I wonder If add parameter to the API that user can choose which plugin apply on request | 14:24 |
| amnik | choose which plugin set apply on request. | 14:25 |
| abhishekk | I am not recovering it but we thought of this while interoperable image import was introduced and it was rejected | 14:25 |
| croelandt | what is the use case here? | 14:26 |
| rajiv | hi | 14:26 |
| amnik | I think it's good to enable user choose which plugins apply on image | 14:27 |
| amnik | instead of static list of plugins apply on all images | 14:27 |
| croelandt | yeah but does this come up in real life? | 14:27 |
| croelandt | is anyone complaining about it? | 14:28 |
| abhishekk | we can always use override way | 14:28 |
| abhishekk | if user sepcifies then apply those plugins only | 14:28 |
| abhishekk | and ignore plugins configured by system | 14:28 |
| abhishekk | BUT as cyril says we need solid use case for that | 14:29 |
| amnik | ok for now I not say any special use cases. | 14:30 |
| croelandt | yeah if no one using a real deployment complains about it, I'd rather not touch it | 14:30 |
| amnik | I think it can be good feature | 14:30 |
| croelandt | oh it could probably be | 14:30 |
| croelandt | but it's not something I'd be willing to spend time on if no one is bothered by the current implementation | 14:30 |
| abhishekk | +1 | 14:30 |
| abhishekk | amnik: if you found any good use case then we can discuss this topic during PTG | 14:31 |
| croelandt | ^ this | 14:31 |
| amnik | yes ok, Thank you | 14:31 |
| abhishekk | thank you!! | 14:31 |
| croelandt | ok, I think we can close this meeting | 14:33 |
| croelandt | unless someone else has anything to add? | 14:33 |
| rajiv | i wanted to follow up on last weeks review request, i am unsure if we can fix the zuul error | 14:33 |
| rajiv | https://review.opendev.org/c/openstack/glance_store/+/977323 | 14:33 |
| croelandt | ah let me check | 14:33 |
| croelandt | hm interesting | 14:35 |
| rajiv | secondly, would this be fixed https://review.opendev.org/c/openstack/glance_store/+/578549 ? | 14:35 |
| croelandt | testtools should probably require typing_extensions | 14:35 |
| rajiv | okay, last, would this be of any interest if i start working on this again : https://review.opendev.org/c/openstack/glance_store/+/788233 | 14:36 |
| croelandt | so, is the swiftclient really retrying like I wrote back in 2022? | 14:37 |
| croelandt | parallel uploads to Swift seems interesting | 14:37 |
| croelandt | abhishekk: ^ what do you think? | 14:37 |
| abhishekk | I need to go through the spec | 14:38 |
| abhishekk | https://review.opendev.org/c/openstack/glance-specs/+/787179 | 14:38 |
| abhishekk | This was my last comment on it, I need to recollect why I said that :D | 14:38 |
| abhishekk | As I told and discuss during the PTG, this is not how we want to modify the swift driver. We don't want condition based implementations anymore. Feel free to discuss this in weekly glance meeting. | 14:38 |
| abhishekk | I think we decided on creating a sub-driver based | 14:39 |
| rajiv | yep, hence wanted to bring this up :) | 14:39 |
| rajiv | ah ok ok | 14:39 |
| croelandt | ok so we agree with the feature, it's just an implementation detail? | 14:39 |
| abhishekk | yes | 14:40 |
| croelandt | ok | 14:40 |
| croelandt | so I think rajiv you could write a PoC and then we'd discuss this at PTG, probably | 14:40 |
| abhishekk | we need spec update as well based on previous comments | 14:40 |
| rajiv | okay, i think i wrote a glance specs for this but unable to find it | 14:41 |
| rajiv | croelandt: regarding the 1st review request, the testtools thing is something for me ? | 14:42 |
| croelandt | I'll look into it | 14:42 |
| rajiv | thank you! | 14:42 |
| croelandt | it's weird that it fails in 310 but not in 313 | 14:42 |
| rajiv | yes | 14:42 |
| croelandt | so yeah, gotta figure it out | 14:42 |
| croelandt | but I think it will be an issue for other patches as well | 14:42 |
| croelandt | so might as well debug it sooner than later | 14:43 |
| rajiv | :) | 14:43 |
| croelandt | ok, thanks everyone for joining | 14:43 |
| croelandt | see you next week! | 14:43 |
| croelandt | #endmeeting | 14:43 |
| opendevmeet | Meeting ended Thu Feb 26 14:43:39 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:43 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/glance/2026/glance.2026-02-26-14.00.html | 14:43 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/glance/2026/glance.2026-02-26-14.00.txt | 14:43 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/glance/2026/glance.2026-02-26-14.00.log.html | 14:43 |
| dansmith | wait | 14:43 |
| abhishekk | thank you | 14:43 |
| dansmith | aww | 14:43 |
| croelandt | TOO LATE | 14:43 |
| abhishekk | TOO FAST | 14:43 |
| croelandt | we shall never know what you had to say | 14:43 |
| rajiv | :D | 14:44 |
| dansmith | mhen: croelandt yep, I'll be pushing up a PoC and I will handle getting that part working | 14:44 |
| mhen | dansmith: thank you! | 14:44 |
| dansmith | mhen: we currently allow operators to disable deep inspection today, which I suppose we could extend to "just don't look inside the encrypted ones" if you want - the implementation allows for that | 14:45 |
| croelandt | \o/ perfect | 14:45 |
| dansmith | however, nova cinder (and as you noted) glance already have to access the key so I see very little reason to just not inspect things | 14:45 |
| dansmith | they're never stored, and only the first block or two will be decrypted in memory | 14:45 |
| dansmith | qemu-img allows me to hide a qcow file inside a luks in a pretty straightforward way, so... | 14:46 |
| fungi | i recall there was some debate as to whether qemu-img's backend auto-selection actually got used in that situation | 14:47 |
| fungi | since if you have to tell it to treat the plaintext payload as a specific type of image then there's no risk of accidentally passing it to one of the dangerous drivers | 14:48 |
| dansmith | fungi: but nova has a mode where we unwrap the luks layer with dm-crypt and pass the inner device to qemu | 14:49 |
| fungi | ah, and then yes it becomes the original problem | 14:49 |
| dansmith | and any of our image manipulation things during snapshots and things get more complicated | 14:49 |
| dansmith | either way, I'm trying to avoid providing a way to expose qemu to these things even if we don't have a specific exploit in mind | 14:50 |
| dansmith | the recent nova one was majorly less severe because glance refused to let nova exfiltrate host data | 14:50 |
| fungi | yep, makes sense | 14:53 |
| opendevreview | Dan Smith proposed openstack/glance master: DNM: Test glance against LUKS images https://review.opendev.org/c/openstack/glance/+/978088 | 15:42 |
| dansmith | this ^ is just to get a baseline of what happens with luks images today and then I'll depends-on the oslo code | 15:46 |
| opendevreview | Dan Smith proposed openstack/glance master: DNM: Test glance against LUKS images https://review.opendev.org/c/openstack/glance/+/978088 | 18:05 |
| dansmith | this ^ should now run with modified oslo.utils and be able to upload the luks images, but it won't detect the bogus qcow2 ones because no inspection | 18:12 |
| dansmith | we'll need tempest to register secrets in barbican for those and set the metadata on the images to find them | 18:13 |
| dansmith | ah, nope, because those tempest tests don't know to set the container_format instead of disk format | 19:48 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!