-
Notifications
You must be signed in to change notification settings - Fork 281
Contact Temporal Support to remove a replica from Namespace with API keys #4030
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
… Namespace with API keys
|
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📖 Docs PR preview links
|
…onal endpoint if using API keys
|
|
||
| <TabItem value="webui" label="Web UI"> | ||
|
|
||
| 1. (if using API keys on this Namespace) Ensure that any Workers or Clients with API keys have been configured to use the [regional endpoint](/cloud/regions) for the Namespace's region. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are there directions on how to do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will link to the updated section that Grant wrote. Does that sound good?
| :::note | ||
|
|
||
| After removing a replica, Temporal Cloud can't re-enable replication for a given Namespace for seven days. | ||
| Namespaces with API keys enabled need assistance from Temporal Support to remove a replica. Please [contact support](/cloud/support#support-ticket) with the Namespace ID of the Namespace on which to remove a replica. You must confirm that Workers and Clients with API keys have been configured to connect to the Namespace using the published [regional endpoint](/cloud/regions). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we're removing this requirement - is this temporary until this is shipped?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, exactly. It sounds like it will be months until we remove this requirement. In the meantime, we are getting a request like this every week or two.
|
Edit, that's merged ✅ |
* added clarifications for API key + high avail * Update docs/production-deployment/cloud/get-started/namespaces.mdx Co-authored-by: Lanie Hei <lanie.b.hei@gmail.com> * Update docs/production-deployment/cloud/get-started/api-keys.mdx Co-authored-by: Lanie Hei <lanie.b.hei@gmail.com> * responded to PR comments --------- Co-authored-by: Lanie Hei <lanie.b.hei@gmail.com>
|
|
||
| ### With High Availability features | ||
|
|
||
| Use the gRPC Namespace endpoint: `<namespace>.<account>.tmprl.cloud:7233`. This allows automated failover without needing to configure worker(s) with both endpoints. These endpoints will still work, but in the event of a failover, there is a brief period of unavailability between your workers and Temporal server. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by both endpoints? Do you mean the regional endpoints for the original namespace and its replica?
When you say there is a brief period of unavailability, do you mean that users will experience this if they manually configured the two regional endpoints? or will it exist regardless even if they use the <namespace>.<account>.tmprl.cloud:7233 endpoint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. I think this rewrite would make more sense:
Use the gRPC Namespace endpoint:
<namespace>.<account>.tmprl.cloud:7233. Using the Namespace endpoint is usually preferred in multi-region architectures, because it allows Workers and Clients to always connect to the active region of the Namespace. When afailoveris triggered and the Namespace's active region changes, Temporal Cloud uses DNS to point this Namespace endpoint to the new active region.
| ``` | ||
|
|
||
| If using API key authentication with the `--api-key` flag, you must add it directly after the tcld command and before `namespace delete-region` | ||
| If using the `--api-key` flag to issue this CLI command, you must add it directly after the tcld command and before `namespace delete-region` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this mean to "Add it directly after the tcld command?" This seems to suggest there is more than 1 command, but we are only showing one command. Do we mean that they must put the --api-key flag in the command?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is only one command. Perhaps:
...directly after
tcldand before...
Co-authored-by: Ben Echols <benjamin.echols@temporal.io>
What does this PR do?
If a Namespace has API keys and replication enabled, and wants to remove the replica, they must switch to regional endpoints and contact Temporal Support to validate that the switch has been done. This was not called out in the docs before. This PR calls it out and explains why this is required.
Notes to reviewers