IDEA: WASM build to deploy-to & manage different clouds without a separate Python server

Feature Request

Aside from a basic web interface, the main thing this would need is a way of setting and storing secrets (like cloud provider auth keys).

As for official CPython support see: https://github.com/python/cpython/blob/main/Tools/wasm/README.md

Now there are plenty of unofficial implementations that don't have those same limitations, for example: cheerpx webvm; py2wasm; pyodide; spin+CPython official approach

Advantage:

• Multicloud management without user installing anything
• Facilitate one-click install use-cases onto multiple cloud vendors
• Many others

@SamuelMarks That sounds like an interesting and cool idea (I know there were / are many SaaS products which include functionality like that, including mist.io which is / used to be open source), but I'm not fully sure if it should directly be part of Libcloud core.

To me it sounds like a perfect addon / app built on top of Libcloud.

We don't want to get into secure credentials storage and in general this sounds like something which should be built on top of and not bundled with the core library. How did they used to say about Python stdlib modules - that's where packages go to die, granted this has changed and improved a bit over the years, but something like that should be a standalone and separate project so it's not tied to Libcloud release schedule, development process, etc.

Of course, if there is anything we can do to make integration / compatibility with wasm runtimes easier, we are welcome to help and contributed are more than welcome :)

@Kami For reference, here's the latest thing I'm working on https://verman.io

(redoing the sidebar right now so mind the mess)

E.g., 1-click and 2-click deploys of PostgreSQL https://verman.io/docs/latest/_lib/_storage/postgres/README.html

To make it functional there are various available mechanisms. The basically undocumented one is where I think I'll end up; namely your libcloud.compute.deployment.ScriptDeployment would be the cleanest way to bootstrap a node with, e.g., PostgreSQL.

A while back I did make these https://github.com/offscale?q=off&language=python#org-profile-repositories all of which are built atop Apache Libcloud and/or Fabric. They accept a simple JSON format and use it to do things like: create/delete {networks, firewalls, [e.g., EC2] instances}; and use Fabric to SSH in—with paramiko—to install & configure different things. FYI: My new version; though still open-source; is much more cross-platform and requires nothing to be installed to bootstrap, been based on /bin/sh with a little bit of .bat for Windows support.

You might've seen the recent JupyterLite. It's Jupyter Notebook but in the browser with nothing installed (just served locally or with, e.g., a CDN). Both Jupyter [https://jupyterlite.github.io/demo/lab/index.html] and numpy now have it on their homepages as a "quickly get started with [project]"

What I'm thinking @Kami is a similar "quickly get started with Apache Libcloud"

You would only need a teeny bit of JavaScript+HTML to prompt and store/load cloud auth secrets in LocalStorage.

Now with this new context and pitch; will you reconsider this proposal? 🤗

Thanks for the additional context.

I didn't have time to dig in deeply, but the project looks interesting :)

As far as the original idea goes - if I understand it correctly, it would be more like "repl in a browser" aka a way for people to try out and play with Libcloud?

If that is the case, it could indeed be interesting and we could perhaps host it at https://try.libcloud.org or similar.

In fact, I worked on a prototype for something like that many, many years ago. That was long before WASM so there was a server side component + client (browser + JavaScript), but securely sandboxing Python interpreter was anything but trivial so it has never seen wide use due to potential of abuse.

And yes, if the secrets are stored locally (browser storage), I don't see a problem with it.

If it would be anything more than that, my original comment still stands - it's not something which should be bundled with the core library, but built as an application on top of it which can be developed and live independently :)

Great. No exactly—try.libcloud.org—that is what I'm proposing.

On my own site I might extend it to accept POSTed data payload so the one-click/two-click deploy can be parameterised (e.g., with CNAME, and port-specific things like POSTGRES_DB_NAME) and then auto-execute. But everything else will be left untouched out of try.libcloud.org.

Now that it has your approval, what're the next steps?

FWIW: Just starting to play around with it here https://verman.io/repl.html EDIT: I'm generating nice HTML forms now to set secrets for all vendors Apache Libcloud has. Will push when it's ready :) UPDATE: @Kami it's ready! - See the aforementioned page

So my literally 10-year old solution for marshalling libcloud constructs into JSON is what I'm using https://github.com/offscale/offutils-strategy-register/blob/master/offutils_strategy_register/init.py#L97C1-L101C2

I've also moved the content to this page https://verman.io/multicloud.html as its name better defines its function. Will see how far I can get with CORS and everything else in the way.

(here's the code )

But here's what I'm thinking:

• Make sizes, networks, nodes all JSON marshallable properly; not hacked together with dir and getattr [@Kami did you want to do this one?]
• Finish up the collection of data from local storage for authentication purposes by using keyword arguments over splatting a tuple
• Add a basic workflow: 0. Specify provider
  1. Set provider auth details
  2. [makes possibly remote call]
  3. Select image size from dropdown
  4. [makes possibly remote call]
  5. Select image from searchable dropdown
  6. [makes remote call]
  7. Specify network or whether to create new; and special settings (maybe just static IP for now; don't want to go crazy on options!)
  8. [makes remote call]
  9. Specify firewall / ports or whether to create new
  10. Show [editable] script that will be bootstrapped onto node
  11. Provide "Execute" / "Deploy" button to 'enact the plan' on click
  12. Illustrate progress in HTML with a scrolling log window

Once this is working I might do something similar for Object Storage like S3. If CORS ends up being too much of a struggle to the point of impossibility without incorporating some crazy overlay network [e.g., webvm uses tailscale] then it might be easier—and possibly more user-friend—to wrap this up with tauri as a desktop web-app.

What do you think of the plan?

PS: As for the libcloud homepage, I suppose this should suffice: 0. Specify provider; 1. Set provider auth details; 2. Show Python REPL to user with libcloud already imported

EDIT: Here's the relevant Sequence diagram; that I just made in LaTeX:

@SamuelMarks This looks great.

Sadly I currently don't have much time to dedicate to the project besides basic maintenance, but since you seem to be active and passionate, this is something you may be interested in and be able to help with - https://libcloud.apache.org/blog/2025/03/19/call-to-action-the-future-of-libcloud.html

@Kami Ouch, zero interest; neither positive nor negative @ https://lists.apache.org/thread/3wt0orz16nzovqo1qdl1c4dq62xkm5bc