Remote clusters missing use cases and structural changes #4170
Conversation
Vale Linting ResultsSummary: 4 suggestions found 💡 Suggestions (4)
|
eedugon
changed the title
shainaraskas
left a comment
shainaraskas
left a comment
There was a problem hiding this comment.
wow, tons of great work here. I really like your attention to detail with the cluster vs. deployment variables.
added some comments mostly around style - would question your decision to place the self-managed to ECK page where you placed it though.
otherwise, as long as eck eng says it looks good, this works for me.
| remote_type: ECK-managed | ||
| --- | ||
|
|
||
| # Connect a self-managed {{es}} cluster to an ECK-managed cluster [self-to-eck-remote-clusters] |
There was a problem hiding this comment.
if this is only applicable to self-managed deployments as your title implies, I believe this should be in this section (Remote clusters on self-managed installations) instead, and just be linked to from the ECK overview. our other sections are all sorted by the local cluster, and this is the exception
(unless you have a specific reason)
There was a problem hiding this comment.
I was planning to move it eventually to self-managed in the TOC at a later stage, as self-managed remote clusters docs haven't been refined or touched at all yet.
Maybe you can help me with a loose end that I left indirectly related with this.... (we can discuss in private also)
The seed of this doc was originally the section called Connect from an Elasticsearch cluster running outside the Kubernetes cluster in the original / unique doc. That original doc only covered TLS-based auth for self-managed or an external ECK towards ECK.
The content now is 95% applicable to sefl-managed -> ECK only, except the TLS based authentication (deprecated) where we consider that the remote could be managed by a different ECK operator (this is a small flaw I've left because I wasn't finding a better solution).
inter-ECKs remote clusters is covered for API key based auth in the new to external doc, but I didn't want to implement in that doc the TLS-based auth (as it would become very complex), so TLS based auth is covered for inter-ECKs is covered here without highlighting it much (it's probably not a good practice to implement it considering we now have API key based auth).
There was a problem hiding this comment.
@shainaraskas , I think I now have a good plan to solve what is concerning me in a much nicer way, I'll share something on Monday. In short:
-
I'll move this doc to
self-managedsection, and it will be focused only in self-managed --> ECK (without that exception I shared that considered inter-ECKs conf). -
I'll create a new doc "Connect Elasticsearch clusters in different ECK environments" where we will exclusively focus on that use case. IMO this is probably a common use case, more than mixing deployment types, and it deserves such a doc. It would be also similar to what we have with ECE and ECH when we talk about same ECE / different ECE or same ORG / different ORG.
-
The "Connect to external clusters" will be focused on connecting to either ECE/ECH or self-managed, and I'll remove a different ECK from that doc, as that will be covered in the previous doc.
| --> | ||
| To add a remote cluster, use the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings). Configure the following fields: | ||
|
|
||
| * `Remote cluster alias`: When using API key authentication, the cluster alias must match the one you configured when adding the API key in the Cloud UI as **Remote cluster name**. |
There was a problem hiding this comment.
I think this nuance about the cloud ui is helpful because it's hard to make the connection between the source value and target value. I realize it doesn't make sense in the new context, but consider trying to figure out a way to make it work
There was a problem hiding this comment.
yeah, I removed it to be able to reuse the snippet..... and I knew we were going to lose this bit of context :)
What if we add a link to a local anchor in when adding the API key so we can link to the relevant section in each of the docs? and we make sure the anchor name is the same in all docs using the snippet so the reader is redirected to the right section (configure the local cluster).
Or do you prefer to leave the text as it was and not reusing this snippet?
|
|
||
| * **Remote cluster name**: This *cluster alias* is a unique identifier that represents the connection to the remote cluster and is used to distinguish local and remote indices. | ||
|
|
||
| When using API key authentication, this alias must match the **Remote cluster name** you configured when adding the API key in the Cloud UI. |
There was a problem hiding this comment.
same here. this detail was helpful.
| ### On the remote cluster [remote-clusters-security-api-key-remote-action] | ||
|
|
||
| 1. Enable the remote cluster server on every node of the remote cluster. In [`elasticsearch.yml`](/deploy-manage/stack-settings.md): | ||
| #### Enable and secure the remote cluster server interface |
There was a problem hiding this comment.
this should get a little intro paragraph
| If the local cluster is part of an {{ech}} or {{ece}} deployment, and the remote cluster is managed by ECK, refer to: | ||
| - [](./ec-enable-ccs-for-eck.md) | ||
| - [](./ece-enable-ccs-for-eck.md) | ||
|
|
||
| For other remote cluster scenarios with ECK, refer to [Remote clusters on ECK](./eck-remote-clusters-landing.md). |
There was a problem hiding this comment.
IMO you don't have to directly link to the ECE/ECH instructions here. you can just link out to the remote clusters on eck overview page.
| Consider the following example: | ||
|
|
||
| * `remote-cluster` resides inside Kubernetes and is managed by ECK | ||
| * `local-cluster` is not hosted inside the same Kubernetes cluster as `remote-cluster` and might not even be managed by ECK |
There was a problem hiding this comment.
can we refine this sentence for its context
deploy-manage/remote-clusters/eck-remote-clusters-from-external.md
Outdated
Show resolved
Hide resolved
Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>
|
I'm removing temporary @elastic/cloud-k8s reviewing request, as we're planning to introduce some extra changes. Apologize for that. |
This PR addresses some missing use cases on Remote Clusters with ECK.
Due to the missing use cases and the fact that originally we only had one doc in the Remote Clusters ECK section we have updated the structure to contain:
Addresses the following issues:
We explicitly address:
I've tried to use snippets when possible, that's why other docs are being reported as updated, the changes in other docs are minor.
MAIN DOCS TO REVIEW BY ECK DEVS
New landing page: deploy-manage/remote-clusters/eck-remote-clusters-landing.md
Original doc, now only intra-ECK: deploy-manage/remote-clusters/eck-remote-clusters.md
New doc: deploy-manage/remote-clusters/eck-remote-clusters-to-external.md
From external (with API key + TLS): deploy-manage/remote-clusters/eck-remote-clusters-from-external.md