On Fri, May 15, 2026 at 10:24 PM Sean Mooney <smooney@redhat.com> wrote:
On 15/05/2026 01:12, Michael Still wrote:
On Thu, May 14, 2026 at 8:24 PM Artem Goncharov <artem.goncharov@gmail.com> wrote:
so nova already has configoption for xoriso command for which cli to build the config drive.
This is an aside, but my recollection is that we used an external binary for config drive creation because at the time all of the libraries we could find to do it in process were GPL'ed and that was a licensing line OpenStack wasn't willing to cross. I suspect no one has ever looked to see if there is an ISO9660 creation library which has an acceptable license now?
i have not had time to look at instar but if your inten is to provd a compatiabel cli with similar output we coudl likely just make that cofnigureabl in the relevent proejct can allow opertors to opt in
Yes, although that could also happen at the distro level. Its all irrelevant if the prototype doesn't "pay out", but my presumption was a drop in replacement that required no / minimal code change to OpenStack was more desirable that something more invasive.
the other approach we had been taking was to build out the image inspector in oslo. with the intent of eventually removing our dependency on qemu-image for doign the safety/validation entirely and only using it if needed for format conversion.
I am aware of the Oslo work. It worries me that its an arms race to be honest. Instar has a portion of its test suite devoted to comparisons with oslo.utils.format_inspector.
so i would need to load context on exactly what you have built but i would not discard it because an experience engineer built it using the assistance of an llm. i have built useful tools, features and bugs-fixes with ai and when used with care it can produce high quality output.
Thank you. The goal is to produce a binary that you can't tell isn't qemu-img, in that for "any" given input you give it you get the same output as you would with qemu-img. Now, that's neither a good idea (some of the qemu-img defaults are in fact unsafe), nor actually 100% feasible (instar wants you to allowlist the filesystem paths backing files can come from), but it is the high level goal. https://shakenfist.com/components/instar/configuration/ is probably the fastest introduction to what it can do now, and https://shakenfist.com/components/instar/quirks/ is an attempt to document all the places where the qemu-img behaviour was deviated from _so_ _far_. The other most notable difference is that because instar runs as a KVM guest, the user running instar _must_ have permissions to read and write to /dev/kvm. Instar _does_ _not_ use qemu or libvirt, so those don't need to be accessible to that user. This also means for now platforms other that x86_64 are _not_ supported because instar only knows how to bootstrap a KVM guest of that architecture.
On the other hand, having done this for about six months, I think the "it's just statistical" view is naive. There is much more to it than that: planning frameworks, clear definitions of correctness, good precommits and CI, etc. This is one of the reasons I have started publishing the planning templates and implementation documents I use, as I think those are just as important in terms of review as including a summary prompt in the commit message. Sadly, instar doesn't have a complete history of those because it was before I realised those things, but given one of my goals was to learn about the tools that seems like a success to me regardless.
Isn't another way to rephrase your stance simply as encouraging authors using ML coding tools not to disclose that because then their code isn't taken seriously? that would be very counter productive and not a stance we shoudl take as a comunity IMO.
llm or not is not the gate of quality human but the maintneres and the authors are :) devaluing the work of contibutors just ebcause the use a tool to help them woudl be counter productive so disculosure is good but shoudl not be a signal that it is of good or bad quality.
I agree, but that is not my interpretation of the current behaviour of all OpenStack community members.
Instar runs thousands of comparison tests between its output and
qemu-img's. There are 121 images in the test suite, including some crafted to specifically trigger previous vulnerabilities. So, as best as I can tell it _works_. It might not be maintainable, but it might also be. I haven't found any evidence yet that it is not. Then again, should maintainability be a primary goal for a _prototype_? Nova has had lots of histocial design missteps we've had to clean up -- surely it's unreasonable to expect machine-assisted code to be perfect at first attempt?
if its optioanl or configurable we can evaulate that with our ci. qemu-img has had many bugs and secuirty issues so human written code is also not perfect.
I don't think instar is ready to be dropped into CI to replace qemu-img -- for example `resize` is not currently supported. That's the goal, but we are some way away from that right now. That said, it does have github CI. That CI is somewhat hampered by my hesitation to publicly share the test data set, but in the end I decided that sharing a collection of images specifically crafted to trigger historic qemu-img bugs was probably not a good idea. Michael