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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.