Go to file
Thomas E Lackey 5c275aa622
All checks were successful
Lint Checks / Run linter (push) Successful in 34s
Publish / Build and publish (push) Successful in 1m7s
Smoke Test / Run basic test suite (push) Successful in 4m0s
Webapp Test / Run webapp test suite (push) Successful in 4m42s
Deploy Test / Run deploy test suite (push) Successful in 4m58s
Database Test / Run database hosting test on kind/k8s (push) Successful in 10m2s
Container Registry Test / Run contaier registry hosting test on kind/k8s (push) Successful in 3m44s
External Stack Test / Run external stack test suite (push) Successful in 4m26s
Defensively handle errors examining app requests. (#922)
Related to cerc-io/webapp-deployment-status-api#10

There are two issues in that.  One is that the output probably changed recently, whether in the client or server, where no matching record is found by ID (Note this is specific to `laconic record get --id <v>` and does not seem to apply to the similar command to retrieve a record by name, `laconic name resolve <n>`).

Rather than returning `[]` it is now returning `[ null ]`.  This cause us to think there *was* an application record found, and we attempt to treat the `null` entry like an Application object.  That's fixed by filtering out null responses, which is a good precaution for the deployer, though I think it makes sense to ask whether this new behavior by the client/server is correct.  Seems suspicious.

The other issue is that all the defensive checks we had in place to deal with broken/bad AppDeploymentRequests were around the _build_.  This error was coming much earlier, merely when parsing and examining the request to see if it needed to be handled at all.

I have now added similar defensive error handling around that portion of the code.

Reviewed-on: #922
Reviewed-by: zramsay <zramsay@noreply.git.vdb.to>
Co-authored-by: Thomas E Lackey <telackey@bozemanpass.com>
Co-committed-by: Thomas E Lackey <telackey@bozemanpass.com>
2024-08-14 18:04:31 +00:00
.gitea/workflows Remove Eth fixturenet workflows (#906) 2024-08-01 02:28:05 +00:00
.github/workflows Enable webapp test in GitHub CI. (#627) 2023-11-07 18:27:08 -06:00
docs rename laconic-sdk to registry-sdk (#897) 2024-07-31 08:01:02 +00:00
scripts Container Registry Stack (#747) 2024-02-18 18:55:55 +00:00
stack_orchestrator Defensively handle errors examining app requests. (#922) 2024-08-14 18:04:31 +00:00
tests Remove Eth fixturenet workflows (#906) 2024-08-01 02:28:05 +00:00
.gitignore Rename app -> stack_orchestrator (#625) 2023-11-07 00:06:55 -07:00
LICENSE Initial version of pip packaging 2022-08-23 11:32:55 -06:00
MANIFEST.in Initial version of pip packaging 2022-08-23 11:32:55 -06:00
README.md Update links from github.com to git.vdb.to (#732) 2024-02-06 22:42:44 +00:00
requirements.txt Switch to Docker-style limits 2024-02-08 00:43:41 -06:00
setup.py Fixes for external stack deployment (#851) 2024-07-09 15:37:35 +00:00
tox.ini Moar complex 2022-10-03 19:43:43 -06:00

Stack Orchestrator

Stack Orchestrator allows building and deployment of a Laconic Stack on a single machine with minimial prerequisites. It is a Python3 CLI tool that runs on any OS with Python3 and Docker. The following diagram summarizes the relevant repositories in the Laconic Stack - and the relationship to Stack Orchestrator.

The Stack

Install

To get started quickly on a fresh Ubuntu instance (e.g, Digital Ocean); try this script. WARNING: always review scripts prior to running them so that you know what is happening on your machine.

For any other installation, follow along below and adapt these instructions based on the specifics of your system.

Ensure that the following are already installed:

  • Python3: python3 --version >= 3.8.10 (the Python3 shipped in Ubuntu 20+ is good to go)
  • Docker: docker --version >= 20.10.21
  • jq: jq --version >= 1.5
  • git: git --version >= 2.10.3

Note: if installing docker-compose via package manager on Linux (as opposed to Docker Desktop), you must install the plugin, e.g. :

mkdir -p ~/.docker/cli-plugins
curl -SL https://github.com/docker/compose/releases/download/v2.11.2/docker-compose-linux-x86_64 -o ~/.docker/cli-plugins/docker-compose
chmod +x ~/.docker/cli-plugins/docker-compose

Next decide on a directory where you would like to put the stack-orchestrator program. Typically this would be a "user" binary directory such as ~/bin or perhaps /usr/local/laconic or possibly just the current working directory.

Now, having selected that directory, download the latest release from this page into it (we're using ~/bin below for concreteness but edit to suit if you selected a different directory). Also be sure that the destination directory exists and is writable:

curl -L -o ~/bin/laconic-so https://git.vdb.to/cerc-io/stack-orchestrator/releases/download/latest/laconic-so

Give it execute permissions:

chmod +x ~/bin/laconic-so

Ensure laconic-so is on the PATH

Verify operation (your version will probably be different, just check here that you see some version output and not an error):

laconic-so version
Version: 1.1.0-7a607c2-202304260513

Save the distribution url to ~/.laconic-so/config.yml:

mkdir ~/.laconic-so
echo "distribution-url: https://git.vdb.to/cerc-io/stack-orchestrator/releases/download/latest/laconic-so" >  ~/.laconic-so/config.yml

Update

If Stack Orchestrator was installed using the process described above, it is able to subsequently self-update to the current latest version by running:

laconic-so update

Usage

The various stacks each contain instructions for running different stacks based on your use case. For example:

Contributing

See the CONTRIBUTING.md for developer mode install.

Platform Support

Native aarm64 is not currently supported. x64 emulation on ARM64 macos should work (not yet tested).