Author:

Dominik Tornow, temporal.io

Summary of the feature being proposed

Split the current "Catch-All" Kubernetes Helm Chart into two different templates:

• to kickstart the setup of a Temporal development environment on Kubernetes
• to kickstart the setup of a Temporal production environment on Kubernetes

What value does this feature bring to Temporal?

Temporal's official Helm Chart needs some tender love and care:

• too many question marks regarding objective (Catch-All)
• too many question marks regarding open github pull requests

Temporal.io proposes two objectives

• to kickstart the setup of a Temporal development environment on Kubernetes
• to kickstart the setup of a Temporal production environment on Kubernetes

All open and future pull requests will be evaluated against these objectives

Development Setup Experience Kickstarter

Note Temporal Application Developement is diffrent from Temporal Development. This proposal addresses Temporal Application Development only.

Guiding Principal

• Batteries included
  • Will just work, does all the heavy lifting

Mechanism

• Vanilla Kubernetes! Kubernetes Resource File temporal.yaml, kubectl
• No customizations

Proposal

• Provide one temporal.yaml file that installs Temporal and its dependencies on a K8s Cluster in the default namespace without customizations.
• In effect, temporal.yaml provides the same experience as docker-compose.yml for Kubernetes as target

Production Setup Experience

Note Setup is different from Operations, therefore, a Setup Experience is different from a Da1 or Day 2 Operation Experience. This proposal addresses Setup Experience only.

Guiding Principal

• Batteries not included
  • Will get you started, does some of the lifting

Mechanism

• Vanilla Kubernetes + Helm! Minimal Helm Chart, helm
• Minimal Customization Options

You are expected to fork and customize

Proposal

• Provide 3 minimal Helm Charts with minimal Customization Options
  • Core
  • Web
  • Admin
• Provide instructions on Temporal's dependencies
  • Provide instructions how to configure Temporal's dependencies
  • Provide guidance on scaling metrics and scaling parameters
  • Provide guidance on security

DO NOT

• Install any dependencies
  • No installation of Cassandra
  • No installation of Postgres
  • No installation of Elastic
• Configure any dependencies
  • No creation of schemas
  • No creation of indices

Are you willing to implement this feature yourself?

The Temporal team with input from community

Author: @robzienert

Summary of the feature being proposed

Support mTLS certificates being refreshed.

What value does this feature bring to Temporal?

This would help organizations that use short-lived, rotating mTLS certificates adopt Temporal. Users of Hashicorp Vault, Amazon CM, or other technologies would find this particular proposal useful.

Our specific use case refreshes certificates every T minutes in /dev/shm. I'm open to specifics of implementation (file watch, polling, etc).

Are you willing to implement this feature yourself?

Yes.

Author: Babak

Summary of the feature being proposed

Implement a SDK for Python

What value does this feature bring to Temporal?

I think many companies (including ourselves) are using Python as their main scripting/programming language. Also in some areas like DevOps and Data Science (that are two important potential areas for Temporal) using Python as a convenient scripting language is so popular. I think providing Python and other popular languages SDKs makes a big leap in Temporal customers.

Are you willing to implement this feature yourself?

Unfortunately I don't have the resources. It will be good if there exists any sample tutorial/reference implementation for implementing Temporal SDKs (language agnostic or not). Also i (and probably future viewer of this issue) am willing to contribute to Python SDK project if you start that.

Author: Dominik Tornow

Summary of the feature being proposed

1. Admission Controllers

Provide Temporal Admission Controllers, similar to Kubernetes Admission Controllers, that intercept requests to Temporal before they get processed

Admission Controllers come in two flavors:

• Validating Admission Controller
• Mutating Admission Controller

Validating Admission Controllers may not alter a request, Mutating Admission Controller may alter a request.

2. Admission Workflows & Activities

Enable developers to implement Admission Controllers as Temporal Workflows and Temporal Activities, therefore enabling the developer to extend Temporal with Temporal.

What value does this feature bring to Temporal?

Admission Controllers have proven to be a surprisingly simple yet surprisingly powerful extension mechanism for Kubernetes, they may prove to be a simple yet powerful extension mechanism for Temporal

1. Example, Validating Admission Controller

The user may define a Validating Admission Controller that rejects a StartWorkflowExecutionRequest if the workflow_id does not match some regex

2. Example, Mutating Admission Controller

The user may define a Mutating Admission Controller that implements a simple versioning strategy:

• Initially, the Admission Controller modifies every StartWorkflowExecutionRequest of type Foo to Foo-v1
• Later, the Admission Controller modifies every StartWorkflowExecutionRequest of type Foo to Foo-v2

Are you willing to implement this feature yourself?

The temporal team

Author: Ruslan Aksenov

Summary of the feature being proposed

Create a new repo for tctl CLI and decouple it from the server

What value does this feature bring to Temporal?

Supports better coding practices by decoupling responsibilities. Limits possibilities for bugs since the CLI will only work with the official SDK and not have access to the server code directly. Streamlines coding practices on CLI side

Are you willing to implement this feature yourself?

Yes

Author: Ruslan Aksenov

Summary of the feature being proposed

Create a configuration file to store the default values

What value does this feature bring to Temporal?

As a user i want to be able to change the default option values, such as the default --namespace value

Are you willing to implement this feature yourself?

Yes

Example proposal

Author: Ryland Goldstein

Summary of the feature being proposed

This is a made up feature I made for the sake of this proposal. This made up feature will double the jigaflops of our flux resistors enabling FTL workflow processing.

What value does this feature bring to Temporal?

Workflows now complete instantly. In some cases workflows can now complete faster than instantly which is accomplished through our uranium powered prediction service.

Are you willing to implement this feature yourself?

Unfortunately I'm not an advanced particle physicist so I will not be implementing this feature myself.

Author: Drew Hoskins

Summary of the feature being proposed

• Can we retain data offset from the start of the workflow rather than its closure?
• Can we have published guidance on how long the deletion takes so we can assess the compliance of retention policies?

Secondary helpful ideas:

• Have per-workflow type retention policies rather than just per-namespace so that we don't have to create a separate namespace for each different retention policy?
• Validate if workflow timeouts are longer than the namespace's retention policy as a sanity check.

What value does this feature bring to Temporal?

Compliance/regulatory regimes typically dictate data retention for sensitive information. One can either adhere to, or avoid being subject to, such regimes using data retention. For example,

• Certain categories of Indian nationals' data cannot be exfiltrated from India and persisted for more than 24 hours. Because one can't have a retention policy of less than 1 day, it's currently impossible to exfiltrate Indian nationals' data in a compliant way and have it stored in Temporal metadata.
• Per GDPR, data takedown requests for Personally-identifiable information (PII) must be processed within N days (and one can avoid needing to process takedown requests at all by having a retention policy that's within that limit). Supposing a 30 day limit: allowing a 30 day policy from workflow start would be more straightforward and understandable by users. It would also avoid games like "run the workflow for up to 3 weeks and then allow 9 days of retention." This isn't ideal: for example, when the workflow finishes instantly, it is only retained for 9 days when you'd rather retain it longer for debuggability.

For this to work, the retention policy should mean (and be documented to mean) that the data will be deleted by that point (assuming the server is up and operating normally) vs just being scheduled for later deletion when the retention window lapses.

Are you willing to implement this feature yourself?

Not sure. We don't have much experience editing temporal-server, but I wouldn't rule it out, given sufficient guidance from the core team.

Author: Ruslan Aksenov

Summary of the feature being proposed

Move namespace option from global options to command options

before:

tctl --namespace test1 workflow run --input "{}"

after

tctl workflow run --namespace test1 --input "{}"

What value does this feature bring to Temporal?

Simplifies the usage of command line by having options under the same command and help of that command. As a user i won't have to find how to specify the namespace as well since i will immediately see --namespace option with the rest of the options.
Makes semantics of the commands a bit nicer by positioning options after the command, not before

Are you willing to implement this feature yourself?

Yes

Author: Ruslan Aksenov

Summary of the feature being proposed

Refactor and improve a number of items in CLI, such as semantics, commands discoverability, integration with bash/zsh, rethink global vs command options, improve UI, support config file for default option values

What value does this feature bring to Temporal?

Makes the Temporal CLI friendlier for both new and experienced users

Are you willing to implement this feature yourself?

Yes

Author: Ruslan Aksenov

Summary of the feature being proposed

Replaces all underscores used in commands and options as delimiters with hyphenes

before:

tctl activity complete --workflow_id <uuid>

after

tctl activity complete --workflow-id <uuid>

What value does this feature bring to Temporal?

This is common practice in command lines. Users are typically used to hyphens and don't expect having to switch to underscores when typing options

Are you willing to implement this feature yourself?

Yes

Author:

Summary of the feature being proposed

Adding support to use serverlessworkflow definitions as DSL for temporal

What value does this feature bring to Temporal?

we can use existing systems and tooling to create DSL to work on temporal

Are you willing to implement this feature yourself?

Yes im willing to work on creating an implemention for the serverless workflow to work with the GO-SDK

Author:

Summary of the feature being proposed

A C#/.Net SDK for Temporal

What value does this feature bring to Temporal?

Wider reach - .Net is one of the most popular development platforms around

Are you willing to implement this feature yourself?

Unfortunately I'm not familiar enough with Temporal's inner workings to even begin to attempt that. I have come across this implementation in progress but it is currently in alpha

Would love to see a Dart/Flutter SDK!

Author: Ruslan Aksenov

Summary of the feature being proposed

Allow operations to run on multiple entities by providing multiple identifiers or by filtering entities by a query
Running on single entity

tctl workflow terminate {options} id1

Running on multiple entities by providing a list of ids

tctl workflow terminate {options} id1 id2 id3

Running on multiple entities by providing providing filter query

tctl workflow terminate {options} --filter 'started > 1 day ago'

What value does this feature bring to Temporal?

Allows to write commands executing operations on multiple entities in one line

Are you willing to implement this feature yourself?

Yes

Author: Linas Valiukas

Summary of the feature being proposed

Given that the unofficial SDK by @firdaus is going to be no longer supported by the author, I'd like to propose rolling out a new Python SDK based on the Rust SDK (https://github.com/temporalio/sdk-core).

What value does this feature bring to Temporal?

• SDK in the second most popular programming language

Are you willing to implement this feature yourself?

Depends - I'd like to learn more about what implementing such a Python SDK would entail.

Author: Fulvio Tozzo

Summary of the feature being proposed
We'd like to restrict read/write access to Temporal task queues based on micro service identity to control who can do what.
To implement this we'd like to leverage on an out-of-the-box feature delivered by Temporal.

This proposal follows this conversation
https://community.temporal.io/t/authorization-on-task-queue/4780

What value does this feature bring to Temporal?
This feature would make Temporal more secure and would facilitate its adoption in environments where security is paramount without the need of creating a security exception approved by CISO.

Are you willing to implement this feature yourself?
Not in the short term as we do not have GO know how nor development capacity to dedicate to this task

Author: Ruslan Aksenov

Summary of the feature being proposed

Limit tctl commands to a maximum of 2 levels nesting.
before

tctl workflow activity complete {options}

after

tctl activity complete {options}

What value does this feature bring to Temporal?

As a user i want to easily find commands i'm interested in. Less nesting leads to easier discovery

Are you willing to implement this feature yourself?

Yes

Author: Dominik Tornow, Ruslan Aksenov

Summary of the feature being proposed

• Extend tctl with plugins (like kubectl)
• Eventually, provide a plugin directory (like krew)

What value does this feature bring to Temporal?

tctl provides the core apis to interact with temporal. tctl plugins provide additional behaviors, possibly combining and/or extending the core apis.

A tctl plugin is a standalone executable, whose name is prefixed with tctl-, located anywhere on the PATH. For example, the command tctl foo will invoke the plugin tctl-foo if the executable tctl-foo is located anywhere on the PATH.

Example: Plugin tctl-foo

#!/bin/bash

# optional argument handling
if [[ "$1" == "version" ]]
then
    echo "1.0.0"
    exit 0
fi

echo "I am a plugin named tctl-foo"

$ tctl foo version
> 1.0.0

$ tctl foo
> I am a plugin named tctl-foo

Note

Any Similarities with kubectl are completely and entirely not accidental.

Are you willing to implement this feature yourself?

The temporal team

Author: Ruslan Aksenov

Summary of the feature being proposed

Standardize words to be used in CLI. Implement the changes

What value does this feature bring to Temporal?

As a user i want the CLI API to be consistent, so that it is easier to remember commands and less chances to mix up the words

Are you willing to implement this feature yourself?

Yes

Author: Greg Haskins

Summary of the feature being proposed

Introduce first-class support for REGO as an Authorizer to augment the current Noop and Default Authorizers. In this model, users opting into the new Authorizer may do so purely with configuration/rego without implementing a custom Plugin and the requisite custom build that it implies.

OPA already offers a Go SDK, so it is a natural fit for the Temporal ecosystem.

The proposal would be to add a new "opa" type to augment the existing "" (noop) and "default" Authorizers. Users configuring the "opa" Authorizer must supply additional configuration as a rego document. A rego policy that equates to the current "default" Authorizer will minimally be provided as an example. Additional examples may be included, as well.

The ability to override any built-in Authorizer with a plugin will be retained as it currently functions.

What value does this feature bring to Temporal?

1. Users may customize the Authorizer logic without requiring a custom build of Temporal.
2. Users may express their Authorizer logic by leveraging the power of REGO, a fit-for-purpose policy grammar.

Are you willing to implement this feature yourself?

Yes

Author: Brendan

Summary of the feature being proposed

Implement a Typescript sdk for Nodejs

What value does this feature bring to Temporal?

broadens the number of companies that would consider using temporal, especially those running primarily on nodejs.

Are you willing to implement this feature yourself?

Unfortunately I don't have the resources.

Author: Loren

Summary of the feature being proposed

Add two capabilities:

• Allow subscriptions to raw Event History events via gRPC streaming
• Provide UI for configuring notification triggers (and the backend that stores and executes them):
  • Flexible condition builder
  • Flexible trigger action (webhook, email, sms, slack)

What value does this feature bring to Temporal?

Users want to be able to receive a push notification when something happens. For example, when a Workflow times out, they want to receive that event with information about the Workflow, like its ID and history.

The current methods of getting this are:

• A count metric (not helpful for knowing which workflow timed out):
  • Open-source server metric: https://github.com/temporalio/temporal/blob/5ab8ab804fa3e0998f419260b4424154419428d9/common/metrics/defs.go#L2763
  • Cloud metric: temporal_cloud_v0_workflow_timeout_count
• Polling ListWorkflowExecutions for Executions in a Timed Out state (note: polling may take more steps and be more resource-intensive to do for other types of events)

Are you willing to implement this feature yourself?

Yes but I'd be pretty slow at the Go part 😄