From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4226527EFEB for ; Thu, 28 Aug 2025 20:00:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756411211; cv=none; b=Ga8nVM1Q/QrpcLu6d1arwYLSzstbECLcZOvkt3tfy1TQTbJc2gOUzO+1gCVdFhoof0eQ5Lmew0hAxfrqM3zoX09zlgdf442NLE4iob01+LpPsAyFld0tpKT0IC+gTuYMew8zBBnAtMMHYebXnk3NyMIstjlQpJh2W5zQ/yjXRcs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756411211; c=relaxed/simple; bh=XNLUtpY6X01LscdEK1LHhQp/TDBjcpFGwTG7f17UdaY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=PmFiQLYTmJ1tZ27k9gowYiYTwfEzh+De5lYHVFcdUOS0QRwoQxf6tmAaoy7tDC0gWNgF2zzNF2fsf045k+x40y/Kefs+3+ZO94l7ii+nzQsXnFnUmPn0sxXmx2E5VGRl4hQZqKiQuTeCD7PueFi1yx6XxLG98AV1lwZL+RBbTaU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hjuNTe6E; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hjuNTe6E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8BA69C4CEEB; Thu, 28 Aug 2025 20:00:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756411210; bh=XNLUtpY6X01LscdEK1LHhQp/TDBjcpFGwTG7f17UdaY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=hjuNTe6ELNshVRy/1K027Lzg64/XWCdFXTo4+S5qAUEzQwnDsifG3RqdzxhYa2V5D eCRCpJIlYLaK+rQ23FT2c2fbIUD8Sne6faebYeLh1sDHJCLXbylsDTPK2JcQ+Z7dPt p22gOaxb7/mauLFjX3u1AazR6CRxh2GtKFPJBuq4559yQQkUJuiK2lYBocHId+TMQm 98q3TG7sBwO2WIVHNLfZbyNAN7z7ClGR+8V5J0WOAxW2zgcLFX9Eadp3pkzEPqeond 7bhCKbp7SwMakpsIXMmcd+Vnm8scEHEiqdPJDKZl3Ema1pXMVEIHTOTQDEmajVlfEj YMkQofOXpPFLA== Message-ID: Date: Thu, 28 Aug 2025 16:00:09 -0400 Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/10] scripts: add Lambda Labs Python API library To: Luis Chamberlain Cc: Daniel Gomez , kdevops@lists.linux.dev References: <20250827212902.4021990-1-mcgrof@kernel.org> <20250827212902.4021990-3-mcgrof@kernel.org> Content-Language: en-US From: Chuck Lever Organization: kernel.org In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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