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:
Thanks for taking the time to reply. I appreciate that.
On Sat, 9 May 2026 at 23:00, Michael Still <mikal@stillhq.com> wrote:
So I wrote it, and by "I wrote it" I mean Claude Code mostly wrote it. Instar is a from scratch rethink of how to handle
For me a statement like this is unfortunately not a quality stamp. While playing around with AI agents I ensured myself that AI does not take care about future maintenance of the code. It proposes the solution to your question (depending on how you ask it) using the statistics - it is not a secret that current AI is nothing else rather than just a statistical probability machine. I have no problem with asking the AI for support but a statement "Claude mostly wrote it" is not a great signal. I recommend you not to use such phrasing if you want to reach acceptance.
Honestly? Meh. If the OpenStack community isn't willing to consider possible new things based on their merits alone then I am not too fussed by OpenStack missing out on new things. Instar is not proposed as a potential OpenStack project, so I see flexibility to do pretty much whatever I want as the author. I think I was also pretty clear that instar is a concept _prototype_. so nova already has configoption for xoriso command for which cli to build the config drive.
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 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. 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.
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.
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.
untrusted image data as well as an opportunity for me to become more familiar with code generation LLMs. All data processing happens in a custom KVM guest which does not run an operating system or have any access to system resources apart from those provided to it by the custom VMM which orchestrates it. The best way to think of this guest is as an embedded system running on a virtual CPU. This is similar in approach to how AWS Nitro Enclaves work in terms of prior art, whilst also being the opposite in intent: Nitro protects sensitive data *from* the cloud; instar protects the cloud *from* malicious data. To be clear, `instar info` doesn't detect or block malicious images -- it processes them safely and reports what it finds. The security comes from containment, not detection. It is then up to the caller to decide how to handle what is reported.
I think the proper strategy would be to do both: protect images from the cloud (confidential computing) and cloud for the image. Nitro (all of them) are giving very useful hints about what could and should be done and we definitely should learn from competitors.
To my current understanding a key underpinning to nitro is hardware acceleration of KVM. Unless deployers want to go all-in on DPUs, much of that remains out of reach for many.
Michael