0.9.0 (#130)
* fix: fix absolute path in run.sh
starting the operator locally gave error "No such file or directory task: Failed to run task "run": task: Failed to run task "d:run": exit status 127", because of an absolute path inside run.sh
* fix: path to check for db ready
changed the path for wait_db_ready. The path without the final / led to a 301 and not a 200
* fix: invoker and operator image from env
removed hardcoded values for cfg.get operator.image / operator.tag and invoker.image and invoker.tag. Config now check env vars and defaults to old images
* fix(test): milvus tests
fixed tests for minio / seaweedfs .
* chore(docs): taskfile
added desc to taskfile tasks
* fix: namespace validation
added namespace validation in user creation
* do not use a fixed offset to nuvolaris.io (#119)
* do not use a fixed offset to nuvolaris.io
* removed talos
---------
Co-authored-by: Trustable User <noreply@example.com>
* remove reference to nuvolaris logo (#120)
Co-authored-by: Trustable User <noreply@example.com>
* fix: validate database and bucket names in user provisioning (#121)
Follow-up to #109, which validated spec.namespace but left two other
tenant controlled WhiskUser fields flowing unsanitized into shell
commands executed inside the data pods via kubectl exec.
* spec.postgres.database reached `bash -c "... psql --dbname {db_name}"`
in exec_psql_command_in_db. Unlike the namespace field it never
becomes a filename, so it was not even constrained to path safe
characters.
* spec.object-storage.{data,route}.bucket reached
`sh -c "echo '{command}' | weed shell"` in the seaweedfs client,
where a quote breaks out of the single quoted string.
Adds util.validate_database_name and util.validate_bucket_name next to
the existing validate_namespace and applies them at the call sites and
at the shell sinks, plus matching CEL rules on the CRD so the API server
rejects the payload before the operator sees it. The regexes and the CEL
rules were cross checked to accept exactly the same inputs.
Also:
* guards the latent render_kvrocks_script / exec_kvrocks_command pair,
which repeats the same pattern but is not currently wired into the
user path
* makes validate_namespace return False for non string input instead of
raising TypeError
* corrects a copy pasted error message referring to exec_mongosh_command
inside exec_psql_command
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* rebranding (#122)
Co-authored-by: Michele Sciabarra <michele@sciabarra.com>
* update naming
* operator build updated
* 0.9.0 (#124)
* updating distro in dockerfile
---------
Co-authored-by: Bruno Salzano <d4rkstar@gmail.com>
Co-authored-by: Trustable User <noreply@example.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Michele Sciabarra <michele@sciabarra.com>
Co-authored-by: miki3421 <42601846+miki3421@users.noreply.github.com>In this readme there are information for developers.
We describe how to build and test the operator in our development environment
Please refer to the website for user information.
For PR-driven infrastructure tests on GitHub, use a PR label in the form <test>-<commit-hash>, for example k3s-abcdef1.
Ensure you have satisfied the prerequisites below. Most notably, you need to use our development virtual machine and you need write access to a GitHub repository.
Once you have satisfied the prerequisites, you can build an image you can use in the development machine.
Build an image with:
task build
Please note that it will build the image locally and push in an internal registry, even if it is name is ghcr.io/${GITHUB_USER}/openserverless-operator.
To be able to build, the task build will commit and push all your changes and then build the operator from the public sources in your local k3s.
It will also show the logs for the latest build.
You can then deploy it with:
task deploy
Once you have finished with development you can create a public image with task publish that will publish the tag and trigger a creation of the image.
Please set up and use a development VM as described here
With VSCode, access the development VM, open the workspace openserverless/openserverless.code-workspace and then open a terminal with operator subproject: this will enable the nix environment with direnv (provided by the VM).
Create a fork of github.com/apache/openserverless-operator
Copy .env.dist in .env and put your GitHub username in it
Since the build requires you push your sources in your repo, you need the credentials to access it. The fastest way is to create a personal token
Now set up a remote to access your repo and set it as your default upstream branch.
git remote add fork https://<GITHUB_USERNAME>:<GITHUB_TOKEN>@github.com/<GITHUB_USERNAME>/openserverless-operator git branch -u https://github.com/<GITHUB_USERNAME>/openserverless-operator
That's it. Now you can use task build to build the image.
To deploy a testing configuration of the Apache OpenServerless operator execute the command
task all
The operator instance will be configured applying the test/k3s/whisk.yaml template. All the components are activated except TLS and MONITORING.