Fixing errors about Namespace connectivity and best practices #4127
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📖 Docs PR preview links
|
| - A Namespace is provisioned with [endpoints](constraints-and-limitations) for executing your Workflows. Accessing a Namespace from a Worker or Temporal Client | ||
| requires [API keys](/cloud/api-keys) or [mTLS](/cloud/certificates) authentication. | ||
| - [Workflow Id](/workflow-execution/workflowid-runid#workflow-id)uniqueness is per Namespace. | ||
| - Every [Workflow Id](/workflow-execution/workflowid-runid#workflow-id) in a Namespace must be unique. Workflow Ids in different Namespaces may be the same. |
There was a problem hiding this comment.
Should probably point out that only open workflow requires this uniqueness constraints. You can have multiple closed workflows with the same ID.
bechols
left a comment
bechols
left a comment
There was a problem hiding this comment.
Lots of small comments/suggestions, but this is a big improvement.
| the system. A Namespace's default limit is set at 400 APS and automatically adjusts based on recent usage (over the | ||
| prior 7 days). Your APS limit will never fall below this default value. | ||
| the system. | ||
| - Each Namespace's default limit is set at 400 APS and automatically adjusts based on recent usage (over the |
There was a problem hiding this comment.
I think default APS limit is 500 now - updated as we're rolling out capacity units. Worth double checking with TLo but good to fix since we're touching the line.
| permitted at the Namespace level. Isolating applications or environments (development, test, staging, production) | ||
| should take this into consideration. | ||
| - A Namespace is provisioned with an endpoint for executing your Workflows. Accessing a Namespace from a Temporal Client | ||
| - A Namespace is provisioned with [endpoints](constraints-and-limitations) for executing your Workflows. Accessing a Namespace from a Worker or Temporal Client |
There was a problem hiding this comment.
| - A Namespace is provisioned with [endpoints](constraints-and-limitations) for executing your Workflows. Accessing a Namespace from a Worker or Temporal Client | |
| - A Namespace exposes [endpoints](constraints-and-limitations) for executing your Workflows. Accessing a Namespace from a Worker or Temporal Client |
| - A Namespace is provisioned with [endpoints](constraints-and-limitations) for executing your Workflows. Accessing a Namespace from a Worker or Temporal Client | ||
| requires [API keys](/cloud/api-keys) or [mTLS](/cloud/certificates) authentication. | ||
| - [Workflow Id](/workflow-execution/workflowid-runid#workflow-id)uniqueness is per Namespace. | ||
| - Every [Workflow Id](/workflow-execution/workflowid-runid#workflow-id) in a Namespace must be unique. Workflow Ids in different Namespaces may be the same. |
There was a problem hiding this comment.
Do we use Id (rather than ID) everywhere?
| - Namespaces should be used to reduce the "blast radius" for mission-critical applications. | ||
| - Workflows that need to communicate with each other should (for now) be in the same Namespace. | ||
| - If you need to share Namespaces across team or domain boundaries, be sure to ensure the uniqueness of Workflow Ids. | ||
| - Environments such as production and development usually have requirements for isolation. We recommend that each |
There was a problem hiding this comment.
Link to (and/or replace in favor of) https://docs.temporal.io/best-practices/managing-namespace#organizational-patterns ?
| key and mTLS authentication to be enabled on your Namespace, please contact | ||
| Temporal Cloud supports authentication to Namespaces using [API keys](/cloud/api-keys) _or_ | ||
| [mTLS](/cloud/certificates). To migrate a Namespace from one authentication method to another, or to use both API | ||
| key and mTLS authentication one the same Namespace, please contact |
There was a problem hiding this comment.
| key and mTLS authentication one the same Namespace, please contact | |
| key and mTLS authentication on the same Namespace, please contact |
| - This endpoint is unique to each Namespace. It will always connect to the Namespace, no matter which region(s) the Namespace is using. (Recommended for Namespaces with High Availability) | ||
| - A Temporal Client that uses a Namespace endpoint doesn't have to be aware of which region the Namespace is in. | ||
| - Restrictions: | ||
| - If [High Availability](/cloud/high-availability) is not enabled, then accessing a Namespace via API key + Namespace endpoint is not supported. To use the Namespace endpoint with API keys, a Namespace must have [High Availability](/cloud/high-availability) enabled. |
There was a problem hiding this comment.
But this is changing soon, right?
| ::: | ||
|
|
||
| For information on how to connect to Clients using a specific authentication method see the following documentation. | ||
| ### Configuring a Temporal Client with API keys or mTLS |
There was a problem hiding this comment.
I think Temporal Client usually means a Temporal SDK that's interacting with workflows (i.e. https://docs.temporal.io/develop/typescript#temporal-client)
Authing to tcld, Cloud Ops, TF etc doesn't happen from a Temporal Client so this is a bit off (I realize it was already like this, and there's a decent change git blame would show me touching this last).
| ### Configuring a Temporal Client with API keys or mTLS | |
| ### Authenticating with API keys or mTLS |
| ### Configuring a Temporal Client with API keys or mTLS | ||
|
|
||
| - To use API keys to connect with the [Temporal CLI](/cli), [Client SDK](/develop), [tcld](/cloud/tcld), | ||
| To use API keys to connect with the [Temporal CLI](/cli), [Client SDK](/develop), [tcld](/cloud/tcld), |
There was a problem hiding this comment.
Minor: risk of drift vs the list at https://docs.temporal.io/cloud/api-keys#api-key-supported-tooling
| ### Accessing the Temporal Web UI | ||
|
|
||
| For accessing the Temporal Web UI, use the HTTPS endpoint in the form: | ||
| `https://cloud.temporal.io/namespaces/<namespace>.<account>`. For example: |
There was a problem hiding this comment.
We're not consistent but do define <namespace>.<account> as the Namespace Id https://docs.temporal.io/cloud/namespaces#temporal-cloud-namespace-id
| - Set up your allow list for outgoing network requests from your Clients and Workers with the IP address ranges of the | ||
| For enhanced protection: | ||
| - Set up [private connectivity](/cloud/connectivity#private-network-connectivity-for-namespaces) to the Namespace. | ||
| - In your own networking architecture, set up an allow list for outgoing network requests from your Clients and Workers with the IP address ranges of the |
There was a problem hiding this comment.
Needs to cover multiple regions if it's a HA namespace
What does this PR do?
Fixes some errors on the Namespace "General Guidance" section and on the "Connecting to your Namespace" section.
Notes to reviewers