-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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] Cloud deployment form when adding new cluster #93953
Conversation
Pinging @elastic/es-ui (Team:Elasticsearch UI) |
@yuliacech the Cloud team is actively working on adding several URLs to the |
💔 Build Failed
Failed CI StepsTest FailuresKibana Pipeline / jest / Jest Tests.x-pack/plugins/remote_clusters/public/application/sections/components/remote_cluster_form.RemoteClusterForm renders untouched stateStandard Out
Stack Trace
Kibana Pipeline / jest / Jest Tests.x-pack/plugins/remote_clusters/public/application/sections/components/remote_cluster_form.RemoteClusterForm proxy mode renders correct connection settings when user enables proxy modeStandard Out
Stack Trace
Metrics [docs]Module Count
Async chunks
Page load bundle
Unknown metric groupsmiscellaneous assets size
To update your PR or re-run it, just comment with: |
@yuliacech Here is some quick feedback. I'm wondering if we need a flyout for this since it is simply a single input? If we think this is the primary way users will enter this info, then let's default to this for the form. And then have a switch to If we need the flyout (and use a smaller sized flyout), I would suggest then using a button that is placed above the proxy input . I'm not sure if the current position of the link is visible enough as an action for the user. General thoughts on the flyout: Some thoughts on this form in general: I am happy to put together a quick wireframe if this feedback isn't clear. |
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.
Thanks for opening the ER!
A couple of comments:
- You used the Elastic Cloud logo while this should be relevant for ECE as well. Not sure if you want to display a different log depending on the platform or just go with text, in which case Elastic Cloud can fit both
- With the new flyout the information presented in the info message is confusing since we already guide users to copy-paste ES URL and show the note in case they use an alias
- I think the screenshot can be refined, specifically the size and red triangle
Will add comments about the text in the relevant parts
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.
Added a few text suggestions.
<p> | ||
<FormattedMessage | ||
id="xpack.remoteClusters.cloudDeploymentForm.formDescription" | ||
defaultMessage="If you're connecting to a Cloud deployment, you can copy and paste the Elasticsearch |
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 know this is cloud deployment (we don't support any other option) so I think the text can be more instructive.
Text suggestion: "Copy and paste the Elasticsearch endpoint URL of the remote deployment to automatically configure the remote cluster. The URL can be found on the remote deployment overview page."
<EuiFlexItem> | ||
<FormattedMessage | ||
id="xpack.remoteClusters.cloudDeploymentForm.formTitle" | ||
defaultMessage=" Add Cloud deployment as remote cluster" |
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 think it should be "Add Cloud deployment as a remote cluster", no?
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.
Also, should it say "Elastic Cloud"?
</strong> | ||
<FormattedMessage | ||
id="xpack.remoteClusters.cloudDeploymentForm.aliasNoteDescription" | ||
defaultMessage="If you configured a deployment alias in Elastic Cloud, |
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.
"If you configured a deployment alias, either in Elastic Cloud, in your reverse proxy or load-balancer, you will need to copy-paste the Proxy address and Server name or the remote deployment in the remote cluster form directly. These values can be copied from the Remote parameters section on the remote deployment Security page. More information is available here".
As you mentioned, we can't point to the relevant security page so I think we need to only keep the link to our user guide.
@shubhaat are we going to call this feature deployment alias or configurable deployment endpoints?
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 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.
Thanks @shubhaat !
Heads up @yuliacech @cjcenizal et al that when using the alias in the URL and changing the alias things will break. That's expected since changing the alias requires changing clients, integrations, etc. Just want to raise it in the context of a need to handle what happens when we can't connect to the cluster during and after creation.
One of the benefits of using a UUID is that it never changes.
Thanks for this info @ryankeairns! I was using |
Thanks a lot both for your great feedback, @mdefazio and @zanbel! I'd like to explore the idea of incorporating the cloud url input directly into the form. I'm wondering if we can force 'proxy mode' on Cloud to avoid having too many toggles (seed nodes vs proxy mode and cloud url vs address + server name). @juliocamarero Could you please weigh in on that? |
I think this is a good idea. We don't support any other mode other than the Proxy Mode on Cloud, therefore I think hiding and enforcing this mode will be a UX improvement. |
@yuliacech reposting the result of our convo on Slack here for visibility for the rest of the team. |
@yuliacech What will the UX be for someone who's editing a remote cluster that was originally configured to connect to a Cloud deployment? |
That's a great question, @cjcenizal! My assumption for editing a remote cluster on Cloud is that if I think what can be confusing for the user, is that when creating a cluster they type in something similar to |
@yuliacech If I understand you correctly, it sounds like you're describing a rule like this: "If the If so, have you verified with the ES engineers that this rule is an invariant? It'd be confusing if someone were able to configure an on-prem remote cluster that incidentally satisfies these criteria, and we end up showing them the wrong UI. :) |
@cjcenizal, yes that is the rule, but we only apply it when on Cloud similar to the 'add new cluster' view. So that the form looks the same for the user for both when adding and editing the cluster. When adding a cluster we default to the cloud url form and when editing we try to guess if they used the simple form to begin with. Does it make sense? :) |
@yuliacech What throws me off is that clusters on Cloud, ECE, and on-prem can all connect to one another as remote clusters. So when the user is logged into a Cloud deployment, there is no guarantee that the remote clusters they're configuring will be on Cloud as well. So even if we only apply this rule when the user is logged into a Cloud deployment, it seems like there will still be edge cases where this rule could be incorrectly applied.
Based on the above, this guess-based approach for editing seems prone to the undesirable UX I originally described. |
Hi @cjcenizal, I understand your concerns, but I didn't think clusters can connect with each other from different platforms. I discussed with @juliocamarero and he confirmed that only same environment clusters are supported right now for CCR/CCS (Cloud, ECE, on-prem). The default |
Thanks for clarifying @yuliacech! I'm not sure how I got the mistaken impression that remote clusters from different platforms were supported. @zanbel Was this something we discussed? Anyway, if only Cloud deployments are being connected to on Cloud, then my concerns aren't valid. Thanks for helping me clear that up. This leads me to another question though. Why do we need the rule you described? If all remote clusters will belong to the same platform that the user's Kibana instance is on, then we can we use the Cloud plugin to determine the platform the user is on, and therefore the platform that all remote clusters are on? |
@cjcenizal Thanks for asking such great questions! This definitely helped me learn a lot about Cloud :) |
OK, thanks @yuliacech! Could you please update the PR description with the information we've covered? This will document the edge cases and intended behavior which will help us test the PR's UX, verify that the code communicates intentions clearly, and if we ever need to do some forensic analysis it will give us a record of our decision-making to help us spot mistakes. The info I'm looking for is something like:
|
Closing this PR in favor of #94450 that implements the in-form solution. |
Summary
This PR adds a new flyout that helps configure a new remote cluster when on Cloud. The flyout has an input for the Elasticsearch endpoint url copied from the deployment page on Cloud. The url is then parsed and fields
proxy address
andserver name
are pre-filled in the main form.Screenshots
Screenshot
Gif
Mar-08-2021.16-39-57.mp4
How to test
When running Kibana locally add following values to
kibana.yml
file to simulate Cloud environmentRelease Note
When adding a remote cluster on Cloud, a new flyout with Cloud-specific instructions now helps pre-filling proxy connection values.