Re: [RFC PATCH] terraform/aws: Add scripts to gather provider resource information
Luis Chamberlain <[email protected]>
| Newsgroups | dev.linux.lists.kdevops |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Sep 13, 2025 at 04:54:53PM -0400, Chuck Lever wrote: > From: Chuck Lever <[email protected]> > > Luis suggested I try my hand... so here goes. > > I prompted Claude for a few ideas about how to grab information > about AMIs, instance types, and regions/AVs. The script output is > either JSON, a human-readable table, or CSV. Additional scripts > (not provided here) would then capture this output and convert it > to Kconfig menus. > > This is not at all complete. Just another way to approach these > tasks, for comparison. <-- snip --> > I would say that this code works and has a pleasant UX but is > still more complex than we might want to carry in kdevops in the > long run. I'm interested in seeing some human or AI effort to > simplifying these scripts further. I no longer code manually on kdevops, but I do review things from at least an long term archtecture perpective. But for areas which I touch more, like fstests, etc, clearly I have a more hands on review process. For other things I think it should be up the maintainer of that component for them to decide how to scale. > And note that the instance type information is always based on > what's available in the queried region and what the credentialed > user has permission to see. Therefore: > - out of the shrink-wrap, kdevops might provide some sensible > generic default menu selections > - a power user might need to run this before selecting the cloud > resources they want to use > > So it better be damn simple and damn reliable. :-) And we probably > need to be very careful before changing the in-tree menus that > are committed to the kdevops repo... They might need to continue > to be hand-rolled. Or we just have some fixed JSON source that > generates the sensible default menus. Since we would replace static with a new dynamic world order, all I personally care about is functionality (things coming up) and defconfigs working. So I'm not attached myself to .configs working as I update kdevops, I believe I can keep kdevops directories for my cloud deployments static. So the defconfig itself could change variable names, I wouldn't care, so long as bringup with it works, that's all I would care for really. The first one I am caring for is the GPU one. I intend on scaling up to larger GPUs with time. > Posting this for thoughts and opinions. Since you maintain terraform/ I think it should be up to you :) I just wanted to get the ball rolling and want to soon expand beyond the simple GPU defonfig PoC I added through patches posted but not yet merged. I'd be happy you just merge whatever you think is right for a new world order, and define the new rules you'd want. Luis