* feat!: rename 'emit' to 'invoke' and default to local This commit renames 'func emit' command to 'func invoke' and makes the default behavior to send an event to localhost. The special '--sink' value 'local' is changed to 'cluster' to indicate that the function should be invoked on the cluster instead of locally. All other behavior has remained the same. BREAKING CHANGE Signed-off-by: Lance Ball <lball@redhat.com> * fixup: update commands.md doc Signed-off-by: Lance Ball <lball@redhat.com> * squash: change Emitter interface to Invoker Changes Emit() to Send() in the (now named) Invoker interface, and changes Emit() to Invoke() in the client. BREAKING CHANGE Signed-off-by: Lance Ball <lball@redhat.com> * squash: use a common Invoker interface for HTTP and events Signed-off-by: Lance Ball <lball@redhat.com> * checkpoint Signed-off-by: Lance Ball <lball@redhat.com> * fixup: change Emitter to EventInvoker Signed-off-by: Lance Ball <lball@redhat.com> * Invoke v2 Draft * feat: client invoke function * static invoke defaults and methods * remove assimilated invoker package * includes an ignored .func directory on create * Instances manager with local and remote defaults Funciton Info is now Instance, representing a Function in a given environment. Describing a Function instance is now Instances().Get(f, environment) Moves Runner to be async with a Stop method to enable returning runtime pid and port for persisting. Instances now have a place for primary Route in addition to all routes slice Running Functions write PID and Port to .func * cascading targets: local vs remote vs ad-hoc endpoint * runner start signals and cancel cleanup * return run on context done or err on channel * async runner Refactors the image runner to start the container asynchronously, reporting back the port on which it started. Errors are communicated back via a provided channel and stop is signaled using context cancelation. * pid neither required nor available * add withTransport option Incorporates addition of custom transport of the emitter into the renamed version invoker. Flag and help text cleanup. Re-additionof the Info accessor. * schema now includes invocation data * loop build msg * run jobs Externally exposed port is now chosen based on availability, with 8080 preferred and falling back to an os-chosen open port. The Client Run method is now async, returning the port assigned to the running Function, a stop/cleanup function and a runtime errors channel. The Runner is internally divided into the runner and its started Jobs. * job metadata Extracts job metadata tracking to a Job object in the core, Handles multiple instances of the same Function by creating a single file for each instances in .func/instances/<port> * remove superfluous error types and flag bindings * feat: enable invoke target remote * feat: preferentially invoke local, remote if running * feat: read --file for invoke * feat: invoke confirm prompts * fixup cli tests - Updates to handle asynchronous Runner - Standardize on the naming convention for selective running * docker runner tests and lint errors * test refactor * feat: invoke format override * comments, spelling and other cleanup * invoke command doc * feat: invoke format interactive option * rename runjob.go to job.go * e2e test flag update * test naming homoginization * silence build activity messages when verbose * test debugging * code review updates - return Job from Client.Run rather than constituent members - Treat .gitignore as contentious, punting on feature to mutate if extant. - docs wording changes - add invocation format to pertinent manifest.yaml files * help text spelling etc. Co-authored-by: Lance Ball <lball@redhat.com> |
||
---|---|---|
.. | ||
guides | ||
knative | ||
provisioning | ||
tls | ||
DEVELOPMENT.md | ||
README.md | ||
getting_started_kubernetes.md | ||
getting_started_localhost.md | ||
installing_cli.md |
README.md
Boson Functions
Telegram Image Analysis Demo Screencast
func
is a Client Library and CLI for enabling the development of implicitly deployed, platform agnostic functions.
Functions can be written in the following languages:
- Go (Golang)
- Node.js (JavaScript)
- Quarkus (Java)
- SpringBoot (Java)
- Python
- Rust
Functions can be deployed on the following platforms:
- Kubernetes
- OpenShift
- Localhost
Client Installation
Functions can be created and managed using the CLI interactively, scripted, or by direct integration with the client library. The Function Developer's Guide and examples herein demonstrate the CLI-based approach.
For direct integration using the Go client library, it is advisible to first follow these CLI-based guides to become familiar with creating and deploying software in this way, and then proceed to the Function Integrator's Guide.
Platform Configuration
Getting Started with Kubernetes
Functions are portable between different infrastructure configurations. While your Function itself remains the same, the platform upon which it is deployed will provide different services and guarantees. For instance, a Function deployed to your local host will not autoscale, nor be highly available nor externally routable by default. Deploying to a properly configured Kubernetes cluster would however provide these features. There is also variance within infrastrucutre types. For instance, a small kubernetes cluster will be limited in the amount of resources which will be ultimately available for allocation to your Function.
Function Development
Any code which provides one of a set of supported function signatures can be deployed to any of the supported platforms using this client library. No process boundary code, container, or configuration outside of the function itself is required.
At their most fundamental, a Function is a set of instructions which export a public function whose method signature conforms to one of the supported forms. It is implicitly deployed to a supported platform when created using the client library, and can be migrated between platforms without code changes. Runtime execution is handled by the platform, which may offer guarantees such as autoscaling and load balancing.
Contributing
We are always looking for contributions to the project from the Function Developer community. For more information on how to participate, see the Development Guide