jabr

> In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer

In the project discord, a user recently experimented with a custom setup that sounds very similar to what you describe.

In fact, a big part of uncloud’s appeal to me is that it also provides powerful building blocks for more complex, custom systems like this, not just the streamlined workflow for simpler, standard cases.

There is a `--no-install` flag on both `uc machine init` and `uc machine add` that skips that `curl | bash` install step.

You need to prepare the machine some other way first then, but it's just installing docker and the uncloud service.

I use the `--no-install` option with my own cluster, as I have my own pre-provisioning process that includes some additional setup beyond the docker/uncloud elements.

Do you have an example of what you mean? I'm not entirely clear on your question.

The `compose.yaml` spec for services let's you specify which machines to deploy it on, so you could target the database and web app to the same machine (or subset of machines).

There is also an internal DNS for service discovery and it supports a `nearest.` prefix, which will preferentially use instances of a service running on the same machine. For example, I run a globally replicated NATS service and then connect to it from other services using the `nearest.nats.internal` address to connect to the machine-local NATS node.

There isn't a cli function for adding a connection (independently of adding a new machine/node) yet, but they are in a simple config file (`~/.config/uncloud/config.yaml`) that you can copy or easily create manually for now. It looks like this:

    current_context: default
    contexts:
      default:
        connections:
          - ssh: [email protected]
            ssh_key_file: ~/.ssh/uncloud
          - ssh: [email protected]
            ssh_key_file: ~/.ssh/uncloud
          - ssh: [email protected]
            ssh_key_file: ~/.ssh/uncloud
          - ssh: [email protected]
            ssh_key_file: ~/.ssh/uncloud

And you really just need one entry for typical use. The subsequent entries are only used if the previous node(s) are down.

DuckPGQ is an interesting option, but unfortunately, that project hasn't been touched in a few months and does not currently work with the latest version of DuckDB.

My best guess is the company was acqui-hired and will soon be working on implementing Kuzu's tech in a different database owned by the acquirer.

My _hope_ is that it was some IP issue with the University of Waterloo and a new company will appear shortly and pretty much pick up where they left off, but that's probably just wishful thinking on my part.