What's New in Acorn Runtime v0.10

We are thrilled to announce the release of Acorn Runtime v0.10.0, bringing a host of new features, enhancements, and bug fixes. Before diving into these updates, let's address some housekeeping matters that mark a significant shift in our project's identity.

We've officially renamed our project from acorn-io/acorn to acorn-io/runtime. This change is more than just a rebranding; it aligns the project's nomenclature with its core functionality. Acorn Runtime is the open-source heart of the broader Acorn platform, which serves as a comprehensive application platform. The platform, simply referred to as "Acorn," enables development teams to swiftly deploy applications with minimal hassle.

Beyond the name adjustment, we've undertaken a substantial restructuring of our documentation for improved clarity and accessibility. The documentation is now divided into two distinct sites:

• Runtime Installation and Operations Docs: This site is for operators and admins focused on installing and operating the Acorn Runtime. Explore it at https://runtime-docs.acorn.io.
• Acorn End-user Docs: This site is for developers looking to build and deploy apps using Acorn. It is available at https://docs.acorn.io.

Our goal is to empower end-users with seamless app deployment, eliminating the need to know about underlying infrastructure technologies like Kubernetes. Simultaneously, administrators and operators can access comprehensive information to install and operate Acorn Runtime within their own Kubernetes clusters.

This release marks an important moment in the evolution of Acorn Runtime, aligning our project's identity with its fundamental purpose and enhancing user experience through streamlined documentation. Now, let’s take a look at the new features that landed in v0.10.0

ComputeClass over-provisioning

With this feature, administrators can configure computeClasses with a requestScaler value. This will cause the memory and cpu requested to be scaled down based on the value set. For example, if the computeClass in use has its requestScaler value set to .1 and a user creates an app requesting 2 GiB of memory, the corresponding pod that is created will have its memory request field set to .2 GiB. However, the memory limit will remain the full 2 GiB. Note that since CPU request is a function the amount memory requested and the computeClass's cpuScaler, it is also scaled down proportionally. Here's a sample computeClass that leverages request scaling to achieve over-provisioning:

kind: ClusterComputeClassInstance
apiVersion: internal.admin.acorn.io/v1
metadata:
    name: sample-compute-class
description: Simple description for a simple ComputeClass
cpuScaler: 0.25
memory:
  min: 1Mi
  max: 2Gi
  default: 2Mi
  requestScaler: .2

More details can be found here.

ComputeClass generic resource fields

Thanks to community user dciangot for this contribution! With this feature, administrators can now configure computeClasses with any kind of resources allowed by Kubernetes' corev1.ResourceRequirements while keeping these ugly details hidden from users. This enables interesting use cases such as supporting GPU-based nodes. Here's example:

kind: ClusterComputeClassInstance
apiVersion: internal.admin.acorn.io/v1
metadata:
  name: gpu
description: Simple description for a simple ComputeClass
cpuScaler: 0.25
memory:
  min: 1Mi
  max: 2Mi
  default: 1Mi
resources:
  limits:
    gpu-vendor.example/example-limit: 1
  requests:
    gpu-vendor.example/example-request: 1

For a developer to use this and thus get their workload scheduled to a GPU node, they just need to run:

acorn run --compute-class gpu .

Ignoring resource requirements

We've introduce a new flag that will cause your acorn runtime to ignore all resource requirements on acorns being launched. This is useful if your Acorns define resource requests appropriate for production environments, but you want to easily spin them up locally and don’t have enough resources to accommodate them. Here's what using the flag looks like:

acorn install --ignore-resource-requirements flag added

Support for user directive in container definitions

You can now specify the user and group that acorn workloads should run as like so

containers: app: {
    image: "some/image:v1"
    user: "1000:1000"
}

This will translate to containerSecurityContext.RunAsUser and RunAsGroup in the pod specification. This is useful if your container image is designed to run as a specific non-root user.Fore the more details, see the docs here.

Credential secret prompting

These secrets are similar to to the existing opaque type because they can hold any data you need, but they provide helpful UX to the end user by displaying instructions and prompting the user for the values. Here's an example Acornfile that leverages this new feature:

secrets: "app-credential": {
    type: "credential.openai.com/gpt4"
    params: {
        instructions: localData.instructions
    }
    data: {
		apikey: "",
		secretkey: ""
    }
}

localData: instructions: """
# API and Secret Key

Please supply your API and Secret key obtianed from Acme Web Services
"""

containers: app: {
    image: "ubuntu"
    entrypoint: ["sleep"]
    command: ["3600"]
    env: {
        API_KEY: "secret://app-credentials/apikey"
        SECRET_KEY: "secret://app-credentials/secretkey"
    }
}

And here's what interacting with that looks like:

$ acorn run .
...
API and Secret Key
Please supply your API and Secret key obtianed from Acme Web Services

apikey ****
secretkey ****

More details here.

App and secret editing commands

We've introduced two new commands to the CLI:

acorn edit [app-name]
acorn secret edit [secret name]

With these commands, you can now easily edit applications and secrets. When editing an application, you'll be able to edit the values you set when launching the app, like the image, environment variables, and deploy arguments.

Wrapping Up

That wraps up this overview of the new features in the Acorn v0.10 release. For the full changelog and additional details, please checkout our release notes.

As always, you can reach us on Github, [Slack(https://slack.acorn.io/)], Twitter, and LinkedIn with feedback or questions! Please join us for one of our live trainings if you’d like to get a hands-on overview of Acorn.

Craig Jellick is Director of Engineering at Acorn Labs. He has extensive experience building and supporting teams that build and support open source infrastructure and developer tools. You can follow him on Twitter or connect on LinkedIn.