| *** JohnnyW559 is now known as JohnnyW55 | 00:25 | |
| elodilles | hi croelandt , fyi, all non-cycle-trailing projects have moved to EOL last week, so I'm about to delete the stable/2024.2 branches. is there any progress with the patch you wanted to merge before glance moves to EOL with its stable/2024.2? o:) | 10:20 |
|---|---|---|
| elodilles | if not, then probably the best is to EOL things as they are currently :/ | 10:21 |
| opendevreview | Pranali Deore proposed openstack/glance master: Stabilize test subprocess and cache queue behavior without eventlet https://review.opendev.org/c/openstack/glance/+/987156 | 11:29 |
| opendevreview | Pranali Deore proposed openstack/glance master: Default Glance unit tests to native threading https://review.opendev.org/c/openstack/glance/+/986329 | 11:36 |
| dtantsur | Hi folks! Do you realize that https://opendev.org/openstack/glance/commit/e2725ffa19c4ffc3d30c637df1a9c74484429518 breaks kernel images (aki)? | 12:02 |
| dtantsur | I guess we revert the configuration value in the Ironic CI, but it's going to affect real operators too, I suspect | 12:03 |
| dtantsur | example: https://zuul.opendev.org/t/openstack/build/6e3d781ac62040779768382b08169655 | 12:05 |
| *** kevko7 is now known as kevko | 12:25 | |
| dtantsur | Is it because we use --disk-format=raw instead of aki? (is aki still a thing - I'm outdated on OpenStack nowadays) | 12:27 |
| dtantsur | cc TheJulia who can probably talk more coherently than me about this whole image situation | 12:28 |
| TheJulia | Let me get up and caffeinate first | 12:30 |
| TheJulia | so, there shouldn't be any continued usage of AKI in CI, that should have been stomped out as it was determined ?in late 2024? that that was wrong. | 12:46 |
| TheJulia | ugh, so... as raw it now fails, that is super problematic | 12:47 |
| TheJulia | so I guess the issue is that this was, I guess, letting through kernel assemblys which look like mbr partitioning to detection code, and now blocking them | 12:49 |
| TheJulia | Seems like that (a) either needs to be reverted and re relaxed, or 25+% of operators will have to tune that setting, or another signature check needs to get added to somehow detect or understand it is a legitimate and bootable artifact. | 12:50 |
| dtantsur | TheJulia: do you know why we use --disk-format=raw? I'm sure we had --disk-format=aki at some point | 12:50 |
| TheJulia | yeah, aki was eradicated | 12:50 |
| TheJulia | as was ari | 12:51 |
| TheJulia | raw as a raw artifact in glance | 12:51 |
| TheJulia | was the agreed upon path forward | 12:51 |
| dtantsur | Hmm, a separate type would come handy here.. | 12:52 |
| TheJulia | the issue is the safety check code is getting applied regardless | 12:52 |
| TheJulia | and it flags as MBR, and the default setting removal is problematic unless the boot header gets removed but then it doesn't work anymore, I think the revert likely needs to be raised if it hasn't already | 12:53 |
| dtantsur | Yeah, I believe Ironic itself does not do any checks if the user specifies a raw image | 12:53 |
| * TheJulia is only on sip #2 | 12:53 | |
| TheJulia | What his happening is the image check code is fingerprinting and its getting flagged as mbr, and getting blocked as a result, I think ironic understands the case, but the issue is glance now blocks it | 12:54 |
| TheJulia | I wonder if the kernel is including a gpt table too along with the mbr fingerprints, then the code in glance applying it to everything is now auto-blocking | 13:12 |
| TheJulia | dansmith: when your around and caffinated :) | 13:13 |
| TheJulia | dtantsur: An alternative might be just to tell all operators, you can't use glance for these key artifacts anymore and that you have to use URL of some sorts. | 13:22 |
| dtantsur | well... it's a possibility. I suspect many of them would rather revert the configuration option | 13:29 |
| dansmith | ari/aki are still available in glance | 13:32 |
| dansmith | is it the kernel or the ramdisk that's getting flagged as MBR? and is it _actually_ wrapped in MBR clothing or is a total false positive? | 13:33 |
| dansmith | we've got plans to make this worse, FWIW, and remove the ability to upload something as raw when it is actually detected as a different format | 13:33 |
| dansmith | it was working before because we detected "hmm, this looks like an MBR in raw, but it doesn't fail safety checks so we'll let it slide" | 13:34 |
| dansmith | but the goal for some time has been to eliminate that | 13:34 |
| dtantsur | I think that for some reasons linux kernels are valid GPT | 13:34 |
| dansmith | okay, well, not *valid* GPT I guess else it wouldn't fail the check | 13:34 |
| dtantsur | Right, yeah, something like them | 13:35 |
| dansmith | but this is sort of why we're doing this - because people are just choosing raw for things like this and nova would try to boot this (and would maybe succeed if it's got enough to actually boot on BIOS) | 13:35 |
| dtantsur | Right, so a linux kernel is actually bootable, even if it looks odd | 13:37 |
| dansmith | yeah, so is using aki properly an option then | 13:38 |
| dansmith | ? | 13:39 |
| dtantsur | assuming TheJulia is wrong on "aki was eradicated" | 13:39 |
| TheJulia | That is a complete 180 from last year | 13:39 |
| TheJulia | err, 1.5 years ago | 13:39 |
| TheJulia | since it was viewed that AKI was "wrong" to continue to use | 13:39 |
| dansmith | are you talking about nova or ironic? | 13:40 |
| TheJulia | this issue came up, the fundimental issue is all along, kernels have had this skelaton applied to them to make them bootable and it gets pulled in | 13:40 |
| TheJulia | in general, going back to the original cve which resulted in this change | 13:40 |
| dansmith | so, _nova_ has a ton of special AKI rules that have apparently never been valid and are quite problematic.. we deprecated using those actual images as bootable (but not kernel/ramdisk boot itself) | 13:41 |
| TheJulia | yeah, seems like that came out of the same discussion back then. | 13:42 |
| dansmith | is this usage issue you're hitting with nova+ironic or just ironic? | 13:44 |
| dtantsur | the issue at hand is that glance rejects uploading kernels as raw images | 13:44 |
| TheJulia | operationally, the admin/operator isen't even at asking for something to be done, they are just trying to use glance as glance | 13:46 |
| dansmith | so I just tried on my quickly available vmlinuz and it is not detected as GPT | 13:46 |
| dansmith | oh maybe because it's aarch64 | 13:49 |
| dansmith | it otherwise looks like EFI but maybe that's why | 13:49 |
| dtantsur | it definitely can be an EFI executable https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.html | 13:50 |
| dansmith | okay yeah, on an amd64 one: FAILURE_REASONS='mbr: MBR PTE 0 has invalid boot flag' | 13:52 |
| dansmith | boot flag is 0xFF on those, which is not valid indeed | 13:57 |
| dansmith | anyway, I think the point is.. aki/ari special handling is deprecated in _nova_.. it's not in glance, and using AKI (or something else) in glance is probably the appropriate thing in general | 13:58 |
| dansmith | ironic was recommending what before, using aki in glance? or has it been raw all along? | 13:58 |
| TheJulia | ari/aki until the cve response effort and your own advocacy caused us to move to raw as it was more proper that way | 14:00 |
| dansmith | TheJulia: I think that might have been some confused messaging where I was advocating for _nova_ to stop supporting _actual_ AKI/ARI because we have a bunch of different code paths for those image types (again, in _nova_) | 14:01 |
| dansmith | the whole point of this effort has been to "stop using raw for everything" :) | 14:01 |
| TheJulia | Likely definitely rooted in an interpretation issue, however it still has me wondering what the right path is. | 14:05 |
| dansmith | this doesn't look like an honest attempt at an MBR, and seems more like something "recognizable but obviously invalid": | 14:05 |
| dansmith | https://termbin.com/0fzo | 14:05 |
| TheJulia | dansmith: remember discussing booting kernels from floppies during that cve effort ? :) | 14:05 |
| dansmith | TheJulia: I'm still trying to ascertain if there is a workflow where ironic requires nova to do something with an image marked as disk_format=aki that will be problematic with nova's planned deprecation of that format | 14:06 |
| TheJulia | dansmith: take a step back, take off the nova hat. Only wear the glance hat first ;) | 14:06 |
| TheJulia | we're nowhere near nova for where this problem is at | 14:06 |
| dansmith | I understand that.. I think I've said that from a glance point of view, uploading these are raw is wrong and aki or something else more descriptive would be best: | 14:07 |
| dansmith | [06:58:13] <dansmith> anyway, I think the point is.. aki/ari special handling is deprecated in _nova_.. it's not in glance, and using AKI (or something else) in glance is probably the appropriate thing in general | 14:07 |
| TheJulia | Ultimately, it is all disjointed, but one area impacts others as common areas change. | 14:08 |
| dansmith | that's why I'm trying to figure out what you actually _need_ from glance, nova and ironic | 14:09 |
| opendevreview | Antonin Ruan proposed openstack/glance-specs master: [spec] Generate temp URL for images in object storage backend https://review.opendev.org/c/openstack/glance-specs/+/970214 | 14:09 |
| TheJulia | From glance, the operator needs to be able to store artifacts related to the boot of baremetal nodes which are not used by Nova in the slightest. Otherwise, operators can define it using urls of other forms, but the question eventually simmers down to "do operators use glance for non-disk iamges" at all | 14:10 |
| TheJulia | images | 14:10 |
| TheJulia | the consensus in the past was, they aren't really disk images, raw seems to be the safe thing since they are also not ec2 artifacts | 14:10 |
| dansmith | yeah, that is a good question for sure.. to me, every image in glance has a disk_format and container_format required, and "raw" has been wildly overloaded.. using it to store JPEG files because there's no closer match is not good | 14:11 |
| dansmith | they are not disk images | 14:11 |
| dansmith | obviously kernel images are in a weird middle space because they're part of (a) boot process | 14:11 |
| dansmith | but calling them raw is not good especially when we have a kernel-flavored disk_format to use.. | 14:12 |
| dansmith | sorry if that nova messaging got mixed into the pot somewhere, but I certainly didn't intend for our deprecation of our aki special code to affect you.. we are still supporting kernel/ramdisk boot even, just not with aki as the entry point | 14:13 |
| dansmith | because in nova, aki brings a bunch of other stuff that works very differently from our normal boot process that hasn't been updated/maintained over the years | 14:13 |
| TheJulia | dansmith: no worries, we all only have so much context to use of others before eyes glaze over ;) | 14:14 |
| TheJulia | Hey, you just left a huge hint there | 14:15 |
| TheJulia | You just said "still supporting kernel/ramdisk" and "just not with aki as the entry point", what entry point are you moving to? | 14:15 |
| dansmith | perhaps we can make this better by updating glance docs to say "while this is called 'aki' for legacy reasons, it should be used for linux kernel images" and then some more words about what qualifies (and doesn't) there | 14:16 |
| TheJulia | .... it feels like we had to previously remove aki/ari usage with glance though because actual use broke it, but.... my memory recall needs more coffee and to ping someone who did actually ahve to make those changes | 14:18 |
| dansmith | TheJulia: booting a (say) qcow2 file with kernel_id/ramdisk_id will work as expected but just slam in the kernel parameters at the last minute to avoid using the bootloader on disk.. if the image you're actually booting from is an AKI (or ARI) itself, then nova does different stuff, creates an empty disk image tries to mount it to lay down the rootfs tarball, etc (I don't even remember what all) | 14:18 |
| dansmith | the latter is full of things we don't do anymore for things like file injection and we don't want to be supporting that mode of boot either | 14:18 |
| TheJulia | oh wow, okay | 14:18 |
| dansmith | TheJulia: I don't think so or know of any, so if you have details there that's something we could chase | 14:19 |
| TheJulia | absolutely, the brain time machine only works so well on the 0>1 cups of coffee | 14:19 |
| dansmith | I mean, ideally we'd do some validation on AKI to say "yeah, BSD kernels not so much" | 14:19 |
| TheJulia | heh | 14:21 |
| opendevreview | Jay Faulkner proposed openstack/glance master: Revert "Remove default to relaxed MBR safety checks" https://review.opendev.org/c/openstack/glance/+/987186 | 15:22 |
| JayF | FWIW we did specifically have a conversation around aki/ari use (I don't remember with who; the image CVEs were a whirlwind) where we werew strongly encouraged to (and did!) update docs to inform operators to upload as raw | 15:30 |
| JayF | I'm pretty sure we have a lengthy release note telling people to make that change | 15:30 |
| JayF | so I would find it particularly unpalatable to just be like "just kidding, use aki/ari" | 15:31 |
| JayF | After reading all the backlog; I feel like we probably need a first class kernel/ramdisk that isn't AKI/ARI (which is it's own format, and we shouldn't overload -- especially after we told operators to change how to upload theirs) | 15:44 |
| JayF | and until such a thing exists, we need to land 987186 to unbreak the model for Ironic | 15:44 |
| opendevreview | Merged openstack/glance-tempest-plugin master: Drop python 3.9 and support python 3.13 https://review.opendev.org/c/openstack/glance-tempest-plugin/+/966127 | 15:44 |
| JayF | dansmith: (I don't know the IRC names of the other two original approvers) can you please land https://review.opendev.org/c/openstack/glance/+/987186 to unblock Ironic and allow time for discussion? | 15:45 |
| dansmith | JayF: it's config so I don't see any need to revert that when it can just be tweaked in devstack, but I'll defer to the PTL (croelandt) | 16:44 |
| JayF | I am pretty strongly -1 to modifying the config in Ironic as I don't think it represents a path I'd suggest to operators | 16:45 |
| JayF | so it'd be changing Ironic CI config to workaround an issue our Operators will also experience, so I prefer to fix it at the root | 16:45 |
| JayF | given we don't have a secure moving-forward path for Ironic operators | 16:45 |
| JayF | So IMO that means the default change itself is invalid and deserving of revert if one of your large downstream services doesn't have a reasonable way for their users to configure | 16:46 |
| JayF | especially given statements in here that "it's gonna get worse" -- which is taken as a threat against Ironic's ability to serve OpenStack customers until/unless our use case is considered | 16:46 |
| dansmith | JayF: I really think that saying "no path for Ironic users" is an unfair characterization here.. this was just a config default, and it had been planned/proposed for the better part of a year | 16:48 |
| JayF | As an Ironic user, without disabling critical security features in my glance, how do I manage ironic python agent ramdisks/kernels? | 16:49 |
| JayF | That's the question -- the default change is a strong signal that our current use case is insecure, but I don't see *any* off ramp to supporting Ironic | 16:49 |
| JayF | that's why I'm pushing back against having this be a config flip in Ironic devstack and another "weird edge case" in ironic for a half-decade | 16:50 |
| dansmith | so you agree this is critical security checking? :) but again, this is just a default for which checks are considered fatal. Reverting the patch and the reno doesn't change anything about what is checked at runtime over changing the config option yourself | 16:51 |
| dansmith | you uploading things as AKI as you were doing before literally doesn't change anything for your use-case, but disabling this actively decreases everyone else's security exposure | 16:52 |
| dansmith | you can disable the fatality of the check in config, or you can upload as aki as you had previously done and will do going forward.. I totally don't understand the logic with dropping this protection for others | 16:52 |
| JayF | I'm saying as an operator, if I see a config option that sounds security related change to a more restrictive default, and Ironic docs say to open the door up, I will assume it's less secure | 16:52 |
| JayF | dansmith: we documented for operators -- and they implemented it in their downstreams -- to not use aki/ari. I believe at some level our security patches depended on it. | 16:53 |
| JayF | It makes us -- OpenStack us but primarily Ironic us -- look like incompetent idiots to flip that documentation now | 16:53 |
| JayF | especially since /we aren't uploading AKIs or ARIs/ so we'd be documenting to users to lie | 16:53 |
| dansmith | I'm really sorry that you guys thought nova's deprecating of the AMI/ARI/AKI workflow meant that you should stop uploading kernel images as such, but I don't think that disabling that check for everyone else when it has been planned for quite some time makes sense | 16:54 |
| JayF | dansmith: I don't wanna spend my day finding reciepts, but I'm 99% sure you and/or others involved in Nova/Glance image security stuff reviewed all these changes | 16:55 |
| JayF | so it feels strongly like a rugpull that we are now paying for | 16:55 |
| dansmith | I don't think there's any reason your kernel images are different from an amazon-provided AKI by the way.. AMI is the only ill-defined bit (it can be a tarball, or a qcow or various other things) but AKI is always a kernel image, AFAIK | 16:55 |
| JayF | That would've been nice to solve before we've spent a year+ documenting to operators to not use AKI :) | 16:56 |
| dansmith | JayF: the point of all this work is to stop calling everything raw, so I feel like if I gave the impression that you should not be uploading kernel images as AKI for use purely by ironic then that was not the intent | 16:57 |
| JayF | I believe the discussion was along the lines of use raw now, we'll solve this later before flipping the default | 16:57 |
| dansmith | but as you noted, there was a lot of stuff flying around at the time | 16:57 |
| JayF | but my memory is highly lossy | 16:57 |
| JayF | that's at least where my understanding of it landed | 16:57 |
| JayF | so IMO it feels like a step was skipped -- finding a better official way to support these artifacts | 16:57 |
| dansmith | I seriously doubt that I said that (or meant that) but okay :) | 16:58 |
| dansmith | to be clear, | 16:58 |
| JayF | Remember this was v1 of the iamge inspector stuff, before the GPT/MBR detection was highly improved | 16:58 |
| dansmith | if you upload anything as raw today that fails other safety checks than this MBR one, it will fail | 16:58 |
| JayF | and I'm OK that it was messy, I just don't think "go back to the old guidence" is an acceptable solution, nor is "all glances that serve Ironic must be configured in a way that Nova/Glance cores consider less secure" | 16:58 |
| JayF | is either | 16:58 |
| dansmith | and we have already told other people who had bad iso-with-gpt images to fix their stuff and refused to relax the checks | 16:58 |
| dansmith | mkisofs in certain configs was generating invalid MBRs and we told those folks to take a hike | 16:59 |
| dansmith | IIRC, some smaller distros (maybe even debian now that I think if it) fixed their process | 16:59 |
| dansmith | let me try to find a link | 16:59 |
| dansmith | JayF: but reverting this change literally is the same as the latter.. it puts glance by default to the same "consider less secure" state instead of just the ones that might need to serve ironic, | 17:00 |
| JayF | that's nice for them; but they aren't another OpenStack project that's tightly integrated with Glance like Ironic is. I don't think it'd be a lot to have asked for a heads up. Hell PTG was 2 weeks ago and nobody even mentioned that there was glance/ironic overlapping issues | 17:00 |
| dansmith | and in that case, only ones that people can't or won't use AKI when they upload | 17:00 |
| dansmith | we discussed this item at PTG and decided to go forward with it.. I certainly didn't expect any ironic overlap because I thought you (since you were) using AKI.. how would we know? | 17:01 |
| dansmith | the patch had been up since last year | 17:01 |
| JayF | How often do you read Ironic patches? | 17:02 |
| JayF | About as often as I read glance ones, I suspect | 17:02 |
| dansmith | right, but I mean.. you guys had been reviewing plenty of other glance/oslo patches in that topic (although I note it seems to have missed or lost the topic affiliation maybe after the most recent gerrit transition) | 17:03 |
| JayF | This is where the disconnect is. I thought Ironic was in good shape now because we followed the advice we were given re: aki/ari deprecation | 17:04 |
| JayF | that circle was never closed | 17:04 |
| dansmith | again, ami deprecation is a nova thing | 17:05 |
| dansmith | here's the debian thing I was thinking of: https://review.opendev.org/c/openstack/oslo.utils/+/964528 | 17:05 |
| dansmith | I thought there was a bug with more discussion but I don't see one tagged and launchpad is on the floor again | 17:05 |
| JayF | I don't really care about the Debian case? I care about the Ironic case. | 17:06 |
| JayF | and I wish we were not being compared to a completely external contribution team | 17:06 |
| JayF | we're in the same governance! | 17:06 |
| dansmith | just pointing it out for prior art | 17:06 |
| dansmith | so what's the plan here? if we were to revert this, we have to wait another couple cycles to proceed on this work until something else gets done, or are we never going to steer people back to aki? | 17:07 |
| JayF | My (not-glance-expert) thought was: revert it, create a container format suitable for IPA kernel/ramdisk (if AKI is for the kernel; that'd be OK I guess but ideally it seems like we'd not point at an ill-defined amazon image type) -- have that format accept IPA images appropriately (and ID them for inspector/safety exclusions as needed -- maybe even lock down scope of who can use it) | 17:09 |
| dansmith | the GPT header on the kernel image seems, if anything, specifically designed to not be valid - likely to prevent a BIOS from being able to boot it at all.. that's sort of exactly the kind of thing we're trying to check for and reject here | 17:09 |
| JayF | Kernel images on inspection change depending on if they are EFI stub or not iirc | 17:10 |
| JayF | I am reaching back to old memory around this, but I remember testing and seeing different complaints for efi stub kernel vs just kernel image w/o efi stub | 17:10 |
| dansmith | I don't know what container format you mean really.. you want to wrap more than just one thing (kernel+ramdisk?) in a single image and call that a new container format? | 17:11 |
| JayF | let's talk about it with Ironic docs, that might help with clarity | 17:11 |
| JayF | https://docs.openstack.org/ironic/latest/install/configure-glance-images.html#deploy-ramdisk-images | 17:11 |
| JayF | right now we doc raw+bare for both cases | 17:11 |
| JayF | I'm suggesting there has to be a way we can use disk and container format to signal "this is a linux kernel" / "this is an initramfs" | 17:12 |
| JayF | aki/ari was that way, it was communicated to us it was deprecated and to move to this -- so we did. If this isn't OK, what's the new point to move to? And explaining to operators "no go back to Amazon-named image types, it's OK" will make us look like idiots | 17:13 |
| dansmith | you can.. aki/ari | 17:13 |
| dansmith | I get that the leading a is unfortunate and confusing, but that predates even this old-as openstack developer :) | 17:13 |
| dansmith | they are literally the types for kernel and ramdisk images | 17:13 |
| JayF | (e.g. https://docs.openstack.org/ironic/2024.1/install/configure-glance-images.html#deploy-ramdisk-images ) | 17:13 |
| JayF | dansmith: you do understand why that response, based on the events as I've explained them, is extremely upsetting? | 17:14 |
| dansmith | sorry, which response? | 17:15 |
| JayF | to switch back to aki/ari after we were specifically asked to switch away from them | 17:15 |
| JayF | even if that originally was a miscommunication | 17:15 |
| * JayF is trying to archeology bugs around this but [gestures generally at the world and ubuntu] | 17:16 | |
| JayF | dansmith: I think a contributing factor: the docs change for aki/ari was a separate add-on from the actual CVE fix. So I think it's extremely possible that one slipped by without having a glance/nova expert see it to raise an alarm. I am tracking the bug that's pointed at but LP=sadness | 17:17 |
| dansmith | can we stop with the "we were specifically asked to switch away from them" part? Unless you want to really pin that on me, I think at this point we can agree that there was some confusion about this | 17:18 |
| JayF | I mainly keep pointing at that due to the knock-on effect: we configured Ironic to assume raw for those, don't have aki/ari in our allowed, and communicated to operators based on that flawed assumption | 17:19 |
| JayF | regardless of how that asusmption got there, it's the shaky foundation the whole support in ironic was built on | 17:19 |
| dansmith | I sent a mail to the list (tagged nova and ops) asking for feedback on *nova's* AMI boot process and if anyone cared if we kept it.. there were responses about kernel/ramdisk boot (separate from AMI) but nothing from ironic people in there but I'm really not sure what else there that could have indicated that ironic should make that change | 17:19 |
| JayF | it's not meant to be a gotcha comment, just something that is inexplicable to an operator :) | 17:20 |
| dansmith | I very much understand the uncomfortable position of asking people to go back on a recent change.. obviously I would not want to be in that position | 17:20 |
| JayF | I think it's worse than that; I think we actually have to flag-day it in Ironic as well | 17:21 |
| JayF | like code and instructional change together | 17:21 |
| JayF | because of [conductor].permitted_image_formats | 17:23 |
| JayF | (at a minimum, at least) | 17:23 |
| TheJulia | So, going back and looking at things, I can also see (downstream) where others independently looked at the back and forth and independently determined that they should not be using aki/ari and instead shifted to raw & bare. :( | 17:24 |
| TheJulia | oh, take that back, they question and got me involved again as I read that thread and see where I affirmed on the then context | 17:25 |
| dansmith | I'm looking at the entire transcript of 2059809 and I don't see any discussion about AKI, ARI, AMI other than one passing note about hiding a qcow in an AKI that would cause nova to do something bad | 17:26 |
| JayF | Yeah I literally know my downstream lost like an hour deploying the security fixes because they had to update their agent images to *not be aki/ari* for it to work post-cve :( | 17:26 |
| TheJulia | Yeah, I think the takeaway impression is just very different on the use side from the "in the thick of it" development perception | 17:28 |
| JayF | finally got https://bugs.launchpad.net/ironic/+bug/2074090 to load and there's no docs, I suspect a misunderstanding happened in IRC / one of the CVE-video-reviews or something that led to actions being taken | 17:28 |
| dansmith | yeah I'm just trying to figure out where I could have even given the impression that aki in glance had any specific issue at all | 17:28 |
| JayF | that was filed by TheJulia to change from aki/ari to raw, and I seconded it with the comment nova is deprecating aki/ari | 17:28 |
| * dansmith hasn't gotten it to load yet | 17:29 | |
| JayF | I don't think we'll ever find it. Too much of the conversation happened in DMs and sync video chats around fixing the CVE issues | 17:29 |
| TheJulia | same here, but I seem to remember that was directly out of one of the calls | 17:29 |
| JayF | dansmith: there's nothing to see, it's me and julia being directive with no comments from others, it reads like an AI that came outta a sync chat tbh | 17:29 |
| dansmith | okay | 17:29 |
| JayF | ACTION ITEM | 17:29 |
| TheJulia | pretty much | 17:30 |
| JayF | retake the a.i. acronym for middle managers :P | 17:30 |
| TheJulia | although, my browswer hopes it will load one day | 17:30 |
| dansmith | perhaps the other confusing bit I guess is that nova's not actually deprecating AKI/ARI as types for direct kernel boot, it's specifically AMI that is the problem because that is where the image content comes from.. so qcow2 with kernel_id pointing to an AMI image is still valid | 17:30 |
| TheJulia | going back to something JayF said, it does sort of feel like we need a net-new type, and that was something I was thinking but not saying earlier | 17:31 |
| dansmith | we don't need a new type... we _could_ create one, but the purpose would just be "because we don't like the A in the front of KI" | 17:32 |
| dansmith | because AKI _is_ the type for a kernel image | 17:32 |
| JayF | I would state the reason more as "We can properly define what this image type means, and reduce the scope of it to as small as needed for our use case" :D | 17:32 |
| dansmith | maybe we change the docs to s/Amazon Kernel Image/A Kernel Image/ ? :) | 17:32 |
| JayF | but getting rid of an A is nice | 17:33 |
| TheJulia | That would be awfully evil, fwiw. | 17:33 |
| JayF | OK dansmith I needed that laugh, that's funny and maybe a good suggestion but I'm unsure | 17:33 |
| dansmith | it literally says "For a Linux machine, this would be a vmlinuz file." | 17:33 |
| JayF | "Agen Kernel Image" | 17:33 |
| JayF | *Agent Kernel Image | 17:33 |
| JayF | lol | 17:33 |
| TheJulia | its not a bad idea. | 17:33 |
| TheJulia | lol | 17:33 |
| JayF | what is a ramdisk in that world? | 17:33 |
| TheJulia | Thank you for the laughs, I've needed them this morning | 17:33 |
| dansmith | "For a Linux machine, this would be an initrd file." | 17:33 |
| TheJulia | rutro, I just had the "do I need to be concerned, that was more than 5 seconds of giggling!" | 17:34 |
| dansmith | ari ^ | 17:34 |
| dansmith | the real problem is AMI, which while it says "image in raw format", that's not right. it can be a raw disk, but it's usually a qcow, and can be a tarball of the rootfs | 17:34 |
| JayF | initrd and initramfs aren't the same thing, from a technical perspective, yeah? but I assume we've already nailed down all the shapes of that in the image inspector? | 17:34 |
| JayF | not normally something I'd be pedantic over but image type conversations is maybe the only place to care lol | 17:35 |
| dansmith | they're not the same, but most bootloaders that I know of treat them as identical for the purposes of being slapped into RAM where the kernel unpacks it on its own | 17:35 |
| TheJulia | from my point of view, its always a CPIO or a chain of CPIOs which are header delimited | 17:35 |
| JayF | TheJulia: initrd-propers are squashfs | 17:35 |
| dansmith | glance/format_inspector doesn't do anything with initrd or initramfs | 17:35 |
| TheJulia | JayF: sorry right, my brain is pre-squashfs | 17:36 |
| dansmith | (currently) | 17:36 |
| JayF | so if you were na Ironic dev, would you subject ARI/AKI to any inspection? | 17:36 |
| JayF | (and/or does glance do any inspection on an ari/aki upload?) | 17:37 |
| TheJulia | I would need to check the code at this point, I just don't remember | 17:40 |
| dansmith | well, we don't intentionally but if you are an aki and you get detected as GPT then we will probably run the same check and fail.. but I think _that_ makes sense to fix (if it's really there) | 17:42 |
| dansmith | we don't run the inspector for any container_format other than bare, | 17:42 |
| dansmith | but we don't specifically exclude it for aki, we just expect that it is not going to match anything | 17:42 |
| dansmith | and we have that in place because of ami being potentially anything | 17:42 |
| TheJulia | so, I think that might be part of the problem then and maybe what forced the shift. It the EFI kernel stub would have been tagged out and then possibly occured with, because I think it was container format bare in CI ages ago. | 17:45 |
| dansmith | no, because that wasn't fatal by default until this patch merged :) | 17:45 |
| dansmith | and all of this actual GPT inspection came way after the original CVE | 17:46 |
| opendevreview | Dan Smith proposed openstack/glance master: MBR safety check is non-fatal for non-disk-image formats https://review.opendev.org/c/openstack/glance/+/987273 | 20:19 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!