Re: [PATCH v2 02/10] scripts: add Lambda Labs Python API library

[Chuck Lever <cel@kernel.org>]

On 8/28/25 3:33 PM, Luis Chamberlain wrote:
> On Thu, Aug 28, 2025 at 02:59:18PM -0400, Chuck Lever wrote:
>> On 8/27/25 5:28 PM, Luis Chamberlain wrote:
>>> Add a Python library for interacting with the Lambda Labs cloud API.
>>> This provides core functionality to query instance types, regions,
>>> availability, and manage cloud resources programmatically.
>>>
>>> The API library handles:
>>> - Instance type enumeration and capacity checking
>>> - Region availability queries
>>> - SSH key management operations
>>> - Error handling and retries for API calls
>>> - Parsing and normalizing API responses
>>>
>>> This forms the foundation for dynamic Kconfig generation and terraform
>>> integration, but doesn't enable any features yet.
>>
>> Thanks for splitting this up. Much much easier for humble humans to
>> understand now. There are some really interesting ideas in the series;
>> kudos to you and Claude.
>>
>> The other cloud providers have their own house-brewed command line
>> utilities that are typically packaged by distributions (eg, oci, aws,
>> and so on), as well as their own Ansible collections.
>>
>> I assume that Lambda does not have those (yet).
> 
> Right. It sad to not see such a thing, which meant it was actually
> harder to do this inference work, and yet it shows its possible. Which
> also means, technically in theory, it might even be possible to do the
> same with other cloud providers without a CLI tool.
> 
>> Can the patch
>> description mention that? 
> 
> Sure.
> 
>> Basically that's the whole purpose for this
>> patch and the two following, IIUC.
>>
>> I would actually encourage this script to be restructured and renamed so
>> that it works like the tooling available from other cloud providers.
> 
> So you mean we write Lambda's CLI tool? Sure we can try that, but who do
> we follow? And do we need to do that now? Or can I do that later?
> 
>> Separate the API calls and retrieval of information (which is rather
>> general purpose) from the translation of that information to Kconfig
>> menus (which is specific to kdevops).
> 
> You mean, to re-use all the knowledge we used for Kconfig dynamic
> kconfig to a create a specific tool, which can then be itself leveraged
> for both the dynamic kconfig and also a user tool?

I think so: Write a command line tool that makes API queries and spits
out JSON. Write a second tool that takes the JSON and turns it into
Kconfig menus. Re-use the first tool for other tasks. That is how I
was thinking of building dynamic menus for the other providers; their
existing command line tools are tool #1 above.

But, we can do it later. I won't hold you up with crazy ideas.


-- 
Chuck Lever