Skip to content
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

[Remote clusters] Add support for proxy mode #59221

Conversation

alisonelizabeth
Copy link
Contributor

@alisonelizabeth alisonelizabeth commented Mar 3, 2020

Summary

Fixes #58927

Items to note:

  • There is a deprecated way to specify "proxy" mode for a remote cluster. This will not be handled by ES on upgrades, as it would involve deleting a user's settings, which is not ideal. The deprecated way was also undocumented. The UI attempts to detect if the cluster settings contain the deprecated setting, and warn the user. In edit mode, if the user saves the cluster, it will be saved using the new format. I have tested this with mocked data, but need to also coordinate with the cloud team to verify behavior.
  • Both the server_name and deprecated proxy field are not available via the GET /_remote/info API, so we need to access them via cluster settings. I only check persistent settings, based on a previous conversation here: [CCR] Remote clusters settings sources #26067 (comment). I tried to document this in the code, but please let me know if there are any questions or if it is unclear.
  • sniff (default) and proxy modes have different settings. To simplify the table view, I generalized the column names, e.g., "Addresses" maps to proxy_address for "proxy" mode and seeds for "sniff" mode. On the details panel, however, I use the more specific description, e.g., "Proxy address" and "Seeds".

Release note

The Remote Clusters UI added support for enabling "proxy" mode when creating or editing a remote cluster. This feature aligns with Elasticsearch's support for remote cluster connection modes that was added in 7.6.

How to test

You will need to set up two clusters in order to test remote clusters. For example:

yarn es snapshot
yarn es snapshot -E cluster.name="my_cluster" -E http.port=9201 -E path.data=/tmp/es (in another tab)

Test cases:

  • Create a remote cluster using the default mode

  • Create a remote cluster with the "proxy" mode enabled

  • Verify detail panel for both clusters

  • Verify edit and delete actions

  • Modify the responses in get_route.ts to simulate a cluster with deprecated settings, and verify icon displays in table and callout appears on the detail panel and edit route.

    • Example mock data:
        // [TESTING ONLY] mock remote cluster with deprecated settings
        clusterSettings.persistent.cluster.remote.deprecation_test = {
          proxy: '127.0.0.1:9300',
          seeds: ['127.0.0.1:9300'],
        };
    
      // [TESTING ONLY] mock remote cluster with deprecated settings
       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,
       };
    
    

Screenshots

Screen Shot 2020-03-13 at 11 28 24 AM

Screen Shot 2020-03-13 at 11 28 12 AM

Screen Shot 2020-03-13 at 11 27 38 AM

Proxy mode enabled
Screen Shot 2020-03-13 at 11 27 09 AM

Deprecation warnings
Screen Shot 2020-03-13 at 11 09 50 AM

Screen Shot 2020-03-13 at 11 10 04 AM

@alisonelizabeth alisonelizabeth added release_note:enhancement Feature:CCR and Remote Clusters v8.0.0 Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more v7.7.0 labels Mar 3, 2020
@elasticmachine
Copy link
Contributor

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

@alisonelizabeth alisonelizabeth changed the title [WIP] [Remote clusters] Add support for proxy mode [Remote clusters] Add support for proxy mode Mar 13, 2020
@alisonelizabeth alisonelizabeth marked this pull request as ready for review March 13, 2020 19:20
@alisonelizabeth
Copy link
Contributor Author

@gchaps do you think you could review the copy in the screenshots I included in the PR description? I also will need to work with you to update the remote clusters documentation. At a minimum, the screenshot should be updated.

Copy link
Contributor

@cjcenizal cjcenizal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fantastic, Alison! I tested locally and everything works as expected. Code looks impeccable. Great job!

export function deserializeCluster(name: string, esClusterObject: any): any {
import { PROXY_MODE } from '../constants';

export interface ClusterEs {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding these types! 😬

} = this.state;

let modeSettings;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great decision here, to allow for caching of the user's input if they flip between modes.

<FormattedMessage
id="xpack.remoteClusters.remoteClusterForm.sectionSeedsDescription1"
defaultMessage="A list of remote cluster nodes to query for the cluster state.
Specify multiple seed nodes so discovery doesn't fail if a node is unavailable."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we lose a bit of helpful information here. Can we move some of this content into the help text below the "Seed nodes" input, changing it to: "An IP address or host name, followed by the transport port of the remote cluster. Specify multiple seed nodes so discovery doesn't fail if a node is unavailable."

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point!

<h2>
<FormattedMessage
id="xpack.remoteClusters.remoteClusterForm.sectionModeTitle"
defaultMessage="Connection mode settings"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll defer to @gchaps if she disagrees, but I think this can be simplified to just "Connection mode", since technically everything in this form is a setting.

// If the cluster hasn't been stored in the cluster state, then it's defined by the
// node's config file.
const isConfiguredByNode = !isTransient && !isPersistent;

// Pre-7.6, ES supported an undocumented "proxy" field
// ES does not handle migrating this to the new implementation, so we need to surface it in the UI
// This value is not available via the GET /_remote/info API, so we get it from the cluster settings
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for these helpful comments.

skipUnavailable: schema.boolean(),
mode: schema.oneOf([schema.literal(PROXY_MODE), schema.literal(SNIFF_MODE)]),
seeds: schema.nullable(schema.arrayOf(schema.string())),
nodeConnections: schema.nullable(schema.number()),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did we miss this in the original NP migration? I'm going to make a mental note to pay extra attention to this when I'm doing my own migration work because it seems super-easy to overlook a missed validation during testing. It seems the only way for us to discover a missed validation is with thorough functional or manual testing, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually added support for defining node connections as part of this PR. It was always possible via the ES API, but we were previously only allowing users to define seeds in the UI (screenshot).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I missed that!

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

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

@alisonelizabeth
Copy link
Contributor Author

@gchaps I'm going to go ahead and merge this PR, but I can address any copy feedback in a follow-up PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:CCR and Remote Clusters release_note:enhancement Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more v7.7.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Remote clusters] Support for proxy mode
4 participants