[Remote clusters] Fix handling of remote clusters with deprecated proxy setting

[alisonelizabeth]

This PR fixes two issues that came up while testing remote clusters with proxy mode on cloud (implemented via #59221).

• In order to successfully "upgrade" a remote cluster with the v1 proxy implementation, the deprecated proxy setting must be set to null on PUT _cluster/settings.
  • The same logic needs to be applied when deleting a remote cluster with the v1 proxy implementation
• The server_name field does not exist in the v1 proxy implementation. The UI attempts to resolve this by creating a server name using the proxy address, minus the port.

How to test

1. Modify the responses in get_route.ts to simulate a cluster with deprecated settings.

Example:

Insert after L20:

    clusterSettings.persistent.cluster.remote.deprecation_test = {
      proxy: '127.0.0.1:9300',
      seeds: ['127.0.0.1:9300'],
    };

Insert after L29:

   clustersByName.deprecation_test = {
     seeds: ['127.0.0.1:9300'],
     connected: false,
     num_nodes_connected: 0,
     max_connections_per_cluster: 3,
     initial_connect_timeout: '30s',
     skip_unavailable: false,
   };

2. Go to the remote clusters UI and edit the cluster.
3. Verify the Server name input has a value.
4. Since this is only mocked data, the request will fail. However, you should be able to view the request flyout and verify that the proxy field is set to null.

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)

[alisonelizabeth]

/cc @juliocamarero

[cjcenizal]

Tested locally, code LGTM!

Just had a question about this:

The server_name field does not exist in the v1 proxy implementation. The UI attempts to resolve this by creating a server name using the proxy address, minus the port.

The UI marks this field as optional. Is this a mistake? Or, if it is optional, do we need to create one per the note above?

[alisonelizabeth]

@cjcenizal Thanks for the review!

Just had a question about this:

The server_name field does not exist in the v1 proxy implementation. The UI attempts to
resolve this by creating a server name using the proxy address, minus the port.

The UI marks this field as optional. Is this a mistake? Or, if it is optional, do we need to create one per the note above?

This was a suggestion from the cloud team. I followed-up with them again regarding it. It is technically optional via the ES cluster settings API, but it is required for the cloud proxy to work correctly. WDYT?

---

Also, I realized that there will be the same bug when deleting a remote cluster with the v1 proxy implementation, so I pushed a commit that resolves this as well and updated the PR description.

[cjcenizal]

@alisonelizabeth As a short-term solution I think we should look at this part of the UI through the eyes of a Cloud user and remove the "Optional" note from the label. Otherwise what we're telling them won't reflect the underlying model. Ideally we can use the Cloud plugin to determine if we're on Cloud or not, and conditionally render the "Optional" note (and conditionally validate that the user has provided a name). If this is too much work for FF, then I think we can just remove it for now.

I think we should also ask Cloud if there's a way to solve this on their side (either by deriving a name just-in-time the way we're doing here, or by using some other identifier). If they can do this then we can reduce complexity in this UI by removing the above conditions and just making the field optional.

[alisonelizabeth]

@cjcenizal makes sense 👍. For this PR, I removed the (optional) label.

Also, just to clarify, the derived name would only be used in the edit flow when the cluster was created pre-7.6 and used the deprecated proxy setting. When creating a new remote cluster, this field would be blank and it would be up to the user to define.

[alisonelizabeth]

@cjcenizal I'm going to leave the implementation as is for now. I think this will be a less-traveled path, and it would be helpful to get user feedback before deciding to make any further changes. I've chatted with @juliocamarero about this and he is OK with the current direction for now.

[cjcenizal]

@alisonelizabeth Sounds good! Thanks.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 83cb6fd

History

• 💔 Build #36223 failed ac7857a
• 💚 Build #36216 succeeded fac50af
• 💔 Build #35933 failed b2d2687
• 💔 Build #35914 failed 2663764

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream